Purple Team

Purple Team

A purple team is not a separate team — it’s a way of working where red team (offense) and blue team (defense) collaborate on the same exercise instead of running adversarial engagements. The output isn’t a “win” for either side; it’s a list of detections that didn’t fire and controls that didn’t trigger, with both teams already aligned on the fix.

The name comes from blending red and blue. The framing matters: the goal is closing the loop, not scoring points.

Why purple beats red-vs-blue

Traditional red-team engagements produce reports. The blue team then has to:

1. Read the report (often weeks after the engagement)
2. Translate the TTPs into detection logic for their tooling
3. Tune the detections without re-running the original attack
4. Verify the detections actually fire — usually by waiting for the next engagement

This loop is slow and lossy. Detections derived from a report often miss the actual signal the attacker generated. By the time the next engagement runs, the org’s environment has drifted; new TTPs are needed.

A purple team exercise compresses this from months to days by running the attack and the detection-engineering response in the same room:

Red team executes TTP → Blue team observes their tooling
                     ↓                  ↓
                     What signal generated? → Was it caught?
                     ↓                  ↓
              Tune detection / add new one → Re-run the TTP
                     ↓
              Detection fires → Document, move on

You leave each session with detections that demonstrably work against the exact attack you ran.

When to run purple instead of red

• After a red-team engagement to translate findings into durable controls
• When standing up new detection tooling (SIEM rules, EDR detections)
• After a real incident, to validate that the gap that allowed it is now closed
• When training new blue-team analysts on what the TTPs actually look like in tooling
• When a threat-intel report (e.g., the Signal/RIS PSA) describes new TTPs you haven’t tested for

Don’t run purple when you specifically need to test the blue team’s response process under realistic conditions — that’s what red is for. Purple is for control coverage, not response practice.

Exercise structure

Pre-engagement (1–2 weeks before)

1. Pick a scenario. Often a specific threat actor or campaign. “Emulate the RIS Signal phishing campaign” is more useful than “test our security.”
2. Build the TTP list. Map the scenario to MITRE ATT&CK techniques. Sort by what you most want to validate.
3. Identify expected detections. For each TTP, write down which control(s) should catch it and where you’d see the signal (which log, which dashboard, which rule).
4. Agree on the environment. Production with read-only safety constraints? A staging environment with mirrored data? A purpose-built range? Different choices yield different fidelity.
5. Set the rules of engagement. Especially important: what happens if a real detection fires during the exercise and triggers a real on-call. (Hint: bake in a known-marker so on-call can distinguish exercise from incident.)

During the exercise (1–3 days, typically)

For each TTP:

1. Red announces — “About to execute T1566.001, spearphishing attachment.”
2. Blue stages — opens the dashboards, log sources, and alerting consoles where they’d expect to see signal.
3. Red executes. No surprises; this isn’t a stealth test.
4. Both observe. Did anything fire? Where? With what fidelity?
5. Score and capture:
   • Detected: alert fired, time-to-detection, was the alert actionable?
   • Visible but not alerting: signal present in logs, no alert
   • Invisible: no signal anywhere
6. Detection engineering: for “visible but not alerting” cases, write or tune the rule on the spot. Re-execute. Verify it fires.
7. For “invisible”: identify the log source or sensor gap. Add to remediation list — usually requires post-exercise infrastructure work.
8. Document: TTP, expected detection, actual outcome, action taken, follow-up needed.

Post-engagement

1. Detection inventory: every new or tuned detection lands in version control with a link to the exercise and the TTP.
2. Gap remediation plan: invisible TTPs become tickets — sensor coverage, log retention, parsing, or new tooling.
3. Detection regression: add the executed TTPs to your detection-as-code regression suite. Running them periodically (monthly or quarterly) confirms detections still work as the environment evolves.
4. Readout to broader security and engineering leadership. Focus on detections-added and gap-tickets-opened, not on “red won.”

Tooling

The space has matured. Use any of these as a backbone:

• Atomic Red Team — a community-maintained library of small, atomic TTP executions mapped directly to ATT&CK. The default starting point. Each “atomic” is a script you can run, with the expected behavior documented.
• CALDERA — MITRE’s automated red-team emulation framework. Higher learning curve; pays off for repeatable purple exercises.
• VECTR — exercise tracking and detection-coverage scoring. Worth adopting if you’ll run purple regularly.
• Sigma — vendor-neutral detection rule format. Write detections in Sigma; convert to your SIEM’s native rule language. Makes detections portable.
• Your real C2 + your real SIEM — for high-fidelity exercises. Atomic Red Team gets you 80% of the value with 10% of the setup; mature programs graduate to live C2.

Detection coverage scoring

A useful output of repeated purple exercises is a coverage matrix — typically the ATT&CK matrix colored by coverage state:

• Green — TTP tested, detection fires reliably
• Yellow — TTP tested, partial detection or noisy alert
• Red — TTP tested, no detection
• Grey — TTP not yet tested

Over time the goal isn’t 100% green (the matrix has too many techniques and many won’t apply to your environment). The goal is green coverage for the TTPs your real adversaries use, identified from threat intel and from incidents in your sector.

Common mistakes

• Treating it like a red engagement. Don’t run stealth, don’t time-pressure, don’t keep the blue team in the dark. Different exercise.
• Skipping detection regression. A detection that fired on Day 1 of the exercise but never gets re-tested decays — schema changes, log source drift, parser regressions all break detections silently.
• Detection-only focus. Some TTPs should be blocked, not just detected. If your exercise produces only detections, you’re undervaluing prevention controls.
• Skipping the readout. Purple exercise value depends on the resulting work landing in tickets and rules — not in a shared doc that nobody reads.
• No follow-through on gaps. Invisible TTPs become permanent gaps if nobody owns the sensor-coverage remediation. Assign owners during the exercise, not after.

For community / personal scale

Most of this page is enterprise framing. The equivalent for community-scale or personal use:

• Run adversary-walkthrough exercises with willing peers: “Here’s how the RIS Signal campaign works. Try each step on a test account. What did you see? What didn’t you notice?”
• Practice with a partner: one runs the lure (in a test account), the other plays the target. Time how long it takes the target to notice and report.
• For families and small orgs: tabletop the SIM swap scenario. Walk through who calls the carrier, what the response chain looks like, where the recovery email lives. Don’t actually swap.

The point isn’t enterprise tooling; it’s closing the gap between knowing about an attack and verifying you’d catch it.

Related

• Red Teaming — the offensive practice purple builds on
• Adversary Threats Catalog — source material for scenarios
• Signal/CMA Takeover (RIS) — example scenario, fully documented
• Cyber Incident Response Guide — what triggers when detections fire for real
• MITRE ATT&CK — the TTP coverage framework
• Atomic Red Team — the practical starting toolkit