What is the difference between the Cyber Kill Chain and MITRE ATT&CK?

The Kill Chain is a linear, seven-stage narrative of an intrusion's shape. ATT&CK is a much larger, non-linear matrix of specific, observed techniques mapped to tactics, with no fixed sequence. The Kill Chain is useful for explaining defense-in-depth to a non-technical audience; ATT&CK is useful for the operational work of detection engineering, because it names the actual technique, not just the stage.

Does the Cyber Kill Chain still apply to ransomware and cloud breaches?

Only loosely. It was built around a malware-delivery intrusion with a defined perimeter. A breach that starts with a stolen cloud credential or a misconfigured storage bucket skips delivery and exploitation entirely -- the attacker is already inside using a valid identity. The model's stages don't map cleanly, which is its most common criticism.

How does the Cyber Kill Chain apply to threat modeling?

It's a useful lens for reviewing an attack tree: walk each root-to-leaf path and ask which kill-chain stage each step represents. A path where every stage has an existing control is well covered. A path where one stage has nothing standing in the way -- often command-and-control egress -- is where to prioritize the next mitigation.

What Is the Cyber Kill Chain?

Q: What is the Cyber Kill Chain?

A seven-stage model of how an intrusion progresses -- reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objectives -- developed by Lockheed Martin in 2011. Each stage has to succeed before the next one can happen, which is the model's central point: a defender doesn't have to stop the whole attack, just one stage of it.

An intrusion isn't one event — it's a sequence, and every stage in that sequence has to succeed before the next one can start. The Cyber Kill Chain, developed by Lockheed Martin in 2011 and borrowed from military targeting doctrine, names seven of those stages in order. Its point isn't really the taxonomy. It's the conclusion that falls out of treating an attack as a chain: an attacker needs every link to hold, but a defender only needs to break one.

Quick definition: The Cyber Kill Chain is a seven-stage model of how an intrusion unfolds — reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objectives. Each stage depends on the one before it, which reframes defense as interrupting any single stage rather than stopping the attacker outright.

The seven stages

Reconnaissance. Identifying and researching the target — employee names and email formats from LinkedIn, exposed subdomains, software versions leaking through response headers, anything that narrows down an entry point.
Weaponization. Pairing a working exploit with a delivery vehicle, done entirely offline — a malicious macro embedded in a document, an exploit bundled into a dropper.
Delivery. Getting the weaponized payload to the target: a phishing email attachment, a link to a compromised site, a USB drop, an exposed service with a known vulnerability.
Exploitation. The payload actually runs — the macro executes, the vulnerability triggers, code runs on the target system for the first time.
Installation. The attacker establishes persistence — a scheduled task, a registry run key, a web shell — so access survives a reboot or a closed session.
Command and control (C2). The compromised system phones home, giving the attacker a remote channel to issue further instructions.
Actions on objectives. Whatever the attacker was actually after — data exfiltration, lateral movement toward a higher-value target, encryption for ransom, or sabotage.

Why the sequencing is the useful part

Treat the seven stages as a checklist and the model doesn't add much — most of it restates what any incident responder already knows. The reframe is what matters: because each stage is a prerequisite for the next, an intrusion that gets caught at delivery never reaches exploitation, no matter how effective the payload would have been. A defender doesn't need a control that stops "the attack." They need one control, anywhere along the chain, that the attacker can't get past — email filtering to block delivery, application allowlisting to block exploitation, egress filtering to block command and control. Different teams, different tools, different budget lines, all contributing to the same chain, and any one of them succeeding is enough.

This is also why it's a useful way to explain defense-in-depth to people who don't think about security for a living: not "we have a firewall so we're covered," but "we have something at four different stages of this sequence, so a single failure anywhere doesn't equal a breach."

Cyber Kill Chain vs. MITRE ATT&CK

These get confused because they're both about attacker behavior, but they solve different problems. The Kill Chain is a fixed, linear narrative — seven stages, always in that order, useful precisely because it's simple enough to reason about in a design review or explain to an executive. MITRE ATT&CK is the opposite: a large, continuously updated matrix of specific, individually observed techniques, organized into tactics with no required order, because real intrusions don't move through them in a straight line — an attacker might re-run reconnaissance mid-intrusion, or skip straight to actions on objectives if the "exploitation" was really just a re-used, already-valid credential.

In practice they're complementary rather than competing: the Kill Chain gives you the shape of the story, ATT&CK gives you the specific, checkable technique inside each part of that story — see what TTPs are for how those techniques get named and mapped once you're past the narrative stage.

Where the model breaks down

The Kill Chain was built around a specific shape of intrusion: malware delivered across a network perimeter into an environment with a meaningful inside-versus-outside boundary. A lot of the highest-impact breaches of the last several years don't look like that. An attacker who buys a leaked password and logs into a SaaS admin console with valid credentials never delivers a payload or exploits anything — they walk in through the front door the same way a legitimate user does, and "installation" and "command and control" don't really apply to a session inside a browser. A misconfigured cloud storage bucket that's simply public doesn't have a kill chain at all; there's no sequence to interrupt, only a door that was never closed. Living-off-the-land techniques — an attacker using only tools already present on the system, like PowerShell or a legitimate admin utility — can blur exploitation and installation into something that barely registers as either.

None of that makes the model wrong, but it does mean treating it as a complete map of how modern breaches happen will leave real gaps. It's best read as one lens among several — useful for organizing thinking about a classic delivery-and-exploit intrusion, and worth pairing with a model that handles identity-based and cloud-native attack paths, which is most of what actually shows up in breach reports now.

Using it inside a threat model

The most direct use is as a review lens for an attack tree you've already built: walk each root-to-leaf path and label which kill-chain stage each step represents. A path where every stage lands on an existing control — filtering at delivery, allowlisting at exploitation, egress rules at command and control — is genuinely well covered. A path where one stage has nothing standing in front of it is where to spend the next mitigation, and in practice that gap is very often command-and-control egress: teams spend heavily on stopping delivery and exploitation and leave outbound traffic from compromised hosts almost entirely unfiltered.

Because the model assumes a perimeter and a malware-delivery path, it's least useful as-is for identity-centric environments — see threat modeling for SaaS for how attack paths built on valid credentials and API tokens need a different framing than "delivery" and "exploitation."