Interpret attack methodology frameworks

Consider a hypothetical endpoint detection and response (EDR) alert: WINWORD.EXE started powershell.exe, followed by outbound network activity. Three questions follow, and each one has its own framework.

• How far has this intrusion got? The Cyber Kill Chain (the Kill Chain from here on) answers with seven ordered phases, from the adversary's first research to the outcome they want.
• What exactly did the adversary do, and why? MITRE ATT&CK (ATT&CK from here on) answers by separating the adversary's goal (a tactic) from the method used to reach it (a technique).
• Is this connected to other activity we have seen? The Diamond Model of Intrusion Analysis (the Diamond Model from here on) answers by relating intrusion events that share features, such as the adversary capabilities^[1] seen in each event.

MITRE treats these models as partners, not rivals: its FAQ calls ATT&CK and the Cyber Kill Chain complementary, with ATT&CK sitting at a lower level of definition to describe adversary behavior^[1], and calls the Diamond Model helpful if you are trying to cluster intrusions^[1]. MITRE's design paper explains the division of labour: high-level lifecycle models such as the Cyber Kill Chain are useful at understanding high level processes and adversary goals, but not at conveying what individual actions adversaries make^[2]. That missing detail is what ATT&CK supplies.

CompTIA's CySA+ V4 exam objectives summary lists "Summarize concepts related to attack methodology frameworks: Models such as MITRE ATT&CK and the Cyber Kill Chain^[3]" under Incident Response and Management (24%). The same domain lists "Outline the incident response process: Phases including preparation, detection, analysis, containment, eradication, and recovery^[3]"; see Explain the incident response process. Those are the responder's phases; the Kill Chain phases are the attacker's steps. Under Security Operations (34%) the summary lists "Explain threat intelligence and threat-hunting concepts: Frameworks, data sources, and methods used to identify and investigate threats^[3]"; see Threat Intelligence and Threat Hunting. That objective lists frameworks alongside data sources and methods^[3] for identifying and investigating threats; the attack methodology frameworks objective quoted above asks you to summarize the models themselves.

The takeaway: identify which of the three questions a scenario is asking before you choose a framework.

The Cyber Kill Chain is Lockheed Martin's model of an intrusion as a fixed sequence of phases, and it is the framework to reach for when the question is how far an attack has progressed. MITRE summarises the difference from ATT&CK in one line: the Cyber Kill Chain uses ordered phases to describe high level adversary objectives^[1]. CISA's analysts use the model to analyze, discuss, and dissect malicious cyber activity^[4], and its GRIZZLY STEPPE analysis report lists the phases as Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, and Actions on the Objective. This page writes the last phase as Actions on Objectives; CISA's wording names the same phase.

Phase	What the adversary is doing	Evidence an analyst may see (examples from the CISA report)
Reconnaissance	Researching the target to decide where or whom to attack	Perimeter vulnerability scans, look-alike (typo-squatting) domains, credential-harvesting pages
Weaponization	Preparing the attack artifact, such as embedding malicious code in a document	Little or nothing at the time: it happens in the adversary's own space; the analyst infers it later from the delivered artifact
Delivery	Moving the artifact to the target	Spear-phishing emails carrying malicious attachments or links
Exploitation	Taking advantage of a weakness so attacker-controlled code runs	Exploits against document software, such as Microsoft Office vulnerabilities
Installation	Placing malware on the victim system	Implants and web shells on hosts or servers
Command and Control (C2)	Directing the compromised system from outside	IP addresses or domains used to send commands to, and receive data from, implants
Actions on Objectives	Carrying out the purpose of the intrusion	Movement of files and user credentials, then exfiltration (data theft) of files, emails, and credentials

The CISA report supplies each example in the right-hand column: network vulnerability scanning and doppelganger domains under Reconnaissance, the note that weaponization actions occur within the adversary space so there is little that can be detected, spear-phishing under Delivery, web shells under Installation, and C2 indicators being the IP addresses or domains used to send and receive commands^[4].

