A junior consultant asked us last month why we bother with red team engagements at all anymore. Their reasoning: EDR catches Cobalt Strike beacons on disk, SIEM correlation rules fire on lateral movement, and every enterprise has at least one threat-hunting team poking at telemetry. So what’s left for an operator to do that a vuln scan plus a tabletop exercise can’t cover?
The answer is the part that was always the actual job. The part that got buried under a decade of operators dropping public payloads, getting a beacon, pivoting once, and calling it a critical finding. That version of red teaming is dead. Good. It should have died sooner.
The thing that died
For most of the 2010s, you could run a competent-looking red team engagement with a checklist that fit on an index card. Phish a user with a macro doc. Land a default Cobalt Strike beacon. Run BloodHound. Kerberoast a service account with a weak password. Pass the hash to a file server. Screenshot the domain admin token. Write a report. Invoice.
That worked because the defensive stack was AV signatures and Windows Event Log forwarding to a SIEM that nobody read. The operator’s tradecraft did not have to be good. It had to exist. The findings wrote themselves because the environment was a greenhouse.
Three things changed that, in roughly this order. EDR vendors learned to hook user-mode APIs and correlate process lineage, so default tooling started getting caught at execution rather than at egress. Identity providers (Entra, Okta, Ping) started emitting useful sign-in telemetry, so the easy credential-replay paths started lighting up dashboards. And SOC teams, at least the ones that hired detection engineers, started writing rules that fired on behavior (T1003.001 LSASS access, T1558.003 Kerberoasting, T1021.002 SMB admin shares) rather than on hashes.
The lazy red team did not adapt. It kept submitting the same report. The findings section got thinner because Defender was eating the payload before the operator could pivot, and the operator’s response was to ask the client to add an AV exclusion for the working directory. We have seen this in scoping calls. It is embarrassing.
If your red team’s working theory is “please disable EDR for the duration of the test,” you are not buying a red team. You are buying an internal vulnerability scan with extra steps.
What still breaks (and why detection still matters)
Here is the part the EDR-killed-red-teaming crowd misses. Modern offensive work still finds things. The categories have shifted, the tradecraft has gotten more expensive, and the report looks different, but every engagement we run produces a path that the client’s existing controls did not catch. A non-exhaustive list of where value still lives:
- Initial access through identity, not endpoints. OAuth consent phishing (T1528), device-code phishing against Entra ID, session token theft from browser process memory, help-desk social engineering to reset MFA. The endpoint never sees a payload. The EDR has nothing to hook. The detection lives in identity logs, and most SOCs are still tuning email rules instead.
- Misconfiguration chains in cloud and SaaS. Overprivileged service principals, federation trusts that span tenants, GitHub Actions workflows with secrets in environment variables, S3 buckets that are private but accessible to a Lambda that is not. CSPM catches the static state. It misses the chain.
- Identity path exploitation post-foothold. Certificate-based persistence (ESC1, ESC8 via AD CS), shadow credentials (T1556.007), abused delegation (T1558.004 / unconstrained delegation), Entra ID role abuse. The blue team has Sysmon. They do not have a Tier 0 access model.
- Supply-chain-adjacent paths inside the client’s perimeter. Internal package registries with weak auth. CI/CD runners with overscoped tokens. SCM tokens in build logs. The path from a developer laptop to production was always shorter than the architecture diagram claimed.
- Custom tradecraft against tuned EDR. Direct syscalls, indirect calls via legitimate signed binaries, in-process execution without new process creation, hardware breakpoint bypasses for AMSI. We do not publish these here. The point is that they exist, the client paid for someone to develop them, and the EDR did not stop them.
None of these are theoretical. All of them have ATT&CK IDs. All of them produce telemetry somewhere in the stack. The question for the SOC is whether the path is detected, and what would have to change for a miss to become a catch.
The purple loop
This is where the value shifted. The deliverable that matters now: what the operator did, what the defender saw, what the defender missed, and what detection rule closes the gap.
One worked example. A few engagements ago, the operator established persistence on a workstation using a scheduled task that ran a signed LOLBin to load a payload from a UNC path on an attacker-controlled internal share. ATT&CK T1053.005 plus T1218 plus T1105. The EDR generated a process-creation event for the LOLBin. The SIEM had no rule that cared. The file share access generated an SMB connection event that nobody was looking at. The scheduled task creation generated a Windows Event ID 4698 that was being collected but not correlated.
The detection breakdown looks like this:
| Technique | What EDR saw | What it missed | Log source to fix |
|---|---|---|---|
| T1053.005 (Scheduled Task) | Task creation event, no alert | Task references a UNC path with a non-standard share name | Windows Event 4698, parse XML body, alert on UNC in action |
| T1218 (Signed Binary Proxy) | Process lineage logged | Parent-child anomaly: scheduled task spawning signed binary loading remote content | EDR process telemetry plus behavioral rule on remote payload load |
| T1105 (Ingress Tool Transfer) | SMB session established | No rule on workstation-to-workstation SMB on a port other than file server VLAN | Network flow / Zeek plus identity context on the source host |
The client had every log source: EDR, Windows Event Forwarding, and network flow. The gap was a detection engineer who had seen the technique recently enough to write the correlation. That is what a modern red team is selling against: three techniques executed, three log sources that saw them, one detection rule that would have fired. The finding is the rule.
Why the quarterly checkbox engagement dies
The other thing that changed is that the executive sponsor finally has good questions. The CISO who signs the SOW now wants to know what the SOC did during the engagement, not just what the operator found. They want timelines: when did the first alert fire, did anyone triage it, how long until the operator was contained, what was the dwell time on each foothold.
Quarterly point-in-time red teams (but especially penetration tests and vulnerability assessments) do not answer this. By the time the report is delivered, the SOC analyst who saw the alert has rotated off shift, the detection rule has been tuned (or muted), and the operator’s path is patched. The findings exist as a historical artifact. They do not change tomorrow morning.
The model that replaces it is some flavor of continuous validation. Call it assumed-breach exercises, purple days, ongoing detection engineering with operator support, or the unfortunate vendor word “BAS plus.” The shape is the same: short engagements (one to three weeks), narrow scope, detection-focused deliverable, and a feedback loop that turns each miss into a new rule or hunt within the same quarter. The operator’s job is to feed the SOC, not to compete with it.
This also kills the dynamic where the operator hides their tradecraft to make the report look better. If the deliverable is “techniques tested, detections built,” the incentive flips. The operator wants the SOC to catch things, because every catch is evidence the engagement worked. The misses are still valuable, but they are framed as “here is the gap, here is the rule, here is the hunt to validate it in your environment.”
The numbers that mean something after a modern red team
If you are running a SOC and your red team report still leads with a CVSS-weighted list of findings, you are buying the wrong product. The numbers that mean something after a modern red team are:
- Mean time to first alert per technique tested. Not the median across the engagement. Per technique.
- Coverage percentage against the techniques actually used, mapped to ATT&CK. If the operator used twelve techniques and you alerted on four, that is your starting baseline.
- Time from alert to triage to containment, measured on the alerts that fired. This is the SOC’s number, not the operator’s.
- Rules built or tuned as a direct result of the engagement, with a follow-up validation date thirty to sixty days out.
- Hunt hypotheses generated for the techniques that did not alert, with owners and a due date for the hunt being run.
None of these require a new tool. They require the report to be structured around the SOC’s workflow rather than around the operator’s ego.
What we’d do this week
- Pull your last red team report. Count how many findings map to an ATT&CK technique ID. If that number is under half the findings, your next engagement scope should require ATT&CK mapping in the deliverable.
- For every technique in that report, write down what log source would have caught it and whether you are currently ingesting that source. The gap between “could detect” and “do detect” is your detection engineering backlog.
- Schedule a purple-team half-day with whoever ran your last engagement. Agenda: replay the three techniques that did not alert, build one detection rule together for each, commit to a validation date.
- Stop measuring red team value in criticals. Start measuring it in detections built and hunts generated. Tell your next vendor that is the deliverable you want before they scope.
- If your current red team partner pushes back on detection-focused reporting or asks for EDR exclusions to “make the test fair,” get a different partner.
Modern EDR raised the floor on tradecraft and forced the operator’s deliverable to align with what the SOC can actually use. Offensive work that makes defenders better was always the goal. The detection-per-technique report shape is what that looks like in practice.
