Letthemin: Facilitating High Value Purple Teams Using Assumed Compromise

Letthemin: Facilitating High Value Purple Teams Using Assumed Compromise

Speakers: Sarah Hume, Purple Team Service Lead, Security Risk Advisors

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=xM8nodIw1_E

Overview

In this DEF CON talk, Sarah Hume, Purple Team Service Lead at Security Risk Advisors, introduces a unique and highly effective strategy for conducting purple team engagements: the assume compromise approach. This methodology challenges traditional security testing paradigms by shifting the focus from proving initial access or exploiting vulnerabilities to rigorously evaluating the efficacy of an organization's existing security tools and controls. Hume argues that by intentionally bypassing early-stage attack vectors and assuming an adversary has already achieved a certain level of access, security teams can gain unparalleled insights into their defensive capabilities against sophisticated, late-stage threats.

Hume's extensive experience leading hundreds of threat intelligence-based purple team engagements for Fortune 500 and Global 1000 companies underpins this approach. She advocates for a collaborative, open-book environment where red and blue teams work side-by-side to test defenses, fostering communication and collective improvement rather than blame. The core value proposition is to provide a "brutally honest" assessment of security tools, uncover hidden detection gaps, and ultimately enhance an organization's resilience by focusing on the fundamental activities of an attack, regardless of the specific execution method.

Background

▶ Watch: Introduction to high-value assumed compromise purple teams (0:00)

To set the stage for her "assume compromise" methodology, Sarah Hume first clarifies what purple teams are and, crucially, what they are not. A purple team engagement, as defined by Hume, is a collaborative workshop where red and blue teams execute attacks side-by-side in an open-book format. Unlike traditional red teaming, which operates in a black box to assess incident response, or penetration testing, which broadly hunts for vulnerabilities, purple teaming focuses on demonstrating adversary techniques and directly observing how security tools respond. This collaborative environment is designed to bring together diverse blue team departments—from SOC analysts to infrastructure and AD teams—to foster communication and develop robust detections. The test plan is derived from threat intelligence, prioritizing a subset of the MITRE ATT&CK framework to evaluate security tool effectiveness.

Hume explicitly differentiates purple teaming from other security assessments. It is not Breach and Attack Simulation (BAS) solutions, which she argues often fall short due to limitations like requiring security tools in audit mode, simulating thousands of techniques from a single process (leading to unrealistic correlations), and lacking the authenticity of a human attacker. While BAS tools have a place for control validation, they cannot replace the nuance and adaptive nature of a purple team. Similarly, purple teams are distinct from red teams, which aim to avoid detection and assess incident response, and penetration tests, which are noisy, broad vulnerability hunts not concerned with stealth or realistic attack emulation.

The concept of an assumed compromise or assumed breach traditionally involves giving testers a baseline level of access, such as an internal network workstation and a domain user account, without first proving they could achieve that access. Hume takes this concept significantly further. She introduces the term Adversary PEMDAS to describe the order of operations an attacker follows during a breach, akin to a kill chain or framework. Her twist on assumed compromise involves not only granting initial access but also making broader assumptions about an adversary's capabilities and even the potential failure of specific security controls, allowing teams to focus on deeper detection layers.

Key Findings

▶ Watch: Defining the assumed compromise approach (3:30)

The central tenes of Hume's talk revolve around several key findings that underpin her high-value purple team approach. The most significant discovery is the power of focusing on visibility, not vulnerability. By adopting an assume compromise mindset, organizations intentionally bypass the initial stages of an attack chain, such as phishing or exploiting external vulnerabilities. This allows the purple team to concentrate on evaluating whether expensive security tools are truly detecting or preventing critical, late-stage adversary activities, rather than getting bogged down in proving initial access. Hume emphasizes that other assessments, like penetration tests, are better suited for finding vulnerabilities. Purple teams, under this model, become the primary mechanism for understanding the true success, limitations, and opportunities for improvement within an organization's security stack.

Another critical finding is the importance of testing against the underlying activity of an attack, rather than getting fixated on specific procedures or procedure variants (TTPVs). Attackers constantly adapt their methods, payloads, and command and control channels. While a security team could attempt to build controls for every conceivable variant of an attack, Hume demonstrates that this is an unsustainable and ultimately futile effort. Instead, by identifying the fundamental, immutable actions an attack performs—such as specific Windows Event IDs or RPC calls—defenders can create more robust and future-proof detections. This approach ensures that even if an adversary changes their tools or execution methods, the core defensive controls designed around the underlying activity will still hold firm.