Weaponization happens before anything reaches you, so a defender rarely watches it happen; you deduce it from the artifact that arrives (a macro-laden document was built by someone). Installation means malware is now on the victim system, whether or not it has talked to anyone yet.

The figure below lays the seven phases out in order, with the kind of evidence each one typically leaves. The takeaway: the phases are ordered, and each one is defined by what the adversary has achieved at that point, which is what the next section uses to place evidence.

Assign each piece of evidence to the furthest Kill Chain phase it actually proves, and no further. This section illustrates how to place evidence at different Kill Chain phases without inferring a later phase from an artifact alone.

Evidence you hold	Furthest proven phase	Tempting wrong phase, and why it is wrong
An unknown external host scans your perimeter for open ports and web flaws	Reconnaissance	Exploitation: the scan gathers targeting information; nothing has executed through a weakness
Evidence that an adversary prepared a malicious document before delivery	Weaponization	Installation: building the payload happened on the adversary's side; installation means malware placed on your system
The mail gateway shows the malicious attachment reached a mailbox	Delivery	Exploitation: receipt proves transport, not execution
The document reader on the workstation ran the embedded code	Exploitation	Weaponization: the preparation happened earlier; code running in the victim's application is exploitation
A backdoor service now exists on the host, with no observed traffic	Installation	C2: the backdoor can communicate, but no control channel has been seen
The backdoor receives tasking from an external server	Command and Control	Actions on Objectives: a working channel does not show that the adversary's goal has been met
Targeted business files are staged and sent out	Actions on Objectives	Installation: the adversary is now using the access, not establishing it

In ordinary victim-side telemetry, Weaponization is usually inferred from a delivered artifact rather than observed as the furthest phase; intelligence about preparation on the adversary's side can provide separate evidence.

The CISA report offers two cautions against over-inference: network perimeter scans are often a precursor to network attacks^[4] (scans alone do not prove exploitation), and a TOR exit-node address in a network log only indicates that the related traffic should be reviewed^[4] to decide whether it is legitimate, not that the intrusion has reached a later phase.

Because the Kill Chain uses ordered phases^[1], you can place evidence by asking from the latest phase down, as the simplified question ladder in the figure below shows. Each rung asks about one typical kind of evidence, so before you accept a No and step down, check the table above for other evidence of that phase. The ladder has no Weaponization rung because that phase is usually inferred, not observed as the furthest one. The takeaway: name the phase the evidence proves today, and treat later phases as hypotheses to test, not conclusions to record.

This section covers the defensive side of the Kill Chain, showing where an intrusion can be stopped, not only how to label it. The rule: a phase you missed is not a lost fight, because every later phase is another chance to interrupt the intrusion. If a phishing email slips past the mail filter, blocking the document's code from running, finding and containing the implant, or cutting the control channel can each still stop the operation before the adversary reaches the objective.

The CISA report pairs most phases with a defender action:

Phase	Defender opportunity described by CISA
Reconnaissance	Monitor for traffic to look-alike domains; identify the types of scans run against your perimeter and patch what they reveal
Weaponization	Little to detect: the work happens in the adversary's space
Delivery	Review inbound email subjects, text, and themes associated with the campaign
Installation	Review systems for unauthorized web shells
Command and Control	Use C2 indicators (the IP addresses and domains used to send and receive commands) to find implant traffic
Actions on Objectives	Watch for files and user credentials moving inside the network, which can reveal the activity before exfiltration occurs

Each row comes from the GRIZZLY STEPPE analysis report^[4], including its observation that SOC (security operations center) analysts may be able to detect actions on the objective before data exfiltration occurs^[4]. The report’s Exploitation subsection lists targeted vulnerabilities but no phase-specific detection step, which is why that row is absent; patching those vulnerabilities is a preventive control there.

Avoid planning defenses for one phase only. Relying on email filtering alone covers one delivery route and leaves every later phase without a planned detection or response. The takeaway: map at least one detection or control to each phase you can observe, so a miss early in the chain still leaves later chances to stop the intrusion.

