Purple Teaming Guide: Adversary Emulation and Detection Validation

Most security operations teams cannot say, technique by technique, which attacker behaviours they would actually see, and red team reports alone rarely change that. Purple teaming closes the gap by putting attackers and defenders in the same room: the red side runs a known behaviour, the blue side checks what was logged, alerted and triaged, and both fix the gap before moving on. This guide goes deeper than the purple teaming section of the Red Teaming Guide. It covers purple team engagement models, planning, emulation plans and atomic tests, a test case template, detection gap tracking, reporting, metrics and continuous or automated purple teaming. It is written for SOC leads, detection engineers, red team operators and security managers who commission or run purple team work. It contains no attack commands or test syntax.

Key takeaways

• Purple teaming is a collaboration, not a third team. EU Delegated Regulation 2025/1190 defines it as "a collaborative testing activity that involves both the testers and the blue team"; the value comes from running a behaviour and inspecting the defence immediately.
• Every test case needs an expected result. Before a technique runs, write down the telemetry, the alert and the analyst action you expect. The gap between expected and observed is the finding.
• Classify gaps precisely. "Not detected" hides four different problems: no telemetry, no analytic, an alert nobody triaged, or a response that failed. Each has a different owner.
• Emulation plans keep tests honest. Build sessions from intelligence on adversaries that target you, using sources such as the MITRE Center for Threat-Informed Defense emulation library, not from whatever the operator knows best.
• Continuous beats annual. A small recurring cycle of tests, fixes and regression runs, partly automated, protects detections that silently break when logging, agents or rules change.

What purple teaming is, and what it is not

A red team emulates an adversary; a blue team (blue teaming) is the defensive function, usually the SOC, incident response and detection engineering, that monitors, detects and responds. Purple teaming is the red and blue team collaboration where both work openly toward the same goal: better detection and response. The TIBER-EU Purple Teaming Best Practices (January 2025) describe it as "a form of a collaborative activity" involving the red team testers and blue team, aimed at jointly pinpointing weaknesses in protection and detection and improving people, process and technology.

The term covers two things. A purple team exercise or purple team engagement is a time-boxed event. A purple team approach or function is a standing way of working in which offensive specialists and detection engineers share a backlog. Both are distinct from the following:

Purple team vs red team: a red team measures whether defenders notice an unannounced attack; a purple team assumes they might not and fixes that, technique by technique. Purple team vs penetration test: a penetration test asks what is exploitable; a purple team asks what the SOC would see if it were exploited. Red team results feed purple teaming; purple teaming outputs feed the next red team. For red team scoping and governance, stay with the parent guide.

Purple team engagement models

The TIBER-EU document adds a format the parent guide does not cover: the war game, where red and blue each know the other's goals, for example capturing flags versus protecting critical assets. Under DORA, Article 12(5) of Delegated Regulation 2025/1190 requires the blue team and testers to "replay the offensive and defensive actions performed during the TLPT" and the control team to "conduct a purple teaming exercise on topics jointly identified". By contrast, the Bank of England's CBEST implementation guide (2024 edition) does not prescribe purple teaming; its detection and response assessment relies on "post-testing interviews with the firm/FMI's SOC and Incident Response Team", so CBEST firms often add a purple team session voluntarily.

Planning a purple team exercise

• Objective: one sentence, for example "validate detection of credential access and lateral movement used by the two groups in our threat profile against Windows servers and Entra ID".
• Threat selection: choose two or three adversaries from threat intelligence and extract their techniques. See the Threat Intelligence Guide.
• Roles: a facilitator who runs the clock and keeps notes neutral; red operators; blue analysts from the shift that would really see the alert; a detection engineer who can write and deploy rules live; a scribe; and a control or risk owner with authority to stop.
• Environment: decide between production, a representative staging network, or an authorised adversary emulation lab. Production gives true telemetry; a lab allows riskier techniques. TIBER-EU expects guardrails on which machines or subnets are in scope and which response actions must not be skipped.
• Rules of engagement: written authorisation from system owners, safe-execution limits (no destructive actions, no real data exfiltration), clean-up of every artefact, and a channel to deconflict with live incidents.
• Communication: TIBER-EU recommends secure channels agreed in advance, plain language all stakeholders understand, and regular checkpoints.
• People: brief blue teams that this is not an assessment of individuals. TIBER-EU notes that right after a red team the blue team may find it hard to shift from a defensive to a cooperative attitude.

