Stop Pretending Your EDR Is Perfect: The Case for Assumed Compromise Purple Teaming

TLDR: Most purple team exercises fail because they focus on finding vulnerabilities rather than testing detection visibility. By adopting an assumed compromise approach, teams can bypass the "vulnerability hunt" and directly test how security tools respond to specific adversary TTPs. This shift allows organizations to measure the actual effectiveness of their security stack against realistic, high-impact attack paths.

Security teams spend millions on defensive tooling, yet the industry remains obsessed with the wrong metrics. We run penetration tests to find vulnerabilities, and we run red team engagements to see if we can get popped. But when the dust settles, the most common question is: "Did the EDR catch it?" The answer is almost always a shrug, followed by a frantic scramble to check logs that weren't configured to capture the right telemetry in the first place.

The industry needs to stop treating purple teaming as a glorified vulnerability assessment. If you are still running exercises where the primary goal is to see if a red teamer can find a misconfigured S3 bucket or a weak password, you are missing the point. You are testing your hygiene, not your resilience.

The Assumed Compromise Shift

True purple teaming is about visibility, not vulnerability. An assumed compromise approach starts with a simple premise: the attacker is already inside. We give the red team the access they need to execute a specific TTP—a workstation, a domain user account, or even a foothold on a server—and then we watch the blue team’s reaction.

This methodology forces a direct evaluation of your detection engineering. When you remove the "how do I get in" phase, you stop wasting time on initial access and start focusing on the high-value, high-impact actions that actually matter during an incident. You are no longer testing if your patch management is up to date; you are testing if your Endpoint Detection and Response (EDR) or SIEM can actually identify a DCSync attack when it happens.

Testing the Under-the-Hood Mechanics

Consider a DC Sync attack. A red teamer might try to run this from a domain controller, only to be blocked by a Privileged Access Management (PAM) solution. They might then try it from a user workstation, only to have the binary flagged by EDR. If you stop there, you have learned nothing about your detection capabilities. You have only learned that your current tooling blocks specific, noisy binaries.

The real test is what happens when the attacker changes their approach. What if they use a custom tool, or a different process, or a SOCKS proxy to route traffic? The underlying activity—the Windows Event ID 4662, the specific RPC call to the DRSUAPI interface—remains the same. If your detection logic is tied to a specific binary hash or a known tool signature, you are failing.

To track these tests effectively, you need a framework that isn't just a spreadsheet. Tools like VECTR allow you to map these test cases directly to the MITRE ATT&CK framework. By documenting the red team's action and the blue team's detection (or lack thereof) in a centralized, collaborative environment, you create a feedback loop that actually improves your security posture over time.

Prioritizing Remediation by Tactic

When you run these exercises, you will inevitably end up with a wall of red and orange boxes. The temptation is to fix everything at once. Don't. Use the data to prioritize based on the kill chain.

We always read the kill chain from left to right. As an attacker moves further down the chain, the signal-to-noise ratio usually improves, but the impact of a successful detection becomes critical. If you are failing to detect lateral movement or exfiltration, you have a much bigger problem than a failure to detect initial reconnaissance.

Focus your remediation efforts on the tactics where your visibility is lowest. If your EDR is blind to process injection or credential dumping, that is where you spend your engineering hours. Do not waste time tuning alerts for low-impact, high-noise events until you have covered the gaps in your core detection coverage.

The Future of Defensive Resilience

Defenders often fall into the trap of thinking they need to be perfect 24/7. We know that's impossible. An attacker only needs to be right once. By flipping the burden of perfection, you stop trying to block every possible attack vector and start focusing on the ones that pose the highest risk to your specific environment.

If you are a security researcher or a pentester, stop just handing over a report of "found vulnerabilities." Start working with your blue team to build these assumed compromise scenarios. Ask them what they are blind to. Then, show them exactly what that looks like in their environment.

The goal of a high-value purple team is not to prove that the red team is smarter than the blue team. It is to prove that the organization can identify, contain, and eradicate an adversary before they reach their objective. If you aren't testing your detection logic against the actual, underlying activity of an attack, you aren't testing your defenses—you're just checking boxes. Stop the noise, start the collaboration, and build a program that actually makes it harder for an attacker to win.