What Microsoft Defender Actually Catches (and Where It Goes Dark)

Microsoft markets Defender XDR as comprehensive, unified threat detection. That framing works for a sales call. For a practitioner trying to figure out whether their high-value assets are actually protected, it answers the wrong question. The right question is: which specific attack techniques does Defender detect, under what deployment conditions, and where does coverage thin out or disappear? Microsoft's own documentation answers that, if you read it the way they didn't intend.

The identity layer is the strongest part of the story

Microsoft Defender for Identity (MDI) is the most coverage-dense piece of the stack when measured against real adversary behavior targeting on-premises Active Directory and hybrid identity environments.

The credential access alert catalog, confirmed as of March 2026, includes more than 30 alerts covering every major Kerberos abuse technique: AS-REP Roasting, Kerberoasting, Golden Ticket, Pass-the-Hash, DCSync, and Golden SAML. Modern hybrid vectors, including AiTM relay and shadow credentials targeting managed service accounts, are covered too. Discovery-phase coverage catches the LDAP and SAMR-based reconnaissance that typically precedes credential theft. Lateral movement detection covers the identity-based traversal paths attackers use to reach domain controllers and other high-value targets.

MDI also maps out how an attacker could traverse from any compromised lower-privilege account to your Sensitive-tagged entities. The graph exists before an incident, not because of one.

Microsoft published a tested attack scenario showing the cross-product model working. A fileless PowerShell script injected shellcode into notepad.exe, contacted a simulated command-and-control server, and ran SMB session enumeration against a domain controller. MDE detected the process injection. MDI detected the DC reconnaissance. Both alerts auto-correlated into a single incident. Automated investigation stopped the process. On paper, the system did exactly what it is supposed to do.

Execution and C2 are nearly empty in the identity layer

MDI has one execution-phase alert (suspicious remote service installation) and two C2-phase alerts, one for DNS queries and one for Graph API queries. That is not a product defect. MDI is an identity infrastructure monitoring tool. Endpoint execution and network C2 is MDE's job.

The problem is the gap this creates when MDE is not fully deployed.

The tools that show up in post-exploitation are Mimikatz, Cobalt Strike, PsExec, and WMI. These operate primarily in the execution and C2 phases. MDI sees almost nothing during these phases. In Microsoft's own attack simulation, the process injection detection came from MDE. Remove MDE from that scenario, and the fileless injection component goes completely undetected. MDI saw the DC reconnaissance afterward. It saw nothing before it.

This matters operationally. An organization that licensed MDI, deployed sensors on their domain controllers, and considers this "Defender XDR" is missing detections for most of what runs after initial access. The alert catalog looks complete until you trace which product covers which phase. Then the picture changes.

The configuration assumptions nobody audits

Strong coverage in the alert catalog does not mean strong coverage in production. A set of configuration requirements sits between the two that is easy to miss and rarely revisited after initial deployment.

Windows Event Auditing is not on by default. MDI detections depend on specific Windows Event Log entries. If auditing was not explicitly configured per MDI's guidance, detections that depend on those events fail silently. Nobody tells you.

MDI sensors are required on domain controllers, AD FS servers, AD CS servers, and Entra Connect servers. DC sensor deployment is usually complete. The federation and certificate services sensors are often missed. Each requires separate installation, a directory service account with specific permissions, and per-server auditing configuration. If your team deployed MDI last year and moved on, I'd check this before assuming AD FS and AD CS vectors are covered.

Sensitive entity tags gate entire detection categories. Certain lateral movement and persistence alerts only fire when the relevant group or account carries a Sensitive tag. Those tags are assigned automatically for well-known privileged groups, but the assignment should be verified, not assumed, especially in environments with custom delegation structures or non-standard group nesting.

Honeytoken accounts require manual placement. They provide operational validation and surface activity that bypasses signature-based detection, but only if someone built them into the deployment. They are not created automatically.

Microsoft's own security research points out that most identity attacks exploit common Active Directory misconfigurations and legacy components, like NTLMv1, rather than novel techniques. The configuration gaps above are what give those techniques room to operate.

Two things you can validate right now

Make sure MDI sensors exist on every identity infrastructure component in your environment, not just domain controllers. Run the sensor health check in the Defender portal and compare the result against your AD FS, AD CS, and Entra Connect servers. A missing sensor is a missing detection, and it will not show up as an alert.

Then review Sensitive entity tag assignments for your actual privileged groups. If a critical group is untagged, a category of lateral movement and persistence alerts is dormant. Tag gaps are easy to find and faster to fix than most of the other items on this list.

One caveat worth naming: everything here is drawn from Microsoft's own documentation. I didn't find independent red team validation of these detection claims. MITRE ATT&CK evaluation data for Defender XDR returned 404 errors during research. Treat Microsoft's coverage statements as claimed, not confirmed, and use honeytoken placement and the built-in hunting queries as ground-truth validation in your own environment. That's a step you have to take yourself.

Revision History

2026-04-15 — published

Initial Publish