Finally, Hume highlights the value of continuous testing and a structured scoring methodology to drive ongoing improvement. She introduces a scoring system that counts successful detections/preventions but does not penalize for unsuccessful tests, fostering an environment free from blame. The Vector platform, or similar tracking tools, is used to visualize results against the MITRE ATT&CK framework, allowing teams to prioritize remediation efforts at the tactic level (e.g., focusing on early-kill chain tactics first) or by specific security tool. Regular engagements enable historical comparisons, demonstrating tangible security improvements over time and proactively identifying regressions, such as detection rules being inadvertently disabled. This systematic approach transforms purple teaming from a one-off assessment into a continuous feedback loop for enhancing an organization's security posture.

Technical Deep Dive

▶ Watch: Speaker's definition of a high-value purple team (4:00)

The technical core of Sarah Hume's "assume compromise" approach is best illustrated through a detailed example: the DC Sync attack. This technique, often executed via tools like Mimikatz, allows an attacker to extract domain user credentials by abusing the legitimate replication activity that domain controllers use to stay synchronized. An adversary with replication rights (typically a Domain Admin account) can trick a legitimate domain controller into sending them credentials for any account on the domain. The severe impact of such an attack, enabling an attacker to simply log in as any user, underscores the critical need for robust detection.

Hume proposes testing this scenario by giving the red team a Domain Admin account from the outset, directly embodying the "assume compromise" principle. This bypasses the often-lengthy and complex process of privilege escalation, allowing the team to directly test defenses against the DC Sync itself. The talk then explores various hypothetical attempts an adversary might make to execute a DC Sync, demonstrating why focusing on underlying activity is paramount:

1. From a Domain Controller: An attacker attempts to run the attack directly on a compromised domain controller, only to be blocked by a Privileged Access Management (PAM) solution.
2. From a User Workstation (Mimikatz on disk): The attacker tries to extract credentials using Mimikatz dropped directly onto disk, which is immediately caught and eaten by the Endpoint Detection and Response (EDR) solution.
3. From a Command and Control (C2) Channel (Cobalt Strike): The attacker sets up a C2, such as a default Cobalt Strike beacon, but it's blocked by the next-gen firewall.

These initial failures might lead a team to prematurely conclude they are "blocked." However, Hume challenges this, posing crucial "what if" scenarios:

• Rogue Workstation: What if an adversary adds a rogue workstation to the domain without security tools?
• Physical Breach: What if an attacker physically breaks into the office and plugs their machine directly into the network?
• Insider Threat: What if an insider threat has months to plan and execute?
• Direct RPC Calls: What if the attacker makes direct RPC calls from a SOCKS proxy or C2, bypassing network traffic signatures?
• Linux Server: What if the attack originates from a compromised Linux server, where antivirus solutions might be less robust or non-existent?
• Novel Payload: What if the attacker uses a previously unseen payload?
• EDR Exclusions: What if the organization's EDR has a long list of exclusions, or local admin privileges are too widespread, allowing an attacker to disable or bypass EDR protections?

Hume emphasizes that while these are all different procedures or procedure variants, the underlying activity of a DC Sync attack remains constant. Regardless of how the attack is executed, it will always:

• Take an action upon a directory service object, generating Windows Event ID 4662.
• Contain a specific GUID string associated with replication activity within that event.
• In network traffic, the RPC call will always bind to the same interface and execute the same function.

This crucial insight leads to the next technical step: assuming compromise of your tools. Instead of hoping a compensating control (like a firewall or EDR) prevents the initial stages, the purple team focuses on the specific defensive tool responsible for detecting the underlying activity. For DC Sync, the primary areas under test would be the Security Information and Event Management (SIM) system and the Identity Threat Protection (ITP) tool, as these are designed to monitor directory service object access. While compensating controls are valuable and should be documented, the direct testing isolates the core detection capabilities.

The process involves selecting 25 to 70 threat intelligence-driven use cases (not full MITRE ATT&CK coverage), isolating a single security area under test for each, and then scoring the outcomes. Successful outcomes are defined as a security tool or secure configuration preventing or detecting the attack. Hume stresses that the scoring avoids the concept of "failure" to foster a collaborative, blame-free environment. The results, tracked in tools like Vector, are then analyzed at the tactic level (e.g., prioritizing left-kill chain tactics) and by individual security tool to identify strengths, weaknesses, and prioritize remediation efforts. Automation, where used, is carefully applied to maintain attack authenticity, with examples like Mythic C2 and custom Jupyter notebooks for automated testing.

