MITRE ATT&CK: MITRE ATT&CK – Tutorial (about 60 minutes)

MITRE ATT&CK is a free, globally used knowledge base that describes how real attackers behave once they target an organisation: the goals they pursue, the methods they use to reach those goals, and which groups and malicious tools have been seen using each method. Security operations centres, threat intelligence analysts, detection engineers, red and purple teams, architects and security managers use it as a shared vocabulary for attacker behaviour. After this tutorial you will be able to read the ATT&CK matrices, map an incident or a threat report to ATT&CK, use it to prioritise detections and defences, measure coverage honestly, and explain how it fits beside other security frameworks.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: ATT&CK is not a standard with fixed editions; it is a living knowledge base maintained by MITRE, a US not-for-profit organisation that operates federally funded research and development centres. MITRE publishes two major releases a year, normally in April and October, with occasional minor point releases (for example v19.1 and v19.2) in between. The current release is ATT&CK v20, released on 13 October 2026; it followed v19 (April 2026). Two recent releases changed the structure in ways this course teaches: v18 (October 2025) replaced the short detection notes on each technique with separate detection strategies and analytics and deprecated the older "data sources" objects, and v19 split the long-standing Enterprise tactic Defense Evasion into two tactics, Stealth and Defense Impairment. According to MITRE's v20 release notes, the Enterprise domain now has 15 tactics, 227 techniques and 479 sub-techniques, while the Mobile and ICS domains have 12 tactics each. ATT&CK is free to use under MITRE's terms of use, which ask you to keep MITRE's copyright notice when you reproduce it. Counts change with every release, so always check the version you are working with. Verified 2026-10-29 on attack.mitre.org (Updates pages for October 2025, April 2026 and October 2026, and the Enterprise tactics list).

Who this is for: SOC analysts, incident responders, detection and platform engineers, threat intelligence analysts, penetration testers moving into purple teaming, security architects, auditors and managers who keep hearing "map it to ATT&CK" and want to know what that really means and how to do it well.

Prerequisites: none. A basic idea of how computers, accounts and networks work helps you picture the examples, and every security term is explained when it first appears.

By the end of this tutorial:

You will be able to explain what ATT&CK is, why MITRE built it, and why attacker behaviour is more useful to defenders than lists of indicators.
You will be able to describe the ATT&CK object model: domains, tactics, techniques, sub-techniques, procedures, groups, software, campaigns, mitigations, detection strategies, analytics and data components.
You will be able to read the Enterprise matrix and explain each of its 15 tactics in plain language.
You will be able to map an incident or a threat report to ATT&CK accurately and avoid the common mapping mistakes.
You will be able to use ATT&CK to prioritise defences, assess detection coverage and plan adversary emulation tests.
You will be able to explain what can and cannot be "certified" or "evaluated" in relation to ATT&CK.
You will be able to place ATT&CK beside related frameworks such as the Cyber Kill Chain, D3FEND, CAPEC, NIST CSF and the CIS Controls.

Lesson 1 – Origins, purpose and scope

Why a catalogue of attacker behaviour was needed

For many years, defence against intrusions relied heavily on indicators of compromise: file hashes of known malware, IP addresses and domain names of attacker servers, and similar fingerprints. Indicators are useful, but they are cheap for an attacker to change. Recompiling a tool changes its hash; renting a new server changes its address. Defenders who only chase indicators are always one step behind.

What attackers find much harder to change is their behaviour. To steal data from a company network, an intruder still needs to get in, run code, keep a foothold, gain more privileges, find valuable systems, move to them, collect the data and send it out. The specific methods for each of those steps are limited by how operating systems, identity systems and networks work. If defenders can describe and detect those methods, the attacker has to invest real effort to get around them. The security researcher David Bianco expressed this idea in his "Pyramid of Pain": hashes and IP addresses sit at the bottom (trivial for attackers to change), while tactics, techniques and procedures sit at the top (painful to change). ATT&CK is, in effect, a detailed map of the top of that pyramid.

Where ATT&CK came from

ATT&CK began in 2013 as an internal MITRE research project. A team was studying how to detect attackers after they had already broken into a network, using data collected from endpoints (the laptops, desktops and servers themselves) rather than only from the network perimeter. To test their ideas they ran red team exercises, recorded what the "attackers" did, and needed a structured way to describe those actions. That structure became ATT&CK. MITRE released it publicly in 2015, initially covering Windows enterprise networks after the initial compromise. The name stands for Adversarial Tactics, Techniques, and Common Knowledge.

