MITRE ATT&CK, the kill chain and the diamond model

Why this matters

Objective 3.1 is about attack methodology frameworks, and they are heavily examined because they are precise, nameable and comparable — ideal question material.

They also do real work. A framework gives you a shared vocabulary for describing what an attacker did, a structure for finding the gaps in your detection, and a way to turn a single observation into an expectation about what else to look for. That last property is the practical one: if you know an attacker is at a particular stage, you know what usually comes next.

The lesson

Tactics, techniques and procedures

The vocabulary underlying all of this, and worth getting exactly right.

• Tactic — the attacker's objective at a point in the operation. Why they are doing something. "Credential Access", "Persistence", "Exfiltration".
• Technique — how they achieve it. "OS Credential Dumping", "Scheduled Task", "Exfiltration Over C2 Channel". Sub-techniques refine further: credential dumping from LSASS memory specifically.
• Procedure — the specific implementation a particular actor uses: this tool, these flags, this sequence.

The hierarchy maps onto the pyramid of pain from lesson 13. Procedures are easiest to change, techniques much harder, tactics essentially fixed — an attacker who needs credentials needs credentials, whatever tooling they use.

The analytical consequence: detections written at technique level survive changes in tooling. A rule matching a specific tool's command-line flags breaks the day they recompile. A rule matching "process opening LSASS with read memory rights" catches everything that needs to read credentials from memory, which is a requirement rather than a choice.

Mapping an observed behaviour to a technique

The practical skill: you have an observation, and you want the technique.

Worked example. You see w3wp.exe spawning cmd.exe, which runs whoami, then net user, then creates a scheduled task.

Mapped:

• Web server spawning a shell → web shell, a persistence and initial-access technique.
• whoami, net user → discovery tactic: system owner and account discovery.
• Scheduled task creation → persistence via scheduled task, and possibly privilege escalation depending on context.

What that mapping buys you immediately:

• Expectation. Discovery is early. You should now look for credential access, lateral movement and collection, because that is what typically follows — and looking before you find evidence is how you get ahead of an intrusion rather than following it.
• Detection assessment. You detected the scheduled task. Did you have anything that would have caught the web shell? If not, that gap is a finding.
• Communication. Saying "initial access via web shell, then discovery and persistence" tells another analyst more in eight words than a paragraph of narrative.

Two cautions when mapping. First, do not over-map: forcing every observation into a technique produces false precision, and "unclear" is a legitimate entry in a timeline. Second, the same observation can map to several techniques, and the honest response is to record the alternatives rather than pick one to look decisive.

Using ATT&CK for coverage gaps, not decoration

ATT&CK's most valuable use, and the one most often skipped in favour of colouring a matrix for a slide.

The exercise:

1. List your detections, and map each to the technique it covers.
2. Colour the matrix by whether you have coverage, and at what confidence.
3. Look at the white space, which is the actual output.
4. Weight by relevance. You do not need coverage of every technique; you need coverage of the ones used against your sector and reachable in your environment — which is where the threat intelligence of lesson 13 supplies the priority.
5. Feed the gaps into hunting (lesson 14) and detection engineering.

The traps, which are common enough to be worth naming:

• Claiming coverage from a log source rather than a detection. Having the telemetry that could detect something is not detecting it. This single error produces most of the impressively green matrices in circulation.
• Untested coverage. A rule that has never fired is a hypothesis, per lesson 14. Colour it differently from one proven by an atomic test.
• Chasing complete coverage, which is neither achievable nor useful — some techniques are effectively undetectable, and effort is better spent elsewhere.
• Treating the matrix as the goal. It is a map of your blind spots, not a scoreboard.

Done honestly, this is one of the highest-value exercises available to a SOC, because it converts "we do not know what we cannot see" into a specific, prioritised list.

The kill chain and where it breaks down

The Cyber Kill Chain models an intrusion as seven sequential stages:

1. Reconnaissance — researching the target.
2. Weaponisation — preparing the payload.
3. Delivery — getting it to the target.
4. Exploitation — executing it.
5. Installation — establishing a foothold.
6. Command and control — establishing remote access.
7. Actions on objectives — doing whatever they came for.

Its enduring value is the defensive implication: breaking any link stops the chain, so defence should be layered across stages rather than concentrated at the perimeter. As a way of explaining defence in depth to a non-technical audience it remains excellent.

Where it breaks down, and the exam does expect the critique:

• It is linear, and real intrusions loop. An attacker gains a foothold, moves, discovers, escalates, moves again — repeating stages on different hosts for weeks.
• It is perimeter-focused, reflecting a network-centric era. It handles an attacker who logs in with stolen credentials poorly, because there is no exploitation and barely any delivery.
• It compresses everything after the foothold into one stage, which is precisely where most of a modern intrusion happens and where an analyst spends their time.
• It does not cover insider threats well at all.

Which is largely why ATT&CK exists: it describes post-compromise behaviour in detail rather than treating it as a single box.

The Unified Kill Chain merges the two ideas, extending the sequence to cover the repeated in-network phases, and is worth recognising by name.

Choosing a framework for the audience

They are not competitors; they answer different questions and suit different listeners.

• Kill chain — for explaining layered defence to executives and for structuring a high-level narrative. Simple, memorable, linear.
• ATT&CK — for analysts and detection engineers. Detailed, behavioural, the right level for coverage analysis, hunting hypotheses and technical communication between teams.
• Diamond Model — for intrusion analysis and attribution. It frames every event as four linked features: adversary, capability, infrastructure and victim. Its strength is the pivot: from a capability you find other infrastructure, from infrastructure you find other victims. It is how one observed indicator becomes a picture of a campaign, and it underpins how intelligence reporting is structured.

A reasonable working approach uses all three: the Diamond Model to pivot during analysis, ATT&CK to describe and detect the behaviour, and the kill chain to explain the shape of it to people who do not need the detail.

For the exam, be able to say what each is for and name its principal limitation. That, rather than reciting the stages, is what the questions test — and it is also what makes the frameworks useful rather than decorative once you are doing the job.

Topics this lesson owns

• [x] Tactics, techniques and procedures
• [x] Mapping an observed behaviour to a technique
• [x] Using ATT&CK for coverage gaps, not decoration
• [x] The kill chain and where it breaks down
• [x] Choosing a framework for the audience