Warmup Guide — From Threat Intelligence to an Adversary-Emulation Plan

Zero-to-principal primer for Phase 01. It builds every concept the phase depends on from first principles: the attacker lifecycle stage by stage (goal, techniques, telemetry, break-the-chain), the three analytic lenses (Cyber Kill Chain, MITRE ATT&CK, Diamond Model), ATT&CK at every level (tactics → techniques → sub-techniques → procedures) and the Navigator, the Mandiant Attack Lifecycle, the Pyramid of Pain, the difference between emulation / simulation / pentest, the CTI→emulation-plan workflow, and purple teaming. It assumes only that you can write software and have read Phase 00's authorization boundary. By the end you can read any intrusion through all three lenses and turn intelligence on a named actor into a runnable, detection-paired emulation plan.

Safety frame (not optional). This is the attacker's playbook taught for authorized emulation and defense. Everything here reasons over synthetic metadata; every offensive concept ends in its detection / break-the-chain control. The difference between a red teamer and a criminal is authorization and intent, not knowledge (Phase 00).

Table of Contents

• Chapter 1: What Adversary Emulation Is, and Why a Named Actor Changes Everything
• Chapter 2: The Attacker Lifecycle, Stage by Stage
• Chapter 3: The Cyber Kill Chain — Break the Chain Early
• Chapter 4: MITRE ATT&CK — Tactics, Techniques, Sub-techniques, Procedures
• Chapter 5: The ATT&CK Navigator, Coverage, and Gaps
• Chapter 6: The Diamond Model and Pivoting
• Chapter 7: The Mandiant Attack Lifecycle
• Chapter 8: The Pyramid of Pain
• Chapter 9: From CTI to an Emulation Plan — the Workflow
• Chapter 10: Emulation vs Simulation vs Pentest vs Red Team vs Vuln Scan
• Chapter 11: Threat-Informed Defense and Purple Teaming
• Lab Walkthrough Guidance
• Success Criteria
• Common Mistakes and OPSEC Failures
• Interview Q&A
• References

Chapter 1: What Adversary Emulation Is, and Why a Named Actor Changes Everything

Zero background. Imagine a client — Meridian Freight International — that wants to know whether it would survive a real attack. There are several ways to answer that, and they are not the same:

• A vulnerability scan lists weaknesses a scanner can fingerprint. It answers "what is broken?"
• A penetration test has a human exploit some of those weaknesses to a goal. It answers "what can an attacker do here?"
• Adversary emulation reproduces the tradecraft of a specific, named threat actor the client actually faces — driven by threat intelligence, scored against the client's detections. It answers "would we detect and stop this adversary, and where exactly do we fail?"

What it is. Adversary emulation is a structured engagement in which the red team behaves like a chosen actor: the same tactics, the same techniques, in roughly the same order, against a consenting client, under a contract with rules of engagement. The output is not a trophy ("we got domain admin"); it is a detection-and-response assessment: a kill-chain narrative mapped to MITRE ATT&CK, with every detection opportunity the blue team had — taken or missed — and a prioritized plan to close the gaps.

Why a named actor changes everything. The moment you anchor to a named actor, three things become true:

1. The technique selection stops being arbitrary. You do what FIN-LATTICE does — phish, run a loader, dump credentials, move laterally, beacon out, ransom — not a grab-bag of whatever exploits. This is threat-informed (Chapter 11): you test the defenses against the threats you actually face.
2. Detection coverage becomes measurable. Because each technique maps to ATT&CK, you can score the client's coverage technique-by-technique and produce a gap map. That is the deliverable.
3. The engagement is repeatable and purple-able. A named actor + ATT&CK mapping + procedures means the blue team can replay the exact behaviors later (purple teaming, Chapter 11) and confirm the gap is closed.

Under the hood — what "emulate an actor" actually requires. You need (a) CTI on the actor: an intel report or a structured profile listing its observed ATT&CK techniques and known infrastructure/ tooling; (b) a way to order those techniques into a campaign (the lifecycle, Chapter 2); (c) a procedure for each (what you actually run on the owned range); (d) the telemetry each emits and a detection idea (the pairing); and (e) success criteria and stop conditions. Lab 01 is exactly the engine that turns (a) into (b)+(c)+(d)+(e).

Engagement significance. This is the Mandiant red team's core product and the reason the Operation Cedar Lattice engagement exists. Everything downstream — the privesc, the AD path, the C2 — is in service of emulating FIN-LATTICE faithfully enough to test Meridian's detections.

Misconception to kill now. "Emulation means I copy the actor's exact malware." No — you reproduce the actor's behaviors (TTPs), safely, on an owned range, often with different tooling. The point is the behavior the sensor sees, not possessing the actor's binary. Copying a hash tests nothing durable (Chapter 8).

Chapter 2: The Attacker Lifecycle, Stage by Stage

Zero background. A real intrusion is not one action; it is a sequence of stages, each with its own goal. Whether you call the stages "kill-chain phases" (Chapter 3), "ATT&CK tactics" (Chapter 4), or "Mandiant lifecycle steps" (Chapter 7), the shape is the same: get in, run code, stay in, get more power, move around, take what you came for, leave or destroy. Memorize the shape once and every framework is a re-labeling of it.

Here is the unified lifecycle this phase uses — the ATT&CK Enterprise tactic order, which the labs encode as TACTIC_ORDER. For each stage: the goal, representative techniques, the telemetry it emits, and the break-the-chain control.