Since then it has grown steadily. Linux and macOS were added, then cloud and container platforms, then network devices and virtualisation hosts. In 2020 two important changes arrived: sub-techniques were introduced to give finer detail, and the separate "PRE-ATT&CK" model for activity before an attack was folded into Enterprise as the Reconnaissance and Resource Development tactics. Separate domains were also created for mobile devices (2017) and for industrial control systems (2020). Recent releases have added objects for campaigns, detection strategies and analytics, and v20 added techniques describing attacker use of, and attacks on, AI-based tools.

Purpose and guiding ideas

MITRE describes several principles behind ATT&CK. Paraphrased, they are:

It is based on real-world observations. Techniques are included because they have been seen in actual intrusions reported publicly or contributed by the community, not because they are theoretically possible.
It describes behaviour from the adversary's point of view: what the attacker is trying to achieve and how, rather than which defensive product category would stop it.
It stays at a level of abstraction that is useful to both attackers' emulators and defenders: more specific than a high-level lifecycle model, less specific than a list of exploits or malware samples.
It is community-driven. Researchers, vendors and practitioners around the world contribute new techniques, procedure examples and corrections, and contributors are credited on the pages.
It is open and free. Anyone can browse the website, download the data in a machine-readable format and build tools on top of it.

Scope: what ATT&CK is and what it is not

ATT&CK is a knowledge base and a common language. It tells you what attackers do and gives you identifiers for it. It is not a compliance standard: it has no "shall" requirements, no certification of organisations and no pass mark. It is not a vulnerability database (that is the role of CVE), not a list of software weakness types (CWE), and not a complete defensive control catalogue (frameworks such as NIST SP 800-53 or the CIS Controls do that). It also does not tell you which techniques matter most for your organisation; that judgement comes from your own threat intelligence, risk assessment and environment. Keeping this scope in mind avoids many of the misuses covered later in the pitfalls section.

Lesson 2 – Key concepts and vocabulary

ATT&CK has its own precise vocabulary. The terms below appear throughout the website, threat reports and security tools, so learn them carefully. Each ATT&CK object type has an identifier pattern, shown in brackets.

Adversary – the person, group or organisation carrying out malicious activity. ATT&CK prefers this word to "hacker" or "attacker" but the meaning is the same.
TTPs – tactics, techniques and procedures: the general term for how an adversary operates. ATT&CK gives each of the three a precise meaning.
Domain – a top-level area of ATT&CK covering one kind of technology environment. There are three: Enterprise (traditional IT, cloud, containers and network devices), Mobile (Android and iOS devices) and ICS (industrial control systems).
Platform – the technology a technique applies to within a domain, such as Windows, Linux, macOS, ESXi, Containers, IaaS, SaaS, Office Suite, Identity Provider, Network Devices or PRE (activity before the target is touched).
Tactic (TA0001) – the adversary's tactical goal: why they perform an action. Examples are Initial Access, Persistence and Exfiltration. Tactics are the columns of a matrix.
Technique (T1566) – how an adversary achieves a tactical goal, described at a general level. Phishing is a technique for Initial Access.
Sub-technique (T1566.001) – a more specific variant of a technique. Spearphishing Attachment and Spearphishing Link are sub-techniques of Phishing.
Procedure – the specific way a particular adversary or piece of software has actually carried out a technique, recorded on technique pages as procedure examples with references.
Matrix – the familiar visual table of a domain, with tactics as columns and techniques listed beneath each tactic.
Group (G0016) – a set of related intrusion activity tracked under a common name, such as a named threat actor. ATT&CK lists aliases used by different vendors.
Software (S0154) – malware or tools used by adversaries. ATT&CK distinguishes malware (written for malicious use) from tools (legitimate or dual-use software, such as remote administration utilities, that adversaries abuse).
Campaign (C0024) – a set of intrusion activity carried out over a specific period with common targets and objectives, which may or may not be attributed to a known group.
Mitigation (M1032) – a category of security control or practice that can prevent a technique from succeeding, such as Multi-factor Authentication or Execution Prevention.
Detection strategy (DET0070) – introduced in v18: a description of the overall approach to detecting a technique, linked to one or more analytics.
Analytic (AN0188) – platform-specific detection logic that forms part of a detection strategy, describing which behaviour to look for and in what data.
Data component (DC0032) – a specific kind of telemetry relevant to detection, such as Process Creation, Command Execution or Network Connection Creation.
Mapping – the act of linking an observed behaviour, a detection rule, a control or a report to the matching ATT&CK tactic, technique or sub-technique ID.
Threat-informed defense – an approach to security that uses knowledge of real adversary behaviour, usually expressed in ATT&CK, to decide what to defend, detect and test first.
Adversary emulation – a controlled exercise in which a red team or automated tool reproduces the known behaviours of a specific adversary so defenders can test their prevention and detection.