Purple team template: the test case record

Emulation plans and adversary emulation libraries

An emulation plan turns intelligence about one adversary into an ordered set of behaviours. MITRE ATT&CK describes its early plans as "prototype documents of what can be done with publicly available threat reports and ATT&CK", intended to "allow defenders to more effectively test their networks and defenses."

• Full emulation plans: the MITRE Center for Threat-Informed Defense (CTID) adversary emulation library holds 11: APT29, Blind Eagle, Carbanak Group, FIN6, FIN7, menuPass, OceanLotus, OilRig, Sandworm, Turla and Wizard Spider. Each has an intelligence summary, an operational flow, scenarios that "can be executed end-to-end, or individual behaviors can be tested", and procedures in human and machine-readable formats. The library describes them as "a repeatable means to test and tune defensive capabilities."
• Micro emulation plans: 12 short plans for compound behaviours (Active Directory enumeration, data exfiltration, DLL sideloading, file access and modification, log clearing, named pipes, process injection, reflective loading, remote code execution, user execution, web shells, Windows Registry). CTID says they are "fully automated using compatible tools" and usable "even those without a red team".
• Your own plans: where no published plan matches your threat profile, write one from intelligence reports in the same structure: summary, flow, steps mapped to ATT&CK, expected detections.
• Authorisation: the CTID library states its content is "only to be used with appropriate prior, explicit authorization". Keep procedures in an access-controlled repository.

An adversary emulation platform is software that executes plan steps through an agent, schedules them and records results; an adversary emulation lab is an isolated, representative environment (domain controllers, endpoints with your real EDR and logging configuration, cloud test tenants) where riskier steps can run. Teams that use deception can also test whether decoys raise alerts; MITRE Engage is "a framework for planning and discussing adversary engagement operations" for that side.

Atomic tests and the test case library

An atomic test is the smallest useful unit: one procedure for one ATT&CK technique or sub-technique, with defined preconditions, execution and clean-up, producing a predictable trace. Atomic tests are good for checking that a single analytic fires; emulation plans are better for checking whether analysts connect a chain of events. Most programmes use both.

• Sources: an open-source library of atomic tests mapped to ATT&CK gives a fast start; CTID micro plans cover compound behaviours; red team findings add procedures specific to your estate.
• Curation: review every imported test for safety before use, record the version, remove tests that touch production data, and note required privileges.
• Variation: run more than one procedure per technique. A rule that only matches one tool's default behaviour is a brittle detection.
• Ownership: the test case library is a controlled artefact with an owner, change history and access control, like detection rules.

Running a purple team session step by step

1. Pre-flight: confirm telemetry is flowing from targets (agent health, log forwarding, clock sync) and that the blue team can query raw logs, not only alerts.
2. Announce and execute: the facilitator names the test case; the red operator runs it and records the exact start time.
3. Look: the blue team checks raw telemetry first, then alerts, then whether the alert reached a queue an analyst watches.
4. Classify: record the outcome on the agreed scale and the gap type.
5. Fix live where safe: a detection engineer drafts or tunes a rule, deploys it to a test rule set, and the red operator re-runs the test to confirm.
6. Vary: run an alternative procedure for the same technique to check the new rule is not tied to one artefact.
7. Clean up and log: remove artefacts, rotate any credential used or exposed, and update the test case record.
8. Roll back: any rule deployed live that causes noise or performance problems reverts to the previous version; the change goes through normal detection engineering review afterwards. See the Detection Engineering Guide.

Example test cases and expected telemetry

Detection gap tracking and the purple team report

Use one outcome scale everywhere so results compare across exercises:

• Prevented: a control blocked the behaviour (and the block was logged).
• Alerted and triaged: an alert fired and an analyst acted within the expected time.
• Alerted, not triaged: a triage gap. CISA's red team assessment AA24-326A found activity that "generated security alerts that network defenders did not review", and an alert that existed but was disabled.
• Logged only: an analytic gap; the data was there but no rule used it.
• Not logged: a telemetry gap; fix collection before writing rules.

Detection gap tracking works best in a purple team tracking tool (a category of software that stores test cases, outcomes and timestamps per ATT&CK technique) or, for small teams, a controlled spreadsheet with the template fields above. Export coverage to an ATT&CK Navigator layer so leaders see change over time. Each gap becomes a ticket in the detection engineering or logging backlog, never a line in a PDF.