This section covers the Diamond Model, the framework to use when the question is not how far one intrusion went, but which intrusions belong together. Where the Kill Chain follows a single intrusion forward through time, the Diamond Model looks sideways across intrusions.

The model relates intrusion events through the features they have in common, and MITRE's FAQ names one of them: the adversary's capability, which it calls adversary capabilities^[1].

Events that share features can then be linked. For example, suppose two intrusions months apart use the same custom loader (a shared capability) and call back to domains registered through the same account: they are candidates for one cluster. MITRE's FAQ names this clustering as the Diamond Model's strength, saying it is helpful if you're trying to cluster intrusions^[1].

ATT&CK and the Diamond Model work together rather than competing. The same FAQ answer says ATT&CK-mapped techniques may be a useful source of input into the Diamond Model to analyze adversary capabilities^[1]: you describe the behavior precisely with ATT&CK, then record it as the capability feature of the event.

Shared techniques are not attribution

Attribution means naming the adversary behind the activity, and a matched technique cannot carry that weight alone. MITRE's design paper is explicit: multiple groups within ATT&CK use the same techniques, so it is not recommended to attribute activity solely based on the ATT&CK techniques used; attribution to a group is a complex process involving all parts of the Diamond Model^[2]. A technique that matches a known group's profile is an investigative lead; corroborate it with infrastructure, victim targeting, and other intrusion context before naming a group. Kill Chain phase labels alone do not establish relationships between intrusions: they describe where an intrusion has progressed, not whether two events belong together.

As the figure below shows, the two intrusions in the example above become one cluster candidate through a shared capability and shared callback domains, with ATT&CK-mapped techniques feeding the capability feature; naming a group still needs corroboration. The takeaway: reach for the Diamond Model when you need to relate events, and treat any single shared feature as a lead, not a conclusion.

This section covers how ATT&CK describes behavior and introduces its vocabulary. ATT&CK is a knowledge base of cyber adversary behavior and taxonomy for adversarial actions across their lifecycle^[1], built mainly from publicly available threat intelligence and incident reporting. It is organised as tactics, techniques, and procedures (TTPs), which CISA's mapping guide describes as four increasingly granular levels^[5] once sub-techniques are counted:

1. Tactic: the why. The adversary's tactical goal, the reason for performing an action. Example: Credential Access, the adversary is trying to steal account names and passwords.
2. Technique: the how. The action the adversary performs to achieve that goal. Example: OS Credential Dumping (T1003).
3. Sub-technique: a more specific how. A narrower category of the same behavior. Example: LSASS Memory (T1003.001), reading credentials from the memory of the Local Security Authority Subsystem Service (LSASS) process.
4. Procedure: what the adversary actually did. One observed, in-the-wild implementation. Example: an adversary using PowerShell to inject into lsass.exe and scrape its memory for credentials.

These definitions and examples come from MITRE's FAQ^[1] and CISA's ATT&CK mapping guide^[5]. Map the goal and the method separately: credential dumping is the method (technique) and Credential Access is the goal (tactic), so labelling credential dumping as the tactic swaps the how for the why.

A procedure is not a narrower behavior category below the sub-technique. MITRE separates the two on purpose: sub-techniques are used to categorize behavior and procedures are used to describe in-the-wild use of techniques^[1], and one procedure can span several behaviors. The PowerShell example above touches PowerShell, Process Injection, and credential dumping from LSASS at once. So an observed tool-and-command sequence is a procedure; it maps to one or more techniques or sub-techniques rather than being one itself.

The Kill Chain's Reconnaissance and Command and Control phases, as CISA's report names them^[4], share their names with ATT&CK Enterprise tactics^[6]. The Kill Chain phase is a position in an ordered sequence; the ATT&CK tactic is an unordered goal (the next section explains why order does not apply). When a question says Command and Control, check which framework it is asking about.

ATT&CK is versioned and its tactic list changes between releases, so record the version you map against. The current release, ATT&CK v19.2 (August 2026)^[7], lists 15 Enterprise tactics^[6], from Reconnaissance and Resource Development through Exfiltration and Impact.