Two further words appear in release notes. An object is revoked when MITRE replaces it with another object (for example after merging two techniques); the old ID then points to its replacement. An object is deprecated when it is withdrawn without a direct replacement. Every object also carries its own version number, so a technique can be at version 2.8 while ATT&CK as a whole is at v20.

Figure 1 – The ATT&CK object model: tactics, techniques and procedures in the centre, with groups, software and campaigns that use techniques, and mitigations and detection objects that defend against them.

Figure 1 is worth studying for a minute because almost every ATT&CK use case follows one of its arrows. Threat intelligence moves from groups and campaigns to the techniques they use. Defensive engineering moves from a technique to its mitigations and detection strategies. Detection engineering moves from a detection strategy to analytics and down to the data components you must collect. When people say "map to ATT&CK", they nearly always mean "attach the right technique ID to something", so that everything else in the model can be linked to it.

Lesson 3 – Structure of the knowledge base

The three domains

ATT&CK is divided into three domains, each with its own matrix. Enterprise is by far the largest and most used. It covers Windows, Linux and macOS endpoints; cloud environments, split into IaaS (infrastructure as a service), SaaS (software as a service), Office Suite and Identity Provider platforms; containers; ESXi virtualisation hosts; network devices; and the PRE platform for activity that happens before the adversary touches the target. Mobile covers Android and iOS devices, from malicious apps to abuse of device features and the networks phones connect to. ICS covers industrial control systems: the controllers, engineering workstations, human-machine interfaces and safety systems that run physical processes in factories, utilities and transport. ICS has two tactics that do not exist elsewhere, Inhibit Response Function (stopping safety and protection functions from responding) and Impair Process Control (manipulating the physical process itself), and it also models assets such as controllers and safety instrumented systems.

The Enterprise tactics

The Enterprise matrix has 15 tactics in v20. Here they are in the order the matrix shows them, each with a plain-language summary:

Reconnaissance – gathering information to plan an attack, such as scanning public systems or collecting staff names.
Resource Development – building or acquiring the resources an operation needs: infrastructure, accounts, tools, stolen credentials or lookalike domains.
Initial Access – getting a first foothold, for example by phishing, exploiting a public-facing application or logging in with stolen accounts.
Execution – running adversary-controlled code, such as scripts or commands.
Persistence – keeping access across restarts, password changes or other interruptions.
Privilege Escalation – gaining higher permissions, such as administrator or root rights.
Stealth – hiding activity so that it looks normal or escapes notice, for example by masquerading as a legitimate file or obfuscating code.
Defense Impairment – breaking, disabling or weakening security controls and monitoring, such as turning off endpoint protection, changing firewall rules or clearing logs.
Credential Access – stealing account names, passwords, tokens and keys.
Discovery – learning about the environment: systems, accounts, network shares, security tools and cloud resources.
Lateral Movement – moving from one system to another inside the environment.
Collection – gathering the data of interest, such as files, emails or screenshots.
Command and Control – communicating with compromised systems to control them.
Exfiltration – moving stolen data out of the environment.
Impact – disrupting availability or integrity: encrypting data for ransom, destroying data, defacing sites or stopping services.

If you learned ATT&CK before April 2026 you will remember a single Defense Evasion tactic. MITRE split it in v19 because it had become very large and mixed two different ideas: hiding from defenders (now Stealth, which kept the old identifier TA0005) and actively damaging defences (now Defense Impairment, TA0112). The distinction matters in practice: an adversary who disables your endpoint agent leaves a very different trace from one who quietly renames a tool to look like a system file.

Figure 2 – The 15 Enterprise tactics grouped into broad stages; real intrusions skip, repeat and reorder tactics, so the order is a reading aid, not a sequence.

