TH0.1 The Detection Coverage Illusion

Rule count versus coverage ratio

Ask your SOC lead how many analytics rules are deployed. You will get a number — 80, 120, 200. The number sounds like coverage. It is not coverage. It is rule count.

Coverage is a ratio: the number of ATT&CK techniques your rules detect, divided by the number of ATT&CK techniques relevant to your environment. A 2025 industry analysis of enterprise SIEMs found average detection coverage at 21% of ATT&CK techniques — meaning 79% of adversary techniques defined in the framework produced no alert, no incident, no notification of any kind. When narrowed to the ten most frequently used techniques in observed attacks, organizations covered only four.

Twenty rules that all detect variants of email phishing give you deep coverage of one technique and zero coverage of everything else. A SOC with 50 rules distributed across 40 distinct ATT&CK techniques has a stronger detection posture than a SOC with 200 rules clustered on 15 techniques. The metric that matters is not how many rules you have. It is how many distinct techniques those rules cover, measured against the techniques attackers actually use in your threat landscape.

Figure TH0.1 — Detection coverage gap. Rules cover the techniques the detection engineering team has written queries for. Everything else is the hunting surface.

The math behind the gap

A reliable detection rule takes real effort. You identify the technique, determine which telemetry records it, write the KQL, test against historical data, tune false positives, deploy, and tune again when production reveals edge cases. Four hours to two full working days per rule, depending on technique complexity and environmental noise.

A detection engineering team shipping two to four new rules per sprint — a good pace — covers 50 to 100 new technique variants per year. The ATT&CK cloud matrix alone, before you add the endpoint and identity techniques relevant to a hybrid M365 environment, contains enough techniques to keep that team occupied for years. The backlog grows faster than the team can clear it. This is not a staffing problem you can solve by hiring. It is a structural constraint of rule-based detection.

Defender XDR's built-in detection engine helps. Its machine learning models draw on telemetry from hundreds of millions of users — a dataset no single organization can replicate. But Microsoft chose a deliberate operating point: high confidence, low false positive rates across millions of tenants. That means Defender XDR does not alert on signals that might be malicious in your specific environment but appear normal across the broader population. Behaviors too context-dependent to model globally pass through silently. Novel technique variants take time to appear in updated detection logic. Defender XDR is excellent for what it covers and structurally silent on what it does not.

Your Sentinel analytics rules fill the gaps Defender XDR leaves. Whether they actually fill them depends on whether someone wrote a rule for each specific gap. The coverage ratio tells you where you stand.

Measuring coverage in your own environment

Stop estimating. Run the query.

// What ATT&CK techniques do your Sentinel analytics rules actually cover?
// Run this in your Sentinel workspace — the results are your coverage map
SecurityAlert
| where TimeGenerated > ago(90d)
| where ProviderName == "ASI Scheduled Alerts"
| extend Techniques = tostring(
    parse_json(ExtendedProperties).["Techniques"])
| where isnotempty(Techniques) and Techniques != "[]"
| summarize
    RuleCount = dcount(AlertName),
    Rules = make_set(AlertName, 10),
    AlertCount = count()
    by Techniques
| sort by RuleCount desc

The techniques that appear in the results are covered. Every ATT&CK technique absent from the results is a technique an attacker can use in your environment without generating any alert from your custom analytics layer.

Now check the other dimension — rules that fire but have no ATT&CK mapping:

// Rules with no ATT&CK mapping — coverage contribution unknown
SecurityAlert
| where TimeGenerated > ago(90d)
| where ProviderName == "ASI Scheduled Alerts"
| extend Techniques = tostring(
    parse_json(ExtendedProperties).["Techniques"])
| where isempty(Techniques) or Techniques == "[]"
| summarize AlertCount = count() by AlertName
| sort by AlertCount desc

If a significant proportion of your rules have no ATT&CK mapping, your coverage ratio is understated — but you don't know by how much until you map them. That mapping is a quick detection engineering task and a prerequisite for any honest coverage assessment.

Where the gaps cluster

The detection gap is not evenly distributed. It clusters in the ATT&CK tactics where attacker activity looks indistinguishable from legitimate business operations.

Initial Access typically has the densest coverage. Email security generates the most alerts. Phishing rules fire. Malware delivery rules fire. Organizations invest here first, and the coverage shows.

Coverage collapses in the middle of the kill chain. Credential Access — how the attacker obtains additional credentials after initial compromise. Lateral Movement — how they reach new systems. Collection — how they identify and gather target data. Exfiltration — how they move it out. These tactics involve legitimate operations (reading email, downloading SharePoint files, connecting to servers) performed by illegitimate actors. The distinction between an attacker downloading 500 files from SharePoint and a legitimate user doing the same before a business trip is context, not a signature. Static rules cannot encode that context. Hunting can.

// Where are your rules concentrated? Which kill chain stages are blind?
SecurityAlert
| where TimeGenerated > ago(90d)
| where ProviderName == "ASI Scheduled Alerts"
| extend Tactics = parse_json(tostring(
    parse_json(ExtendedProperties).["Tactics"]))
| mv-expand Tactic = Tactics
| summarize
    RuleCount = dcount(AlertName),
    AlertVolume = count()
    by tostring(Tactic)
| sort by RuleCount desc

If Lateral Movement returns zero rules — and in many M365 environments it does — an attacker who compromises one account can move to every system that account can access without generating a single alert from your analytics layer. The attacker's entire middle-of-kill-chain activity is invisible to your SIEM.

