Cyber Kill Chain and Diamond Model Guide: Frameworks for Analysing Intrusions

Security teams collect alerts and indicators by the thousand but often cannot say how far an intrusion progressed, what else the same adversary did, or which defence would have stopped it earliest. The Lockheed Martin Cyber Kill Chain and the Diamond Model of Intrusion Analysis are the two classic models for answering those questions: the first orders an intrusion in time, the second connects the adversary, their capability, their infrastructure and the victim. This guide explains both models from their original papers, how they relate to MITRE ATT&CK and the Unified Kill Chain, how to apply them to identity-based and non-human identity (NHI) intrusions where there is no malware to find, and how to build them into incident analysis and detection planning. It is for SOC analysts, incident responders, threat intelligence analysts and the security leaders who use their output; the wider intelligence programme is covered in the Threat Intelligence Guide.

Key takeaways

• The kill chain is about sequence and defensive coverage. Hutchins, Cloppert and Amin described seven phases and argued that a single effective mitigation at any phase breaks the chain.
• The Diamond Model is about relationships. Every intrusion event links an adversary, a capability, infrastructure and a victim, and analysts pivot across those links to find related activity.
• Use them together with ATT&CK. MITRE describes the kill chain as a high-level lifecycle model and ATT&CK as a mid-level model that maps individual adversary actions to defences.
• Identity intrusions compress the early phases. When the "weapon" is a stolen password, token or API key, delivery and exploitation collapse into a login, so detection must shift to identity behaviour.
• Reconstruct every phase, including blocked attempts. The original paper stresses that detection late in the chain means the earlier phases already succeeded and must be analysed too.

What it is and who it applies to

Both models are analytic frameworks, not standards with compliance obligations. They apply to any organisation that investigates intrusions or plans detection coverage, from a two-person security team using them as a whiteboard structure to a national CERT using Diamond activity groups to track campaigns.

Structure and key requirements

The seven kill chain phases

The paper's second contribution is the courses of action matrix: for each phase, the defender lists what can detect, deny, disrupt, degrade, deceive or destroy the activity, terms borrowed from US information operations doctrine. Gaps in the matrix are gaps in resilience. The paper also defines three indicator types used throughout: atomic (such as an IP address or email address), computed (such as a file hash or regular expression) and behavioural (combinations of the two with logic or thresholds). Finally it describes campaign analysis: comparing intrusions over time to find the key indicators that recur, which reveal the adversary's tactics and intent without needing to name them.

The Diamond Model

• Core features: adversary (split into the operator who conducts the intrusion and the customer who benefits), capability (tools and techniques, with command and control treated as part of capability), infrastructure and victim (split into persona, the people and organisations, and assets, the attack surface).
• Infrastructure types: Type 1 is owned or controlled by the adversary; Type 2 is operated by a witting or unwitting intermediary, such as compromised hosts or staging servers, which obscures the true origin.
• Meta-features: timestamp, phase, result, direction, methodology and resources, each recorded per event, plus a confidence value whose scale the paper leaves to implementers.
• Extended axes: the social-political axis (the adversary-victim relationship and why the victim was chosen) and the technology axis (the protocols and systems linking capability to infrastructure).
• Activity threads: phase-ordered graphs of events for one adversary-victim pair, with arcs labelled as actual or hypothesised and joined by AND or OR logic, which act as intelligence-driven attack graphs.
• Activity groups: clusters of events and threads that share features, built in six steps from the analytic problem through feature selection, creation, growth, analysis and redefinition.
• Pivoting: moving from one known feature to a connected one, for example from a known infrastructure address to other victims contacting it. The paper describes victim-, capability-, infrastructure-, adversary-, social-political- and technology-centred approaches.

The models fit together naturally: the Diamond's "phase" meta-feature can use kill chain phases or ATT&CK tactics, so each Diamond event is placed in sequence and an activity thread becomes a kill chain populated with evidence.

Identity and NHI requirements

The 2011 kill chain was built around malware delivered by spear-phishing. Many current intrusions use none: the adversary logs in. Applying the models well means adapting them to identity.

• Delivery and exploitation become a login: with Valid Accounts (T1078) or Cloud Accounts (T1078.004), phases 2 to 4 compress into one authentication event. Record the credential itself as the Diamond capability and the login source as infrastructure.
• Installation becomes persistence on the identity: instead of a backdoor, adversaries add credentials to an application, register a new OAuth grant or change account settings (Account Manipulation, T1098). The SolarWinds compromise shows both worlds: signed SUNBURST updates followed the classic chain, then the attackers forged SAML tokens and added credentials to existing application service principals to read email as trusted applications.
• Command and control may be the SaaS API itself: a stolen token (Steal Application Access Token, T1528; Application Access Token, T1550.001) lets the adversary operate through the provider's normal API, so there is no beacon to block. Identity provider and SaaS audit logs replace proxy logs as the primary evidence.
• Type 2 infrastructure includes trusted third parties: a compromised vendor integration or partner tenant (Trusted Relationship, T1199) is intermediary infrastructure in Diamond terms and should be modelled that way.
• Victim assets include non-human identities: record service accounts, API keys, OAuth apps and AI agent credentials as assets, because they are often the asset that lets the intrusion reach its objective.

The Colonial Pipeline attack is a compact identity kill chain: access through a legacy VPN account that was no longer used but never disabled and had no MFA, more than a week inside, roughly 100 GB exfiltrated, then ransomware. Under the courses of action matrix, disabling the dormant account would have denied the chain at its first step. See the ITDR Guide for identity-centred detection.

