MITRE ATT&CK Explained

What it is

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a publicly maintained knowledge base of attacker behaviour. It catalogues what real intrusion groups have been observed doing in real environments, organised in a way that lets defenders, red teams, and intel analysts talk about the same things using the same words.

The content is curated by MITRE, a US-based not-for-profit, but the contributions come from the wider community: vendors, government agencies, incident response firms, and individual researchers who have observed an attacker doing something new.

What makes ATT&CK different from earlier models is its level of detail. It does not stop at "the attacker moved laterally". It describes the specific techniques used to move laterally, the sub-techniques inside each technique, and concrete procedures that named threat groups have used. This precision is what makes it useful as an operational tool rather than a slide deck.

Why it matters

Before ATT&CK, security teams talked about attacker behaviour in inconsistent and often vague ways. The Lockheed Martin Cyber Kill Chain (published in 2011) gave the industry a shared model of an intrusion from reconnaissance to exfiltration, but it stopped at seven phases. It described the shape of an attack without describing the contents.

ATT&CK fills in the contents. When a SOC analyst writes a detection rule, they can tag it with the specific technique it covers. When a threat intel report says a group used T1566.001, every defender reading the report knows it means spearphishing attachment, has a clear definition of what that includes, and can map it back to their own detections.

The practical effect is that ATT&CK has become the common vocabulary for describing attacker behaviour across the industry. Detection vendors map their content to it. Threat intel reports reference technique IDs directly. Regulators in some sectors expect it. Red team reports often arrive structured as ATT&CK coverage rather than narrative prose. For most modern security teams, working without ATT&CK is now harder than working with it.

Where it came from

The framework began inside MITRE in 2013 as part of an internal research project on adversary emulation. The team needed a structured way to describe what attackers actually did once inside a Windows enterprise network, so that defenders could test whether their tools would catch the same behaviour.

The first public release came in 2015. Initial coverage was Windows enterprise environments. Linux and macOS were added later, then cloud platforms, mobile, network devices, and industrial control systems. The matrix has grown steadily since, with formal releases roughly twice a year.

A few milestones worth knowing:

• 2018. PRE-ATT&CK matrix added (later folded into Enterprise) for reconnaissance and resource development.
• 2019. Sub-techniques introduced, splitting overly broad techniques into more granular entries.
• 2020. Cloud matrix consolidated AWS, Azure, GCP, and SaaS coverage.
• 2021. ICS ATT&CK published as a separate matrix.
• 2023 onwards. MITRE ATLAS extended the pattern to AI and machine learning. MITRE EMB3D (2024) covered embedded device threats.

How it is structured

ATT&CK is organised as a hierarchy. Knowing the levels is essential to using it without getting lost.

Tactics (the why)

Tactics are the goals an attacker is trying to accomplish at a given stage of an intrusion. They answer "what is the attacker trying to do right now?" The Enterprise matrix has 14 tactics including Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact.

A tactic on its own is not actionable. "The attacker is trying to escalate privileges" tells you the goal but not the method.

Techniques (the how)

Techniques are specific ways of accomplishing a tactic. They answer "what method is the attacker using?" Technique IDs look like T1078 (Valid Accounts) or T1059 (Command and Scripting Interpreter). Each technique entry includes a description, examples of groups that have used it, data sources you can use to detect it, and suggested mitigations.

Most techniques map to multiple tactics. Valid Accounts, for example, is relevant to Initial Access, Persistence, Privilege Escalation, and Defense Evasion all at once.

Sub-techniques (the specific implementation)

Sub-techniques split broad techniques into more specific patterns. T1059 (Command and Scripting Interpreter) has sub-techniques for PowerShell (T1059.001), AppleScript (T1059.002), Windows Command Shell (T1059.003), Unix Shell (T1059.004), and more. Detection rules and threat intel usually operate at the sub-technique level because the detection signals differ between PowerShell and bash even though the tactic is the same.

Procedures (the exact actions)

A procedure is the concrete way a specific group executed a technique. The procedures section of a technique entry lists named groups (APT29, FIN7, Sandworm, etc.) and what those groups specifically did when using that technique. For example, "APT29 has used PowerShell to download additional payloads from external servers" is a procedure for T1059.001.

Procedures are where ATT&CK ties to threat intelligence. They are the level of detail that lets you go from "we saw something suspicious" to "this matches the behaviour of a specific group we have intelligence on".

The matrices

ATT&CK is published as several matrices, each scoped to a specific environment:

