ATT&CK Framework Fundamentals and Data Model
What this domain tests
This domain tests whether you can read ATT&CK as a structured knowledge base, not a list of alert names. Expect questions on tactic versus technique, sub-technique versus procedure, matrix scope, identifiers, and STIX relationships.
Core rules
- A tactic is the adversary goal or why; a technique is how; a sub-technique is a narrower how; a procedure is a specific observed implementation.
- Enterprise, Mobile, and ICS are separate matrices. Do not assume an object from one matrix applies unchanged to another.
- Identifiers are stable handles: T#### for techniques, T####.### for sub-techniques, G#### for groups, S#### for software, C#### for campaigns, M#### for mitigations, and DS#### for data sources.
- Technique metadata includes platforms, required permissions, effective permissions, defenses bypassed, and data sources. These fields constrain whether a mapping is plausible.
- STIX represents objects and relationships such as uses, mitigates, attributed-to, and targets. Procedures are generally examples inside technique descriptions, not standalone catalogue objects.
Worked example
A hunt finds rundll32.exe loading a DLL from a user Downloads folder and making an outbound connection. The analyst maps T1218.011 Signed Binary Proxy Execution: Rundll32, not the parent T1218 and not the tactic Defense Evasion as the technique. Reasoning: the observable is a specific execution mechanism, so the sub-technique is the best fit. The tactic is recorded separately as the goal. The exact command line, parent process, and destination are procedure details saved in hunt notes.
Traps that cost marks
Mapping a tool name as a technique, choosing a parent technique when the sub-technique is explicit, treating a tactic as a detection, and ignoring platform or permission metadata. Another trap is assuming every ATT&CK object is a STIX object; procedures often are not.