MITRE ATT&CK

What is MITRE ATT&CK?

MITRE ATT&CK is a publicly maintained knowledge base of adversary tactics and techniques observed in real-world attacks. It gives defenders a shared vocabulary for describing attacker behaviour, and a structure against which detection coverage can be described, compared and measured.

Key takeaways

• Tactics are the why; techniques are the how. Credential access is a tactic, an adversary objective. The specific methods of obtaining credentials are its techniques.
• It records observed behaviour, not theory. Entries are grounded in reporting of intrusions that happened, which makes the knowledge base credible as a planning instrument.
• Detection teams use it to find gaps. Mapping rules to techniques turns an unstructured rule set into a picture of which behaviours are visible and which are not.
• Coverage percentages are easy to inflate. A rule referencing a log field no host ships counts as coverage on a dashboard and detects nothing.
• Behaviour outlives vulnerabilities. Techniques persist across years and product versions, so detection built around behaviour ages better than detection built around a single vulnerability.

Why it matters

The framework reframed detection from whether rules exist to which adversary behaviours can actually be seen. That is a more useful question, and it made coverage discussable with people who do not write queries, which changed how detection work is funded and reviewed.

It also exposed how much detection content is written for breadth rather than relevance. Content designed to tick as many technique boxes as possible produces high alert volume and low signal, because it treats every technique as equally likely in an environment where most are not applicable at all. A catalogue is a map of what adversaries do, not a specification for what a particular organization should detect.

How the framework is structured

• Tactics. The adversary objective at a stage: initial access, execution, persistence, privilege escalation, defence evasion, credential access, discovery, lateral movement, collection, command and control, exfiltration, impact.
• Techniques and sub-techniques. The methods used to achieve a tactic, with sub-techniques giving the granularity needed to write a detection rather than describe a category.
• Procedures. How a named group or piece of malware has been observed using a technique in a real intrusion.
• Data sources and components. The telemetry required to observe a technique, which is the part of the model that makes coverage claims falsifiable.
• Mitigations and matrices. Configuration changes that reduce a technique's viability, catalogued separately from detection, across distinct matrices for enterprise, mobile and industrial environments.

The coverage-percentage trap

A stated coverage figure is meaningful only if three conditions hold at once: the rule exists, the log sources it depends on are actually flowing from the relevant hosts, and the rule has been validated against real data rather than assumed to work from its logic alone.

The second condition fails constantly and silently. A detection referencing a process command-line field a fleet does not collect, or an authentication event type disabled in group policy, is a gap that presents as coverage on every report. Nothing alerts, because nothing arrives to evaluate.

A third failure is subtler. Coverage is counted at technique level, but a technique with a dozen sub-techniques can be marked covered on the strength of a rule detecting one.

A worked example

Take a rule written to detect a web shell dropped by exploitation of an internet-facing application. The logic matches a web server process spawning a command interpreter, a well-understood pattern under the execution tactic. On paper the technique is covered.

In practice three things decide whether it fires. The endpoint agent has to be installed on the web tier, which for appliance-based or containerised web servers is frequently not the case. Process creation events have to include the parent process and full command line, which requires configuration off by default in several common deployments. And the rule has to survive an adversary substituting an equivalent expression: an encoded command, a different interpreter, or a spawn one level removed from the web server. The technique entry describes the behaviour accurately; the distance between that entry and a working detection is where the engineering effort lives, and a coverage dashboard measures none of it.

How to use the framework well

• Scope to the environment. Filter to the platforms actually in use before measuring anything. A matrix including irrelevant operating systems is a meaningless denominator.
• Prioritize by threat and exposure. Techniques used by groups known to target the sector, and techniques following directly from exposures already present, are worth more than uniform breadth.
• Verify telemetry before claiming coverage. Confirm the specific fields a rule depends on are arriving from the hosts that matter, and re-confirm after logging changes.
• Validate with adversary emulation. Executing a technique in a controlled way is the only reliable evidence a rule fires on real data rather than on a hand-crafted test event.
• Keep mappings on the rule. Storing the technique reference and the exposure that motivated the rule as metadata tells an analyst what an alert exists to catch.

Common misconceptions

• That it is a compliance framework. It is a knowledge base of adversary behaviour. Some assessments reference it, but it prescribes no controls and certifies nothing.
• That one rule covers one technique. Techniques are broad, and sub-techniques and procedure variants routinely defeat a rule written against a single implementation.
• That it describes an ordered attack sequence. Tactics are objectives, not stages. Real intrusions revisit some repeatedly and skip others entirely.
• That mapping existing rules is the work. Mapping is the inventory step. The work is closing the gaps it reveals, which is usually a telemetry problem before it is a rule-writing problem.

Standards and sources

The knowledge base is maintained by MITRE and versioned, so a coverage claim should name the version it was measured against. MITRE Engenuity runs public evaluations in which products are tested against emulated adversary behaviour; results are published without a ranking. Detection logic is commonly expressed in the vendor-neutral Sigma format, which carries technique references as standard metadata.

FAQ

Is MITRE ATT&CK a compliance framework? No. It is a knowledge base of adversary behaviour. Some frameworks reference it, but it prescribes no controls and issues no certification.

Should a team aim for 100 percent ATT&CK coverage? No. Many techniques are irrelevant to a given environment, and pursuing completeness produces alert volume rather than security. Coverage should follow the exposures actually present.

How is ATT&CK different from the cyber kill chain? The kill chain describes a linear attack progression at a high level. ATT&CK is a far more granular catalogue of specific techniques and assumes no fixed order.

What makes a coverage figure trustworthy? Evidence that the required telemetry is arriving from the relevant hosts and that each rule has fired against real or emulated activity, measured at sub-technique level.

Sources

• MITRE, ATT&CK for Enterprise, version 17, 2025.
• MITRE, ATT&CK Design and Philosophy, 2020.
• MITRE Engenuity, ATT&CK Evaluations for Enterprise, 2025.
• SigmaHQ, Sigma Rule Specification version 2, 2024.
• Lockheed Martin, Intelligence-Driven Computer Network Defense (Cyber Kill Chain), 2011.