MITRE ATT&CK for defenders: which techniques matter most
MITRE ATT&CK catalogues over 400 techniques. Here's how defenders should prioritise coverage - with real detection logic for the techniques that appear most in incident reports.
The MITRE ATT&CK framework catalogues over 400 attack techniques across 14 tactics. For a SOC team trying to build detection coverage, that number is less useful than it sounds. You can’t write quality detections for 400 things. You have to prioritise.
This post walks through how to think about technique prioritisation and which ATT&CK sub-techniques are worth building detections for first.
Why prioritisation matters
Every detection rule you write has an operational cost. It needs to be tested, tuned, and maintained as the environment changes. A rule that fires on legitimate admin activity and floods analysts with false positives is worse than no rule at all - it trains your team to ignore alerts.
The ATT&CK matrix is a reference, not a checklist. The useful question isn’t “do we cover T1234?” - it’s “which techniques are threat actors actually using against environments like ours, and how good is our signal on each one?”
Prioritisation frameworks exist to answer this. Red Canary’s annual Threat Detection Report publishes the top techniques observed across their customer base each year. CISA advisories map specific threat groups to specific sub-techniques. Both are worth bookmarking and revisiting each quarter.
The techniques that appear most often
Without naming specific CVEs or attribution that dates quickly, there is a cluster of ATT&CK sub-techniques that appear in incident post-mortems year after year:
| Tactic | Sub-technique | Why it’s common |
|---|---|---|
| Execution | T1059.001 - PowerShell | Ubiquitous on Windows; hard to block outright |
| Execution | T1059.003 - Windows Command Shell | Appears in nearly every Windows intrusion |
| Persistence | T1543.003 - Windows Service | Reliable persistence that survives reboots |
| Privilege Escalation | T1055 - Process Injection | Used by most commodity malware for AV evasion |
| Credential Access | T1003.001 - LSASS Memory | Credential dumping; often follows initial access |
| Defence Evasion | T1070.001 - Clear Windows Event Logs | Adversaries clean up before moving laterally |
| Discovery | T1082 - System Information Discovery | Near-universal; attackers enumerate before acting |
| Lateral Movement | T1021.001 - Remote Desktop Protocol | Legitimate but heavily abused |
| Command and Control | T1071.001 - Web Protocols | Blends into normal traffic; harder to detect |
These aren’t the only techniques worth covering - but if you can’t detect most of them with high confidence, fix that before adding exotic coverage.
How to build a detection for a specific sub-technique
Take T1003.001 (LSASS Memory access) as an example. The canonical behaviour is a process opening a handle to lsass.exe with PROCESS_VM_READ access rights. On Windows, that generates a 4656 (Handle Requested) or 4663 (Handle Used) audit event.
A Sigma rule for this looks like:
title: LSASS memory access via handle request
status: test
logsource:
product: windows
service: security
detection:
selection:
EventID: 4656
ObjectName|endswith: '\lsass.exe'
AccessMask|contains:
- '0x10' # PROCESS_VM_READ
- '0x40' # PROCESS_DUP_HANDLE
filter:
ProcessName|endswith:
- '\MsMpEng.exe' # Windows Defender
- '\svchost.exe'
condition: selection and not filter
falsepositives:
- Legitimate security products; tune by process name
level: high
tags:
- attack.credential_access
- attack.t1003.001
This rule won’t be perfect on day one - svchost.exe may still need sub-process filtering, and your AV vendor’s process name needs adding to the filter list. That tuning work is the real job. But you get there faster starting from a known-good structure than from a blank page.
Coverage is not binary
A common mistake is treating ATT&CK coverage as a heatmap you fill in. In practice, detection quality sits on a spectrum:
- No detection - you have no visibility into this technique at all
- Logging only - the relevant event is captured but no alert fires
- Low-confidence alert - fires but produces too many false positives to act on
- High-confidence alert - fires reliably on true positives, rare false positives
- Validated and tuned - tested against known-good data, reviewed in the last 90 days
Most mature SOC teams have the first three for much of the ATT&CK matrix and the last two for a subset that matters to them. Being honest about where you sit is more useful than a green heatmap built on untested rules.
LightEDR maps every behavioural alert to the corresponding ATT&CK sub-technique and surfaces your coverage in the dashboard, so you can see gaps against real telemetry rather than guessing. If you want to see what out-of-the-box coverage looks like for your environment, get in touch.