MITRE ATT&CK Fundamentals common mistakes
MITRE ATT&CK Fundamentals · Understand the traps and how to avoid them.
Treating ATT&CK as a linear kill chain and answering questions as if an adversary must complete every tactic in order, so a scenario describing credential dumping before initial access is judged impossible or the first tactic listed is chosen as a technique's 'parent'.
Candidates carry over the Lockheed Martin Cyber Kill Chain's sequential model from security awareness training and assume ATT&CK tactics are stages with enforced ordering, when ATT&CK is a set of unordered categories of observed behaviour.
What to do instead
Memorise that the Enterprise matrix columns are categories, not phases, and that techniques are assigned to a tactic by the adversary's goal at that moment. When a question asks which tactic a technique belongs to, ask 'what is the adversary trying to achieve with this action?' rather than 'where in the sequence does this sit?'. Note that many techniques map to several tactics (for example Command and Scripting Interpreter maps to Execution, Persistence, Privilege Escalation, and Defense Evasion).
Confusing techniques with sub-techniques in identification questions, for example naming T1059 as the answer when the scenario describes PowerShell specifically, or writing sub-technique IDs without the parent (T1059.001 written as T001).
Candidates learn technique names from summaries or blog posts that omit the dotted ID structure and never internalise that sub-techniques are the more granular level introduced in ATT&CK v7 (October 2020) to separate distinct implementations of a broad behaviour.
What to do instead
Learn the ID grammar: T#### is a technique, T####.### is a sub-technique whose parent is the part before the dot. Practise converting scenario language into the most specific level the question asks for: 'PowerShell' points to T1059.001, 'command and scripting interpreter generally' points to T1059. Check whether the question asks for a technique or a sub-technique before answering, and always write the full dotted ID.
Reading procedure examples in group, software, or campaign pages as definitions of the technique and answering 'which technique does this group use?' based on a single cited example, rather than separating what the group did from the technique it maps to.
ATT&CK pages present procedure examples as prose with citations, and candidates skim the prose without tracing which technique page the example is attached to, or they assume a group 'owns' a technique because it appears on its page.
What to do instead
Treat procedure examples as evidence that links a specific actor behaviour to a specific technique ID. When revising, cover the technique name and reconstruct it from the example, then check against the ID. Remember that a group page is an aggregation of mapped behaviours, not a signature list, and that absence from a group page does not mean the group never used a technique.
Confusing groups, software, and campaigns: describing a tool as a group, treating a campaign as a persistent threat actor, or assuming every software entry is malware rather than including legitimate dual-use utilities.
The three object types live in adjacent sections of the ATT&CK site and share a similar page layout, and candidates assume 'software' means malicious tooling when ATT&CK software includes commercial and open-source tools abused by adversaries.
What to do instead
Anchor the definitions: a group is a tracked cluster of related intrusion activity (with aliases from other vendors), software is a tool or malware family used during operations (including legitimate utilities), and a campaign is a specific set of activity within a limited time frame against specific targets. Use the STIX object type as a tiebreaker: intrusion-set, tool or malware, and campaign respectively. Note that ATT&CK uses 'Group' where STIX uses intrusion-set.
Treating ATT&CK mitigations as a compliance checklist or as one-to-one fixes for techniques, and answering mitigation questions by picking the control that sounds strongest rather than the one ATT&CK actually maps to the technique in the scenario.
Candidates transfer habits from control frameworks where controls map to assets, and they do not realise ATT&CK mitigation mappings are many-to-many and deliberately incomplete, since ATT&CK does not attempt to cover every defensive measure.
What to do instead
Learn that a mitigation can address multiple techniques and a technique can be addressed by multiple mitigations, and that some techniques have no listed mitigation. When answering, identify the technique first, then recall its mapped mitigations; where a question asks about detection rather than prevention, switch to Data Sources and Data Components instead of forcing a mitigation answer.
Answering detection questions with log source names that are not ATT&CK Data Sources or Data Components, such as naming a specific SIEM product, an index name, or a generic term like 'network logs' when the question expects the ATT&CK data model term.
Candidates rely on operational experience with vendor tooling and have not studied the Data Sources and Data Components lists, which were restructured in recent ATT&CK versions (Data Sources such as Process, Command, File, Network Traffic, Logon Session, with Data Components beneath them).
What to do instead
Study the current Data Sources list and the Data Components under each, and practise mapping a technique's detection guidance to those terms. Learn that ATT&CK detection guidance describes what to collect and monitor, not which product to buy, and that analytic content in ATT&CK is expressed against data components rather than vendor fields.
Assuming ATT&CK for Mobile and ATT&CK for ICS are subsets of the Enterprise matrix, or applying Enterprise tactic names and technique IDs to a mobile or ICS scenario.
Candidates study only the Enterprise matrix and assume the other platforms are trimmed versions, when Mobile and ICS are separate matrices with their own tactic sets, technique IDs, and platform-specific content (for example Mobile's device access and network-based effects, and ICS's focus on process control and safety).
What to do instead
Learn the three matrices as distinct: Enterprise, Mobile, and ICS, each with its own tactics and techniques. Note where tactic names differ or are unique, and revise the platform-specific technique families (for example ICS techniques around manipulation of control, and Mobile techniques around abuse of device permissions and enterprise mobility management). When a scenario mentions HMIs, PLCs, or safety instrumented systems, switch to the ICS matrix; when it mentions Android or iOS, switch to Mobile.
Treating the ATT&CK Navigator as a scoring or detection-coverage tool, or expecting it to query a live ATT&CK server, rather than as a visualisation and annotation layer over a static matrix layer file.
Navigator's interface resembles a heatmap dashboard, and candidates assume the colours represent measured coverage or risk when they are user-supplied scores and comments stored in a layer file.
What to do instead
Remember that Navigator renders a matrix layer (JSON) and lets you annotate techniques with scores, colours, comments, and metadata such as a description and links; it does not collect data or compute coverage. Learn the workflow: choose the ATT&CK version and domain, apply or create a layer, export the layer JSON for sharing, and use it to compare coverage across teams or time. Distinguish Navigator from ATT&CK's STIX data and from TAXII servers, which are where machine-readable data is exchanged.
Confusing STIX and TAXII roles, or answering data model questions with the wrong STIX object type, for example calling a technique an 'attack-pattern' only when prompted, or assuming ATT&CK data is downloaded from TAXII rather than published as STIX.
The two acronyms appear together in every ATT&CK data discussion, and candidates memorise them as a single 'data format' without separating STIX (the structured language and object model) from TAXII (the transport protocol for exchanging STIX).
What to do instead
Fix the split: STIX defines the objects and relationships (attack-pattern for techniques, intrusion-set for groups, malware and tool for software, campaign, course-of-action for mitigations, x-mitre-data-source and x-mitre-data-component for data sources, with relationship objects and external references to other frameworks). TAXII is the API for sharing those objects. Learn the ATT&CK-specific extensions and that ATT&CK is distributed as STIX JSON, with the Enterprise, Mobile, and ICS domains available as separate collections.
Mapping threat intelligence to ATT&CK at the wrong granularity: mapping an entire report to a handful of tactics, mapping a tool name directly to a technique without the observed behaviour, or claiming coverage because a technique appears somewhere in a matrix.
Candidates treat mapping as keyword tagging and skip the step of extracting specific adversary behaviours and the context in which they occurred, which is the core discipline of threat-informed defence.
What to do instead
Practise the mapping workflow: extract concrete behaviours from the report, identify the goal (tactic), then the specific method (technique or sub-technique), and record the evidence and confidence. Distinguish what was observed from what was inferred. For coverage questions, require evidence that a detection or control addresses the specific technique and its variants, not merely that the technique is listed in a matrix or that a tool is deployed.