Why the order matters. Two reasons. First, a plan must read as a campaign — you cannot "emulate impact" before "initial access." Second, "defend left." A control at a low-order stage prevents everything downstream. Stopping the phish (stage 2) prevents the credential theft, the lateral movement, and the ransom (stages 7, 9, 13). A control at the impact stage only limits the damage of an attack you already lost. The cheapest disruption is always the earliest placeable stage in the observed chain — which is exactly what earliest_break computes in Lab 02.

Under the hood — stages are goals, not steps. A real actor does not march stage 0→13 once. It loops: discovery → credential access → lateral movement → discovery again on the new host. Some stages repeat; some are skipped (a stolen valid account skips "exploit"). The lifecycle is the set of goals, ordered by typical earliest occurrence, not a strict script. The Mandiant lifecycle (Chapter 7) makes that loop explicit.

Misconception to kill now. "ATT&CK tactics are sequential steps you do once." They are goal categories. An intrusion visits some, repeats some, and skips some. The ordering in the labs is a modelling convenience (so a campaign has a canonical narrative), not a claim that real actors are linear.

Chapter 3: The Cyber Kill Chain — Break the Chain Early

Zero background. In 2011, Lockheed Martin published Intelligence-Driven Computer Network Defense, introducing the Cyber Kill Chain: a model of an intrusion as seven linear phases, borrowed from a military targeting concept (the "kill chain" of find → fix → track → target → engage → assess).

The seven phases:

1. Reconnaissance   research the target
2. Weaponization    pair an exploit with a deliverable (e.g., a malicious doc)
3. Delivery         transmit the weapon (email, web, USB)
4. Exploitation     trigger the vulnerability / user action
5. Installation     install the implant / establish footing
6. Command & Control  open the remote-control channel
7. Actions on Objectives   do the thing (exfil, destroy)

Why it exists. Before the kill chain, defense was indicator-centric ("block this bad IP"). The kill chain reframed defense as disrupting a process: the attacker must complete every phase to succeed, so the defender only has to break one. And — the model's central insight — breaking an early phase is cheaper and prevents more. Stop delivery and there is no exploitation, no installation, no C2, no impact. This is the original statement of "defend left."

Under the hood — the "courses of action" matrix. The Lockheed paper pairs each phase with six defensive actions: detect, deny, disrupt, degrade, deceive, destroy. The intellectual move is that for every phase you can ask "how do I detect it? how do I deny it?" — turning a linear attack into a grid of defensive opportunities. A red team report's gap matrix is a direct descendant of this idea.

Telemetry / detection. Each phase emits something: reconnaissance shows up as scanning in flow logs; delivery as a message at the mail gateway; C2 as beaconing in proxy logs. The kill chain's job is to remind you that every phase is a detection opportunity — you are never limited to catching the final action.

Engagement significance. The kill chain is the coarse, durable, executive-friendly lens. When you brief a CISO, "the attacker reached Actions on Objectives; we had detection opportunities at Delivery and C2 that fired late" is instantly legible. Its weakness is granularity: "exploitation" is one box, where ATT&CK has hundreds of techniques. So you use the kill chain for the narrative arc and ATT&CK for the behavioral detail.

Misconception to kill now. "The kill chain is obsolete; ATT&CK replaced it." No — they are different resolutions of the same picture. The kill chain gives you the seven-phase arc for storytelling and the "break early" principle; ATT&CK gives you the technique-level map for detection. Mature teams use both. (The "Unified Kill Chain" attempts to merge them into 18 phases; know it exists.)

Chapter 4: MITRE ATT&CK — Tactics, Techniques, Sub-techniques, Procedures

Zero background. ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge), published by MITRE, is a curated, evidence-based knowledge base of how real adversaries behave, organized as a matrix. It is the lingua franca of red, blue, and threat-intel teams: when you say "T1003," everyone means the same behavior.

The four levels — this is the spine of the whole phase:

TACTIC       the adversary's GOAL                "credential access"        (the WHY)
   └ TECHNIQUE     a way to achieve the goal      "OS Credential Dumping" T1003   (the HOW, general)
        └ SUB-TECHNIQUE   a specific variant       "LSASS Memory" T1003.001        (the HOW, specific)
             └ PROCEDURE   a concrete implementation "actor X used comsvcs.dll MiniDump on lsass"  (the WHAT, observed)

• A tactic is a goal — the column of the matrix (Reconnaissance, Initial Access, … , Impact — the same lifecycle as Chapter 2). There are 14 in ATT&CK Enterprise.
• A technique (e.g., T1003 OS Credential Dumping) is a general method of achieving a tactic.
• A sub-technique (e.g., T1003.001 LSASS Memory) is a specific variant of a technique. Not all techniques have sub-techniques; the .NNN suffix denotes one. This granularity matters for detection: dumping LSASS memory and dumping the SAM hive are both T1003 but emit different telemetry and need different detections.
• A procedure is a specific observed implementation — "FIN-LATTICE used comsvcs.dll MiniDump against lsass.exe." Procedures are what CTI reports document and what your emulation plan reproduces.

Why the levels matter for emulation. Your CTI gives you procedures; you map them up to sub-techniques/techniques to find the data source and detection; you group by tactic to order and to score coverage. The whole movement of Lab 01 is: take observed technique ids → classify each (technique + tactic + telemetry + detection) → order by tactic → group → count coverage.