Implementation steps

1. Pick the vocabulary: choose kill chain phases for summary reporting and ATT&CK tactics and techniques for detail, and document the mapping between them (table below).
2. Template the incident record: add Diamond fields (adversary, capability, infrastructure, victim, plus timestamp, phase, result, direction, confidence) to the case management system, so every significant event is captured the same way.
3. Reconstruct full chains: for each confirmed intrusion, populate every phase, marking evidence as observed or hypothesised. Include blocked intrusions; the paper argues they show what the adversary would try next.
4. Build the courses of action matrix: for each phase list current controls under detect, deny, disrupt, degrade, deceive and destroy, and highlight empty cells. Prioritise early-phase deny and detect controls and identity controls that cut several phases at once.
5. Cluster into activity groups: monthly, compare events for shared infrastructure, capability or victim patterns and record activity groups with confidence ratings. Link to named groups only where external reporting supports it; see the Threat Actor Groups Guide.
6. Feed detection engineering: convert recurring key indicators, especially behavioural ones, into detections. See the Detection Engineering Guide.
7. Test the chain: run purple team or tabletop exercises that walk a realistic chain and confirm each planned control fires. See the Purple Teaming Guide.

Piloting: start with retrospective analysis of three to five past incidents before changing live processes; it shows where the templates are too heavy. If analysts find the full Diamond record slows triage, keep it for confirmed intrusions only and use a lighter kill chain tag at alert level.

Choosing a model

• Executive and board reporting: the seven-phase kill chain, because it is short and conveys "how far did they get".
• Detection coverage and engineering: ATT&CK techniques, because controls and analytics map to specific behaviours.
• Campaign tracking and intelligence sharing: the Diamond Model, because it captures relationships and supports pivoting.
• Complex, multi-stage intrusions: the Unified Kill Chain, which reflects that attackers cycle through internal phases such as discovery, privilege escalation and lateral movement more than once.
• Small teams: use the kill chain plus a simple four-field Diamond note per incident; larger teams with a threat intelligence function gain most from activity groups and structured pivoting.

Evidence and assessment

Assess the analysis process the same way as any other control: is it used, is it consistent, and does it change defences?

• Evidence sources by phase: external attack surface and scan logs (reconnaissance); email gateway and web proxy logs (delivery); EDR and application logs (exploitation and installation); DNS, proxy and firewall egress logs (command and control); identity provider sign-in logs, SaaS audit logs and cloud control plane logs (identity phases and actions on objectives).
• Evidence quality: every Diamond feature has a confidence value and a source; hypothesised links are labelled as such.
• Retention: keep logs long enough to reconstruct dwell periods. Where dwell exceeded a week, as at Colonial Pipeline, short retention removes the early phases from view.

Metrics that show the approach is working:

• Phase of first detection: distribution of the kill chain phase at which confirmed intrusions were first detected, trending earlier.
• Reconstruction completeness: percentage of confirmed incidents with all phases populated or explicitly marked unknown.
• Matrix coverage: percentage of phase and action cells with at least one tested control.
• Pivot yield: number of additional events or victims found per intrusion through Diamond pivoting.
• Indicator to detection conversion: share of key behavioural indicators turned into production detections within 30 days.

Mapping to other frameworks

The mapping is approximate: ATT&CK tactics are not strictly ordered, and in ATT&CK v20 the former defence evasion tactic is split into Stealth (TA0005) and Defense Impairment (TA0112). See the MITRE ATT&CK Guide for Defenders, and the MITRE ATLAS Guide for AI-specific techniques.

Common pitfalls

• Treating the kill chain as perimeter-only: teams invest in delivery and exploitation controls and have little coverage for credential abuse and actions on objectives, where identity intrusions spend most of their time.
• Stopping analysis at the detected phase: the alert fired at command and control, so nobody asks how delivery happened or which other users received the same lure.
• Collecting atomic indicators only: IP addresses and hashes change quickly; behavioural indicators and Diamond capability patterns last longer.
• Overconfident attribution: naming an adversary from one shared infrastructure feature. Diamond confidence values and the operator versus customer distinction exist to prevent this.
• Ignoring non-human identities: service principals, API keys and OAuth grants are left out of victim assets and persistence analysis, so a rotated user password is treated as full containment.
• Diagram without action: a populated kill chain in the incident report that never updates the courses of action matrix or the detection backlog.

Practitioner checklist

• Agree a mapping between kill chain phases, ATT&CK v20 tactics and your case management fields.
• Add Diamond fields and confidence values to the incident record template.
• Reconstruct every phase for confirmed and blocked intrusions, marking hypothesised links.
• Maintain a courses of action matrix and review empty cells quarterly.
• Model stolen credentials and tokens as capability, and non-human identities as victim assets.
• Collect identity provider, SaaS audit and cloud control plane logs with retention that covers realistic dwell time.
• Cluster events into activity groups monthly and pivot on shared infrastructure and capability.
• Convert recurring behavioural indicators into detections and test them in purple team exercises.
• Report phase of first detection and matrix coverage to leadership.

Standards and references

• Lockheed Martin: Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains
• US Department of Defense (DTIC): The Diamond Model of Intrusion Analysis
• MITRE: ATT&CK Design and Philosophy
• MITRE ATT&CK: Enterprise tactics
• Paul Pols: The Unified Kill Chain
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Threat Intelligence Guide · Threat Hunting Guide · Incident Response Guide · Lateral Movement Guide · Ransomware Prevention Guide