MITRE ATT&CK: The Attacker's Playbook, Published for Defenders

The 30-second explanation

It's a big, shared map of the moves attackers make, from how they first get in to how they eventually steal data, laid out so defenders everywhere can describe the same attack in the same words. Instead of one team calling something 'weird admin activity' and another calling it 'lateral movement', both can point to the exact same named technique in the matrix and know they mean the same thing.

How it works

1. 1

   1. Tactic

   Identify the attacker's goal at a given stage, chosen from the matrix's fixed set such as Initial Access, Persistence or Exfiltration.

2. 2

   2. Technique

   Find the specific, named method used to reach that goal, such as a spearphishing attachment or credential dumping from memory.

3. 3

   3. Map

   Match the observed log evidence or incident timeline against these technique names to describe exactly what happened in standard terms.

4. 4

   4. Cover

   Check each mapped technique against your detection rules and tooling to see which ones would actually have fired, and which are gaps.

Each column of the framework is a tactic: the attacker's goal at that particular stage of an intrusion, like getting an initial foothold or moving from one machine to another. Each item listed beneath a tactic is a technique, one specific way of reaching that goal. Under Lateral Movement, for instance, you'll find techniques like using stolen credentials with a remote service, or abusing legitimate remote-desktop software. A technique can be broken down further into sub-techniques that capture meaningfully different variations of the same idea. Phishing splits into a malicious attachment, a malicious link, and phishing over a third-party service, because each leaves different evidence behind and needs a different detection. Defenders use the matrix three ways: to describe an incident in standard terms ('initial access via a phishing attachment, persistence through a scheduled task, lateral movement via a remote service'), to check which of those techniques their existing detections actually cover, and to decide what to test or build detection for next. It deliberately doesn't tell you which technique to worry about first, since that still depends on your own environment and threat model, but it does give every team, vendor and report the same names to work with, and that matters once an incident spans multiple tools and multiple people writing about it.

Real-world example

How to spot it

• Coverage counted, not tested

  A technique marked as 'covered' in a spreadsheet because a rule exists for it, without anyone confirming the rule actually fires against realistic activity.

• Checklist thinking

  Treating the matrix as a to-do list to complete in order, rather than a reference map to consult based on your own threat model.

• Ignoring frequently used techniques

  Spending detection effort on rare, exotic techniques while common ones like valid-account abuse or phishing remain undetected.

• No link to real incidents

  A coverage matrix that is built once and never compared against what actually happened in the organisation's own incidents.

What to do

1. 1Map your last few incidents or red-team exercises to specific technique names and look for the ones that keep reappearing.
2. 2Actually test a detection, with a simulated action or a red-team exercise, before marking a technique as covered.
3. 3Use the shared tactic and technique names in incident reports and vendor conversations so other teams and tools understand the finding without translation.