The 20 detections worth building before anything else

The 20 detections worth building before anything else

I sat in a coverage review where the VP of Security pulled up the MITRE ATT&CK Navigator heatmap. Green everywhere: tactics covered, sub-techniques covered, a respectable percentage in the corner of the slide. Then I asked how many of those rules fired with a confirmed true positive in the last 30 days.

The room went quiet. Nobody knew, because nobody tracked it. The heatmap measured rule inventory and said nothing about whether the detections worked. Most coverage reports dress a rule-count metric up as a capability metric.

A rule mapped to a technique tells you a detection engineer wrote something once. It says nothing about whether the telemetry feeds it, whether the fields parse, or whether it has ever caught anything. Credible baseline coverage starts with 20 detections that show up repeatedly in real breach chains.

In Brief:

• Detection coverage as commonly measured counts rules mapped to techniques and leaves out whether those rules work, which is why a green heatmap can sit on top of a security operations center (SOC) that misses the boring breach.
• Select baseline coverage by frequency in real breach chains before expanding by ATT&CK technique count or theoretical severity.
• A handful of sub-techniques dominate real intrusions year after year. Any real baseline covers PowerShell, Server Message Block (SMB) admin shares, Remote Desktop Protocol (RDP), service execution, and file deletion with validated detections.
• A rule in the security information and event management (SIEM) tool becomes built only after it has been tested, tuned, reviewed, documented, and true-positive validated.

Coverage percentage counts rules and misses capability

The textbook definition of detection coverage is the percentage of MITRE ATT&CK techniques for which your program has active detection rules. That's true and useless: it conflates two things mature teams keep separate, technique coverage and detection health.

Traditional coverage metrics can count detections aligned to techniques while required log sources stay uningested, required fields stay absent, or those fields fail to parse correctly.

Tactic-level coverage overstates real capability worse than anything. Tactic-level mapping should be a fallback for when the available detail lacks enough specificity to identify a technique or sub-technique.

Credible baseline coverage is a small set of detections that fire on behaviors attackers actually use, tested against real telemetry and validated before it ships.

Frequency in real breach chains is the only filter that matters

I've watched teams chase 100% technique coverage and end up with 400 rules, half of which have never fired. The selection criterion is prevalence in confirmed breach chains, the same logic behind a small set of techniques driving most detections.

The top sub-techniques Mandiant tracks stay remarkably stable: PowerShell, SMB and Windows admin shares, RDP, file deletion, and service execution.

The 20 break into five domains: identity and authentication (5), endpoint execution and persistence (8), defense evasion (3), lateral movement and privilege escalation (2), and cloud and software-as-a-service (SaaS) (2). Identity gets five slots because adversaries are logging in with valid identities rather than breaking in.

Endpoint gets eight because malware-free intrusions reached 82% of CrowdStrike detections, which means the living-off-the-land problem is the endpoint problem now.

The 20 detections, grouped by attack surface

Each detection earns its slot on frequency. The point is to cover behaviors that keep showing up in real incidents, not to fill a matrix.

Identity and authentication

Modern breaches often start with identity attacks, and more than 97% of those attacks are password spray or brute force. The rarer techniques carry disproportionate impact, so these five cover the spread.

1. Password spray and brute force lead by volume. Entra ID Protection's PasswordSpray detection fires only on successful password validation, so build a custom rule against SigninLogs that pivots on IPAddress across users, with separate thresholds for low-and-slow sprays and single-day replay.
2. Token theft by malware is the largest category in the non-spray bucket. Anomalous token detections don't always have a corresponding SigninLogs entry, so you also need OfficeActivity and AuditLogs. Infostealer tokens may be replayed days or weeks after theft, so your correlation window has to be long.
3. Adversary-in-the-middle (AiTM) and device code phishing deserve explicit coverage because these attacks bypass multifactor authentication (MFA) entirely. Any rule keyed on MFA failure events will never fire. Detect successful Auth Broker sign-ins through device-code-flow patterns where the target resource sits outside your commonly observed first-party set.
4. MFA fatigue and push bombing is rarer by volume but rising fast. A workable Okta rule fires on two denied pushes followed by a successful auth within a 10-minute window. Correlate to the successful login or you'll drown in noise.
5. OAuth and consent abuse is tiny by volume and brutal in impact. When a user grants consent, the app's access survives password resets and MFA changes, and standard sign-in detections never fire because the attacker never signs in as the user. Monitor AuditLogs for new service principal creation and consent grants to externally registered apps.

Endpoint execution and persistence

Malware-free intrusions now dominate, so endpoint coverage depends on process telemetry depth. These eight cover the execution and persistence behaviors that recur.