Figure 2 groups the tactics into stages to help you remember them, but be careful: the matrix is not a strict kill chain. An adversary may perform Discovery on day one and again in week three, may never need Privilege Escalation, or may go straight from Initial Access to Impact. Command and Control often runs from very early in an intrusion to the end. Treat tactics as categories of intent rather than steps in a fixed order.

Techniques and sub-techniques

Under each tactic sit techniques. A technique can appear under more than one tactic when the same behaviour serves different goals. Valid Accounts (T1078) is the classic example: logging in with legitimate credentials can give initial access, keep persistence, escalate privileges, or blend in for stealth. When you map an observation, the tactic you choose depends on what the adversary was trying to achieve at that moment, not just on what they did.

Many techniques have sub-techniques that describe more specific variants. Sub-technique IDs add a three-digit suffix to the parent ID, so T1059.001 is PowerShell under Command and Scripting Interpreter (T1059). When you have enough detail, map to the sub-technique; when you do not, mapping to the parent technique is correct and honest.

Anatomy of a technique page

Every technique page on attack.mitre.org follows the same layout, and reading one well is a core skill:

A header with the ID, the tactic or tactics, the platforms, contributors, the object version and the created and last-modified dates.
A description of the behaviour in general terms, with references.
A list of sub-techniques, if any.
Procedure examples: groups, software and campaigns known to use the technique, each with a short note and a citation to the public source.
Mitigations: the mitigation categories that apply, each with a sentence explaining how it helps against this technique.
Detection strategy: the linked detection strategy and its analytics for each relevant platform.
References: the reports and articles the page relies on.

Data formats and tools

ATT&CK is published not only as web pages but also as machine-readable data in STIX 2.1, the OASIS standard format for exchanging cyber threat intelligence. MITRE provides the data on GitHub and through programming libraries, so security tools can import it. The free ATT&CK Navigator web application lets you create "layers": copies of a matrix where you colour, score and comment on techniques, for example to show which techniques a group uses or which ones you can detect. Layers are saved as small JSON files and can be shared. MITRE's ATT&CK Workbench lets organisations run a local copy of the knowledge base and extend it with their own notes and objects.

Versions and releases

Because ATT&CK changes twice a year, every serious use of it should record the version. Version permalinks on the website let you link to a page as it was in a given release. Release notes list new, changed, revoked and deprecated objects. The v19 split of Defense Evasion and the v18 move to detection strategies are good examples of why this matters: a detection rule tagged "Defense Evasion" in 2025 needs re-mapping today.

Lesson 4 – How it works in practice

ATT&CK does not prescribe a process, so organisations combine it with their own security operations. In practice, five use cases dominate, and together they form a cycle that is often called threat-informed defense.

Use case 1: threat intelligence

Cyber threat intelligence (CTI) analysts read incident reports, vendor research and government advisories and translate the described behaviours into ATT&CK techniques. This turns prose into structured data that can be compared across reports, adversaries and time. Many public advisories from national cybersecurity agencies now include ATT&CK tables. Analysts can then answer questions such as "which techniques are used by the groups that target our sector?" and "which techniques appear in most ransomware intrusions this year?".

Use case 2: detection engineering

Detection engineers write the rules and analytics that run in a SIEM (security information and event management system) or an EDR (endpoint detection and response) platform. They use the technique pages and detection strategies to understand what to look for, the data components to know which telemetry they need, and they tag each rule with the technique it targets. Tagging makes it possible to see coverage across the matrix and to route alerts with useful context to analysts.

Use case 3: assessment and gap analysis

Security teams compare their prevention and detection capabilities against the techniques that matter most to them. A Navigator layer of prioritised techniques coloured by how well each is covered becomes a powerful planning tool, as long as the colours reflect evidence rather than guesswork.

Use case 4: adversary emulation and purple teaming

Red teams use ATT&CK to plan exercises that reproduce the behaviour of real adversaries instead of inventing generic attacks. In a purple team exercise the red and blue teams work together: the red team runs a technique, the blue team checks whether it was prevented, logged, detected and alerted, and both improve the result on the spot. Open-source tools such as MITRE CALDERA (an automated emulation platform) and Atomic Red Team (a library of small, ATT&CK-mapped tests) make this practical even for small teams. The Center for Threat-Informed Defense, a MITRE-run research collaboration, publishes adversary emulation plans and other free resources.

Use case 5: communication and architecture

