What Is the MITRE ATT&CK Framework? A Plain-English 2026 Guide

MITRE ATT&CK — short for Adversarial Tactics, Techniques, and Common Knowledge — is a publicly available, continuously updated knowledge base that catalogs every way real-world adversaries have been observed to attack computer systems. It is published by MITRE Corporation, a nonprofit federally funded research and development organization, and it has effectively become the common vocabulary every modern security team uses to describe how attackers operate.

Concretely: imagine an attacker phishes one of your employees, harvests credentials, logs into your VPN as that employee, pivots through your internal network, escalates privileges, and steals customer data. ATT&CK gives every step of that attack a specific identifier. The phishing email is T1566. The credential harvesting is T1056. The valid-account VPN login is T1078. The internal pivot might be T1021. The privilege escalation is one of several T1068 sub-techniques. The data exfiltration is T1041. Each step also maps to a higher-level "tactic" — the goal of that step — like Initial Access, Credential Access, Lateral Movement, Privilege Escalation, or Exfiltration.

That is the entire framework, structurally. ATT&CK is a giant standardized catalog of what attackers do, who has been observed doing it, and what evidence each technique tends to leave behind.

The ATT&CK Matrix is the chart you have probably seen — columns of red boxes that look like the world's most intimidating periodic table. The columns and the boxes mean very specific things, and knowing the difference is the entire game.

Tactics are the columns. They represent the goal the attacker is trying to achieve at that stage of the attack: Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact, Reconnaissance, and Resource Development. Fourteen total in the enterprise matrix. Think of tactics as the chapters of the attack story.

Techniques are the individual boxes inside each column. They represent how the attacker accomplishes that goal. T1566 (Phishing) is one technique under the Initial Access tactic. T1078 (Valid Accounts) is another. Each technique has a unique T-number, a description, real-world adversary examples, and detection guidance.

Sub-techniques are variants of a technique. T1566.001 is Spearphishing Attachment. T1566.002 is Spearphishing Link. T1566.003 is Spearphishing via Service. Same parent technique (T1566 — Phishing), different specific implementations. Sub-techniques exist because saying "the attacker used phishing" is not specific enough to drive a detection rule.

A short tour of each tactic in the order an attacker typically uses them. Real attacks rarely march through these in a clean sequence — they jump around — but knowing the names is enough to read any ATT&CK-mapped report.

Reconnaissance — gathering information about you before any active attack. OSINT, DNS, scraping LinkedIn, identifying your tech stack.

Resource Development — building or buying the infrastructure for the attack. Acquiring domains, setting up command-and-control servers, buying stolen credentials.

Initial Access — getting the first foothold inside your environment. Phishing, internet-facing exploits, stolen credentials, supply-chain compromise.

Execution — running adversary code on the systems they just compromised. PowerShell, WMI, scheduled tasks, malicious office macros.

Persistence — making sure access survives reboots, patching, or credential changes. Registry run keys, scheduled tasks, account creation, startup folders.

Privilege Escalation — going from a low-privilege foothold to a high-privilege one. Token impersonation, kernel exploits, abuse of misconfigured services.

Defense Evasion — hiding from security tools. Disabling logging, abusing trusted binaries (LOLBins), obfuscation.

Credential Access — stealing credentials to expand or maintain access. Password dumping, Kerberoasting, NTLM relay, browser credential theft.

Discovery — exploring the environment they're now in. Enumerating users, groups, shares, domain trusts.

Lateral Movement — moving from the initial host to other hosts. SMB, RDP, WMI, pass-the-hash, pass-the-ticket.

Collection — gathering the data the attacker actually wants. Screen captures, keystroke logging, file staging.

Command and Control — maintaining a channel back to the attacker's infrastructure. HTTP/S beacons, DNS tunneling, encrypted channels.

Exfiltration — moving the collected data out. Over the C2 channel, over removable media, to a cloud storage service.

Impact — the visible consequence to the victim. Encryption (ransomware), data destruction, service denial, defacement.

Red teams — the offensive side of security, including pentesters and pentest providers like us — use ATT&CK to plan engagements in two main ways: as a coverage map and as an adversary emulation script. The playbook applies whether the engagement is a focused network pentest or a full red-team simulation.

Coverage map. Before an engagement starts, the red team identifies which tactics and techniques the scope can plausibly cover. A web app pentest obviously can cover Initial Access via web exploits and some Credential Access (e.g., authentication bypass) — but it will not exercise Persistence on a Windows endpoint or Lateral Movement across an internal network. Naming the coverage explicitly is honest scoping.

Adversary emulation script. For more advanced engagements, the red team picks a specific real-world threat actor — say, the techniques used by FIN6 or APT29 — and emulates that actor's observed playbook step by step. MITRE publishes adversary profiles that map each known group to the specific techniques they have been observed using. For a financial institution, emulating a financially motivated actor like FIN6 produces a much more useful test than a generic "try whatever works" engagement.

The output of a well-run red team engagement is an attack narrative where every step is tagged with the specific ATT&CK technique used. Your defenders can then look at their detection coverage and answer the only question that matters: would we have caught this if a real attacker had done it?

