Running a Purple Team Exercise

A pentest tells an organization where it can be broken into. A purple team exercise tells it whether anyone would notice, and fixes that on the spot. This guide covers how to plan and run one, whether you’re on the red side, the blue side, or organizing both.

Before anything runs

Pick a threat, not a tool list. Start from an adversary relevant to the organization. Threat intelligence and MITRE ATT&CK’s group pages list the techniques specific groups use. A healthcare provider and a crypto exchange face very different actors.

Choose 10 to 20 techniques. More than that and the exercise becomes a checklist. Prioritize techniques that are common across many adversaries, such as T1059 command interpreters, T1053 scheduled tasks, T1003 credential dumping, and T1021 remote services.

Get it in writing. A purple team exercise is still an authorized test. Document scope, systems, timing, who is involved, and how to stop if something breaks.

Agree on what “detected” means. There are levels, and the difference matters:

Outcome	Meaning
Not logged	No telemetry exists. Nothing could ever detect it.
Logged	The data exists, but nothing looked at it.
Alerted	A rule fired.
Triaged	An analyst saw the alert and understood it.
Contained	Someone acted on it within an agreed time.

Emulating techniques safely

Use emulation frameworks built for this, not real malware:

• Atomic Red Team from Red Canary offers small, documented tests mapped to ATT&CK technique IDs. Each test lists exactly what it does and how to clean up.
• MITRE Caldera automates multi-step adversary emulation with an agent and planner.
• Adversary emulation plans from MITRE’s Center for Threat-Informed Defense reproduce specific groups’ behavior in detail.

Run each test on a designated lab or test endpoint first. Read every test before running it, and run the cleanup command afterward.

The exercise loop

For each technique, run the same loop with both teams together, in a room or on a call:

1. Announce. Red states which technique, which host, and the exact time.
2. Execute. Red runs the test and records the command and timestamp.
3. Look. Blue searches for it. Was it logged? Did anything alert?
4. Diagnose. If not detected, find out why. Missing log source? Rule too narrow? Alert routed nowhere?
5. Fix. Write or tune the detection right there, where possible.
6. Rerun. Execute again and confirm the fix works.

Announcing in advance is the point. This is not a test of whether blue is paying attention. It’s a test of whether the tooling and rules work.

Measure it

Record results in a simple matrix and keep it. ATT&CK Navigator layers work well: color each technique by outcome, then compare layers across exercises.

Technique	Before	After	Fix
T1053.005 Scheduled task	Logged	Alerted	New Sigma rule on event 4698
T1003.001 LSASS access	Alerted	Alerted	Already covered
T1021.002 SMB admin shares	Not logged	Logged	Enabled object access auditing

The before and after columns are the exercise’s value, in a form leadership understands.

Common findings

• Logs exist but aren’t collected. The endpoint logged it. The SIEM never received it.
• Rules match one exact command line. Changing an argument order evades them. Good rules match behavior.
• Alerts fire into a queue nobody watches. Detection without response isn’t detection.
• Test systems differ from production. Validate coverage on representative endpoints.

Takeaway

Purple teaming replaces “we think we’d catch that” with evidence. Run small, announce everything, fix live, and measure the change.