Because ATT&CK is a shared vocabulary, it helps different people talk to each other. An incident report that says "the adversary used T1078.004 Cloud Accounts" is precise to anyone familiar with ATT&CK. Architects use it to ask which techniques a proposed design makes easier or harder. Managers use summaries of coverage to explain where investment is needed. Vendors describe their product capabilities in ATT&CK terms, although you should verify such claims yourself.

Figure 3 – The threat-informed defense cycle: intelligence is mapped to ATT&CK, turned into priorities, closed with defences, proven by testing and fed back into the next round.

Mapping step by step

Mapping is the skill underneath all five use cases. CISA, the US Cybersecurity and Infrastructure Security Agency, together with MITRE's Homeland Security Systems Engineering and Development Institute, published a free guide on mapping best practices. Its process for a finished report can be summarised in your own words as follows:

Find the behaviour. Look for what the adversary actually did, not for the tools or indicators alone. "The actor used a remote access tool" is weaker than "the actor created a scheduled task to relaunch the tool every hour".
Research the behaviour. If you do not understand a protocol, command or tool, learn enough to know what it achieves.
Identify the tactic. Ask what goal the action served at that point in the intrusion.
Identify the technique. Search the techniques under that tactic and read their descriptions; keyword matches can mislead.
Identify the sub-technique, if the evidence is specific enough.
Compare with other analysts. Peer review catches bias and inconsistency, especially across a team.

The same thinking applies when you map raw data, such as logs from an incident: you start from the observed events, work out the behaviour they represent, and then follow the same steps. Record the ATT&CK version you mapped against, the evidence for each mapping and your confidence.

Figure 4 – Mapping a behaviour to ATT&CK: start from what the adversary did, choose the tactic by its purpose, go only as specific as the evidence allows, then have it reviewed.

Prioritising techniques

No organisation can defend against several hundred techniques and sub-techniques at once, and it should not try. A sensible priority list combines several inputs. First, threat relevance: which groups and campaigns target your sector, region and technology, and which techniques do they use? Second, prevalence: which techniques appear across many intrusions; the Center for Threat-Informed Defense publishes free tooling to help rank techniques this way. Third, your environment: a technique that only affects macOS matters little if you have no Macs. Fourth, choke points: techniques many attack paths depend on, such as credential theft or abuse of valid accounts, give more value per control. The output is usually a short list, perhaps a few dozen techniques, that becomes the scope for the next coverage assessment.

Roles and artefacts

Typical roles in an ATT&CK programme are the CTI analyst (maps intelligence and maintains the threat profile), the detection engineer (builds and tags analytics), the SOC lead (owns alert quality and response), the red or purple team (tests techniques), and a security manager who sponsors the work and reports to leadership. Typical artefacts are a threat profile (the adversaries and techniques that matter, with sources), a Navigator layer for priorities and one for coverage, a detection catalogue with technique tags, emulation plans and test results, and a gap register with owners and dates.

Lesson 5 – Assessment, certification and compliance

There is no ATT&CK compliance certificate for organisations

This point is often misunderstood, so be clear about it. ATT&CK contains no requirements, so an organisation cannot be "ATT&CK compliant" or "ATT&CK certified". No accredited certification bodies exist for it, and MITRE does not audit or approve organisations against it. When a vendor or consultant says a product or a SOC "covers ATT&CK", ask what exactly is covered, how it was tested, and against which version.

What does exist

Self-assessment of coverage. Organisations assess themselves, usually by mapping their controls and detections to techniques and then testing them. This is internal evidence for management and for other frameworks, not a certification.
Product evaluations. MITRE runs the ATT&CK Evaluations programme, in which security vendors volunteer their products to be tested against an emulation of a real adversary's behaviour. MITRE publishes detailed results openly and explicitly does not rank or score vendors as winners; readers are expected to study the results for the behaviours that matter to them. Recent rounds have added more emphasis on blocking attacks and on the quality of alerts, not just raw detections.
Individual training and credentials. MITRE's ATT&CK Defender training programme is now run by MAD20 Technologies, an independent company, which offers an ATT&CK fundamentals course and role-based credentials, for example in cyber threat intelligence, SOC assessments and adversary emulation. These certify individuals' knowledge, not organisations. Check the provider's current catalogue for details.
Use within other assessments. Regulators, auditors and other frameworks increasingly reference ATT&CK. For example, many government security advisories and red team reports describe adversary behaviour in ATT&CK terms, and control-mapping projects link ATT&CK techniques to NIST SP 800-53 controls and cloud provider security features. In those settings the requirement comes from the other framework; ATT&CK provides the vocabulary.