Under the hood — what ATT&CK actually ships. Each technique page carries: a description, the tactic(s) it serves (a technique can belong to several tactics — e.g., Valid Accounts is both Initial Access and Persistence and Privilege Escalation and Defense Evasion), the data sources that observe it (Process Creation, Logon Session, Network Traffic, …), detection guidance, mitigations (M-codes mapping to D3FEND), and procedure examples from named groups. ATT&CK is distributed as a STIX 2.1 bundle you can parse programmatically (the Lab 01 "extensions" do exactly this).

Telemetry / detection — the data-source pivot. ATT&CK's most useful property for a red teamer who must ship detections is the data source field. It tells you, for any technique, what sensor would see it. T1003.001 (LSASS Memory) → data source Process: OS API Execution / Process Access → in practice, Sysmon EID 10 (a handle opened to lsass.exe with suspicious access rights). That chain — technique → data source → concrete log event → detection rule — is the heart of detection engineering, and the reason every CORPUS row in the labs carries a telemetry field next to the detection field.

Engagement significance. ATT&CK is the common language of the entire engagement. The emulation plan is an ATT&CK layer; the report's gap matrix is an ATT&CK layer; the purple-team replay is scored per ATT&CK technique. If you cannot read all four levels fluently, you cannot do this job.

Misconception to kill now. "A technique maps to exactly one tactic." False — many techniques serve several tactics. The labs simplify to one tactic per technique for a clean lifecycle ordering; real ATT&CK is multi-tactic, which is why the Lab 01 limitations note flags it and the STIX extension fixes it.

Chapter 5: The ATT&CK Navigator, Coverage, and Gaps

Zero background. The ATT&CK Navigator is a free web tool that renders the ATT&CK matrix as a grid you can color and annotate — a "layer." Each cell is a technique; you assign it a score/color and comment. Layers are JSON; you can generate them programmatically.

Why it exists. A flat list of techniques ("FIN-LATTICE uses T1566, T1059, …") is hard to reason about. Painted onto the matrix, it becomes a picture: you instantly see which tactics the actor exercises and — crucially — which it does not. Overlay your detection coverage (green = we detect, red = we are blind) and the picture becomes a gap map.

The two questions a layer answers:

• Coverage — "what does this actor do?" (Lab 01 tactics_covered, coverage_summary). A techniques-per-tactic count is the simplest coverage view: it shows where the actor concentrates.
• Gaps — "what would we not test if we only emulate this actor?" (Lab 01 coverage_gaps). If FIN-LATTICE never does discovery in your CTI, an emulation of FIN-LATTICE alone never tests your discovery detections. That is a blind spot in your assessment, distinct from a blind spot in your defense — and naming it is a staff-level move.

Under the hood — comparing layers. Navigator supports layer arithmetic: overlay actor A and actor B to see shared techniques (prioritize those — they defend against the most threats); subtract "techniques we detect" from "techniques this actor uses" to get the detection gap; intersect two groups to build a threat-informed prioritization. The CTID "Top ATT&CK Techniques" methodology is a formalization of this.

Telemetry / detection. A coverage layer is only honest if it distinguishes three states:

DETECTED      the data source is collected AND a rule fires        → green
VISIBLE-ONLY  the data source is collected but NO rule fires       → yellow (a detection gap)
BLIND         the data source is NOT even collected                → red   (a visibility gap)

A red teamer who reports "we have no coverage of T1003" without distinguishing blind from visible-but-no-rule has given the client a worse remediation than necessary: the first costs a new sensor, the second costs a rule. The Lab 01 extension that joins the plan to a SOC data-source inventory is exactly this distinction.

Engagement significance. The Navigator layer is the portfolio artifact of Phase 01. "Here is FIN-LATTICE painted on the matrix; here is your detection coverage; here are the red cells we will test; here is the gap map after the engagement." It is the single most legible deliverable a red team produces for a security leader.

Misconception to kill now. "Green coverage means we are safe." Green means a rule exists, not that it fires reliably, low-false-positive, and gets actioned. Coverage is necessary, not sufficient; the purple-team replay (Chapter 11) is what validates that green is real.

Chapter 6: The Diamond Model and Pivoting

Zero background. The Diamond Model of Intrusion Analysis (Caltagirone, Pendergast, Betz, 2013) models a single malicious event as four connected vertices:

            ADVERSARY
           /         \
   INFRASTRUCTURE — CAPABILITY      (the two are linked: a capability runs over infrastructure)
           \         /
             VICTIM

• Adversary — who is doing it (often unknown at observation time).
• Capability — the tool/malware/technique used (a loader, a RAT, an exploit).
• Infrastructure — the physical/logical resources used (a C2 IP, a domain, a redirector).
• Victim — the target (an organization, host, or asset).

Every observed event populates some of these vertices. The model's axioms are simple but powerful: for every intrusion there is an adversary; every adversary uses capability over infrastructure against a victim.

Why it exists — the analytic move is PIVOTING. The kill chain and ATT&CK describe one intrusion in time. The Diamond Model lets you link separate events into a campaign in space by their shared meta-features. If event A and event B used the same C2 infrastructure (203.0.113.7), they are probably the same campaign — even if you do not yet know the adversary. If A and C share the same loader capability (LatticeLoader), same conclusion. You pivot from one vertex to find events sharing it. This is the engine of threat-intel correlation and the first step toward attribution.

