MITRE ATT&CK: A Practical Guide to Understanding Adversary Behavior 

If you work in cybersecurity, there is a good chance you have seen the MITRE ATT&CK matrix. It appears in security product dashboards, threat reports, detection rules, assessments, and red-team exercises. For many security teams, “mapping to ATT&CK” has become a standard way to describe capabilities and adversary activity. 

But knowing what the matrix looks like is not the same as knowing how to use it. 

MITRE ATT&CK is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. At its core, ATT&CK gives security teams a common language for describing what attackers do, why they do it, and how those behaviors can be observed and tested. 

That common language is what makes ATT&CK valuable across threat intelligence, security operations, detection engineering, red teaming, and security assessments. 

Understanding the Building Blocks 

The easiest way to understand ATT&CK is to start with four concepts: tactics, techniques, sub-techniques, and procedures. 

Tactics describe why an adversary is taking an action. They represent objectives such as gaining initial access, obtaining credentials, moving through an environment, collecting information, or exfiltrating data. 

Techniques describe how an adversary may accomplish one of those objectives. 

For example, Phishing, T1566, is a technique associated with the Initial Access tactic. It describes an adversary attempting to gain access by delivering a malicious message. 

Techniques can also contain sub-techniques, which describe behavior more precisely. Spearphishing Attachment, T1566.001, is a sub-technique of Phishing. Instead of simply saying that phishing occurred, the sub-technique tells us that a malicious attachment was used. 

Procedures go another level deeper. A procedure describes how a real adversary or piece of software has actually implemented a technique or sub-technique. This distinction is important. A technique describes a category of behavior. A procedure describes an observed example of that behavior. 

Consider a simple scenario. An attacker sends an employee a malicious attachment. That behavior may map to Spearphishing Attachment. If the employee opens the file and execution relies on that interaction, another part of the activity may map to User Execution: Malicious File, T1204.002. From there, the attacker might perform additional actions related to credential access, discovery, persistence, lateral movement, collection, or exfiltration. 

ATT&CK provides a consistent way to describe each part of that activity without tying the conversation to a particular vendor or security product. 

ATT&CK Is More Than the Matrix 

The matrix is the most recognizable part of ATT&CK, but the knowledge base contains considerably more information. Technique pages can connect behaviors to platforms, procedure examples, mitigations, defensive information, known adversary groups, software, and supporting references. 

That makes ATT&CK useful to several security disciplines at the same time. 

Cyber threat intelligence teams can map threat reporting to ATT&CK so they can compare adversaries based on behavior instead of relying only on malware names, indicators of compromise, or threat actor labels. MITRE’s own ATT&CK training covers how intelligence teams can map narrative reporting and raw data to ATT&CK, store ATT&CK-mapped intelligence, analyze that information, and turn it into defensive recommendations. 

In practice, that means pulling specific attacker actions out of a report, mapping each action to the closest ATT&CK technique or sub-technique, recording the supporting evidence, and then comparing those mapped behaviors against your existing detections, telemetry, and controls to identify gaps. 

Threat hunters and detection engineers can use ATT&CK to identify behaviors worth detecting and then determine what data is necessary to observe them. Instead of starting with a security product and asking what alerts it can generate, teams can start with adversary behavior and work backward toward the telemetry and analytics required to detect it. 

Red and purple teams can use the same framework to organize testing. Instead of simply reporting that a particular tool or exploit was used, they can explain which adversary behaviors were exercised and determine whether the organization was able to observe, detect, and respond to them. You can read about how FRC uses MITRE ATT&CK in our AEV Lab Environment here. 

The value is not just the matrix itself. It is having attackers, defenders, and intelligence teams describe behavior in the same language. 

Why “100% ATT&CK Coverage” Is the Wrong Goal 

One of the most useful lessons in MITRE’s ATT&CK guidance is also one of the easiest to overlook: ATT&CK should not be treated as a checklist. 

MITRE does not recommend pursuing 100 percent ATT&CK coverage, and there is a practical reason for that. Every organization has a different technology environment, attack surface, and threat profile. A technique that is highly relevant to one organization may have little relevance to another. 

There is also a bigger problem with the word coverage. 

What does it actually mean to say that a technique is covered? Does it mean you collect a relevant log source? Does it mean a detection rule exists? Has the rule been tested? Can your analysts investigate the resulting alert? Can an endpoint or network control prevent the behavior? 

Even detecting one implementation of a technique does not necessarily mean that an organization can detect every way an adversary might perform that technique. 

A better approach is to use ATT&CK to prioritize. 