Assessing detection coverage honestly

The most common ATT&CK "assessment" is a coverage heatmap. Done well, it is very valuable. Done badly, it gives false confidence. A good coverage assessment has these properties:

It is scoped to the prioritised techniques, not the whole matrix.
It distinguishes levels of capability, for example: no data; data collected but no analytic; analytic exists but untested; tested and alerts reliably; tested and prevented. Some teams use simple scores such as 0 to 3.
It is based on evidence: a test run, a captured log, a fired alert, a ticket. A rule that exists but has never fired against a realistic test is an assumption, not coverage.
It considers platforms separately. Detecting a technique on Windows says nothing about the same technique on Linux or in a cloud tenant.
It is dated and versioned, and it is repeated, because both the environment and ATT&CK change.

Remember also that one technique can be performed in many ways. A single analytic for PowerShell abuse may catch one procedure and miss another. Coverage is therefore a matter of degree, and honest reports say so.

Reporting to management

Leaders need a small number of meaningful measures, not a giant coloured matrix. Useful measures include the share of prioritised techniques with tested detection, the trend over time, the number of significant gaps with owners and target dates, and lessons from the latest emulation exercise. Present the heatmap as supporting detail and explain what each colour means.

Lesson 6 – Worked example

To tie the lessons together, follow a fictional but realistic organisation through one round of the cycle. Northbridge Logistics is a mid-sized freight company with 2,500 staff, a Windows-based office network with Active Directory, a cloud identity provider for email and collaboration, and some Linux servers that run its tracking platform. It has a small SOC of six analysts using an EDR product and a SIEM. After a competitor suffered a ransomware attack, the board asks the security manager, Amina, a simple question: "Could that happen to us, and would we see it coming?"

Step 1 – Build a threat profile

Amina asks the CTI analyst, Jonas, to identify adversaries that target logistics and transport companies. Jonas reads government advisories and vendor reports from the last two years and picks three ransomware operations and one financially motivated group that often sells access to them. Using the ATT&CK Group and Software pages and the reports' own ATT&CK tables, he records the techniques each one uses, the sources and the ATT&CK version (v20). Where a report is vague, he maps to the parent technique and notes low confidence.

Step 2 – Map a real intrusion

Jonas also maps the competitor's incident, which was described publicly. His working notes look like this:

A finance employee received an email with a malicious document attached and opened it: Initial Access, Phishing: Spearphishing Attachment (T1566.001).
A macro in the document launched an encoded PowerShell command: Execution, Command and Scripting Interpreter: PowerShell (T1059.001); the encoding itself is Obfuscated Files or Information (T1027) under Stealth.
The malware created a scheduled task to restart itself: Persistence, Scheduled Task/Job: Scheduled Task (T1053.005).
The actor read credentials from the memory of the Windows authentication process: Credential Access, OS Credential Dumping: LSASS Memory (T1003.001).
They listed domain computers and file shares: Discovery, Remote System Discovery (T1018) and Network Share Discovery (T1135).
Using a stolen administrator account, they connected to servers with Remote Desktop: Lateral Movement, Remote Services: Remote Desktop Protocol (T1021.001); the stolen account itself is Valid Accounts: Domain Accounts (T1078.002), recorded under Privilege Escalation because it gave them administrator rights they did not have before.
They turned off the endpoint protection agent on key servers: Defense Impairment, Disable or Modify Tools (T1685).
They uploaded archives of business data to a cloud storage service: Exfiltration, Exfiltration Over Web Service (T1567).
Finally they deleted backup snapshots and encrypted the servers: Impact, Inhibit System Recovery (T1490) and Data Encrypted for Impact (T1486).

Notice two mapping decisions. The stolen administrator account is mapped to Valid Accounts because the adversary logged in normally, and Valid Accounts is not listed under Lateral Movement, so Jonas files it under the tactic it served at that moment (Privilege Escalation) while RDP carries the Lateral Movement mapping. And disabling the security agent goes under Defense Impairment, not Stealth, because the adversary actively broke a control rather than hiding from it. Jonas asks a colleague to review the mapping, who suggests one correction: the archive creation before exfiltration should also be recorded as Archive Collected Data (T1560) under Collection.

Step 3 – Prioritise