When Tom runs this query at Northgate Engineering, the output tells a story. Initial Access and Execution return the bulk of his rules — phishing detection, malware submission, suspicious email. Persistence returns three rules, all focused on mailbox rules. Credential Access, Lateral Movement, Collection, and Exfiltration return zero custom rules each. That means an attacker who gets past the front door operates freely through four stages of the kill chain.

The analyst decision above is not a theoretical exercise. It is the artifact you produce when you run the coverage queries against your own environment, and the artifact Rachel Okafor reads to understand where Northgate's detection posture has structural blind spots. The coverage ratio is the starting point. The tactic distribution reveals where those blind spots concentrate. Together, they define the hunting surface — the specific areas where proactive investigation is the only mechanism that detects compromise.

Calculating your denominator

The numerator — distinct techniques your rules cover — comes directly from the KQL output. The denominator requires judgment. The full ATT&CK Enterprise matrix contains over 200 techniques and 400 sub-techniques. Not all of them are relevant to your environment. An organization running exclusively in the cloud with no on-premises infrastructure can exclude techniques that require physical access or on-premises server exploitation.

Open the ATT&CK Navigator and select the techniques relevant to your M365 environment: cloud identity, SaaS, email, endpoint (if Defender for Endpoint is deployed), and hybrid identity (if Azure AD Connect or cloud sync is in use). Count the techniques. That is your denominator. A typical M365 E5 environment with endpoint protection produces a denominator between 70 and 100 techniques, depending on how aggressively you scope.

If your ratio is below 25%, you're in the majority. Between 25% and 40% indicates a mature detection engineering program. Above 40% is advanced. Regardless of where you land, the remaining gap is the hunting surface — the space where only proactive investigation finds compromise.

What lives in the gap — real M365 examples

These are not theoretical categories. They are techniques that appear in production M365 compromise investigations where no detection rule existed at the time of discovery.

OAuth application abuse (T1098.003). The attacker consents to a malicious application with Mail.ReadWrite and Files.ReadWrite.All permissions using the standard Entra ID consent flow. The application reads every email in the mailbox and downloads OneDrive files indefinitely — without re-authenticating, surviving password resets. Most organizations have no analytics rule monitoring application consent events. The consent itself is a legitimate Entra ID operation. The distinction between a user consenting to a productivity tool and a user tricked into consenting to a data theft application is what the application does after consent: data access volume, access patterns, permission scope relative to stated purpose. That analysis is a hunt, not a rule.

Inbox rule manipulation via Graph API (T1564.008). BEC operators create inbox rules that redirect emails containing financial keywords to hidden folders. The rules suppress password reset notifications, security alerts, and inquiries from finance about suspicious transfers. Most detection rules for inbox rule creation monitor Outlook or OWA activity. Rules created via the Microsoft Graph API — the preferred method for automated post-compromise toolkits — produce telemetry in CloudAppEvents, not Exchange admin audit logs. If your detection only watches the admin audit path, Graph API rule creation is invisible.

Service principal credential rotation (T1098.001). The attacker adds a new credential to an existing service principal that already has high-privilege permissions — perhaps created by IT for a legitimate automation workflow. The attacker now authenticates as that service principal, with all its permissions, with no association to a user account. Service principal authentication appears in AADServicePrincipalSignInLogs, a table many organizations do not ingest into Sentinel at all.

Conditional Access policy modification (T1562.001). The attacker with Global Admin or Conditional Access Administrator adds an IP exclusion to a CA policy, exempting their infrastructure from MFA requirements. The modification is recorded in AuditLogs but buried among hundreds of daily directory change events. Without a specific detection rule for CA policy changes — and most organizations lack one — the attacker weakens the identity security perimeter without generating any alert.

Each of these techniques shares three characteristics: the attacker uses a legitimate M365 operation, the operation is recorded in available telemetry, and no detection rule covers it. The data exists. The rule does not. That is the detection gap — evidence of compromise sitting in your logs, waiting for someone to look.

Coverage decays

Even strong coverage degrades. Three forces work against you continuously.

Technique evolution. When Microsoft publishes detection guidance for a technique, attackers adapt. The AiTM toolkits that worked in 2023 have been modified to evade the specific detection signatures Microsoft described. M-Trends 2026 found that the mean time from vulnerability disclosure to exploitation has dropped to negative seven days — attackers are routinely exploiting before patches exist. Your rule that worked six months ago may catch 80% of current variants instead of 95%. Nobody notices unless someone tests through purple team exercises or through hunting.

Environmental drift. Your M365 environment is not the same environment your detection rules were written for. New applications deployed, new conditional access policies, new user populations onboarded, new integrations connected. Each change introduces attack surface your existing rules were not designed to cover. A rule written before you adopted Defender for Cloud Apps does not examine OAuth consent phishing through that workload.

Rule atrophy. A rule that has not fired in 12 months is either a well-targeted detection for a rare event or a broken rule that would not fire even if the attack occurred. Without validation, there is no way to tell the difference. A 2025 analysis found 13% of SIEM detection rules are non-functional due to misconfigured data sources and missing log fields. Organizations accumulate silent failures the way they accumulate technical debt.

The coverage ratio is not a number you calculate once. It changes as your environment changes, attackers adapt, and rules age without maintenance. Hunting reveals whether your detections still work. When a hunt finds evidence of a technique that should have triggered an existing rule, it surfaces both a potential compromise and a detection failure simultaneously.