MITRE ATT&CK® is everywhere in detection engineering. Vendor products label alerts with ATT&CK techniques, EDRs claim 100% mitigation in evaluation scenarios, and detection engineering consultants recommend building “ATT&CK heatmaps” as the best practice for understanding “detection coverage”1. But have you ever stopped to wonder how ATT&CK was made, and whether it’s suited to detection?
While discussing how attackers abuse legitimate capabilities with my friend Michael, we were asking the same question. How is it possible that so many techniques in ATT&CK are so difficult to detect comprehensively and with low false positive rates? Elsewhere, I’ve mentioned some of these, and more come easily to mind: PowerShell, Scheduled Tasks, Valid Accounts, Kerberoasting, or System Shutdown.
The ATT&CK FAQ page includes this fascinating tidbit about the origin of ATT&CK:
ATT&CK … was created out of a need to document adversary behaviors … to investigate use of endpoint telemetry data and analytics to improve post-compromise detection of adversaries operating within enterprise networks.
Together, we realized that the purpose of the project was to document attacker behaviors with the goal of improving post-compromise detection, but from a very different starting point than an analyst triaging an alert. The ATT&CK researchers already knew that a technique was malicious because they could link it to a known intrusion. However, an analyst reviewing an alert does not know the disposition of the activity — in fact, this is the primary task of the analyst! They must infer user intent from context, compare activity to known user or group baselines, or even ask users directly if they were responsible. This context is often expensive in terms of collection or analysis time, and organizations must naturally choose which leads to prioritize (à la the Funnel of Fidelity).
Key principle: Attacker behavior can be labeled after an incident without those labels corresponding to usable detections
The high costs to collect context for some ATT&CK techniques disqualify them from effective security monitoring. This is not a flaw in ATT&CK, but in how detection engineering applies it. It’s one reason why some techniques should only be detected opportunistically, and shows us one of the criteria for yielding — only detect techniques where intent can be identified.