The figure below stacks the four levels with the credential-dumping example beside each. The takeaway: tactic answers why, technique and sub-technique answer how, and the procedure records what was actually observed.

This section covers ordering, the point where ATT&CK and the Kill Chain behave most differently. The rule: ATT&CK tactics are unordered, and an intrusion need not use every one. MITRE states that ATT&CK Tactics are unordered and may not all occur in a single intrusion because adversary tactical goals change throughout an operation, whereas the Cyber Kill Chain uses ordered phases^[1].

The matrix lays tactics out as columns, which invites a left-to-right reading, so the misread needs debunking here. CISA's mapping guide says the ATT&CK framework is not intended to be interpreted as linear^[5] and gives an example: after initial access, an adversary may exfiltrate data and then add more persistence, moving from right to left across the matrix. The same guide notes that an adversary does not need every tactic to reach its goals.

Two true statements sit side by side here: the Kill Chain says intrusions progress in order, and ATT&CK says tactics have no order. They do not conflict, because they describe different levels. The Kill Chain sequences a handful of high-level objectives; ATT&CK catalogues individual goals and methods that an adversary can pursue, repeat, or skip as the operation develops.

In practice: if you observe a Lateral Movement technique, do not record an unseen Persistence or Privilege Escalation step just because those columns sit further left. Treat the earlier steps as hypotheses and look for their evidence. The takeaway: impose the Kill Chain's order on Kill Chain phases only, never on an ATT&CK matrix.

This section covers why analysts map behavior at all, when matching known-bad artifacts already finds threats. An indicator of compromise (IOC) is a specific artifact such as a file hash, a domain, or an IP address; it is quick to match, but a match alone does not describe the adversary’s behavior. A behavior, such as dumping credentials from LSASS memory, describes how the adversary operates, and stays the same when the tool, hash, or domain changes.

MITRE's design paper describes behavioral analytics as going beyond traditional indicators of compromise (IoCs) or signatures^[2], identifying malicious activity in a way that is agnostic of the specific tools used, and says ATT&CK documents group profiles from a behavioral perspective that is agnostic of the tools the group may use^[2]. So a list of malicious IP addresses is an indicator list, not a TTP description: it records infrastructure, not how the adversary worked.

Indicators still earn their place. MITRE's own guidance on how not to use ATT&CK warns: don't limit yourselves to behaviors, a timely indicator can catch an adversary^[8]. Use indicators to find specific artifacts quickly, and behavior mappings to describe and detect the method those artifacts serve.

A behavior mapping also needs its technical context to be useful. CISA's mapping guide warns that a simple list of ATT&CK tactics or techniques without associated technical context may not be actionable enough^[5] for defenders to detect, mitigate, or respond. The takeaway: indicators find the artifact; behaviors, recorded with their procedure detail, describe the method and survive the adversary's next change of tools.

This section covers ATT&CK as a measuring stick for your own defenses, a common analyst task after an incident or before a tooling decision. MITRE describes a defensive gap assessment as determining what parts of an enterprise lack defenses and/or visibility^[2]: you map existing telemetry, detections, and mitigations to ATT&CK techniques, and the techniques with nothing mapped are candidate blind spots. MITRE adds that the identified gaps help prioritize investment, and its resources page says ATT&CK can assess your organization's capabilities and drive engineering decisions like what tools or logging you should implement^[8].

Not a checklist

The goal is coverage of the behaviors relevant to you, not every cell in the matrix. MITRE's guidance is blunt: don't try to achieve 100% coverage; not every tactic or technique will apply to everyone, so prioritize the ones most relevant to you^[8]. The design paper agrees that coverage of every ATT&CK technique is unrealistic and that ATT&CK is not intended to provide a checklist of things that need to all be addressed^[2]. Rank techniques by your platforms, the threats you face, and the gaps the assessment reveals.

One procedure is not the whole technique