Demo / Proof of Concept

▶ Watch: What purple teams are NOT: avoiding BAS pitfalls (5:55)

While Sarah Hume's talk did not feature a live, interactive demonstration in the traditional sense, she effectively walked the audience through a theoretical proof of concept using the DC Sync attack example. This simulated demonstration served to illustrate the core tenets of her "assume compromise" methodology and the critical importance of focusing on underlying attack activities rather than superficial procedures.

The scenario began with the red team being granted a Domain Admin account, immediately putting them in a privileged position to execute the DC Sync attack. This "assumed compromise" allowed the purple team to bypass the initial stages of a typical attack chain and directly test the organization's ability to detect this high-impact, late-kill chain activity. Hume then presented a series of hypothetical attempts an attacker might make, and how an organization's existing security controls might react:

1. Attempt 1: Direct Execution from a Domain Controller. The attacker tries to run the DC Sync command directly on a domain controller. The hypothetical outcome: Blocked by a Privileged Access Management (PAM) solution. This highlights a compensating control, but not necessarily a detection of the DC Sync itself.
2. Attempt 2: Mimikatz on a User Workstation. The attacker moves to a user workstation, attempts to drop Mimikatz onto disk, and execute it. The hypothetical outcome: The Endpoint Detection and Response (EDR) solution immediately catches and quarantines Mimikatz. Again, a successful block, but it's a block on the tool, not necessarily the underlying replication activity if Mimikatz were somehow bypassed.
3. Attempt 3: Cobalt Strike Command and Control. The attacker establishes a Cobalt Strike beacon and attempts to execute the DC Sync through it. The hypothetical outcome: The next-gen firewall blocks the default Cobalt Strike traffic. This demonstrates another layer of defense, but again, tied to a specific C2 and its signature.

These initial "failures" for the red team are where Hume's methodology truly shines. Instead of declaring victory, she forces the audience to consider the myriad of ways an intelligent adversary would bypass such controls. She posed scenarios like:

• An attacker adding a rogue workstation to the domain, devoid of security tools.
• A physical breach where an attacker plugs directly into the network.
• An insider threat who has had months to craft a unique execution method.
• The use of direct RPC calls from a SOCKS proxy or non-signatured C2, bypassing network traffic analysis.
• Execution from a compromised Linux server, where EDR/AV coverage might be weak or non-existent.
• The use of a previously unseen payload, bypassing signature-based detections.
• Exploiting EDR exclusions or widespread local administrator privileges to disable or circumvent security agents.

The core "demonstration" here is not just about showing how an attack works, but how many ways it can work, and how critical it is to look beyond the specific "procedure" to the immutable "underlying activity." Hume's point is that while an attacker can tweak their approach with countless procedure variants (TTPVs), the fundamental action of a replication attack—such as generating Windows Event ID 4662 with a specific GUID for replication activity, or making a specific RPC call—will always be the same. This insight is the true proof of concept: by shifting the focus to these underlying activities, defenses become resilient to the ever-changing landscape of attacker tools and methods.

Defensive Implications

▶ Watch: Distinguishing purple teams from red teams and pentests (6:45)

The "assume compromise" approach offers profound defensive implications for organizations aiming to build true resilience against adversarial threats. Sarah Hume outlines several actionable strategies that defenders can implement based on this methodology:

1. Prioritize Visibility Over Vulnerability: The most critical implication is to reframe security testing. Instead of solely focusing on finding vulnerabilities (which pentests do) or assessing incident response (red teaming), organizations should dedicate purple teams to rigorously testing the visibility and efficacy of their security tools. This means intentionally bypassing early kill chain stages to ensure that defenses can detect or prevent late-stage, high-impact activities, regardless of how an attacker initially gained access. This provides a "brutally honest look" at tool performance.