1. PowerShell was the most common sub-technique Mandiant tracked, at 26.2% as T1059.001. Capture script block logging (Event ID 4104) and parse decoded base64, because attackers chain -w hidden -nop -noni -enc to beat string matches. Monitor for Antimalware Scan Interface (AMSI) patch attempts separately, or in-memory bypasses will blind your script block logging.
2. Windows command shell is everywhere, so focus detection on anomalous parent-child chains, like winword.exe → cmd.exe, enriched with command-line content inspection. Without that content inspection, living-off-the-land binary (LOLBin) chaining through cmd is invisible.
3. Service creation and execution as T1569.002 showed up in 19% of Mandiant investigations. Legitimate installers create services constantly, so tune on binary path location and signing status. PsExec leaves PSEXESVC artifacts, but custom service names walk past name-based rules.
4. Scheduled tasks require more than watching schtasks.exe. Tasks created via the COM ITaskService API leave no schtasks.exe process-creation event, so monitor task XML writes to C:\Windows\System32\Tasks\ and the TaskCache registry keys directly. Attackers hide tasks in \Microsoft\Windows\ subdirectories to blend with operating system tasks.
5. Windows Management Instrumentation (WMI) execution and persistence requires watching WmiPrvSE.exe spawning child processes and the event subscription classes (__EventFilter, __EventConsumer, __FilterToConsumerBinding). Remote WMI execution creates its distinctive signal on the target host, so target-side telemetry matters.
6. ClickFix clipboard execution matters because it became the top initial-access technique in Microsoft's Defender Experts notifications, at 47% of cases. Standard process-creation rules miss the clipboard paste step because execution looks user-initiated. RunMRU registry writes feed explorer.exe → cmd.exe / powershell.exe / mshta.exe / wscript.exe via the Run dialog.
7. Remote monitoring and management (RMM) tool abuse is common, recurring across a large share of ransomware intrusions. Most orgs run RMM legitimately, so you need an approved-tool baseline and alerts on the unapproved install. Attackers use portable versions that leave no service or Add/Remove Programs entry, so hunt the process and network connection.
8. Suspicious parent-child process chains underpin the malware-free reality behind most of these intrusions. LOLBin detections without parent-process context produce massive false positives. With the fastest breakout time observed at 51 seconds, these chains need automated response before they sit in an alert queue.

Defense evasion

Attackers blind defenders in nearly every breach chain, so these three need baseline coverage.

1. Obfuscated and encoded payloads made T1027 the #2 technique at 37.3% of Mandiant investigations. Variations make the detection surface effectively unbounded; tools like DOSfuscation generate thousands of unique samples. Entropy thresholds catch a lot but false-positive on legitimate encoded content, so some variants belong in a hunting query, not an alert.
2. Antivirus (AV) and endpoint detection and response (EDR) tampering shows up across a large share of intrusions. Set-MpPreference is used legitimately all the time, so tune your rules to the base64 variants because the non-encoded forms raise too many false positives. The registry path is the highest-fidelity source, because no matter how an exclusion gets set, it lands in the registry. Build out-of-band telemetry for cases where the agent is killed.
3. Indicator removal through log clearing and file deletion maps to T1070 Indicator Removal, which showed up in 29.4% of investigations, with file deletion among the most common sub-techniques. Forward Event ID 1102 and Event ID 104 as log-clearing events to the SIEM in real time so they survive local clearing. For file deletion, Event IDs 4660 and 4663 require object-deletion auditing, and bulk clearing of multiple logs is a far stronger signal than a single clear.

Lateral movement and privilege escalation

Two detections cover the techniques present across every major ransomware family.

1. SMB admin shares and PsExec-style service execution cover a sub-technique where T1021.002 was the #2 sub-technique at 23.3%. Alert whenever .exe or .dll files are written to ADMIN$, IPC$, or C$, then correlate with service creation Event ID 7045 to catch the full chain. The most adversary-used tools are Impacket variants like smbexec.py and wmiexec.py, so account for the Python flavors.
2. Kerberoasting and credential dumping detection starts with the fact that credential stealers were 18% of tools in 2024 ransomware intrusions. For Kerberoasting, filter Event ID 4769 on RC4 encryption type 0x17, but volume thresholds fail against patient attackers requesting one ticket per hour, and RC4 flags get tuned out in environments with legacy systems. For LSASS dumping, Sysmon Event ID 10 with filtered GrantedAccess values catches the access, but aggressive filtering is mandatory.

Cloud and SaaS

Breach data is shifting fastest around cloud and SaaS sign-ins and OAuth grants. Two detections anchor the baseline.