A technique can be carried out in many ways, so detecting one of them proves coverage of that one only. MITRE's own example: a detection on ipconfig.exe covers one procedure of System Network Configuration Discovery, but the same details can be discovered by an adversary through other means, such as the Get-NetIPConfiguration cmdlet within PowerShell^[2]. The resources page puts it as don't shout Bingo when you have one technique^[8]: adversaries have multiple ways to perform most techniques. Before you mark a technique as covered, test which procedures the detection actually catches; MITRE's design paper says anyone mapping to ATT&CK should be able to explain the procedures they cover.

The takeaway: an ATT&CK coverage map is a prioritised gap list for the threats you face, and each covered cell is only as good as the procedures you have tested against it.

This section covers the step between seeing a technique match and declaring an incident. Many ATT&CK techniques are also everyday administration, so a match tells you what happened, not whether it was malicious.

Valid Accounts (T1078) is the clearest case. ATT&CK describes adversaries who obtain and abuse credentials of existing accounts^[9], and who may choose not to use malware at all, relying on the legitimate access those credentials provide to make detection harder. Yet legitimate users also routinely sign in with valid accounts. MITRE's design paper says use of these accounts would normally occur in any environment, but the context of how the accounts are used may or may not indicate the use is malicious^[2]. The same paper notes that if ipconfig.exe runs frequently and legitimately, alerting an analyst on every instance would be excessive, although collecting the telemetry is still worth it as a record for later investigation.

The context to check before declaring malice includes:

• Identity: whose account or host performed the action, and is it normal for that role?
• Purpose: is there a change ticket, maintenance window, or business reason?
• Timing: does it fall inside normal working patterns for that account?
• Surrounding activity: what came before and after (new logon source, unusual data access, disabled logging)?

The mapping itself needs evidence too. CISA lists leaping to conclusions as a common mistake, for example mapping malware using ports 80/443 to the web protocols sub-technique without first confirming usage of the HTTP/S protocol^[5]. The same discipline applies to attribution, covered in the Diamond Model section above: a familiar technique is a lead, not a name. The takeaway: collect telemetry on dual-use behavior, but decide malice from context, never from the mapping alone.

This section collects practice scenarios, with the answer each one points to and the tempting wrong answer to avoid. These examples give you an artifact and ask you to name the phase, the framework, or the ATT&CK level; the deciding skill is matching the claim to the evidence actually shown.

Scenario shows	Answer the evidence supports	Tempting wrong answer, and the mechanism that makes it wrong
External host and port scans from an unknown address	Reconnaissance	Exploitation: scans gather targeting information; nothing ran through a weakness
A malicious attachment delivered but not opened	Delivery	Exploitation: receipt proves transport, not execution
The document reader runs embedded attack code	Exploitation	Weaponization: preparation happened on the adversary's side before delivery
A backdoor installed, no outbound traffic yet	Installation	C2: capability to communicate is not an observed channel
An implant receiving commands, no data movement yet	Command and Control	Actions on Objectives: a channel does not show the goal was achieved
Targeted business files exfiltrated	Actions on Objectives	Installation: the adversary is using access, not establishing it
Only email filtering is planned as intrusion defense	Add controls at later phases	Delivery-only defense: leaves later phases with no planned interruption
Three intrusions must be linked to one another	Diamond Model	Kill Chain labels: give one intrusion's progress, not relationships
One technique matches a known threat group	Investigative lead only	Naming the group: several groups share techniques
Credential dumping labelled as the tactic	Technique; the tactic is Credential Access	Treating the method as the goal
A tool-and-command sequence labelled as a sub-technique	Procedure	Confusing an observed implementation with a behavior category
An earlier tactic assumed from matrix column position	Investigate; do not record it	Treating unordered tactics as a timeline
A list of malicious IP addresses offered as the TTP description	Map the behavior those addresses supported	Indicators record infrastructure, not method
One detected tool marks a technique fully covered	Test other procedures first	One procedure is not the whole technique
Every ATT&CK technique given equal priority	Prioritise by platforms and threats	Treating the knowledge base as a compliance checklist
A legitimate admin tool maps to ATT&CK	Check identity, purpose, timing	Declaring an incident from the mapping alone

The takeaway: name only what the evidence proves, pick the framework by the question asked, and treat any single match as a lead until context confirms it.