TH0.1 The Detection Coverage Illusion

The number nobody calculates

Ask your SOC lead how many analytics rules are deployed. You will get a number. Maybe 120 Sentinel rules, plus whatever Defender XDR generates natively, plus a handful of custom detection rules in Advanced Hunting. The number sounds like coverage.

It is not coverage. It is rule count. They are different things.

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. When organizations actually calculate this — and almost none do — the result is typically between 20% and 40% in mature programs. Below 20% in programs that rely primarily on out-of-the-box detections. That means 60–80% of the techniques attackers use against M365 environments produce no alert, no incident, no notification of any kind.

This is not because the detection engineering team is failing. It is because detection engineering faces a structural constraint that no amount of rule-writing resolves.

The math does not work

A reliable detection rule takes real effort. You need to understand the technique, identify which telemetry records it, write the KQL, test it against historical data, tune out the false positives that would drown the SOC, deploy it, and then tune it again when production data reveals edge cases you did not anticipate. Depending on the technique complexity and the noise in the environment, that is four hours to two full working days per rule.

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 busy for years.

And the attackers are not waiting.

Midnight Blizzard (APT29) shifted from email-based consent phishing to Teams-based delivery in 2023. Storm-1567 started using Cloudflare Workers with Turnstile CAPTCHAs to host AiTM proxy pages that bypass URL scanning. BEC operators moved from classic credential phishing to AiTM session hijacking specifically because organizations deployed MFA. Every defensive improvement generates an offensive adaptation. The detection rules you shipped last quarter may already be partially evaded by this quarter’s technique variants.

The Defender XDR misconception

Defender XDR has a substantial built-in detection engine. It catches credential attacks, BEC, malware delivery, and ransomware behavior without a single custom rule. This is genuinely good. The machine learning models behind it draw on telemetry from hundreds of millions of users — a dataset no single organization can replicate.

The problem is the operating point Microsoft chose. The built-in detections are tuned for high confidence and low false positive rates across millions of tenants. That is the right engineering choice for a product serving every organization from a 50-person company to a Fortune 10 enterprise. But it means Defender XDR deliberately does not alert on signals that might be malicious in your environment but look normal in most environments. It does not alert on behaviors too specific to your organizational context to model globally. It does not alert on novel technique variants until Microsoft’s own threat intelligence identifies them and pushes updated detection logic — which takes time.

The result: Defender XDR is excellent for the threats it covers and structurally silent on the threats it does not. Your Sentinel analytics rules are supposed to fill those gaps. Whether they actually do depends entirely on whether someone wrote a rule for each specific gap — and the math above tells you why the gaps outnumber the rules.

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

Measure it in your own environment

Stop estimating. Run the query.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

// 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
// RuleCount = how many distinct rules cover each technique
// AlertCount = how often those rules fire
// Techniques missing from this result = your blind spots
| sort by RuleCount desc

The techniques that appear in the results are covered. The ones that do not appear are your detection gap — the techniques an attacker can use in your environment without generating any alert from your custom analytics layer.

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// 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 == "[]"
// These rules may detect real threats but their coverage
// contribution is unmeasured — map them to ATT&CK
| 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 do not 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 predictable places — the ATT&CK tactics where the attacker’s 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. This is where organizations invest first, and it shows.

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

// 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 Discovery, Lateral Movement, Collection, or Exfiltration
// return zero rules — the attacker operates undetected through
// the entire middle of the kill chain
// Your rules see the beginning. Your rules see the end.
// Everything in between is invisible.

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. Defender XDR may flag some of this activity through its built-in detections, but the techniques it misses pass through completely. That is the gap hunting fills.

What lives in the gap — specific M365 examples

These are not theoretical attack categories. They are techniques that security practitioners encounter in real M365 investigations that had no detection rule covering them at the time of compromise.

OAuth application abuse (T1098.003). The attacker consents to a malicious application with Mail.ReadWrite and Files.ReadWrite.All permissions. The consent uses the standard Entra ID consent flow. The application then reads every email in the mailbox and downloads files from OneDrive — 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 legitimate productivity app and a user tricked into consenting to a data theft app is the application’s intent — which is not visible in the consent event alone. You need to examine what the application does after consent (data access volume, access patterns, permission scope relative to stated purpose). That examination is a hunt, not a detection rule.

Inbox rule manipulation via Graph API (T1564.008). BEC operators create inbox rules that redirect emails containing financial keywords to hidden folders. The rule hides password reset notifications, security alerts, and emails from the finance team asking “did you really authorize that wire transfer?” Most detection rules for inbox rule creation monitor for rules created through Outlook or OWA. Rules created via the Microsoft Graph API — the method of choice for automated post-compromise toolkits — use a different telemetry path in CloudAppEvents. If your rule only watches Exchange admin audit logs, the Graph API creation path is invisible.

Service principal credential rotation (T1098.001). The attacker adds a new credential (client secret or certificate) to an existing service principal. The service principal already has high-privilege permissions — maybe it was created by IT for a legitimate automation workflow. Now the attacker has a credential for that service principal and can authenticate as it, with all its permissions, without any association to a user account. Service principal authentication appears in AADServicePrincipalSignInLogs — a table many organizations do not ingest into Sentinel at all, let alone write detection rules against.

Conditional access policy modification (T1562.001). The attacker — now with Global Admin or Conditional Access Administrator — adds an IP exclusion to a conditional access policy, exempting their infrastructure from MFA requirements. Or they create a new policy that grants broader access from a specific location. The modification is recorded in AuditLogs but buried among hundreds of daily directory change events. Without a specific detection rule for conditional access policy changes (and most organizations do not have one), the attacker has weakened the identity security perimeter without generating any alert.

Each of these techniques has three things in common: the attacker uses a legitimate M365 operation, the operation is recorded in available telemetry, and almost no organization has a detection rule covering it. The data exists. The rule does not. That is the definition of the hunting surface — 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, the attackers adapt. The AiTM toolkits that worked in 2023 have been modified specifically to evade the detection signatures Microsoft described in their blog posts. 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. Organizations accumulate rules the way they accumulate technical debt — silently, until something breaks.

The practical implication: your coverage ratio is not a number you calculate once. It changes as your environment changes, as attackers adapt, and as rules age without maintenance. Hunting is one of the mechanisms that reveals whether your detections are still working — 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.

References Used in This Subsection

• MITRE Corporation. “MITRE ATT&CK — Enterprise Matrix.” https://attack.mitre.org
• MITRE Corporation. “ATT&CK Navigator.” https://mitre-attack.github.io/attack-navigator/
• Microsoft. “Microsoft Sentinel — Analytics Rules.” Microsoft Learn. https://learn.microsoft.com/en-us/azure/sentinel/detect-threats-built-in
• Microsoft. “Microsoft Defender XDR — Built-in Detection Capabilities.” Microsoft Learn. https://learn.microsoft.com/en-us/defender-xdr/automatic-attack-disruption
• Microsoft Threat Intelligence. “Midnight Blizzard conducts targeted social engineering over Microsoft Teams.” Microsoft Security Blog, August 2023. — verify URL
• MITRE ATT&CK Techniques referenced: T1566 (Phishing), T1078 (Valid Accounts), T1098 (Account Manipulation), T1550 (Use Alternate Authentication Material), T1199 (Trusted Relationship), T1537 (Transfer Data to Cloud Account)