Combining the four adversaries' techniques with the competitor's incident, Jonas loads everything into ATT&CK Navigator as separate layers and combines them, giving a higher score to techniques used by more of the adversaries. He removes techniques that only apply to platforms Northbridge does not use and adds two cloud identity techniques because of the company's heavy use of the identity provider. The result is a list of 32 prioritised techniques.

Step 4 – Assess coverage

The detection engineer, Priya, maps existing SIEM and EDR rules to the 32 techniques. For each technique she records whether the needed data components are collected (for example, Process Creation and Command Execution on Windows servers), whether a rule exists, and whether it has been tested. Her first finding is uncomfortable: the Linux servers send almost no process telemetry to the SIEM, so every Linux technique is scored 0 regardless of rules. Her second finding is that the RDP lateral movement rule exists but has never fired, even in normal operations, which suggests it may be broken.

Step 5 – Close the most important gaps

Amina's team agrees on a 90-day plan. Mitigations come first where they are cheap and effective: tighter macro settings for documents from the internet (Execution Prevention and Software Configuration), multi-factor authentication for all remote administrative access, removing local administrator rights, and immutable backups. In parallel Priya enables process and command-line logging on Linux servers, repairs the RDP rule, and writes new analytics for scheduled task creation by unusual parents and for attempts to stop the EDR service.

Step 6 – Test with adversary emulation

With approval from IT operations and a change window, the team runs a purple team exercise in a test segment that mirrors production. Using a small set of Atomic Red Team tests and a CALDERA plan based on one of the ransomware operations, the red team executes 20 of the prioritised techniques. For each one the blue team records: prevented, alerted, logged only, or missed. The results show 9 alerted, 4 prevented, 5 logged only and 2 missed. The two misses lead to new analytics, and the five "logged only" items become tuning work.

Step 7 – Report and repeat

Amina reports to the board in one page: the threat profile, the share of prioritised techniques with tested detection or prevention (up from 31 % to 59 %), the remaining gaps with owners and dates, and the decision to repeat the cycle every six months, timed shortly after each ATT&CK release so that new and changed techniques are reviewed. The coloured Navigator layer is attached as an appendix with a legend. The board now has an honest answer to its question: some of the competitor's attack path would be seen early, some later, and a clear plan exists for the rest.

Lesson 7 – Relationship to other standards and frameworks

ATT&CK is most powerful when combined with other frameworks. It describes adversary behaviour; others describe defences, weaknesses, governance or exchange formats. The table compares the most common neighbours.

Framework	Owner	What it describes	How it relates to ATT&CK
Lockheed Martin Cyber Kill Chain	Lockheed Martin	A seven-stage, linear model of an intrusion from reconnaissance to actions on objectives	Higher-level and sequential; ATT&CK gives far more detail and does not assume a fixed order. Teams often use the Kill Chain for storytelling and ATT&CK for analysis.
MITRE D3FEND	MITRE	A knowledge graph of defensive cybersecurity techniques, such as hardening, detection and isolation methods	The defensive counterpart: D3FEND links its countermeasures to the ATT&CK techniques they address.
MITRE Engage	MITRE	A framework for adversary engagement, including deception and denial activities	Uses ATT&CK to plan engagements that exploit predictable adversary behaviour.
CAPEC	MITRE	A catalogue of attack patterns that exploit weaknesses in software and systems	Focused on application-level attack patterns; many CAPEC entries reference related ATT&CK techniques.
CVE and CWE	CVE Program and MITRE	Specific publicly known vulnerabilities (CVE) and types of software weakness (CWE)	ATT&CK describes behaviour such as exploiting a public-facing application; CVE and CWE identify the particular flaw exploited.
MITRE ATLAS	MITRE	Adversary tactics and techniques against AI and machine learning systems	Modelled on ATT&CK and complementary to it; v20 also added some AI-related techniques to Enterprise ATT&CK.
NIST Cybersecurity Framework 2.0	NIST	Outcome-based programme structure: Govern, Identify, Protect, Detect, Respond, Recover	CSF says what outcomes a programme needs; ATT&CK helps decide which threats the Protect and Detect outcomes must handle and how to test them.
NIST SP 800-53 and the CIS Controls	NIST; Center for Internet Security	Catalogues of security and privacy controls or prioritised safeguards	Control-to-technique mappings show which ATT&CK techniques a control helps against; the CIS Controls use ATT&CK in their own threat modelling.
STIX 2.1 and TAXII	OASIS	Data format and transport protocol for sharing threat intelligence	ATT&CK itself is published as STIX data, and intelligence feeds use ATT&CK IDs to describe attack patterns.