1. Anomalous cloud sign-ins and valid account abuse matter because stolen credentials accounted for 35% of cloud intrusion initial vectors in Mandiant's M-Trends 2025, and cloud intrusions are climbing hard. SaaS breaches happen via compromised single sign-on (SSO) identities, so the sign-ins look legitimate. Export Entra ID sign-in and audit logs to your SIEM, and watch for the pivot from a compromised identity into Azure Run Command for remote code execution.
2. New OAuth app consent grants in the cloud tenant are the complement to the identity-layer OAuth detection. Search Purview Audit for Consent to application activities and watch for dormant apps that suddenly send mail or access files. Adversaries abuse legitimate first-party apps with localhost redirect URIs, so an app-legitimacy check alone is insufficient.

A detection is built only after validation

A SIEM rule becomes a built detection only after validation. I've inherited repos full of rules written once, copy-pasted from a blog, and left to rot: no tests, no context, no record of whether they ever caught anything. That is coverage debt showing up green on a heatmap.

Built means it cleared five gates, the sequence the detection development lifecycle lays out:

• Tested against real telemetry, both historically and in a live test queue.
• False positive rate documented against acceptance criteria agreed with the incident response (IR) team.
• Investigation context attached, so the analyst who catches it at 3 am knows what to do.
• Peer reviewed in version control.
• True-positive validated through adversary emulation before production.

A detection that hasn't fired on a confirmed true positive or a controlled emulation stays unverified.

Check the telemetry before the rule goes in the backlog

You can't detect what you can't see, and most detection problems are data problems. Many detection teams report inadequate data access, and cloud-native environments are repeatedly named the top coverage gap. Run a pre-flight by group before anything hits the detection backlog.

• For identity and authentication, ingest Entra ID SigninLogs, AuditLogs, OfficeActivity, and Okta System Log, and confirm the connector configuration is producing usable records.
• For endpoint execution and persistence, use EDR process telemetry with full command-line and parent-child relationships, Sysmon for endpoint telemetry, and Windows Event Forwarding for PowerShell script block logging and Windows service events.
• For defense evasion, forward log-clearing events in real time, monitor registry writes, and use Sysmon ImageLoad for bring your own vulnerable driver (BYOVD) detection.
• For cloud and SaaS, ingest cloud audit logs and verify the subscription tier. Mandiant has repeatedly seen investigations slowed by subscription-level logging gaps.

Missing telemetry makes the item a pre-backlog telemetry task until the behavior becomes observable. Writing a rule against a log source you don't ingest is how programs drift into false confidence and claim coverage for behaviors they can't see.

These 20 are the floor, not the ceiling

Treat these 20 as the program floor for detection engineering.

Once they're operational and validated, layer in the ATT&CK Cloud Matrix for deeper IaaS and SaaS coverage. Build out identity threat detection and response (ITDR) for identity behavioral detection.

Then stand up the feedback loop from your incident response plan that turns every confirmed incident into a new detection. That loop is usually the weakest program link, patched together or enforced tribally.

Use the ATT&CK Navigator for what it's good at: planning and trending coverage quarterly. Keep it away from the board-level coverage number.

The next time someone shows me a green heatmap, I'm asking the same question: how many of these fired with a confirmed true positive last month? A shrug means the green squares overstate coverage.

Frequently asked questions about detection coverage

How should a SecOps team measure detection coverage?

Detection coverage is the share of relevant attacker techniques for which you have active detections. The useful version separates technique coverage (a rule exists) from detection health (the rule works, fed by ingested telemetry with parsed fields and a validated true positive).

A green ATT&CK heatmap measures the first while leaving the second unanswered.

Do I need all 20 of these before adding anything else?

Yes, with one caveat. These 20 are selected by frequency in confirmed breach chains, so they're the behaviors you're most likely to face. Adding exotic detections on top of an incomplete baseline is how you end up with a high rule count and a SOC that still misses the boring credential-abuse breach.

What if I'm missing the telemetry for some of these?

Treat it as a pre-backlog item. Verify the log source is ingested and the required fields parse before you write the rule. Writing a detection against telemetry you don't collect produces false confidence, worse than a known gap because it hides on your coverage map as green.

How do I know when a detection is actually done?

It's done when it has cleared five gates: tested against real telemetry, false positive rate documented, investigation context attached, peer reviewed in version control, and validated on a confirmed true positive or adversary emulation.

A rule that has never fired on real or simulated attacker behavior stays unverified.

Does this apply to MDR customers or only in-house teams?

It applies to both, but the ownership boundary shifts. Managed detection and response (MDR) providers typically cover their predefined stack, and meaningful gaps remain in custom detections, identity, and cloud.

Use this list to audit your provider: ask which of these 20 they detect and whether the detection content is retained if you leave.