A purple team report should contain: objective and threat profile; scope and environment; test cases run with ATT&CK IDs and outcomes; gaps by type with owners and dates; detections created or tuned during the session; items deferred and why; and a retest plan. Keep procedures and any captured secrets out of the report.

Continuous and automated purple teaming

CISA recommends "continually testing your security program, at scale, in a production environment" against the ATT&CK techniques in its advisories: select a technique, align controls, test, analyse performance, repeat, and tune people, processes and technology. That loop is continuous purple teaming.

• Cadence: a monthly sprint of a few new test cases plus regression of everything previously fixed.
• Automation: automated purple teaming schedules atomic tests and micro emulation plans through an adversary emulation or breach and attack simulation platform, then sends results to analysts. Automation finds regressions; humans still judge triage and response. See the Breach and Attack Simulation (BAS) Guide.
• Change triggers: rerun relevant tests after EDR policy changes, log pipeline migrations, SIEM rule refactors and major OS upgrades.
• Threat refresh: add test cases when a new advisory or incident report describes techniques used against your sector.

Purple team metrics

Choosing an approach by organisation size

• Small teams without a red team: start with CTID micro emulation plans and a curated set of atomic tests in a lab or a few production hosts, half a day a month, tracked in a spreadsheet. An external provider can run an annual facilitated purple team assessment.
• Mid-sized organisations: quarterly threat-informed assessments with an external or internal red operator, a named detection engineer, and automated regression in between.
• Large and regulated organisations: a standing purple team function joining red team, threat intelligence and detection engineering, purple team closure after every TLPT, and continuous automated testing across all EDR and logging configurations.

Use an external facilitator when internal teams are too close to the results, or when findings must carry weight with management. Keep it internal when speed and frequency matter more than independence.

Where identity fits

Many of the most useful test cases are identity techniques: Kerberoasting, DCSync, use of valid service and cloud accounts, token theft and help desk reset abuse. AA24-326A found no detection for anomalous LDAP activity. Include non-human identities in the test case library: interactive use of service accounts, cloud access keys used from new networks, and CI/CD tokens used outside pipelines. Rotate any credential exercised in a test. See the ITDR Guide.

Framework mapping

Common failure patterns

• Testing what the operator knows: sessions full of familiar techniques that bear no relation to the threat profile.
• Counting alerts, not triage: a rule fired, so the case is marked detected, although no analyst would have seen it.
• Fixes without retest: a rule is written in the session but never deployed, or breaks a month later with no regression run.
• Brittle detections: rules matched to one tool's file names or default strings that a second procedure walks past.
• Uncontained test infrastructure: automation, and increasingly AI agents, acting beyond the authorised scope. The Anthropic Claude evaluation incidents show how misconfigured cyber tests reached real organisations; contain labs and allow-list targets.
• Blame: analysts treated as the subject of the test stop sharing what they missed.

Practitioner checklist

• Write a one-sentence objective and a threat profile before choosing any test case.
• Build sessions from emulation plans or intelligence, mapped to ATT&CK v20 IDs.
• Record expected telemetry, alert and response for every test case before execution.
• Confirm telemetry health before the session and give the blue team raw log access.
• Classify every outcome as prevented, alerted and triaged, alerted not triaged, logged only or not logged.
• Turn each gap into a ticket with an owner and retest date; close only on a passing retest.
• Test each technique with more than one procedure.
• Automate regression of fixed test cases and rerun after logging or EDR changes.
• Include service accounts, cloud keys and pipeline tokens in the test case library, and rotate credentials used.
• Report coverage, gap closure time and regression rate to leadership each quarter.

Standards and references

• European Central Bank: TIBER-EU Purple Teaming Best Practices
• EUR-Lex: Commission Delegated Regulation (EU) 2025/1190 on threat-led penetration testing
• MITRE Center for Threat-Informed Defense: Adversary Emulation Library
• MITRE Center for Threat-Informed Defense: Micro Emulation Plans
• MITRE ATT&CK: Adversary Emulation Plans
• CISA: Enhancing Cyber Resilience, Insights from CISA Red Team Assessment of a US Critical Infrastructure Sector Organization
• NIST: SP 800-115 Technical Guide to Information Security Testing and Assessment
• Bank of England: CBEST Threat Intelligence-Led Assessments Implementation Guide

Related NHI Mgmt Group resources: Red Teaming Guide · Breach and Attack Simulation (BAS) Guide · Detection Engineering Guide · MITRE ATT&CK Guide for Defenders · Threat Hunting Guide