Blue teams — the defensive side, including your SOC and IR engineers — use ATT&CK as a coverage scoreboard. The exercise looks like this.

For every technique in the matrix, the blue team asks: do we have a detection that would alert if this technique were executed in our environment? If yes, what is the detection quality — high-fidelity, noisy, or unreliable? If no, why not (out of scope, infeasible, deprioritized, or just missed)?

The output is a coverage heatmap — the same ATT&CK matrix you've seen, colored by detection quality. The heatmap is more useful than any CVSS-driven dashboard because it answers the question your CFO actually asks: where are we exposed? You can't fix everything at once, but a coverage heatmap tells you which tactics to invest detection budget into next.

Modern detection-as-code tooling has made this exercise radically easier than it was five years ago. Detection rules in SIEM and EDR platforms are increasingly tagged with the specific ATT&CK technique they detect, which means coverage rolls up automatically. The shop running your pentest should be able to map their findings back to your detection coverage gaps directly.

Three frameworks come up in pentest proposals: ATT&CK, the Lockheed Martin Cyber Kill Chain, and PTES (Penetration Testing Execution Standard). They are not competitors and they are not interchangeable.

Cyber Kill Chain is the seven-stage model Lockheed Martin published in 2011: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, and Actions on Objectives. It is older, simpler, and intentionally linear. Useful for executive communication. Not granular enough for technical engineering.

ATT&CK is what the Kill Chain became when MITRE got more rigorous: dozens of tactics, hundreds of techniques, real adversary observations underneath. ATT&CK is what your technical defenders and red teams actually work with.

PTES is a methodology standard for how pentests should be conducted — pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, reporting. PTES describes the process; ATT&CK describes the content. A pentest can claim PTES methodology while still mapping findings to ATT&CK techniques. Both, together, are the default for serious shops in 2026.

ATT&CK's adoption curve in 2018–2026 has been almost unprecedented for a security framework. Three reasons account for it, and they're worth naming because they also explain where the framework is most useful.

First, it's observational rather than aspirational. Older frameworks like ISO 27001 or the NIST Cybersecurity Framework describe how you should defend; ATT&CK describes how attackers actually attack. That shift in orientation made ATT&CK immediately operational in a way the older frameworks were not. Engineers can write detection rules against specific techniques; auditors and CFOs cannot write a useful check against "adequately addresses cybersecurity."

Second, it's standardized vocabulary. Before ATT&CK, every vendor had their own taxonomy for describing attacker behavior, and translation between them was friction-heavy. ATT&CK became the lingua franca that lets a CrowdStrike alert, a Sentinel rule, and a pentest report all speak the same language. The network effect was immediate and durable.

Third, MITRE has been disciplined about updates. The matrix has two annual update cycles, additions are debated publicly, and deprecations are rare and carefully managed. Compare this to other security frameworks that update every five years and you see why operational teams trust ATT&CK as the moving frontier.

ATT&CK is excellent and it is not magic. Three real limitations worth naming.

It is observation-driven, not predictive. ATT&CK only catalogs what has already been seen in the wild. Novel techniques — the ones a sophisticated adversary uses before anyone has named them — are not in the matrix yet by definition. If your threat model includes nation-state adversaries with original capability development, ATT&CK coverage alone does not protect you.

It is enterprise-skewed. The original ATT&CK matrix focused on enterprise IT environments. ICS, mobile, and cloud sub-matrices exist now and are improving, but they are not as mature as the enterprise matrix. If your risk is dominated by ICS or specialized mobile threats, ATT&CK is part of the picture but not the whole picture.

Mapping does not equal coverage. A vendor saying their product "maps to ATT&CK" is making a very specific and small claim — they have a translation layer between their telemetry and ATT&CK identifiers. It does not mean their product actually detects every technique it maps to. Coverage requires real detection rules tested against real techniques.

When you receive a pentest report claiming ATT&CK mapping, here is what to look for to verify the mapping is real and not decorative.

Every finding should have a specific T-number (and ideally a sub-technique like T1566.001 rather than just T1566). The attack narrative — the section that tells the story of how the testers chained findings together — should reference the technique IDs as the testers move from one stage to the next. If the report only puts ATT&CK labels in a summary table at the end and the narrative reads like a list of CVEs, the mapping is decoration, not methodology.

A good report should also tell you which tactics were not exercised by the scope and why. A web app pentest report that silently leaves out half the tactics is honest only if it says so explicitly. Coverage transparency is a sign of a serious shop. For more on what to look for in a report, our full pentest buyer's guide covers the full anatomy.

For founders running an ATT&CK-aligned assessment for the first time, our MITRE ATT&CK assessment service walks through your environment's coverage map in detail and produces the kind of heatmap your board will actually use. If you're scoping deeper offensive testing, our Active Directory pentest and web app pentest offerings are ATT&CK-mapped by default. Case studies of real engagements live on our Active Directory pentest case page for readers who want to see the deliverable shape before scoping.