Under the hood — pivoting as graph connectivity. Model each event as a node; draw an edge between two events that share a non-null infrastructure or capability value; the connected components are the campaigns. That is exactly Lab 02's pivot: union-find over shared meta-features, returning clusters of size ≥ 2 (a lone event has nothing to pivot to). Pivoting is transitive: if A→B share infra X and B→C share infra X, then A, B, C are one cluster even if A and C were never directly observed together. This is how an analyst expands from a single indicator to the whole intrusion.

  event e1  (infra: mail.evil.test, capability: LatticeLoader)
  event e3  (infra: —,               capability: LatticeLoader)   ← pivots to e1 on capability
  event e4  (infra: 203.0.113.7,     capability: —)
  event e5  (infra: 203.0.113.7,     capability: LatticeCrypt)    ← pivots to e4 on infrastructure

Telemetry / detection — pivoting is a defensive weapon, not just an attacker concept. Once incident responders have one indicator (say, the C2 IP from a single beacon), pivoting on it finds every other event that touched it — so they can scope and contain the whole intrusion, not just the alert they happened to see. A defender who cannot pivot cleans one host and leaves the actor in ten others.

Engagement significance. In a red team report, the Diamond pivot explains why the blue team should connect two alerts they treated as separate. In a purple-team replay, you deliberately reuse infrastructure across stages so the blue team can practice pivoting. And in the Operation Cedar Lattice narrative, the Diamond Model is how the scattered FIN-LATTICE events become one attributable campaign.