• Enterprise (the largest, covers Windows, Linux, macOS, network infrastructure, containers, and cloud)
• Cloud (a sub-matrix of Enterprise covering AWS, Azure, GCP, Office 365, Google Workspace, IaaS, and SaaS)
• Mobile (Android and iOS)
• ICS (industrial control systems)
• MITRE ATLAS (a sibling project for adversarial machine learning)
• MITRE EMB3D (embedded systems and IoT)

Matrices are not silos. An attacker who phishes a corporate account (Enterprise), pivots to cloud admin (Cloud), and then accesses a connected ICS environment (ICS) will appear across all three.

How teams use it in practice

Knowing the structure does not tell you what to do with it. The patterns that produce real value are concrete.

Detection coverage gap analysis. Map every detection you have to the techniques it covers. Lay that against the matrix. Gaps are where you have no detection, regardless of how many alerts your SIEM produces. ATT&CK Navigator (the free MITRE-maintained heatmap tool) is the standard way to visualise this.

Threat intel attribution and mapping. When a vendor report describes a new campaign, the technique IDs let you check whether your existing detections cover what is described. If a report lists 18 techniques and you have detection for 11, you have a concrete starting point for what to build next.

Red team and purple team exercises. Red teams plan engagements by selecting techniques to test. Purple teams run through a list of techniques together with defenders, executing each in a controlled way and confirming whether the detection telemetry shows up. This is the highest-value use of ATT&CK because it produces concrete evidence of what your stack actually catches.

Threat actor profiling. Each named group in ATT&CK has a profile listing the techniques it has been observed using. Picking a group relevant to your industry (FIN7 for retail, Lazarus for finance, APT41 for almost everyone) gives you a focused list of techniques to prepare for, rather than the entire matrix.

Communication with leadership. Mapping incidents and detections to ATT&CK gives executives a consistent picture over time. "Our detection coverage of credential access techniques went from 40 percent to 75 percent this year" is a concrete metric that does not depend on which tool generated it.

Where it falls short

ATT&CK is useful but not without problems:

• Technique-procedure ambiguity. Some techniques are broad enough that two analysts can disagree about which one a given observation belongs to.
• Gaps for newer attack patterns. Cloud identity abuse, OAuth consent phishing, and AI-specific attacks are still less mature in the matrix than traditional Windows endpoint techniques.
• Coverage is not capability. Mapping a detection to a technique does not prove the detection works. A poorly tuned rule still counts as coverage on a Navigator chart. Validation is separate work.
• The matrix is enormous. Trying to cover all of it is not feasible for any team. Focused use beats comprehensive use.
• It describes behaviour, not severity. Prioritisation has to come from elsewhere (threat intel, business context, validation).

How to start using it

If your team is new to ATT&CK, the realistic starting point is small.

1. Pick a single threat actor profile relevant to your industry. FIN7 if you are retail. APT38 or Lazarus if you are finance. The CISA-maintained profiles or the MITRE group pages are the place to start.
2. List the techniques that group has used. Most named groups have between 30 and 80 techniques in their profile. Manageable.
3. Map your existing detections to that list. Where you have coverage, mark it. Where you do not, mark it red.
4. Pick the top few gaps to address. Build detections, run a purple team exercise to confirm, and iterate.
5. Expand to a second group on the next cycle. Over time the coverage grows organically and stays grounded in the actual threat landscape.

This is more useful than trying to cover the whole matrix at once. The whole matrix is too large for any team to address in any meaningful timeframe. A focused threat-led approach delivers measurable improvement.

Best practices

• Use sub-techniques, not just techniques. The detection signals differ enough between sub-techniques that lumping them together hides real gaps.
• Validate every coverage claim. A mapped detection is a hypothesis until you have tested it. Purple team exercises and breach and attack simulation tools confirm what actually fires.
• Re-map after every major incident. A real intrusion will reveal techniques you missed and detections that did not fire when they should have. Update the Navigator after the post-incident review.
• Tie detections to data sources, not just techniques. ATT&CK lists data sources for each technique (process creation, authentication logs, network traffic). If you do not have the data source, the detection is impossible regardless of how many rules you write.
• Avoid using ATT&CK as a marketing layer. Vendors who claim "100 percent ATT&CK coverage" are usually counting techniques their tool nominally addresses, not techniques it would actually catch in your environment. Your own validation matters more than any vendor matrix.
• Keep one source of truth. A single Navigator file, owned by the detection engineering team, with regular updates, beats five different team-owned mappings that drift apart.
• Read the procedures section. The technique pages are useful, but the named-group procedure examples are where you find out what the technique actually looks like in real intrusions.