Chapter 2 — Adversary emulation and purple teaming

In one sentence

Adversary emulation runs known attacker techniques against your real environment on purpose, so you can measure — not guess — whether your controls prevent them and your telemetry detects them.

Where we are

You have detections (G1 Ch 50) and controls. Do they work? "We have a SIEM rule for that" is a hypothesis until someone executes the technique and you watch the alert fire (or not). Purple teaming is the discipline of doing that collaboratively: red executes, blue observes, both tune, repeat.

How it works

   1. CHOOSE techniques from a framework, prioritised by YOUR threat model:
        MITRE ATT&CK  -- the technique taxonomy (Txxxx). Filter by the
                         tactics that matter for your system (cloud:
                         "Valid Accounts", "Exfiltration to Cloud Storage";
                         k8s: "Container Administration Command",
                         "Escape to Host").
        MITRE ATT&CK for Cloud / Containers  -- the relevant matrices.
        Threat-intel:  what are groups targeting orgs like yours actually
                       doing? (Ch 53)

   2. EXECUTE with a controlled tool, in a lab or a sanctioned window:
        Atomic Red Team   -- small, single-technique tests (YAML "atomics"),
                             endpoint-focused, run via `Invoke-AtomicTest`.
        Stratus Red Team  -- cloud-native techniques (AWS/k8s), "warm up /
                             detonate / cleanup" lifecycle. Purpose-built
                             for this.
        CALDERA           -- MITRE's automated emulation server; chains
                             techniques into operations; plug-ins for cloud.
        Leonidas          -- AWS attack techniques as code, YAML-defined.
        Prelude Operator, Vectr (tracking), AtomicTestHarnesses.

   3. OBSERVE: for each technique, record
        PREVENTED?   did a control stop it (IAM deny, admission policy,
                     network policy)?  -- best outcome
        DETECTED?    did an alert fire? with what fidelity and latency?
        LOGGED?      is the evidence in the data even if no rule matched?
        MISSED?      nothing -- a gap.

   4. TUNE: write/fix the detection (Ch 51), add the control, re-run until
        it's PREVENTED or DETECTED with acceptable latency.

   5. TRACK coverage as a heat map: ATT&CK technique x (prevent/detect/gap).
        This is your honest security posture, and it's reportable (Ch 62).

Purple team vs red team vs pentest:

   PENTEST        find as many vulns as possible in a scope/time box. Output:
                  a findings report. Point-in-time.
   RED TEAM       achieve a specific objective (get to the crown jewels)
                  stealthily, testing detection & response as much as
                  prevention. Output: "we got in via X, moved via Y, you
                  saw Z". Adversarial.
   PURPLE TEAM    red and blue in the same room, running techniques openly
                  to build detection coverage. Output: new/tuned detections
                  and a coverage map. Collaborative, repeatable, the best
                  ROI for most orgs.
   ADVERSARY      automated, continuous purple: run the technique library
   EMULATION /    on a schedule (BAS -- breach & attack simulation) so
   BAS            regressions are caught.

Worked example

A single purple-team cycle for one cloud technique.

   TECHNIQUE: T1552.005 -- "Unsecured Credentials: Cloud Instance Metadata
   API" (steal role creds via SSRF-to-IMDS).

   EXECUTE (Stratus Red Team, in the sandbox account):
     stratus detonate aws.credential-access.ec2-steal-instance-credentials
       -> launches an EC2 instance, curls IMDS, exfils the creds, then
          uses them from an external IP.

   OBSERVE:
     PREVENTED?  No -- the test instance had IMDSv1. (In prod: is
                 http-tokens=required set? Check.)
     DETECTED?   GuardDuty fired
                 `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration
                 .OutsideAWS` ~15 min later. Good signal, slow.
     LOGGED?     CloudTrail shows the role's access key used from an IP not
                 in AWS ranges, ~1 min after detonation.
     -> gap: 15 min detection latency; no fast rule.

   TUNE:
     - Control: enforce IMDSv2 hop-limit-1 org-wide via SCP + Terraform
       (prevents the class).
     - Detection: a near-real-time rule -- "an instance-profile role's
       credentials used where sourceIPAddress is not in the AWS IP ranges
       AND not the instance's own ENI" -> alert in <2 min.
     - Re-run: PREVENTED (IMDSv2) + DETECTED fast (the new rule, for any
       residual v1). Mark T1552.005 green on the heat map.

   Cost: ~half a day. You now KNOW, not hope.

Real-world scenario: MITRE's own vendor-neutral emulation program

   MITRE runs a public, ongoing "ATT&CK Evaluations" program that IS,
   at industry scale, exactly this chapter's exercise: MITRE researchers
   emulate the real, documented TTPs of a specific named adversary group
   (they have run rounds emulating APT29, APT3, Wizard Spider/Sandworm,
   Turla, and others) against SECURITY VENDORS' PRODUCTS in a controlled
   environment, and publish the PREVENTED/DETECTED/gap results for every
   technique, for every participating vendor, publicly.
   Two things worth taking directly from how MITRE runs it:
     - techniques are drawn from REAL, OBSERVED CAMPAIGNS of the emulated
       group (Ch 53's threat-intelligence sourcing), not a generic
       checklist -- the same discipline this chapter argues for when
       choosing which techniques to detonate against your own
       environment.
     - the results are reported per-technique, not as a single pass/fail
       score -- a vendor might catch 90% of a campaign and still miss the
       one step that would have stopped real damage. Your own coverage
       heat map (Ch 57) should be read with the same scepticism toward
       a single aggregate number.

Practice (60 min)

Install Atomic Red Team on a lab VM and Stratus Red Team pointed at your sandbox cloud account.
Pick 5 techniques matching SecureShop's threat model — e.g. T1078.004 (valid cloud accounts), T1552.005 (IMDS creds), T1537 (exfil to cloud storage), T1611 (escape to host — do this in Part 4), T1098.001 (add cloud credentials / persistence).
For each: detonate, then fill the PREVENTED / DETECTED / LOGGED / MISSED grid. Note detection latency.
Pick the worst gap and write one detection rule (Sigma or your stack's query). Re-run. Confirm it fires.
Start a coverage heat map (a spreadsheet: technique x status). You'll grow it in Part 8.

Common mistakes

Emulation without cleanup. Stratus/CALDERA leave artefacts (IAM users, instances, files). Use the tool's cleanup; verify with a cost check.
Testing techniques your threat model doesn't include. Coverage of irrelevant TTPs is vanity. Prioritise from your actual adversaries and assets.
"Detected" without fidelity/latency. An alert that fires 6 hours later, or once per 500 false positives, is not real coverage.
Red team as a gotcha. If findings are used to punish blue, blue stops sharing. Purple is collaborative by design.
One and done. Techniques regress when infra changes. Automate re-runs.

Check yourself

Difference between a pentest, a red team, and a purple team — objective and output of each.
What are the four outcomes to record per emulated technique, best to worst?
Why prioritise techniques from your threat model rather than running the whole ATT&CK matrix?
Name a tool for endpoint technique emulation and one for cloud.
What is a coverage heat map and who is its audience?