A practical way to remember the relationships: frameworks such as NIST CSF and ISO/IEC 27001 tell you how to run a security programme; control catalogues such as NIST SP 800-53 and the CIS Controls tell you what safeguards to have; ATT&CK tells you what adversaries actually do, so you can check that your safeguards and detections address real behaviour; D3FEND and Engage help you choose specific defensive and engagement actions; and CVE, CWE and CAPEC describe the weaknesses that attackers exploit along the way.

One more relationship deserves attention: ATT&CK versus your own environment. Public ATT&CK reflects what has been reported, which over-represents some sectors and regions and lags behind the newest tradecraft. Your own incidents and threat hunting may show behaviours not yet in ATT&CK. Record them carefully, map them to the nearest technique with a note, and consider contributing them to MITRE through the contribution process described on the website.

Common pitfalls and best practices

Common pitfalls

Treating the matrix as a checklist to complete. Trying to "turn the whole matrix green" wastes effort on irrelevant techniques and encourages shallow rules. Prioritise first.
Equating a tagged rule with coverage. A rule labelled with a technique ID may never fire, may cover one procedure out of many, or may depend on data you do not collect. Only testing proves coverage.
Mapping by keyword. Seeing the word "token" or "credential" in a report and picking a technique with a similar name leads to wrong mappings. Read the technique description and choose by the adversary's goal.
Mapping indicators instead of behaviours. A malicious IP address or file hash is not a technique. Map what the adversary did with them.
Over-specific mapping. Choosing a sub-technique when the evidence only supports the parent technique creates false precision.
Ignoring versions. Mixing mappings from different ATT&CK versions, or never updating rules after releases such as the v19 tactic split, produces inconsistent and broken reports.
Believing vendor coverage claims without checking. "Covers 90 % of ATT&CK" usually means something much narrower; ask how it was measured.
Calling the organisation "ATT&CK certified". No such certification exists for organisations.

Best practices

Start from your threats. Build a threat profile from intelligence relevant to your sector, region and technology, and let it drive priorities.
Collect the right data first. Use data components to check that you have the telemetry, such as process creation and command execution, before writing analytics.
Record evidence, confidence and version for every mapping, and peer review mappings within the team.
Test regularly with adversary emulation and purple teaming, in controlled conditions with proper approvals, and record outcomes per technique and platform.
Use graded coverage scores (no data, logged, alerted, prevented) instead of a simple yes or no.
Prefer mitigations for choke-point techniques such as credential theft and abuse of valid accounts, where one control blocks many attack paths.
Review each ATT&CK release for new, revoked and deprecated objects that affect your rules, layers and reports.
Communicate simply. Give leaders a few trend measures and clear gaps, with the heatmap as supporting detail and a legend.

Summary and key takeaways

MITRE ATT&CK is a free, community-informed knowledge base of real-world adversary behaviour, currently at v20 (October 2026), with Enterprise, Mobile and ICS domains.
Tactics describe why an adversary acts, techniques and sub-techniques describe how, and procedures describe exactly what a specific actor did.
The Enterprise matrix has 15 tactics; since v19 the former Defense Evasion tactic is split into Stealth and Defense Impairment.
Groups, software and campaigns link to the techniques they use; mitigations, detection strategies, analytics and data components link defences to those techniques.
Good mapping starts from observed behaviour, chooses the tactic by purpose, goes only as specific as the evidence allows, and is peer reviewed and versioned.
Threat-informed defense uses ATT&CK in a cycle: intelligence, prioritisation, coverage assessment, defences, emulation testing and reporting.
There is no ATT&CK certification for organisations; product evaluations and individual credentials exist, and coverage claims must be backed by testing.
ATT&CK complements, rather than replaces, governance frameworks, control catalogues, vulnerability databases and defensive knowledge bases such as D3FEND.

Reflection questions

Think of a security incident you know about, from your organisation or the news. Which three tactics were most important in it, and which techniques would you map them to, with what confidence?
Which adversaries are most relevant to your sector and region, and what sources would you use to build a threat profile for them?
If you produced a coverage heatmap tomorrow, what evidence would you require before colouring a technique as "covered", and how would you show partial coverage?
Which data components are you collecting today on each of your main platforms, and where are the blind spots that would make detection impossible?
How would you explain to a senior manager, in two minutes, why "we are ATT&CK compliant" is the wrong claim and what a better statement would be?