Misconception to kill now. "Shared infrastructure proves the same adversary." It is evidence, not proof — adversaries share, rent, and hijack infrastructure; one C2 IP can host several actors over time. Pivoting generates leads; it does not settle attribution. (Lab 02's extension that infers a conflicting adversary across a cluster encodes exactly this caution.) The strongest pivot is on a TTP (top of the Pyramid of Pain), not on a reusable IP.

Chapter 7: The Mandiant Attack Lifecycle

Zero background. Mandiant — the firm running Operation Cedar Lattice — publishes its own lifecycle model, refined over thousands of real incident responses and summarized annually in M-Trends. It is the vendor lens you will speak in on this engagement.

The Mandiant Attack Lifecycle:

  Initial Recon  →  Initial Compromise  →  Establish Foothold
                                                 │
                                                 ▼
        ┌─────────────────  THE INNER LOOP  ─────────────────┐
        │  Escalate Privileges → Internal Recon →            │
        │  Move Laterally → Maintain Presence                │
        └──────────────────────  ↺  ──────────────────────────┘
                                                 │
                                                 ▼
                              Complete Mission (exfil / impact)

Why it differs from the Lockheed kill chain — the LOOP. The Lockheed chain is linear (seven phases, once). Mandiant's key contribution is the explicit inner loop: after the foothold, the actor cycles escalate → recon → move laterally → maintain presence repeatedly, ratcheting through the environment one host and one credential at a time, until it reaches the data. This matches what real intrusions look like far better than a single linear pass.

Under the hood — why the loop matters for the defender. Because the actor loops, the defender gets many chances at the same detection. Every lateral movement is another logon event; every privesc is another integrity-level change; every "maintain presence" is another persistence artifact. A SOC that misses the first lateral move can still catch the third. The loop is also why dwell time (the time from initial compromise to detection — a headline M-Trends metric) is the number that matters: the longer the actor loops undetected, the deeper it gets.

Mapping the three frameworks together (you will be asked this in interviews):

Engagement significance. When you brief Meridian, you will narrate the engagement in the Mandiant lifecycle (because that is the firm's house language and the client expects it), map each step to ATT&CK (for the technical detail and detection), and use the kill chain for the executive arc. Three lenses, one story.

Misconception to kill now. "These three models contradict each other." They are the same intrusion at different resolutions and from different houses. Knowing how to slide between them — and which to use for which audience — is a core consulting skill.

Chapter 8: The Pyramid of Pain

Zero background. David Bianco's Pyramid of Pain ranks the types of indicators you can detect or block by how much pain it causes the adversary when you do. Pain = how hard/expensive it is for the actor to change that indicator and keep operating.

                ▲  most pain to the adversary
          ┌───────────┐
          │   TTPs    │   tough!!!   (behaviors — change = redesign the operation)
          ├───────────┤
          │  Tools    │   challenging  (the actor must find/build a new tool)
          ├───────────┤
          │ Network/  │   annoying   (rotate the C2 domain/IP)
          │ Host arts │
          ├───────────┤
          │ Domain    │   simple     (register a new domain)
          │ names     │
          ├───────────┤
          │ IP addrs  │   easy       (new IP in minutes)
          ├───────────┤
          │  Hashes   │   trivial    (recompile → new hash instantly)
          └───────────┘
                ▼  least pain

Why it exists. Most immature detection blocks the bottom of the pyramid — hashes and IPs — because they are easy to collect and share. But they are also trivial for the adversary to change. Block FIN-LATTICE's malware hash and it recompiles in seconds; block its C2 IP and it rotates in minutes. The pyramid's message: the higher you detect, the more durable your win and the more the adversary suffers. Detect a TTP — "any process opening a handle to LSASS with these access rights" — and the actor must redesign how it steals credentials, which is expensive and slow.

Under the hood — why TTP detection is hard but worth it. Bottom-of-pyramid indicators are exact-match (a hash either matches or not) — easy to write, easy to evade. TTP detection is behavioral — it describes what the technique does, independent of the specific binary or address. Writing it requires understanding the technique's mechanism (which is what the rest of this curriculum teaches), and it is harder to make low-false-positive. But once it works, it catches every variant of the behavior, including ones you have never seen. This is precisely why ATT&CK (which catalogs techniques, i.e., the TTP layer) is the right altitude for detection.

Connection to emulation and the labs. When you choose what to emulate and what detections to recommend, aim at the top of the pyramid. A FIN-LATTICE emulation that only checks "do we block the known hash?" tests nothing durable; one that checks "do we detect the behavior of credential dumping, lateral movement, and beaconing?" tests defenses the actor cannot trivially evade. The Lab extensions that rank steps by Pyramid level and weight Diamond pivots by indicator type encode this: a pivot on a shared TTP is a far stronger lead than a pivot on a shared IP the actor rotates daily.

Engagement significance. In the report, the pyramid justifies prioritization: "Your detections are concentrated at the IP/hash layer (easy for the adversary to defeat). We recommend investing in TTP-layer detections for credential access and lateral movement, which FIN-LATTICE cannot evade without re-engineering." That is a staff-level, business-framed recommendation.

Misconception to kill now. "More indicators = better detection." No — higher indicators are better. A thousand hashes are worth less than one solid behavioral analytic for LSASS access.

Chapter 9: From CTI to an Emulation Plan — the Workflow

Zero background. This is the chapter that ties the phase together and that Lab 01 implements. The input is CTI on a named actor; the output is a runnable, ordered, detection-paired emulation plan. Here is the full workflow.

Step 1 — Select the actor and gather CTI. Why this actor? Because the client faces it (sector, geography, motivation). The CTI is a structured profile: the actor's observed ATT&CK techniques (procedures rolled up to technique ids) and known infrastructure/tooling patterns. For Operation Cedar Lattice the actor is FIN-LATTICE, with profile T1566 → T1059 → T1003 → T1021 → T1071 → T1486 (phish → execute → dump creds → move laterally → beacon → ransom — a canonical financial chain). Sources: CTID Adversary Emulation Plans, vendor intel reports, M-Trends, the actor's ATT&CK Group page.

Step 2 — Map procedures to ATT&CK. Each observed procedure becomes a (sub-)technique id with a tactic. This is classify(tid) in Lab 01: id → {name, tactic, order, procedure, telemetry, detection}.

Step 3 — Order along the lifecycle. Group the techniques by tactic and sequence them by tactic order so the plan reads as one campaign. This is build_plan (sort by (order, technique) and number the steps). The plan is now a narrative, not a list.

Step 4 — Write a procedure per step. Exactly what will you run on the owned range? Not "do phishing" but "send the seeded pretext from owned infra to a seeded mailbox in the range." Procedures must be safe (synthetic/owned only), specific, and scoped.

Step 5 — Pair each step with telemetry + a detection idea. What does this behavior emit, and what should fire? This is the column that makes the plan a purple-team artifact. T1003 → "Sysmon EID 10 LSASS handle access" → "Credential Guard + LSASS PPL + alert on LSASS handle opens." Without this column the plan is just an attack script and fails this track's bar.

Step 6 — Define success criteria and stop conditions. Success is two things: the procedure ran and you observed whether the detection fired (_success_criteria in Lab 01). Stop conditions (from Phase 00's ROE) bound the run: data limits, blast-radius limits, time windows, and the deconfliction contact. No step runs without a stop condition.

Step 7 — Score coverage and gaps. coverage_summary (techniques per tactic) and coverage_gaps (lifecycle tactics the actor never exercises) produce the Navigator view: what this emulation tests and what it leaves untested.

The whole workflow, as a pipeline:

CTI profile (actor + observed technique ids)
        │  classify(tid)            → technique + tactic + telemetry + detection
        ▼
ordered emulation plan              ← build_plan (sort by lifecycle order, number steps)
        │  + procedure per step
        │  + telemetry + detection  (the pairing)
        │  + success criteria + stop conditions
        ▼
coverage_summary / coverage_gaps    → ATT&CK Navigator layer (coverage + gaps)
        ▼
RUN on owned range → observe telemetry → score detection → purple-team replay (Chapter 11)

Engagement significance. This pipeline is the Phase 01 deliverable for Operation Cedar Lattice. Everything downstream executes Step "RUN" of this plan, host by host, and the report scores Step "score detection," technique by technique.

Misconception to kill now. "The CTI technique list is the plan." The list is Step 1. The plan is Steps 2–7. The work — and the value — is in the ordering, the procedures, the detection pairing, the success criteria, and the coverage scoring. That work is Lab 01.

Chapter 10: Emulation vs Simulation vs Pentest vs Red Team vs Vuln Scan

Zero background. These terms are used loosely in the market and precisely in a Mandiant engagement. Getting them right is a credibility marker in interviews and scoping calls.

The key distinctions:

• Emulation vs pentest. A pentest hunts whatever is exploitable to reach a goal; it may use a zero-day the actor would never touch. Emulation deliberately constrains itself to the actor's tradecraft — even taking a harder path — because the point is to test the specific threat, not to find the easiest win. A pentest optimizes for "did we get in?"; emulation optimizes for "did the defender see the behaviors this actor uses?"
• Emulation vs simulation. Often used interchangeably. The careful distinction: emulation reproduces a specific named actor's procedures as faithfully as safe; simulation exercises a representative set of TTPs without claiming actor fidelity (e.g., an automated breach-and-attack- simulation tool firing a battery of Atomic tests). Emulation is higher-fidelity and intel-driven.
• Red team vs emulation. A red team assessment is the broad category (goal-oriented, tests detection/response, often covert). Adversary emulation is a methodology a red team uses — specifically, an intel-driven one anchored to a named actor. Mandiant red teams do emulation.
• All four vs a vuln scan. A scan finds potential weaknesses with no demonstrated impact and no test of detection. The others demonstrate and (the top three) test the defender's response.

Engagement significance. When Meridian asks "is this a pentest?", the correct answer is: "No — this is adversary emulation: we are reproducing FIN-LATTICE's specific tradecraft, driven by intelligence, to measure whether your detection and response would stop that actor, and to leave you durable detections." That sentence is the whole value proposition.

Misconception to kill now. "Red team / pentest / emulation are the same thing with fancier names." They differ in what drives the technique selection and what the output measures. Conflating them leads to scoping a pentest and calling it an emulation — and delivering a list of bugs where the client needed a detection-gap map.

Chapter 11: Threat-Informed Defense and Purple Teaming

Zero background. Threat-informed defense is the discipline of prioritizing your defenses by the behaviors of the adversaries you actually face, using ATT&CK as the common map. Instead of "harden everything" (impossible) or "buy the product the vendor pushes," you ask: which techniques do the actors targeting my sector use, and do I detect them? The answer drives investment.

Why it exists. Defense budgets are finite and the attack surface is infinite. Threat-informed defense is the answer to "where do I spend first?" — and adversary emulation is how you measure whether the spend worked. The two are a loop: emulate → find gaps → invest in detections → re-emulate.

Purple teaming — the loop made collaborative. Classic red/blue is adversarial and serial: red attacks covertly, blue tries to catch them, then a report lands weeks later. Purple teaming is collaborative and real-time: red and blue sit together. Red runs an ATT&CK technique; blue watches their tooling live; together they answer did the data source fire? did the rule alert? was it actioned? If not, they write the detection on the spot, red re-runs the technique, and they confirm it fires. The gap becomes a durable detection in hours, not weeks.

The purple-team loop, per technique:

1. red runs the technique on the owned range (from the emulation plan, Chapter 9)
2. blue observes their telemetry: did the EXPECTED data source produce the event?
        ├─ no  → VISIBILITY GAP   (the sensor isn't collecting it) → deploy/configure the sensor
        └─ yes → did a detection FIRE?
                ├─ no  → DETECTION GAP (no rule) → write the rule now
                └─ yes → was it ACTIONED? → tune the response/playbook
3. write/tune the detection
4. red RE-RUNS the technique → confirm the detection fires (regression)
5. record the result on the ATT&CK Navigator layer (red→green) — a DURABLE artifact the client keeps

Under the hood — why this maps onto the labs. Lab 01's success_criteria is exactly the purple question: did the procedure run AND was the expected telemetry observed, and did the detection fire? Lab 02's earliest_break and reconstruct give the blue side the narrative: here is how far the emulated actor got, and the earliest stage we should have stopped it. Together they are the inputs to the purple replay.

Telemetry / detection — the three outcomes again. The purple loop is the only honest way to know which of the three states (DETECTED / VISIBLE-ONLY / BLIND, Chapter 5) you are really in. A Navigator layer colored from belief is fiction; one colored from a live purple run is evidence.

Engagement significance. The purple-team replay is the Phase 12 close of Operation Cedar Lattice and the reason the engagement creates lasting value: Meridian does not just learn it was breached in the exercise — it leaves with new, tested detections for FIN-LATTICE's techniques, written and regression-confirmed with its own team. That is the difference between "we got domain admin" and "you now detect the actor that targets you."

Misconception to kill now. "Purple teaming is just red and blue in the same room." The room is not the point — the per-technique detect-tune-rerun-confirm loop is. Without the loop, you have a demo, not a detection.

Lab Walkthrough Guidance

Tackle the labs in order; together they implement the two halves of the methodology — building the plan (Lab 01) and reading the resulting campaign (Lab 02).

Lab 01 — CTI-to-Emulation-Plan Builder. Implement in this order:

1. classify(tid) first — every other function calls it. Look the id up in CORPUS; fall back to UNKNOWN so an unmapped id never crashes the plan. Set order from the tactic's index, or len(TACTIC_ORDER) for unknown so it sorts last. (Chapter 4.)
2. detection_for(tid) — a one-liner over classify; it is the purple-team pairing for a step (Chapter 11).
3. build_plan(actor_tids) — de-duplicate, classify, attach success_criteria, sort by (order, technique), number the steps. This is the CTI→plan workflow (Chapter 9). Determinism comes from the total-order sort key.
4. tactics_covered and coverage_summary — the Navigator coverage view (Chapter 5). Remember to drop unknown from tactics_covered.
5. coverage_gaps — the threat-informed-defense "what would we miss?" question (Chapters 5, 11). The reference frame is TACTIC_ORDER (or a caller-supplied subset); only count placeable tactics.

Lab 02 — Kill-Chain Campaign Reconstructor + Diamond Pivot. Implement in this order:

1. classify, then reconstruct (sort by (order, timestamp, event_id); carry the Diamond features through) — the kill-chain ordering (Chapters 2, 3).
2. tactics_reached, furthest_tactic ("how far along?"), earliest_break ("defend left" — the cheapest break point and its control). Note furthest_tactic/earliest_break ignore unplaceable (unknown) techniques — you cannot claim a stage you cannot map (Chapter 2).
3. pivot(events, on=...) — the Diamond Model move (Chapter 6): union-find over events sharing a non-None infrastructure or capability, returning clusters of size ≥ 2, sorted, deterministic. Raise ValueError on an unsupported feature.

Run LAB_MODULE=solution pytest -q first to see the reference pass, then fill in lab.py and run pytest -q.

Success Criteria

You understand this phase when you can, without notes:

• Recite the attacker lifecycle stage by stage and give, for each, the goal, a technique, the telemetry, and the break-the-chain control (Chapter 2).
• State what question each of the three lenses answers and use them together to narrate one intrusion (Chapters 3, 4, 6, 7).
• Read an ATT&CK id at all four levels (tactic / technique / sub-technique / procedure) and name the data source that observes it (Chapter 4).
• Explain coverage vs gaps and the three detection states (detected / visible-only / blind) on a Navigator layer (Chapter 5).
• Pivot a set of events in the Diamond Model and explain why shared infrastructure is evidence, not proof of a shared adversary (Chapter 6).
• Walk the CTI→emulation-plan workflow end to end and explain why each step exists (Chapter 9).
• Distinguish emulation / simulation / pentest / red team / vuln scan crisply (Chapter 10).
• Run a purple-team loop and explain how it turns a gap into a durable detection (Chapter 11).
• Pass both labs with your own implementation and explain why each design choice (ordering, determinism, unknown-handling, the detection pairing) is there.

Common Mistakes and OPSEC Failures

• A list is not a plan. Handing over the CTI technique list and calling it an emulation plan. The ordering, procedures, detection pairing, success criteria, and coverage are the work.
• Mapping to a tactic but not to telemetry/detection. ATT&CK without the data source is half the value and fails the detection-pairing bar (Chapters 4, 5).
• Defending right. Building the impact-stage detection while the cheap initial-access break point goes untested ("defend left", Chapters 2, 3).
• Bottom-of-pyramid detections. Recommending hash/IP blocklists as if they were durable wins (Chapter 8).
• Treating pivoting as attribution. Concluding "same adversary" from shared infrastructure (Chapter 6). Pivoting generates leads; attribution needs more.
• Calling a pentest an emulation. Selecting techniques by "what's exploitable" instead of "what this actor does" (Chapter 10).
• A purple session without the loop. Red and blue in a room but no per-technique detect-tune-rerun-confirm cycle (Chapter 11).
• OPSEC: running a procedure with no stop condition or deconfliction. Every step in the plan must carry the Phase 00 stop conditions and the deconfliction contact. If you cannot name the owner, scope, stop conditions, and deconfliction contact for a step, you do not run it.
• Reusing real infrastructure or data in fixtures. The labs and the plan are synthetic/owned only; a real C2 IP or real victim name in a fixture is a safety failure, not a detail.

Interview Q&A

Q1. Explain the Cyber Kill Chain, MITRE ATT&CK, and the Diamond Model — what does each answer and how do you use them together? The Cyber Kill Chain (Lockheed) models an intrusion as seven linear phases (recon → weaponization → delivery → exploitation → installation → C2 → actions on objectives). It answers "how far along is this intrusion, and where is the cheapest place to break it?" — its central lesson is "defend left": break an early phase and you prevent everything downstream. It is coarse but executive-legible. MITRE ATT&CK is a knowledge base of real adversary behaviors organized as tactics (goals) → techniques → sub-techniques → procedures. It answers "what specific behavior is this, what data source sees it, and can we detect it?" — it is the technique-level detail and the common language the kill chain lacks. The Diamond Model describes a single event as adversary/capability/infrastructure/ victim and answers "what else is connected to this?" via pivoting on shared infrastructure or capability — the engine of campaign correlation and attribution. They are complementary resolutions, not rivals: I use the kill chain for the narrative arc and "break early," ATT&CK for behavior-to-detection mapping, and the Diamond Model to link scattered events into one campaign. On a real engagement I narrate in the Mandiant lifecycle, map technical detail to ATT&CK, and frame the arc with the kill chain.

Q2. Walk me from CTI on a named actor to a runnable emulation plan. Seven steps. (1) Select the actor and gather CTI — chosen because the client faces it; the CTI is the actor's observed ATT&CK procedures plus its infra/tooling patterns. (2) Map procedures to ATT&CK — each becomes a (sub-)technique id with a tactic. (3) Order along the lifecycle — group by tactic, sequence by tactic order so the plan reads as one campaign. (4) Write a procedure per step — exactly what runs on the owned range, safe and scoped. (5) Pair each step with the telemetry it emits and a detection idea — the column that makes it a purple artifact, not an attack script. (6) Define success criteria and stop conditions — success = the procedure ran and we observed whether the detection fired; stop conditions come from the ROE. (7) Score coverage and gaps — techniques per tactic, and the lifecycle tactics this actor never exercises. That pipeline is exactly what my Lab 01 builder implements; the output is an ATT&CK Navigator layer plus an ordered, detection-paired plan.

Q3. Adversary emulation vs penetration test vs vulnerability scan? A vuln scan enumerates potential weaknesses from a signature database — no demonstrated impact, no test of detection. A pentest has a human exploit weaknesses to a goal via whatever path works, including techniques the real threat would never use — it answers "what can be exploited here?" and optimizes for getting in. Adversary emulation deliberately constrains itself to a named actor's tradecraft, driven by CTI, even taking a harder path — because the goal is to measure whether the client detects and stops that specific actor's behaviors and to leave durable detections. The pentest optimizes "did we get in"; emulation optimizes "did the defender see the behaviors this actor uses." A red team assessment is the broad goal-oriented category; emulation is the intel-driven methodology a Mandiant red team uses within it.

Q4. What is the Pyramid of Pain and how does it change which detections you prioritize? It ranks indicators by how much pain it costs the adversary to change them: hashes (trivial — recompile) → IPs (easy) → domains (simple) → host/network artifacts (annoying) → tools (challenging) → TTPs (tough). Most immature detection lives at the bottom (hashes/IPs) because they are easy to collect and share — and trivial for the actor to rotate. The lesson: detect higher. A behavioral analytic for the TTP of credential dumping catches every variant and forces the actor to redesign how it steals creds, which is expensive. So in an emulation I recommend investing in TTP-layer detections (which ATT&CK catalogs) for the actor's core behaviors — credential access, lateral movement, beaconing — rather than feeding the SOC another hash blocklist. I also weight Diamond pivots by pyramid level: a pivot on a shared TTP is a far stronger lead than one on an IP the actor rotates daily.

Q5. A SOC hands you 200 scattered alerts from one night. How do you reconstruct the campaign, decide how far the actor got, and choose where to break the chain? First I classify each alert to an ATT&CK technique and tactic, then reconstruct by ordering them along the lifecycle (tactic order, then time) so the pile becomes one narrative — this is my Lab 02 reconstruct. The furthest tactic reached ("how far along?") is the deepest placeable stage; I won't claim a stage I can't map. The earliest break point is the lowest-order stage observed and its control — "defend left," because a control there prevents everything downstream and is the cheapest fix. Then I pivot in the Diamond Model: take a strong indicator (a C2 IP) and find every other alert that touched it, so I scope the whole intrusion, not just the alerts I happened to see — pivoting is transitive, so one shared indicator can stitch a dozen alerts into one campaign. I'd caution that shared infra is evidence, not proof of one adversary. The deliverable is the ordered narrative, the furthest-reached stage, the earliest break point with its control, and the pivoted scope.

Q6. What is threat-informed defense, and how does a purple-team replay produce a durable detection? Threat-informed defense prioritizes defenses by the behaviors of the adversaries you actually face, using ATT&CK as the map — the answer to "where do I spend first?" when the attack surface is infinite. Emulation measures whether the spend worked; the two form a loop: emulate → find gaps → invest → re- emulate. A purple-team replay makes that loop collaborative and real-time: red runs a technique on the owned range while blue watches live; together they ask did the expected data source fire (no → visibility gap, deploy a sensor), did a rule alert (no → detection gap, write the rule now), was it actioned (no → tune the playbook). They write the detection on the spot, red re-runs the technique to confirm it fires (regression), and they record it on the Navigator layer red→green. The durability comes from that detect-tune-rerun-confirm loop and from aiming the detection at the TTP layer — the client leaves with tested detections for the actor that targets it, not a slide deck.

Q7. How does the Mandiant Attack Lifecycle differ from the Lockheed kill chain, and why does the loop matter? The Lockheed chain is linear — seven phases, traversed once. Mandiant's lifecycle adds an explicit inner loop: after establishing a foothold, the actor cycles escalate-privileges → internal-recon → move-laterally → maintain-presence repeatedly, ratcheting through the environment host by host until it reaches the objective. That matches real intrusions far better. The loop matters defensively because it gives the SOC many chances at the same detection — every iteration is another logon, another persistence artifact, another integrity-level change — so missing the first lateral move doesn't mean losing; you can catch the third. It is also why dwell time is the headline metric: the longer the actor loops undetected, the deeper it gets. In a briefing I narrate in the Mandiant lifecycle (the client's house language), map the detail to ATT&CK, and use the kill chain for the executive arc.

Q8. Why does every step of your emulation plan ship a detection, and what makes a coverage map honest? Because the deliverable is a detection-and-response assessment, not a trophy. An ATT&CK mapping without the data source and a detection idea is half-finished — it tells the client a behavior happened but not how they'd have seen it. Pairing each step with the telemetry it emits and a detection turns the plan into a purple-team artifact and makes the offensive knowledge a defensible asset, which is the whole ethos of this work. A coverage map is honest only when it distinguishes three states: detected (data source collected and a rule fires), visible-only (collected but no rule — a detection gap, costs a rule), and blind (not even collected — a visibility gap, costs a sensor). Reporting "no coverage" without that distinction gives the client a worse, more expensive remediation than necessary — and a map colored from belief rather than a live purple run is fiction.

References

Primary sources — read the originals, not summaries.

• MITRE ATT&CK — the Enterprise matrix, technique pages (tactic, data sources, detection, mitigations, procedure examples), and the STIX 2.1 bundle. attack.mitre.org.
• ATT&CK Navigator — the layer tool and its JSON layer format. mitre-attack.github.io/attack-navigator.
• Center for Threat-Informed Defense (CTID) — the Adversary Emulation Library (per-actor emulation plans), the Top ATT&CK Techniques methodology, and ATT&CK Flow.
• Atomic Red Team (Red Canary) — small, ATT&CK-mapped, runnable tests; the model for per-technique procedures.
• Hutchins, Cloppert, Amin (Lockheed Martin) — Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains (the Cyber Kill Chain paper, 2011).
• Caltagirone, Pendergast, Betz — The Diamond Model of Intrusion Analysis (2013).
• Mandiant — M-Trends annual reports and the Mandiant Attack Lifecycle (dwell-time metrics, the inner loop).
• David Bianco — The Pyramid of Pain (2013/2014).
• MITRE D3FEND — the defensive technique counterpart of ATT&CK (the mitigation/detection mapping).
• Vest & Tubberville — Red Team Development and Operations (engagement methodology, ROE, reporting).
• VECTR / Scythe purple-team material — the per-technique detect-tune-rerun-confirm loop and coverage tracking.