Start with the threats and adversary behaviors that matter to your organization. Identify the relevant techniques and sub-techniques. Then evaluate whether you have the telemetry, detections, controls, and response processes necessary to address those behaviors. 

ATT&CK becomes much more useful when it exposes meaningful gaps instead of becoming a scoreboard filled with green boxes. 

Using ATT&CK for Adversary Emulation 

One of the most practical uses of ATT&CK is adversary emulation, which involves testing defenses by reproducing behaviors associated with real threat actors. Rather than selecting attack techniques at random, teams can combine ATT&CK with cyber threat intelligence to determine which tactics, techniques, and procedures make sense to test. 

Suppose we look at the APT29, as it is relevant to much of the United States public sector. 

ATT&CK provides information about behaviors associated with APT29, including techniques and sub-techniques the group has used, software associated with its operations, and examples drawn from publicly reported campaigns. A red or purple team can use that information to identify behaviors worth testing instead of simply working through the ATT&CK matrix technique by technique. 

The goal is not simply to ask, “Can we execute T1059, Command and Scripting Interpreter?” 

A more useful question is, “Would an adversary we care about use this behavior against our environment, and if they did, would we see it?” 

MITRE demonstrated this type of approach when APT29 was used as the adversary for an ATT&CK Evaluation. The emulation was built using publicly available threat intelligence and organized around operational flows and behaviors associated with APT29.  

An important part of adversary emulation is that teams do not necessarily have to reproduce an attacker’s exact malware or infrastructure. The objective is to reproduce the behavior. For example, an emulation team may use a different red-team tool from the one used by the real adversary as long as it accurately reproduces the ATT&CK behavior being tested. This makes adversary emulation much more practical. Security teams do not need access to every malware family used by APT29 to determine whether they can detect the behaviors associated with its operations. 

The Pyramid of Pain, developed by security researcher David Bianco, illustrates why focusing on adversary behavior is more valuable than relying only on indicators of compromise. At the bottom of the pyramid are things like file hashes, IP addresses, and domain names, which attackers can often change quickly. Higher up are tools and, ultimately, tactics, techniques, and procedures, or TTPs. Forcing an adversary to change how they operate is much more difficult than forcing them to change an IP address or malware hash. This is one reason ATT&CK is so useful: it helps defenders focus on behaviors that are harder for attackers to simply replace.

Threat intelligence also has limitations. Public reporting does not always provide a complete step-by-step account of an intrusion. A report might document individual techniques, malware capabilities, or portions of an attack without showing exactly how every action was chained together. An emulation team still has to use the available intelligence, knowledge of its own environment, and reasonable assumptions to build a realistic attack path and ATT&CK provides structure for that process. 

Instead of testing unrelated techniques simply because they exist in the matrix, organizations can identify relevant adversaries, examine the TTPs those adversaries are known to use, and build testing around those behaviors. 

That leads to much more meaningful questions: 

Can our controls stop this behavior? Can we detect it? Are we collecting the right telemetry? And can our analysts investigate what happened? 

This is where ATT&CK moves from being a knowledge base to becoming a foundation for threat-informed security testing. 

A Practical Way to Start 

You do not need to memorize hundreds of ATT&CK techniques before the framework becomes useful. 

A better starting point is to choose one use case. 

If you work in threat intelligence, take a recent threat report and map the behaviors it describes. If you work in a SOC, identify several techniques associated with a threat that matters to your organization. Determine whether you have the telemetry and detections necessary to observe them. If you are on a red or purple team, select a relevant adversary or set of techniques and test whether the organization can observe and investigate those behaviors. 

The ATT&CK Navigator can also help. Navigator allows teams to annotate and visualize ATT&CK matrices. It can be used to compare threat actors, visualize defensive capabilities, plan red and blue team activities, and highlight techniques that deserve additional attention. 

The important part is to start small. Learn the tactics, become familiar with the techniques that matter to your environment, and build from there. 

The Real Value of ATT&CK 

ATT&CK is useful because it gives security teams a shared way to talk about what adversaries do. 

A threat intelligence analyst can identify behavior. A detection engineer can determine what telemetry is required to see it. A red team can reproduce it. A SOC analyst can investigate it. Security leaders can use the same information to understand gaps and prioritize improvements. 

For organizations getting started, the goal should not be to “implement ATT&CK.” The goal should be to use ATT&CK to make threat intelligence more actionable, defensive testing more realistic, detection more intentional, and security decisions easier to explain. Once teams begin using the framework that way, ATT&CK stops being a poster on the wall and becomes part of how security work gets done.