What is MITRE ATT&CK?

What MITRE ATT&CK actually is

ATT&CK stands for Adversarial Tactics, Techniques, and Common Knowledge. MITRE began it in 2013 to document how intrusion sets behaved against Windows enterprise networks, as part of a research project into whether endpoint telemetry and analytics could reliably catch adversaries already operating inside a network. It grew into a curated, free model of adversary behaviour covering three domains: Enterprise (Windows, macOS, Linux, network devices, containers, cloud services, and identity providers), Mobile (Android and iOS), and ICS (industrial control systems). The content is distilled from publicly reported threat intelligence and incident reporting. That provenance matters more than most readers notice: ATT&CK documents behaviour someone has observed and written up, which makes it evidence-based but also inherently incomplete and lagging. Techniques nobody has published on are simply not in it. MITRE updates the knowledge base on a roughly twice-yearly cadence, in April and October, so any static copy of the matrix begins drifting almost immediately.

What ATT&CK is not

More confusion comes from what people assume ATT&CK is than from anything it actually contains. It is a descriptive taxonomy, and nearly every misuse of it involves treating a description as a prescription. Nothing in ATT&CK tells you which techniques matter to your organisation, how mature your security programme is, or whether you have done enough. Those judgements are yours, and the framework deliberately declines to make them for you. That restraint is a feature rather than an omission, but it is also the gap into which a great deal of vendor and consultant messaging has been poured. ATT&CK gets presented as a target to hit, a percentage to raise, or a standard to be certified against, and it is none of those things.

• Not a maturity model — there is no level to reach and no rating ATT&CK assigns you
• Not a compliance standard — no auditor certifies you against it and no regulator mandates it
• Not a scoring system — techniques carry no severity, weight, or priority values
• Not a checklist — the matrix is a reference catalogue, not a list of items to complete
• Not a control framework — it describes attacker behaviour, not the defences you should deploy

Tactic, technique, sub-technique, procedure

These four terms are the framework's grammar, and confusing them is the most common reason ATT&CK conversations go sideways. A tactic is the adversary's goal — the why. Credential Access is a tactic: the attacker wants credentials. A technique is how that goal is achieved, such as dumping credentials from the operating system. A sub-technique is a more specific variant of the same behaviour, such as reading them from LSA Secrets. A procedure is the concrete implementation observed in a real intrusion — a named group using a particular script to scrape memory on a particular victim. Tactics carry IDs in the form TA0006; techniques use a four-digit form such as T1059 (Command and Scripting Interpreter); sub-techniques append a three-digit suffix, so T1059.001 is PowerShell. The Enterprise matrix currently holds fifteen tactics, running from Reconnaissance and Resource Development through Initial Access, Execution, Persistence, and Privilege Escalation, then Stealth, Defense Impairment, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact.

Groups, Software, Campaigns, and the defensive objects

The matrix is the part everyone screenshots, but the objects around it are where most of the analytical value sits — they are what turn a taxonomy into something you can reason about. This layer is not fixed, either. In the April 2026 release MITRE split the long-standing Defense Evasion tactic into Stealth and Defense Impairment, on the reasoning that blending in with legitimate activity and actively breaking defensive tooling are different behaviours deserving different detections. The defensive side changed more sharply in October 2025, when the old Data Sources objects were deprecated in favour of a more explicit detection model.

• Groups — activity clusters tracked under a common name (G-prefixed IDs), each linked to the techniques they have been reported using
• Software — malware and legitimate tools used to carry out modelled behaviour (S-prefixed)
• Campaigns — sets of intrusion activity over a period of time, attributed or otherwise (C-prefixed)
• Mitigations — security concepts and classes of technology that prevent a technique succeeding (M-prefixed)
• Detection Strategies and Analytics — introduced in October 2025 to replace per-technique detection notes, with platform-specific detection logic sitting beneath each strategy
• Data Components — the telemetry a detection depends on, which replaced the deprecated Data Sources objects

How detection engineers actually use it

In a working security operations centre, ATT&CK does four useful jobs. It gives detections a label, so a rule is not merely "suspicious PowerShell" but a specific technique that can be discussed, tested, and compared. It supports coverage analysis: lay your detections over the matrix — usually in ATT&CK Navigator, MITRE's free layer-annotation tool — and the empty cells become visible. It makes threat intelligence actionable, because a report naming a group lets you pull that group's technique list and check your detections against it specifically rather than generally. And it gives red and blue teams a shared language during purple-team exercises, so an emulation plan and a detection backlog reference the same identifiers. That last one is often the biggest practical win. Arguments about whether a detection "worked" get much shorter when both sides are pointing at the same technique ID and the same procedure. None of this requires the whole matrix — it requires the parts your adversaries actually use.

Why "100% ATT&CK coverage" is a marketing artefact

Coverage claims are the most abused thing in this space, and they deserve suspicion regardless of who makes them — vendors very much included. There are several reasons why a coverage percentage says almost nothing. Techniques are not equivalent units: some are narrow and mechanically detectable, others are broad umbrellas over behaviour indistinguishable from routine administration, and counting them equally implies a precision that does not exist. Coverage is also usually self-assessed, so one low-fidelity rule that merely mentions a technique can turn a cell green without ever catching anything real. Prevalence varies enormously — a small number of techniques appear in most intrusions and most techniques appear in almost none — so breadth and risk reduction are only loosely related. Above all, coverage measures breadth while detection is a problem of quality: whether the rule fires on the real thing, survives tuning, and produces something an analyst can act on. A modest set of well-tested detections against the techniques that threaten your sector beats a full matrix of green squares. Ask for the detection logic, not the heat map.

How it relates to the Cyber Kill Chain and D3FEND

The Lockheed Martin Cyber Kill Chain describes an intrusion as an ordered sequence of high-level phases. ATT&CK sits beneath it at a much finer level of detail, and MITRE is explicit that ATT&CK tactics are unordered: they are categories of goal, not stages, and a real intrusion may revisit some repeatedly and never touch others. Reading the Enterprise matrix left to right as a timeline is the most common beginner error. The two are complementary — the kill chain for narrative and executive communication, ATT&CK for the specifics underneath. D3FEND, also from MITRE and funded by the NSA, comes at the problem from the opposite direction: it is a knowledge graph of defensive countermeasures, organised so that defensive techniques can be linked back to the offensive behaviours catalogued in ATT&CK. Where ATT&CK tells you what an adversary did, D3FEND helps you reason about the classes of countermeasure that address it. It is younger and less widely adopted, but it fills a real gap.

Practical first steps for a team adopting it

Teams that get value from ATT&CK almost always start narrow. The classic failure is opening the full Enterprise matrix, resolving to map everything, and abandoning the effort three weeks later with a half-coloured spreadsheet nobody trusts. Pick a small, threat-informed scope and widen it only once the first pass is genuinely finished and tested. Adoption works better as a habit than as a project: the teams that sustain it treat mapping as something that happens alongside normal detection work rather than as a separate initiative with its own deadline and its own steering group. The sequence below is deliberately conservative, and each step produces something usable even if you stop there.

• Choose three to five adversary groups or campaigns that plausibly target your sector and geography, and work only from their technique lists
• Map the detections you already have to technique IDs before writing any new ones — most teams find both gaps and duplicates
• Record honestly whether each mapped detection has ever been tested against the real behaviour, not merely written
• Hold the picture in ATT&CK Navigator layers, and keep those layers under version control so drift stays visible
• Test a handful of techniques through atomic tests or a purple-team exercise, and fix what fails before adding breadth
• Re-check your mappings after each ATT&CK release, because tactics and techniques do get restructured