Blue Team Con 2026

Active Directory Domain Services has been around for 26 years, making it far from a young technology - yet it is not going anywhere anytime soon. Most companies still rely on Active Directory as their primary identity provider and management solution. One might assume that after all these years we have already mastered securing Active Directory with best practices. However, the reality is often the opposite: many AD environments are still poorly secured, which keeps them a common target for attackers.
In this talk, I will demonstrate three important vulnerabilities that still exist in Active Directory and are either unknown or not discussed enough. We will challenge a few assumptions along the way:

• If an account is locked out, can you still brute-force its password?
• If a user is in Protected Users, is the NT hash truly out of reach?
• When you use RDP (MSTSC), does it cache more than just fragments of your screen?

By the end of the session, you will learn that some common assumptions are wrong and that you must always test and verify security controls in practice. You will also leave with practical mitigations and best practices to secure your environment against these vulnerabilities and reduce their impact.

Container security is one of those topics that sounds solved. We've got image scanning. We've got runtime policies. We've got Kubernetes RBAC. So why are containers still showing up as the initial access vector in breach reports year after year?


Because most of our tooling is looking at the wrong things at the wrong time.


This talk is about shifting container threat hunting from reactive to genuinely proactive, not by buying another tool, but by understanding what behavioral signals containers are already producing and building detection logic around those signals.


I've spent years running Kubernetes at scale in production environments, managing security for platforms that can't afford downtime and can't afford breaches. What I've learned is that containers are actually quite chatty. Syscall patterns, network connection behavior, image layer anomalies, runtime drift. They tell a story. The problem is most teams aren't set up to read it.


In this session, I'll cover:


- The most common gaps between what container scanning tools report and what's actually happening at runtime
- Behavioral indicators that predict compromise before it escalates, drawn from real incident data
- How to build a lightweight threat hunting workflow using open-source tooling (Falco, eBPF-based detection, and custom OPA policies) that doesn't require a six-figure budget
- A demo of an open-source AI-powered Docker security analyzer showing how AI-assisted analysis can surface vulnerabilities that static scanners consistently miss


The demo portion will be hands-on. We'll start with a "clean" container environment that passes standard scanning, introduce an attack scenario, and then walk through how behavioral hunting catches what the scanners don't.


By the end, you'll have a practical hunting framework, a set of detection rules you can implement immediately, and a better mental model for where container defenses actually break down in the real world.


This is for defenders who are tired of being told their container stack is secure, and then watching alerts prove otherwise.

Defenders have deployed honeypots and honeytokens to detect threats targeting GCP workloads. The dynamic and ephemeral nature of cloud workloads with the resource-based policy model in GCP introduces unique characteristics that influence the design of deception. Defenders need to determine answers to questions such as: how many deceptions to deploy, what should they represent, how many of each type, how should these be named, where should the deceptions be placed? This session provides real-world insights from a security practitioner on the design of a deception strategy for cloud workloads that spans honeytokens (GCP IAM service accounts, GKE service accounts) and honeypots (compute instances, storage, pods).

Microsoft Entra environments rely heavily on implicit trust in Microsoft first-party applications, yet most defenders have limited visibility into how expansive that trust boundary truly is. With more than 4,000 Microsoft first-party app IDs, many operate as “ghost” applications: active in authentication and token issuance, but not clearly represented in enterprise application views or routinely monitored by defenders. This creates a significant blind spot in identity security.
This session explores how these trusted applications can be abused through Resource Owner Password Credentials (ROPC), Family of Client IDs (FOCI), and token issuance behaviors that extend access beyond what defenders typically expect. Rather than focusing on generic anomalous sign-ins, the talk centers on capability: the delegated scopes these applications request, the permissions they inherit, and how those access paths can be leveraged to persist and expand access within a tenant. These behaviors can be executed through standard Graph API interactions and demonstrate how ROPC can be leveraged to obtain tokens without interactive authentication and, in many real-world environments aligned with historical Microsoft guidance, results in effective MFA bypass conditions.
Attendees will learn how ROPC remains relevant in modern identity attacks, how first-party application trust complicates Conditional Access enforcement, and why policy evaluation differs between interactive and non-interactive authentication paths. The session also examines token lifecycle in depth, including how refresh tokens can persist for extended periods, how Continuous Access Evaluation (CAE) impacts enforcement, and why resetting user credentials does not necessarily revoke active access without additional token invalidation steps.
From a defensive perspective, this talk provides practical, immediately usable guidance. It includes KQL queries specifically designed to identify ROPC authentication activity, enumerate first-party application usage, and help defenders understand which client applications are requesting access and with what scope. It also covers Conditional Access policy considerations, validation techniques, and response actions to take during identity incidents involving token abuse.
A companion GitHub repository is included with ready-to-use KQL queries, detection logic, and example configurations. Attendees will leave with a concrete understanding of how first-party application trust can be abused, where visibility and enforcement gaps exist, and how to build effective identity-focused detection and response workflows in Microsoft Entra.

Most penetration test reports get filed and forgotten. SOC teams never confirm whether their alerts fired during the engagement, and adversaries keep reusing the same techniques. This session shows blue teamers how to digest a penetration test report and turn every pentest finding into a working detection.
We'll break down pentest reports from the SOC's perspective, focusing on the methodology sections where attacker behavior is documented with command line invocations, tooling, and attack narratives. We'll cover what artifacts to require from testers before the engagement begins, including timestamped command logs, source and target IPs, compromised accounts, and MITRE ATT&CK technique IDs.
Attendees will leave with a repeatable feedback loop for transforming pentest results into measurable detection improvements, supported by tools like Sigma, Atomic Red Team, VECTR, and Caldera.

The most critical stage when using offensive security to improve defenses comes after obtaining leadership approval for a testing exercise. Current industry definitions have significant overlap, with the same term used to describe different underlying services, and with the added complication of AI-based offensive tools. Overshadowed by years’ worth of penetration tests exploiting the same set of techniques, or red teamers waltzing through the front door, driving lasting and impactful security improvements based on testing results continues to become less straightforward.


As an industry, we have accepted that using offensive testing is a good way to find gaps in our defenses. However, less attention is given to whether the type of testing chosen actually helps to systematically fix the gaps identified. This leads to problems like:

1. Penetration tests continuing to surface the same class of findings as previous years, or the same finding in a different location.
2. Organizations paying for advanced red team exercises while not having implemented foundational security controls.

The types of problems mentioned above arise because defenders often select offensive testing solutions based on the service "name". This leads to a mismatch between the type of offensive testing conducted and the defensive technologies that need to be validated. 


In this session, I will first provide a framework for defenders to categorize types of offensive security testing based on what their security controls will be tested against (attacks vs. adversaries) and how they will be tested (emulation vs. simulation). This framework helps defenders to:

1. Understand what the core value proposition of each offensive security service is, independent of what terminology is used to describe it.
2. Work bottom-up from the defenses you have to identify the most appropriate testing methodology.

Next, I will demonstrate how to use this model within attendees’ organizations to plan out an offensive testing program based on their threat model, security goals, and maturity. 


The goal of this session is to encourage attendees to think about offensive security from a new standpoint. By introducing a framework to categorize offensive testing methodologies with a primary focus on the security controls being validated, defenders will understand how to distinguish between the various offensive security services on the market, select the most appropriate solution for their organization, and progress between offerings as their security program matures.