← All posts

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.