Analyst Field Guide · Threat Intelligence
Two problems, one discipline: describe precisely what an adversary did, and reason honestly about who did it. The three frameworks, ATT&CK mechanics, and attribution as a layered, probabilistic judgment — with a worked incident from alert to assessment.
One idea underlies everything here. Indicators — a hash, an IP, a domain — are artifacts of one specific intrusion, and they're cheap for the adversary to change. Behaviors — the techniques and tradecraft, the how — are expensive to change. Every framework in this guide exists to push your analysis up from indicators toward behavior, because behavior-based detection and attribution survive when the adversary rotates infrastructure. Hold that, and the rest follows.
The single most useful model for why this matters is the Pyramid of Pain (Bianco, 2013): it ranks the things you can detect by how much pain it causes the adversary to change them.
This is why "they ran a script / PowerShell execution / fileless attack" — three analysts describing one behavior three ways — is a problem worth solving. A taxonomy is a controlled vocabulary that pins the behavior down so it can be detected, measured, compared, and handed off.
A shared vocabulary for adversary activity buys five concrete things:
A taxonomy is a means, not an end. Teams routinely produce a colourful ATT&CK heatmap, declare victory, and change nothing. A wrong or lazy mapping is worse than none — it manufactures false confidence and pollutes metrics. The discipline: map only what the evidence supports, at the granularity it supports, and tie every label to a decision. If a mapping doesn't change what you detect, hunt, or report, you wasted the effort.
Three frameworks every analyst holds at once. They aren't competitors — they answer different questions and are most powerful stacked.
| Framework | Core question | Shape | Best for |
|---|---|---|---|
| Cyber Kill Chain | What stage is the intrusion at? | Linear lifecycle | Narrative, exec comms, early warning |
| Diamond Model | Who/what/where, and how do the pieces connect? | Relationship graph | Analysis, pivoting, attribution |
| MITRE ATT&CK | What specific behavior occurred? | Behavior catalog | Detection, mapping, coverage, hunting |
Kill Chain is the story · Diamond is the investigation · ATT&CK is the dictionary. You'll usually use all three together on the same incident. (Others you'll meet but shouldn't confuse: VERIS for breach statistics, STRIDE for design-time threat modeling, D3FEND for defensive countermeasures — none is a substitute for the three above.)
Lockheed Martin's model (Hutchins, Cloppert & Amin, 2011) frames an intrusion as seven sequential phases. The doctrine: break any one link, break the chain — and the earlier you break it, the cheaper the outcome.
The chain's one genuinely operational output: pair the seven phases against six defensive actions (from DoD Information Operations doctrine), weakest-to-strongest interference — Detect · Deny · Disrupt · Degrade · Deceive · Destroy. Fill each cell with the specific control you have; the empty cells are your coverage gaps. (Destroy is rarely available to defenders and is legally constrained.)
Where the Kill Chain is a timeline, the Diamond (Caltagirone, Pendergast & Betz, 2013) is a relationship graph for a single intrusion event. Four connected vertices, two axes.
Six meta-features add context to each event — timestamp, phase (maps to a Kill Chain stage, which is how the two frameworks integrate), result, direction, methodology, and resources. And six centered approaches formalize the pivot, one entry point per feature; infrastructure-centered (passive DNS, WHOIS, TLS certs) is usually the most productive, because infrastructure is the most externally observable. The social-political approach is the odd one out — alone it yields hypotheses, not indicators.
MITRE ATT&CK (first released 2013) is a knowledge base of real-world adversary behavior, not a lifecycle. It's hierarchical — internalize the four levels as why / how / specific-how / actual-instance:
| Level | Is the… | ID looks like | Example |
|---|---|---|---|
| Tactic | why — the goal | TA0002 | Execution — run malicious code |
| Technique | how — the method | T1059 | Command & Scripting Interpreter |
| Sub-technique | specific how — a variant | T1059.001 | PowerShell |
| Procedure | actual instance | (not ID'd) | the literal powershell -enc <base64> one-liner |
T-IDs are persistent. A technique's number doesn't change when it's renamed — or even moved to a different tactic. T1059 is T1059 regardless of which column it sits under in a given version. That's why you reference techniques by ID, not name or placement: names and placement drift; the ID is the anchor.
Roughly the order an intrusion progresses — but the columns are categories, not a timeline; adversaries revisit, skip, and loop.
| ID | Tactic | Goal |
|---|---|---|
| TA0043 | Reconnaissance | Gather info to plan |
| TA0042 | Resource Development | Build infra, accounts, capabilities |
| TA0001 | Initial Access | Get in |
| TA0002 | Execution | Run code |
| TA0003 | Persistence | Keep the foothold |
| TA0004 | Privilege Escalation | Higher permissions |
| TA0005 | Stealth | Hide, blend in with normal |
| TA0112 | Defense Impairment | Break defenses & telemetry |
| TA0006 | Credential Access | Steal credentials |
| TA0007 | Discovery | Learn the environment |
| TA0008 | Lateral Movement | Move through |
| TA0009 | Collection | Gather target data |
| TA0011 | Command & Control | Control hosts |
| TA0010 | Exfiltration | Steal data out |
| TA0040 | Impact | Disrupt, destroy, manipulate |
The April 2026 release split the old single "Defense Evasion" tactic: TA0005 kept its ID but was renamed Stealth (concealment/blending), and a new Defense Impairment (TA0112) absorbed the "actively break defenses" behaviors — taking Enterprise from 14 to 15 tactics. If your playbooks or dashboards reference "Defense Evasion," they predate v19 and need review. This is the standing example of why you verify the live matrix before citing tactic placement.
ATT&CK is a graph, not a list, and the relationships are the value. The objects — each a pivot point:
G####) — tracked adversary clusters (e.g. G0016 — APT29). Lists the techniques, software, and campaigns attributed to that cluster in open reporting.S####) — malware and tools (e.g. S0154 Cobalt Strike, S0002 Mimikatz).C####) — time-bounded operations (e.g. C0024 — SolarWinds Compromise).M####) — defenses mapped to the techniques they reduce (e.g. M1017 User Training).The workflow that pays off: in Navigator, build a threat layer (the techniques of the actors that realistically target your sector) → build a coverage layer (your detections) → compare → the uncovered, high-relevance techniques are your detection-engineering backlog. Pull ATT&CK programmatically (STIX 2.1 / TAXII, the mitreattack-python library) rather than hand-copying the website, and pin the version.
Where ATT&CK catalogs what adversaries do, MITRE D3FEND (NSA-funded; reached v1.0 in January 2025) catalogs what defenders do about it — a knowledge graph of countermeasures across seven tactics (Model, Harden, Detect, Isolate, Deceive, Evict, Restore), linked to ATT&CK techniques through a shared "digital artifact" ontology. Practically: take the techniques from your Navigator coverage gap, look up the D3FEND countermeasures that act on the same artifacts, and you get a structured shortlist of defenses to weigh — the bridge from "here's how they'd attack" to "here's what to consider deploying" (which the Detection Engineering guide then turns into actual rules, with its own false-positive discipline). Note the asymmetry: ATT&CK spans three matrices (Enterprise, Mobile, ICS); D3FEND is a single matrix. And like ATT&CK it's versioned and still growing — cite the version rather than assuming a technique exists.
Attribution is not a yes/no fact — it's a layered, probabilistic judgment, in three levels of increasing difficulty and consequence.
Attribution synthesizes evidence across the Diamond's vertices — infrastructure (registration patterns, TLS reuse), capability (code reuse, builder artifacts), victimology (often the strongest signal of intent), and TTPs (the behavioral signature). Strong attribution comes from convergence — multiple independent streams pointing the same way — never from a single artifact.
Attribution is reasoning under uncertainty with an adversary who actively deceives. Four disciplines keep it honest.
Analysis of Competing Hypotheses (Heuer): enumerate all plausible hypotheses up front — including "unknown criminal group" and "false-flag operation" — matrix the evidence as consistent / inconsistent with each, and seek to disprove, not confirm. The surviving hypothesis is the one with the fewest inconsistencies, not the most confirmations. ACH forces you to test the alternative you'd rather ignore.
Two distinct things, routinely conflated. Probability is how likely the judgment is true (a verbal scale: almost no chance · very unlikely · unlikely · roughly even · likely · very likely · almost certain). Confidence is the quality of the evidence and reasoning behind it (low / moderate / high). You can be highly confident that something is unlikely, or hold a likely judgment with low confidence. State both, always: "moderate confidence it is likely…" Never bare-fact attribution; name what would change the call; avoid false-precision numeric scores.
Capable actors plant misleading evidence: reused tools, foreign-language strings, borrowed infrastructure. The canonical case is Olympic Destroyer (2018), salted with artifacts mimicking several actors, which caused public misattribution before deeper analysis untangled it. Single low-pyramid artifacts are cheap to fake; faking infrastructure and deep TTPs and victimology and operational tempo consistently is expensive. Internal inconsistency — tooling of actor A, victimology of actor B, working hours of neither — is the red flag ACH surfaces.
A vendor's group name is that vendor's cluster with that vendor's boundaries — don't blindly merge "the same" group across vendors. Temporary labels (UNC/TEMP/DEV-style) are deliberate placeholders that resist premature closure — good tradecraft. And sometimes the right call is not to attribute: when the evidence supports only clustering, when you can't rule out a false flag, or when a name wouldn't change the response. You patch, contain, and detect the same way regardless of who's behind it.
A manufacturing SOC gets EDR alerts on a finance workstation. Reconstruction: an invoice-themed email with a macro attachment → macros spawned a PowerShell loader → it pulled a beacon → the beacon added a scheduled task → the operator dumped credentials, moved laterally to a file server, staged and compressed data, and exfiltrated over C2 before containment. All three frameworks, stacked:
Kill Chain (exec brief): Delivery (phishing) → Exploitation (macro) → Installation (scheduled task) → C2 (beacon) → Actions (credential theft, lateral movement, data theft). Detected at C2/Actions; contained before full exfiltration.
ATT&CK (detection — v19.1, ID-anchored, evidence-tied): Phishing (T1566) · PowerShell (T1059.001) · Scheduled Task/Job (T1053) · OS Credential Dumping (T1003) · Valid Accounts (T1078) + Remote Services (T1021) · Exfiltration Over C2 Channel (T1041). Data staging left at technique level where the evidence didn't justify a specific sub-technique — honest granularity.
Diamond (pivot): pivot on the C2 domain via passive DNS → two more domains, same registrant pattern → same beacon family → prior victims also regional mid-market manufacturers. Victimology + capability reuse cluster these into one activity group.
Attribution judgment (proper language): "We assess with moderate confidence that this is very likely part of a single activity cluster responsible for at least two prior intrusions against regional mid-market manufacturers, based on shared beacon tooling, consistent C2 registration patterns, and consistent victimology. We make no judgment on sponsorship; the reused loader hash alone is insufficient and could be shared tooling."
ATT&CK tracks the supply-chain operation discovered December 2020 as campaign C0024, attributed to group G0016 (APT29 — also Cozy Bear, The Dukes, NOBELIUM, Midnight Blizzard, UNC2452: one cluster, many vendor names). The nation-level call — attributing it to Russia's SVR — came only in April 2021, from governments drawing on intelligence beyond network forensics. The takeaway: you can track and defend the C0024/APT29 cluster with ATT&CK without making the nation-state call yourself. The defensive actions (detect the techniques, segment, harden the build pipeline) are identical whether or not the name "SVR" is ever spoken.
A mapping that changes no decision was wasted. Map from evidence, not the story in your head. Honest granularity beats impressive granularity — a guessed sub-technique is a fabrication someone downstream treats as fact. Reference by ID; pin the version; re-baseline on every ATT&CK upgrade.
Climb the Pyramid of Pain — block on indicators for speed, detect on behavior for durability. Paper coverage ≠ real coverage; validate by emulation. Document false-positive/false-negative exposure on every rule.
It's a layered judgment, not a fact — cluster (Level 1) is where the value is and where evidence usually stops. Demand convergence; a single artifact is spoofable and maybe planted. Run ACH when stakes are high. Separate observed/inferred/assumed, and probability/confidence, in writing.
You usually don't need attribution to respond — patch, contain, detect regardless. Beware the named-group illusion (a vendor's name is that vendor's cluster). Write for the analyst acting at 3 a.m.: lead with the judgment and the so-what. Verify every ID-specific claim at attack.mitre.org before it goes in a report.
Adapted from the Attack Taxonomy & Attribution guide in this set. ATT&CK content pinned to v19.1 (April 2026); the Defense Evasion → Stealth (TA0005) + Defense Impairment (TA0112) split and the 15-tactic count were verified against MITRE's v19 release. Object IDs (G0016/APT29, S0154/Cobalt Strike, S0002/Mimikatz, C0024/SolarWinds, M1017/User Training) reflect the live knowledge base and open-source reporting, which grows over time. Treat any technique ID, sub-technique number, or tactic placement carried from memory as probably stale — verify against attack.mitre.org before it goes in a report. The SolarWinds → SVR attribution is a public government judgment drawing on non-public intelligence, not a claim reproducible from network artifacts alone. D3FEND is pinned to v1.0 (January 2025); it revises, so verify the current version before citing a countermeasure or tactic. Companion to the Critical Thinking Field Guide (ACH, calibrated probability/confidence), Detection Engineering (turning coverage gaps into validated rules), Incident Response (mapping during an incident), and Root Cause Analysis.