1. Focus on Underlying Activity, Not Procedure Variants: Defenders should shift their detection engineering efforts from creating signatures for specific tools or attack procedures (e.g., a specific Mimikatz binary) to identifying and alerting on the fundamental, atomic actions an adversary must take. For instance, instead of just blocking known C2 domains, focus on detecting the RPC calls or Windows Event IDs (like 4662 for directory service object access with its specific GUID for replication) that characterize a DC Sync attack, irrespective of the C2 used or the host it originates from. This strategy provides future-proofness, ensuring detections remain effective even as adversaries evolve their tools and methods.

1. Assume Compromise of Compensating Controls: A radical but effective defensive posture is to assume that initial layers of defense (e.g., email gateways, firewalls, EDRs) will eventually be bypassed. This allows security teams to isolate and test the "area under test" directly relevant to the attack's underlying activity. For a DC Sync, this means rigorously testing the SIM and Identity Threat Protection tools, without relying on EDR or network firewalls to catch the initial infection vector. While compensating controls are valuable and should be documented, they should not be the sole focus of detection validation for a specific technique.

1. Structured Scoring and Prioritized Remediation: Implement a clear scoring methodology where successful detections or preventions contribute positively, but unsuccessful tests do not count negatively. This fosters a blame-free environment essential for collaboration. Utilize tools like Vector to track results against the MITRE ATT&CK framework. Remediation efforts should then be prioritized systematically:

• By Tactic: Analyze results at the tactic level, prioritizing improvements for left-kill chain activities first, as these offer the highest signal-to-noise ratio for early detection and eradication.
• By Tool: Identify which security tools consistently underperform and prioritize their tuning or replacement.
• Historical Comparison: Conduct purple team engagements on a regular interval (e.g., quarterly) to track improvements over time, validate new controls, and identify regressions (e.g., alerts being inadvertently disabled, as Hume describes the common scenario of an alert being created, then turned off due to noise, and never reactivated). This continuous testing is crucial for ensuring expected security behaviors are maintained.

1. Foster Collaboration and Communication: The "assume compromise" purple team is inherently a collaborative workshop. Defenders should actively involve all relevant blue team departments—SOC analysts, infrastructure, Active Directory, networking teams, etc. This cross-functional engagement breaks down silos, allows different teams to understand the adversary's POV, and facilitates joint problem-solving for detection and response. The open-book format encourages free discussion without fear of blame, leading to more robust and integrated defensive strategies.

Ultimately, Hume's methodology aims to "flip the burden of perfection" from the defender to the attacker. Instead of trying to prevent every single action an adversary might take, the goal is to find "every possible place that we can to add that new control that might allow us to identify and eradicate an adversary." It's about breaking the kill chain at multiple points, assuming controls will fail, assuming adversaries will find a path, and continuously learning from each other to gain true resilience to adversarial threats.

Key Takeaways

• Prioritize Visibility, Not Vulnerability: High-value purple teams focus on evaluating security tool efficacy against late-stage attacks by assuming initial compromise, rather than proving initial access.
• Focus on Underlying Activities: Design detections around the fundamental, immutable actions of an attack (e.g., specific Windows Event IDs, RPC calls) rather than changeable procedures or tools, ensuring future-proof defenses.
• Assume Compromise of Tools: Rigorously test specific security tools by intentionally bypassing upstream compensating controls (e.g., assume an EDR is bypassed when testing SIM for a specific threat).
• Embrace Collaborative, Blame-Free Testing: Conduct open-book engagements involving all blue team stakeholders, using a scoring system that eliminates "failure" to foster communication and continuous improvement.
• Implement Continuous, Threat-Intelligence Driven Testing: Regularly run purple teams with threat-intelligence-based test plans, using tools like Vector to track progress, prioritize remediation by tactic and tool, and validate controls over time.
• Flip the Burden of Perfection: The goal is to find every opportunity to add controls that can identify and eradicate an adversary, breaking the kill chain at multiple points, rather than attempting to prevent every single attack step.

About the Speaker(s)

Sarah Hume is the Purple Team Service Lead at Security Risk Advisors. With over seven years of experience, she has led hundreds of threat intelligence-based purple team engagements for numerous Fortune 500 and Global 1000 organizations. Her background is firmly rooted in offensive security, having previously specialized in network penetration testing, IT/OT systems penetration testing, and even occasional physical penetration tests. This offensive background provides her with a unique and valuable perspective on adversary tactics, techniques, and procedures, which she now leverages to help organizations build more robust defenses. Hume is a passionate advocate for collaborative security approaches and regularly contributes to the cybersecurity community, as demonstrated by her talk at DEF CON's Adversary Village.