/22-purple-team

name: Purple Team & Adversary Emulation
description: Collaborative purple-team operations — threat-informed adversary emulation planning (ATT&CK, CTID, Atomic Red Team, CALDERA), the detect-tune-validate loop, detection coverage measurement (DeTT&CT/Navigator), safe execution and deconfliction, and MTTD/coverage reporting
version: 3.1.0
author: Masriyan
tags: [cybersecurity, purple-team, adversary-emulation, attack, atomic-red-team, caldera, detection-engineering, detection-coverage, mttd, breach-attack-simulation]

Purple Team & Adversary Emulation

Purpose

Enable Claude to plan and run *purple team* engagements: red and blue working the same ATT&CK techniques together so that every emulated behavior produces a measured answer to "did we see it, and could we have stopped it?" The deliverable is not a compromise — it is a **validated, quantified improvement in detection and prevention coverage**.

This skill sits between Skill 14 (Red Team — how to execute the offensive TTPs) and Skills 15/12/11 (Blue Team, SIEM/Sigma, SOC — how to detect and respond). It supplies the collaborative loop and the coverage measurement that turn one-off findings into durable detections.

---

⚠️ Authorization Gate — Read First

Adversary emulation executes real attack techniques against real systems. Before providing operational assistance (test execution, payloads, C2, live-fire steps), confirm:

[ ] Written authorization naming the systems/environment in scope exists and is current
[ ] Scope, allowed techniques, and explicit exclusions (fragile prod, safety systems, OT) are defined
[ ] A deconfliction channel and point of contact are agreed with the SOC/blue team
[ ] A stop/abort procedure and rollback plan are documented and understood
[ ] Destructive or availability-impacting techniques are excluded unless separately authorized
[ ] Test data/accounts are used; no real user data is exfiltrated

If authorization cannot be confirmed, restrict assistance to **planning, coverage analysis, detection engineering, and tabletop emulation** — which need no live execution — and say so explicitly. Never provide live-fire steps against systems the user cannot show authorization for. For the offensive tradecraft itself, defer to Skill 14's Rules of Engagement.

---

Activation Triggers

This skill activates when the user asks about:

• Planning a purple team engagement, adversary emulation plan, or breach-and-attack-simulation exercise
• Choosing and emulating a specific threat actor's TTPs (from CTI / ATT&CK groups)
• Atomic Red Team, MITRE CALDERA, CTID Adversary Emulation Library, or MITRE Engenuity ATT&CK Evaluations
• The detect → tune → re-test validation loop for a technique
• Measuring or visualizing detection coverage (ATT&CK Navigator layer, DeTT&CT, heatmap)
• Detection maturity per technique (none / telemetry / detection / prevention)
• Deconfliction between red and blue, or safe execution of attack techniques
• Purple-team metrics — MTTD/MTTR, detection rate, per-technique time-to-detect, gap backlog

---

Prerequisites

python3 --version          # 3.10+; standard library only for the core script
pip install pyyaml         # optional — only to load emulation plans written in YAML

**Optional enhanced tooling:**

• [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) — library of small, ATT&CK-mapped tests
• [MITRE CALDERA](https://github.com/mitre/caldera) — automated adversary emulation platform
• [CTID Adversary Emulation Library](https://github.com/center-for-threat-informed-defense/adversary_emulation_library) — full actor emulation plans
• [DeTT&CT](https://github.com/rabobank-cdc/DeTTECT) — data-source and detection coverage scoring
• [ATT&CK Navigator](https://mitre-attack.github.io/attack-navigator/) — coverage heatmaps
• [VECTR](https://github.com/SecurityRiskAdvisors/VECTR) — purple-team assessment tracking

---

Core Capabilities

1. Engagement Model Selection

Pick the collaboration model that fits the maturity and goal:

• **Tabletop emulation** — walk the actor's kill chain on paper; verify each step *would* generate telemetry and *should* fire a detection. No execution; safe anywhere, ideal first pass.
• **Micro-emulation** — a handful of atomic tests for a specific technique or a newly deployed detection. Fast feedback, small blast radius.
• **Full-campaign emulation** — end-to-end emulation of a named actor across the kill chain, run collaboratively with the SOC watching in real time. Highest fidelity, highest coordination cost.
• **Continuous / automated (BAS)** — scheduled automated tests to catch detection regressions over time.

Default to the least invasive model that answers the question, and escalate only with cause and authorization.

2. Threat-Informed Emulation Planning

**When the user asks to plan an emulation:**

1. **Choose the adversary from intelligence, not convenience.** Pull the actor/campaign relevant to the org's sector and crown jewels (hand-off from Skill 21 CTI / Skill 06). Prefer an actor the org actually faces. 2. **Build the technique list** by walking the actor's known TTPs across ATT&CK tactics (Initial Access → Impact). For each, capture: technique ID, tactic, a concrete procedure, the expected data source/telemetry, and the expected detection. 3. **Order by kill chain and set objectives** — what "success" means for each step (e.g., "Kerberoast a service account" → objective: SOC alerts within N minutes). 4. **Map to a test source** — an Atomic Red Team test, a CALDERA ability, or a documented manual procedure — so execution is repeatable. 5. **Record the plan** as structured data (`scripts/detection_validator.py` reads a JSON/YAML plan) so results are trackable across re-tests.

3. The Detect–Tune–Validate Loop

For every technique, run the collaborative loop and record the outcome:

Execute technique (red, announced to blue)
        ↓
Confirm telemetry exists  ──no──▶ GAP: missing dat