# Microsoft Defender for Identity: The Defensive AD Stack That Sees What BloodHound Maps
> A field guide to Microsoft Defender for Identity, the on-DC sensor and cloud analytics engine descended from Aorato, that fires named alerts on almost every offensive AD primitive in the corpus -- and the five structural blind spots it cannot close.
*Published: 2026-05-27*
*Canonical: https://paragmali.com/blog/microsoft-defender-for-identity-the-defensive-ad-stack-that-*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
**Microsoft Defender for Identity (MDI) is the cloud-backed, on-DC defensive sensor that watches for almost every offensive Active Directory primitive in the SpecterOps / Mimikatz / Certipy corpus** -- DCSync, DCShadow, Golden / Silver / Diamond ticket forgery, Kerberoasting, AS-REP roasting, NTLM relay, and AD CS abuse -- by parsing Kerberos, NTLM, LDAP, and DRSUAPI on the wire and running per-principal behavioural baselines in a multi-tenant cloud backend. The product began as the Israeli startup Aorato (acquired by Microsoft in November 2014), shipped on-prem as Microsoft ATA in 2015, moved to the cloud as Azure ATP in 2018, was renamed to MDI in 2020, folded into Microsoft Defender XDR at Ignite 2023, and reached its current MDE-integrated v3.x sensor in October 2025. The alert catalogue maps cleanly onto MITRE ATT&CK, and the residual blind spots are knowable: the Credential Guard wall, the Sapphire Ticket's cryptographic indistinguishability, the encrypted-channel DCSync class, the cross-forest under-instrumentation tail, and legitimate-principal compromise. The operator question in 2026 is not whether MDI detects the attack, but whether the sensor is deployed, the alert was triaged inside the batched-emission window, and the residuals are covered by KQL, Sigma rules, or out-of-band controls.
## 1. A Friday Afternoon at the Domain Controller
Friday, 14:33. A red-team contractor in conference room C runs `Rubeus.exe asreproast` on a corporate laptop she was issued an hour ago. A junior auditor on the fourth floor, working from a desk with read-only Active Directory access, runs `bloodhound-python -c All` for a routine quarterly review. A quiet service account on the SQL host in rack 14 runs `mimikatz "lsadump::dcsync /domain:contoso.com /user:Administrator"`. The operator at the other end of that session is not on the payroll. Three different workstations. Three different intents. One domain controller on the receiving end of all three.
The Security Operations Center has not noticed any of them yet. The watcher on the domain controller, however, has. By 14:35 three named alerts are sitting in the Defender XDR queue, each tagged with a MITRE ATT&CK technique ID, each waiting for someone to triage. *Suspected AS-REP Roasting attack* (T1558.004) for the Rubeus invocation [@mslearn-mdi-alerts-xdr]. *Security principal reconnaissance (LDAP)* for the BloodHound enumeration [@mslearn-mdi-alerts-mdi-classic]. *Suspected DCSync attack -- replication of directory services*, External ID 2006, T1003.006, for the Mimikatz call [@mslearn-mdi-alerts-mdi-classic][@mitre-t1003-006]. The watcher is Microsoft Defender for Identity.SOC operators inside Microsoft customers describe this with a stock phrase: "the watcher was already on the DC." The phrase shows up in incident-response runbooks, vendor training decks, and the Microsoft Defender for Identity Tech Community archive. It captures what is, architecturally, a strange thing -- the defender's sensor is co-located with the attacker's target, not perched outside it.
A Windows Server hosting the Active Directory Domain Services role, responsible for processing Kerberos authentication, NTLM challenges, LDAP queries, and inter-DC directory replication (DRSUAPI) for a domain. Every named MDI runtime alert in this article fires on signal that originates on or transits a domain controller; the deployment model assumes one MDI sensor per DC, plus optional sensors on AD FS, AD CS, and Microsoft Entra Connect servers when those identity roles run on dedicated hosts.
Almost every offensive AD primitive a reader of the SpecterOps, Mimikatz, and Certipy corpus already knows has a runtime alert or a posture assessment shipped by Microsoft on that same DC. *Almost* is the load-bearing word. The alert fires only if three things are true: the sensor is deployed on the surface the attack touches, the audit subcategory the alert depends on is enabled, and the SOC opens the Defender XDR incident inside the batched-emission window the cloud backend uses to aggregate signal. This article is about all three conditions, the twelve-year arc that built the watcher, and the structural blind spots no future MDI release will close.
The watcher was not always on the domain controller. For the first decade of Active Directory, nothing on the DC saw what [BloodHound](/blog/ad-is-a-graph-how-bloodhound-made-defenders-think-like-attac/) today maps. To understand where the watcher came from -- and why its blind spots look the way they do -- we have to start with three founders in Herzliya and a Kerberos forgery presentation in Las Vegas.
## 2. Origins -- Aorato, the Israeli Startup That Became the Watcher
August 2014, Black Hat USA. Tal Be'ery and Michael Cherny take the stage with Alva Duckwall and Benjamin Delpy to present *"Abusing Microsoft Kerberos: Sorry You Guys Don't Get It,"* a demonstration that a stolen [`krbtgt`](/blog/krbtgt-the-account-that-owns-active-directory/) key lets an attacker mint Kerberos ticket-granting tickets that survive every password rotation in the standard remediation playbook [@blackhat-us14-briefings]. The audience is Active Directory operators who thought their password-reset runbook covered them. By the end of the talk it does not. The startup behind the research is **Aorato**, three years old, headquartered in Herzliya, Israel. Three months later, Microsoft buys it.
The credential a Kerberos client receives from the Key Distribution Center (the KDC, which on a Windows network runs on every DC) after successful pre-authentication. The TGT is encrypted with the KDC's own long-term key -- on Active Directory, the password hash of the `krbtgt` account. Possession of the `krbtgt` hash therefore lets an attacker forge a valid TGT for any principal in the domain, since the KDC has no other way to distinguish a forged ticket from a real one. This forged-ticket class is what MITRE catalogues as T1558.001 Golden Ticket [@mitre-t1558-001].
The Aorato deal closed on **November 13, 2014**, announced on the Microsoft Official Blog by Takeshi Numoto, then Corporate Vice President of Cloud and Enterprise Marketing [@msblog-aorato]. The post named the central technology Microsoft was acquiring: Aorato's *Organizational Security Graph*, described as "a living, continuously-updated view of all of the people and machines accessing an organization's Windows Server Active Directory." Pre-acquisition Microsoft had Azure AD on the cloud side and per-DC event log auditing on the on-prem side, but no first-party behavioural-analytics product over Active Directory. Aorato's pre-acquisition product, the *Directory Services Application Firewall*, did exactly that -- it parsed Kerberos, NTLM, LDAP, and DRSUAPI on the wire and ran per-principal behavioural baselines against the parsed protocol stream. Microsoft wanted that capability inside Windows Server, and inside Office 365.Aorato's three founders, per the Globes coverage of the acquisition in November 2014, were Idan Plotnik (CEO), Michael Dolinsky (VP R&D), and Ohad Plotnik (VP professional services). Tal Be'ery was VP of Research. A popular reading of the deal names "the Plotnik brothers and Tal Be'ery" as the co-founder trio, which compresses out Dolinsky's role -- the contemporaneous record names four people, not three [@globes-aorato-2014].
The product lineage that follows is twelve years long and runs through five names. **Microsoft Advanced Threat Analytics (ATA)** was announced as generally available on August 27, 2015 (build 1.4.2457, dated August 31, 2015) -- the on-prem productisation of Aorato's wire-side parser, packaged as a SPAN-mirror appliance ("ATA Gateway") plus an on-prem analytics server ("ATA Center") with its own MongoDB-style document store [@mstc-ata-ga][@atadocs-versions]. **Azure ATP** went GA on March 1, 2018 -- the cloud-side rewrite that kept the on-DC sensor but moved the analytics engine to a multi-tenant cloud backend [@mstc-azureatp-ga][@mstc-azureatp-intro]. **Microsoft Defender for Identity** was the September 22, 2020 rename announced at Ignite 2020, part of Microsoft's broader brand consolidation that also rebranded Office 365 ATP to Microsoft Defender for Office 365 and Microsoft Defender ATP to Microsoft Defender for Endpoint [@mssecblog-unified-xdr][@itpro-defender-rebrand][@infusedinnov-names]. The November 2023 Ignite keynote consolidated Microsoft 365 Defender into **Microsoft Defender XDR** [@virtreview-ignite2023][@handsontek-defender-rebrand]. In October 2025 the **v3.x sensor** GA folded MDI's on-DC sensor into the Microsoft Defender for Endpoint agent that organisations were already running on every server [@mslearn-mdi-whats-new][@modernsec-v3x][@jeffreyappel-v2v3]. The May 2026 release notes extended the v3.x sensor to cover AD FS, AD CS, and Microsoft Entra Connect identity roles directly when those roles run on a domain controller, and raised the per-workspace sensor cap from 350 to 1,000 [@mslearn-mdi-whats-new].
gantt
title Microsoft Defender for Identity lineage, 2012-2026
dateFormat YYYY-MM-DD
axisFormat %Y
section Aorato
Aorato startup (DSAF product) :a1, 2012-01-01, 2014-11-13
section Microsoft ATA
ATA initial release SPAN-mirror Gateway :a2, 2015-08-27, 2016-05-01
ATA 1.6-1.9 Lightweight Gateway :a3, 2016-05-01, 2018-03-01
ATA Extended Support window :a4, 2018-03-01, 2026-01-31
section Cloud rewrite
Azure ATP GA :a5, 2018-03-01, 2020-09-22
Microsoft Defender for Identity name :a6, 2020-09-22, 2023-11-15
section Defender XDR era
MDI inside Defender XDR (v2.x) :a7, 2023-11-15, 2025-10-01
MDI v3.x MDE-integrated sensor :a8, 2025-10-01, 2026-05-27
Aorato's pitch in 2014 was that the Windows Security event log -- the thing every SIEM in the world was ingesting -- could not see the attacks an Active Directory operator most needed to catch. To believe that pitch you have to know exactly what the event log misses.
## 3. Why the Event Log Could Not See Golden Tickets
Present a Golden Ticket to a domain controller, and the LSA writes a successful event 4769 -- a [Kerberos service ticket request](/blog/kerberos-in-windows-the-other-half-of-ntlmless/). Present a legitimate ticket from the same principal, and the LSA writes a successful event 4769. Nothing in the event log's schema, anywhere in any field, distinguishes the two. The ticket is forged with the real `krbtgt` key, so the KDC's signature checks pass. The event log records *that an authentication happened*, not *whether the ticket presented was genuine*. This is the structural ceiling the SIEM industry could not work around for the first decade of its existence, and it is the gap Aorato was built to close [@mitre-t1558-001][@semperis-golden-ticket].
The bare-event-log model has three structural failure modes, each of which drove a generation of detection engineering. **Forged-ticket invisibility** is the first: the LSA logs that an auth happened, but every byte in the 4769 event matches the legitimate case. **Per-DC silo** is the second: a Kerberos auth against one DC and a follow-up auth against another DC five seconds later sit in two different `Security.evtx` files, on two different machines, with no aggregation layer to ask "did the same principal hit ten DCs in five minutes?" **Manual-review throughput collapse** is the third: a medium-sized forest emits thousands of 4624, 4768, 4769 events per minute per DC, and the human analyst hand-walking them never catches up.
[DCSync](/blog/two-checkmarks-and-the-keys-to-the-kingdom-how-active-direct/) makes the first two failure modes vivid. Sean Metcalf's September 2015 ADSecurity writeup walks through running `lsadump::dcsync /domain:contoso.com /user:Administrator` from a workstation: the DC handles the DRSUAPI replication request, the LSA emits a 4662 event for the directory-service-object access, and the attacker walks away with the password hash [@adsec-dcsync].Metcalf's companion DerbyCon V talk, *Red vs. Blue: Modern Active Directory Attacks & Defense* (September 2015), is the canonical operator-grade introduction to the same material [@adsec-dump-ad]. The 4662 event is structurally indistinguishable from a legitimate replication request between two DCs. A SIEM rule that flagged 4662 events whose source IP was not a DC could catch it -- but only if the analyst maintained the IP allowlist (a single Microsoft Entra Connect server in the wrong subnet broke the rule), and only if 4662 was enabled at all (it was high-volume, and many SOCs disabled it to stay under the SIEM's GB/day licence).
> **Key idea:** The SIEM was not failing at Active Directory detection because the rules were wrong. It was failing because the event log -- the data source every SIEM relied on -- could not see what the SIEM needed it to see. Better rules over the same event log would not have closed the gap. Aorato's contribution was to find a different data source: the wire itself.
Aorato's three primitives, none of which the SIEM-plus-event-log model had, were: **per-principal behavioural baselines** so that a long-tail anomaly stood out without anybody writing a rule for it; **on-DC network capture** so that the ticket structure, the DRSUAPI opnum, and the LDAP search filter were available to detection logic; and **a graph over the directory** so that the path from compromised workstation to crown-jewel asset could be computed rather than inferred. ATA shipped the first two in 2015. The graph took longer.
## 4. Early Approaches -- ATA 1.x and the Generations That Tried Before
By the time Aorato shipped its first product, four prior generations of Active Directory detection had already tried and stalled. Each one could see something the previous generation could not. Each one had a structural ceiling an attacker primitive eventually pushed through. The seven generations that follow are the real spine of the article.
flowchart LR
G1["Gen 1: bare per-DC event log audit"] --> G2["Gen 2: SIEM-centralised events with static rules"]
G2 --> G3["Gen 3: first-generation UEBA over SIEM events"]
G3 --> G4["Gen 4: Aorato DSAF and ATA 1.4-1.5 (SPAN mirror)"]
G4 --> G5["Gen 5: ATA 1.6-1.9 (Lightweight Gateway + LMP)"]
G5 --> G6["Gen 6: Azure ATP, MDI v1.x-v2.x (cloud analytics)"]
G6 --> G7["Gen 7: MDI v3.x (MDE-integrated + Identity Explorer)"]
**Generation 1 -- bare per-DC event log auditing (1999-2008)** was already covered above. It was the only model that existed for the first decade of Active Directory, and its structural ceilings became Aorato's pitch deck.
**Generation 2 -- SIEM-centralised event log ingestion with static correlation rules (2005-2014)** is the era of ArcSight, Splunk, QRadar, and LogRhythm. Windows Event Forwarder agents on every DC streamed Security event log entries into a central index, and SOC operators wrote rule-based correlation searches in the vendor's query language. The model gave the SOC cross-DC correlation, a query language, and an audit trail that satisfied PCI-DSS Requirement 10. It did not give the SOC anything new about the data the LSA emitted. Mimikatz's `lsadump::dcsync` was committed to the public Mimikatz repository in March 2015 [@mimikatz-github][@adsec-dcsync]. Sean Metcalf's longer ADSecurity writeup of the technique followed in September 2015. At commit time, every SIEM in production was correlating DC event logs and not one was emitting a DCSync alert, because the 4662 event was structurally identical to a legitimate DC-to-DC replication.
**Generation 3 -- first-generation UEBA on SIEM event data (2013-2017)** was Securonix, Exabeam, and Splunk UBA. Per-principal behavioural baselines layered on top of the SIEM event index could catch novel TTPs without prior signatures -- a Kerberoasting variant whose SPN list had never been seen before could still trip "this account is requesting an unusual number of service tickets compared to its baseline." UEBA also closed Generation 2's per-principal context gap. It did not, however, see ticket structure: a Golden Ticket replayed against ten DCs produces ten successful auths that are behaviourally indistinguishable from the legitimate Domain Admin's pattern unless the attacker's source IP or geographic distribution breaks the baseline. This is the *legitimate-principal-compromise non-detection class* that survives every defensive generation into 2026.
**Generation 4 -- on-wire protocol analytics via off-DC SPAN-mirror Gateway** is where Aorato's product, and then Microsoft ATA 1.4 and 1.5, lived. A switch SPAN port mirrored DC traffic to a dedicated ATA Gateway appliance, which ran libpcap-equivalent capture and parsed Kerberos AS-REQ / TGS-REQ / AP-REQ, NTLM challenges, LDAP searches, and DRSUAPI replication calls. Parsed events streamed to the on-prem ATA Center, which ran detection logic and surfaced alerts in a web console [@mstc-ata-ga]. The wire-side parse closed Generation 1-3's biggest blind spot: ticket structure was finally visible. The SPAN-port operational tax killed the architecture in nine months. Many enterprises could not provision a SPAN mirror. Virtualised DCs on shared hypervisors had no equivalent of a physical SPAN. And the security review of "all DC traffic now mirrors to this appliance" was non-trivial.
**Generation 5 -- ATA 1.6 Lightweight Gateway through ATA 1.9 (May 2016 to March 2020)** moved the Gateway in-process onto the DC itself. ATA 1.6 (May 2016) introduced the Lightweight Gateway with dynamic resource management that capped the sensor's CPU and memory footprint and let the sensor consume events locally rather than via mirrored network traffic [@mslearn-ata-1-6]. ATA 1.7 (August 31, 2016) added Role-Based Access Control for the ATA Console, Windows Server Core support, and detection of reconnaissance through directory-services enumeration [@mssupport-ata-1-7][@atadocs-versions]. **ATA 1.8 (June 30, 2017; announced July 26, 2017)** shipped behavioural-brute-force detection, a Golden Ticket lifetime detector, and the abnormal-modification-of-sensitive-groups alert [@mslearn-ata-1-8][@mstc-ata-1-8][@ataversions-1-8-availability]. **ATA 1.9 (March 21, 2018)** shipped both the entity-profile lateral-movement-aware view and the *Lateral movement paths to sensitive accounts* report [@mslearn-ata-1-9][@atadocs-versions][@atadocs-lmp-usecase].A widespread reading of the ATA timeline anchors LMP to ATA 1.7 in late 2017. The primary record contradicts this on both date and feature: ATA 1.7 shipped on August 31, 2016 per the Microsoft Support KB and the ATA-versions table, and the 1.7 release notes do not mention Lateral Movement Paths. Neither do the 1.8 release notes -- LMP first appears in ATA 1.9 (March 21, 2018), which introduced both the entity-profile lateral-movement view and the full Lateral movement paths to sensitive accounts report in the same release [@mssupport-ata-1-7][@atadocs-versions][@mslearn-ata-1-8][@mslearn-ata-1-9].
> **Note:** A popular framing of the LMP timeline says "Microsoft adopted BloodHound-style graph attack paths in 2022." The primary sources contradict this. Graph-anchored attack-path evaluation in Microsoft's defensive stack originates in **ATA 1.9 (March 2018)**, not in any 2022 adoption event. What did happen in 2022 was the start of the deprecation arc for the SAM-R-based discovery the LMP graph depended on, which culminated in Message Center notice **MC1073068 in May 2025** when Microsoft disabled SAM-R-based local-administrators collection across MDI tenants [@handsontek-mc1073068]. The 2022 date that lingers in operator memory is the *deprecation* anchor, not the adoption anchor.
An attack chain through Active Directory in which a non-sensitive account whose credentials are exposed on one workstation can be used to authenticate to a second workstation where a sensitive account's credentials are cached, which in turn can be used to reach a third workstation, and so on until a Domain Admin or comparable target is reached. ATA 1.9's Lateral Movement Paths report was the first graph-anchored defensive surface that computed the chain in advance; the report was populated by SAM-R queries that enumerated each host's local-administrators group. Microsoft disabled the SAM-R-based collection in May 2025 (MC1073068), and the post-LMP graph layer migrated to the Defender XDR hunting graph plus the April 2026 Identity Explorer preview.
The limitation that drove Generation 5 into Generation 6 was the on-prem ATA Center's release cadence. Benjamin Delpy and Vincent Le Toux disclosed **DCShadow** at BlueHat IL 2018 in January 2018 -- the technique of registering a rogue domain controller via `nTDSDSA` object creation plus SPN registration, then pushing arbitrary updates into AD via legitimate DRSUAPI replication that the event log records as ordinary inter-DC traffic [@dcshadow-com][@mitre-t1207]. ATA 1.9 shipped two months later, in March 2018, with no DCShadow detection. Azure ATP -- the cloud-side rewrite, also GA in March 2018 -- shipped paired alerts External ID 2028 (*Suspected DCShadow attack -- domain controller promotion*) and External ID 2029 (*Suspected DCShadow attack -- domain controller replication request*) **five months later, in July 2018** [@mslearn-mdi-alerts-mdi-classic][@mslearn-mdi-whats-new-archive]. The on-prem release cadence could not have closed that five-month gap. The cloud rewrite was the structural answer.
## 5. The Breakthrough -- Azure ATP and the Inverted Data Path
If the wire was the right data layer, the cloud was the right place to run the analytics. That is the architectural decision Azure ATP committed to in March 2018, and it is what distinguishes the Microsoft defensive product from every prior generation. The on-DC sensor stayed on the DC. The analytics engine moved.
Four architectural shifts followed. **First**, the on-DC sensor became a thin parser. Sensors no longer hosted detection logic; they captured the Kerberos / NTLM / LDAP / DRSUAPI traffic, parsed it into a stream of structured events, and shipped the stream upstream. **Second**, the data path inverted. Generation 4 sent unparsed packets from the wire to the off-DC Gateway, which parsed them and stored them on-prem; Azure ATP sent parsed events from the on-DC sensor upstream to a multi-tenant cloud backend that ran detection logic and wrote alerts back into a tenant-specific workspace. **Third**, per-principal behavioural baselines accumulated centrally rather than per-DC, so a baseline survived DC reboots, sensor restarts, and migrations across data centres. **Fourth**, identity signal joined endpoint and email signal in the same incident queue once Azure ATP folded into Microsoft 365 Defender -- the cross-product correlation that no on-prem product had ever offered [@mstc-azureatp-ga][@mstc-azureatp-intro][@mslearn-xdr-overview].
Then came the brand-and-architecture history every operator has to know to read a 2026 runbook. The **September 22, 2020** rename from Azure Advanced Threat Protection to Microsoft Defender for Identity was a brand consolidation, not an architecture change -- the same sensor, the same alerts, the same workspace [@mssecblog-unified-xdr]. The legacy `portal.atp.azure.com` standalone portal was **retired on June 30, 2023** via Message Center notice MC567494, with all requests automatically redirected to `security.microsoft.com` [@handsontek-mc567494][@mslearn-mdi-portal]. The **November 15, 2023** Ignite keynote renamed Microsoft 365 Defender to Microsoft Defender XDR (Message Center MC696570) [@handsontek-defender-rebrand][@virtreview-ignite2023]. Again a brand change, again not an architecture change: the sensors stayed on the DC, the analytics stayed in the cloud, and the KQL schema -- `IdentityLogonEvents`, `IdentityQueryEvents`, `IdentityDirectoryEvents` -- stayed the same [@mslearn-xdr-identitylogon][@mslearn-xdr-identityquery][@mslearn-xdr-identitydirectory].The legacy `portal.atp.azure.com` URL is worth remembering because runbooks and SOAR rules from 2018 to 2023 frequently hard-coded it. Any rule that referenced the old portal needs an update; the redirect handles browser traffic but not API calls.
What the sensor actually feeds into the cloud backend, in 2026, is four data-input layers, ordered roughly by evidence strength. **First**, the Windows Security event log -- the audit subcategories that the MDI event-collection page lists as required, including *Audit Credential Validation*, *Audit Kerberos Authentication Service*, *Audit Kerberos Service Ticket Operations*, *Audit Directory Service Access*, and *Audit Computer Account Management* among others [@mslearn-mdi-event-collection]. These are public, documented, and easy to verify with `auditpol /get /category:*`. **Second**, on-DC network capture of Kerberos, NTLM, LDAP, and DRSUAPI -- well-documented because the sensor's network requirements are part of the public deployment guide. **Third**, [Event Tracing for Windows](/blog/etw-how-windows-2000s-performance-hack-became-the-edr-substr/) providers that the sensor subscribes to in order to get signal the event log does not surface. **Fourth**, AD CS audit-log subscriptions added with the AD CS sensor release in August 2023 [@mstc-adcs-sensor][@dirteam-sander-aug2023].
The breakthrough was not better detection algorithms. The breakthrough was moving the analytics off the DC entirely, so the per-principal baselines could accumulate centrally and the detection set could ship on a cloud cadence instead of an on-prem one. That decision is why MDI shipped DCShadow detection within five months of disclosure -- a cadence the on-prem product could not have matched.
That is the move that turned a wire-side parse into a sustained detection program. The proof is the DCShadow timeline: five months from disclosure to detection, on a cadence the on-prem product could not have matched. Now we can ask the question every reader of the offensive-AD corpus actually wants answered. What does the watcher catch in 2026?
## 6. MDI in 2026 -- Sensors, Alerts, KQL, and the Graph in Transition
This is the article's bookmarking section. Four parts: what is on the DC, what alerts fire, what KQL the operator writes when the alerts miss, and where the graph layer that began as ATA 1.9's Lateral Movement Paths report actually lives in 2026.
### 6.1 Sensor topology in 2026
What is on a Windows Server 2022 (or 2025) domain controller running MDI in May 2026? Two sensor families, two target-server matrices, and a workspace cap.
The **v2.x sensor** is the legacy standalone agent: supported on Windows Server 2016 and earlier domain controllers, and on AD FS, AD CS issuing certificate authorities, and Microsoft Entra Connect servers that are not themselves domain controllers, per the v2.x prerequisites page [@mslearn-mdi-prereq-sensor-v2]. v2.x carries its own installer, its own update cadence, and its own packet capture stack (NPCap). It also requires a *Directory Service Account* (DSA) -- a gMSA configured during install whose forest-wide read rights let the sensor enumerate AD objects.
A group Managed Service Account configured during MDI v2.x sensor installation, granted forest-wide read permissions on Active Directory objects so the sensor can resolve principal identities, enumerate group memberships, and read schema attributes that the wire-side parse refers to by SID. The v3.x sensor replaces the DSA pattern with LocalSystem impersonation -- the sensor impersonates the local-system account of the domain controller it runs on, which has equivalent on-DC read rights without needing a separate gMSA per tenant [@mslearn-mdi-deploy-sensor-v3][@mslearn-mdi-action-accounts].
The **v3.x sensor** is the current path. It requires Windows Server 2019 or later with the March 2026 (or later) cumulative update installed, the Defender for Endpoint agent already deployed and onboarded, and -- critically -- there is no separate MDI installer at all. The MDI sensor capability ships as an extension of the MDE SENSE service. Self-imposed resource caps: **CPU at most 30% of the host DC's CPU, memory at most 1.5 GB**, with explicit Hyper-V Dynamic Memory and VMware reservation guidance that ensures the cap is honoured under contention [@mslearn-mdi-deploy-sensor-v3]. v3.x uses LocalSystem impersonation for AD reads rather than a gMSA-based DSA. The May 2026 release notes added direct v3.x support for AD FS, AD CS, and Microsoft Entra Connect identity roles *when those roles run on a domain controller* (which is the recommended deployment pattern for most mid-sized tenants) [@mslearn-mdi-whats-new].The 30% CPU cap is honoured by the MDE SENSE service's scheduling, but Hyper-V Dynamic Memory and VMware ballooning can break the assumption -- if the hypervisor reclaims memory under contention the sensor cannot get its 1.5 GB and the local capture buffer drops events. Microsoft's deployment guide recommends a static memory reservation on virtualised DCs for that reason.
The four target server roles are domain controllers (every DC, including RODCs), AD FS federation servers (not Web Application Proxies), AD CS online issuing certificate authorities (not offline root CAs), and Microsoft Entra Connect servers (both active and staging). The May 2026 release notes also raised the per-workspace capacity ceiling from 350 sensors to **1,000 sensors per workspace** [@mslearn-mdi-whats-new].
flowchart TD
DC1["Domain Controller (WS2019+, v3.x sensor inside MDE SENSE)"]
DC2["Domain Controller (WS2016, v2.x sensor)"]
ADFS["AD FS server (v2.x sensor, non-DC)"]
ADCS["AD CS issuing CA (v2.x or v3.x sensor)"]
EC["Entra Connect server (v2.x sensor)"]
CLOUD["MDI cloud backend (multi-tenant analytics, per-principal baselines)"]
XDR["Microsoft Defender XDR (security.microsoft.com) Identity tables + alerts"]
DC1 --> CLOUD
DC2 --> CLOUD
ADFS --> CLOUD
ADCS --> CLOUD
EC --> CLOUD
CLOUD --> XDR
The deployment matrix below is the operator-grade reference -- which role gets which sensor, which audit subcategories the sensor depends on, and what posture data the role unlocks.
| Server role | Sensor version | Required audit subcategories | Posture coverage unlocked |
|---|---|---|---|
| Domain controller (WS 2019+) | v3.x (preferred) | Credential Validation; Kerberos AS; Kerberos TGS; Logon; DS Access; Computer Account Mgmt | Full Identity Security Posture (entity hygiene, dormant accounts, weak crypto) |
| Domain controller (WS 2016) | v2.x | Same as above | Same as above, minus v3.x-only enhancements |
| AD FS federation server | v2.x (or v3.x if also a DC) | AD FS audit logs (Application + Security) | Hybrid auth signal (Entra ID + on-prem) |
| AD CS issuing CA | v2.x (or v3.x if also a DC) | AD CS audit logs (certificate request and template events) | Nine ESC posture assessments (ESC1-Preview, ESC2, ESC3, ESC4, ESC6-Preview, ESC7, ESC8, ESC11, ESC15) [@mslearn-mdi-certificates-posture] |
| Entra Connect server | v2.x (or v3.x if also a DC) | Sync engine event log | Sync-engine attribute-flow signal |
> **Note:** For new DC deployments on Windows Server 2019 or later, use **v3.x**: no separate installer, no gMSA, no NPCap, and the sensor ships its updates with the MDE agent. For AD FS, AD CS, or Entra Connect roles that run on dedicated Windows Server 2016 hosts, **v2.x** is the supported path until those hosts are upgraded. Mixed environments are normal during the migration window; the cloud backend handles both versions without operator intervention [@modernsec-v3x][@jeffreyappel-v2v3]. **One known limitation as of May 2026**: Windows Server 2025 domain controllers that currently run a v2.x sensor cannot be migrated to v3.x; Microsoft's What's New page is explicit that "migration of domain controllers with Windows Server 2025 from sensor v2.x to sensor v3.x is not supported" and the operator should continue on v2.x on those hosts until migration support ships [@mslearn-mdi-whats-new].
Sensor topology determines coverage. Coverage determines which alerts can fire.
### 6.2 The alert taxonomy mapped to MITRE ATT&CK
Every offensive Active Directory primitive a reader of the SpecterOps, Mimikatz, and Certipy corpus knows has a row in MDI's alert catalogue. The catalogue is the article's bookmarkable artifact, and the table below is the load-bearing data-density object. Four MITRE-aligned categories, the named alert for each primitive, and the ATT&CK technique ID the alert maps to.
| Category | MDI alert (External ID / detector) | MITRE ATT&CK technique |
|---|---|---|
| Reconnaissance | Account enumeration reconnaissance (LDAP) -- External ID 2437 | T1087 Account Discovery |
| Reconnaissance | Network-mapping reconnaissance (DNS) | T1018 Remote System Discovery |
| Reconnaissance | Security principal reconnaissance (LDAP) | T1069 Permission Groups Discovery |
| Reconnaissance | User and IP address reconnaissance (SMB) | T1018 |
| Persistence and privilege escalation | Honeytoken activity (authentication / attribute / group) | T1098 Account Manipulation |
| Persistence and privilege escalation | Suspected Skeleton Key attack | T1556 (Modify Authentication Process) |
| Persistence and privilege escalation | Suspected Golden Ticket usage (encryption downgrade) | T1558.001 Golden Ticket [@mitre-t1558-001] |
| Persistence and privilege escalation | Suspected Golden Ticket usage (forged authorization data) | T1558.001 |
| Persistence and privilege escalation | Suspected DCShadow attack (DC promotion) -- External ID 2028 | T1207 Rogue Domain Controller [@mitre-t1207] |
| Persistence and privilege escalation | Suspected DCShadow attack (DC replication request) -- External ID 2029 | T1207 |
| Persistence and privilege escalation | Suspicious additions to sensitive groups | T1098 Account Manipulation |
| Credential access | Suspected DCSync attack (replication of directory services) -- External ID 2006 | T1003.006 DCSync [@mitre-t1003-006] |
| Credential access | Suspected Brute Force attack (Kerberos, NTLM) | T1110 Brute Force |
| Credential access | Suspected AS-REP Roasting attack | T1558.004 AS-REP Roasting [@mitre-t1558-004] |
| Credential access | Suspected Kerberos SPN exposure / Kerberoasting | T1558.003 Kerberoasting [@mitre-t1558-003] |
| Credential access | Suspected over-pass-the-hash attack | T1550.002 Pass the Hash |
| Lateral movement | Suspected identity theft (pass-the-hash) | T1550.002 |
| Lateral movement | Suspected identity theft (pass-the-ticket) | T1550.003 Pass the Ticket |
| Lateral movement | Remote code execution attempt | T1021 Remote Services |
| Lateral movement | Suspected NTLM relay attack (the ESC8 class) | T1187 Forced Authentication |
| Lateral movement | Suspected NTLM authentication tampering | T1557.001 LLMNR / NBT-NS / Man-in-the-Middle |
Both alert documentation surfaces -- the classic-format alert reference and the XDR-format alert reference -- are the canonical primaries for this catalogue [@mslearn-mdi-alerts-mdi-classic][@mslearn-mdi-alerts-xdr]. Reading either page in sequence is the single most useful afternoon a SOC operator new to MDI can spend.The numeric External IDs (2006 for DCSync, 2028 and 2029 for DCShadow, 2437 for LDAP account enumeration, and so on) are a Microsoft-internal stability anchor that survives alert-name renames over time. Microsoft has renamed alerts -- "Suspected DCSync attack" was named differently in early Azure ATP -- but the External IDs do not change. Production SOAR rules should match on the External ID, not the alert name string.
An offensive primitive in which a principal that has been granted the *Replicating Directory Changes* and *Replicating Directory Changes All* extended rights uses the DRSUAPI replication interface (specifically `IDL_DRSGetNCChanges`) to request a full or partial replication of directory contents from a domain controller -- typically targeting the `unicodePwd` attribute on sensitive accounts like `krbtgt` and `Administrator`. The technique requires no code execution on the DC, no `Ntds.dit` copy, and no presence on a domain-joined machine other than network connectivity to a DC. Mimikatz's `lsadump::dcsync` command, written by Benjamin Delpy and Vincent Le Toux, is the canonical implementation; MITRE catalogues the technique as T1003.006 [@mitre-t1003-006][@adsec-dcsync].
A specific adversary behaviour catalogued in the MITRE ATT&CK framework, identified by a stable ID (for example T1003.006 for DCSync, T1558.001 for Golden Ticket, T1207 for Rogue Domain Controller). MITRE updates the framework periodically; the IDs themselves do not change, which is why detection-engineering tooling -- including MDI's per-alert MITRE mapping -- anchors to the IDs rather than the human-readable names.
Concrete mechanism, for one named alert. *Suspected DCSync attack -- replication of directory services*, External ID 2006, fires on the structural pattern that an `IDL_DRSGetNCChanges` request reached a domain controller from a source that is not itself a domain controller. The mechanism is the one place where MDI's wire-side capture pays for itself most visibly -- the 4662 event the LSA emits records the directory-service-object access but does not identify the source as not-a-DC; only the wire view sees the calling host's IP and resolves it against the directory's `serverReference` set.
sequenceDiagram
autonumber
participant Attacker as Attacker workstation (Mimikatz)
participant DC as Domain Controller
participant MDI as MDI v3.x sensor (on DC)
participant Cloud as MDI cloud backend
participant XDR as Defender XDR portal
Attacker->>DC: IDL_DRSGetNCChanges (DRSUAPI replication request)
DC->>DC: LSA writes event 4662 (DS object access)
DC-->>Attacker: Replication response (unicodePwd, supplementalCredentials)
MDI->>MDI: Wire parse: caller IP not in serverReference set
MDI->>Cloud: Stream parsed event (caller, target object, attributes)
Cloud->>Cloud: Correlate against known-DC IPs, fire detector
Cloud->>XDR: Write alert External ID 2006 (T1003.006)
XDR->>XDR: Surface in unified incident queue
The alert taxonomy makes the bookmarkable promise the rest of the article rests on. The trigger logic that fires each row, however, depends on signal the sensor can only acquire on the wire or in the event log -- and when the trigger logic misses, the operator's last-mile coverage is KQL.
### 6.3 The advanced-hunting schema and a worked KQL example
When the alert template misses, the hunter writes Kusto Query Language. Defender XDR exposes three identity-specific tables that the MDI sensor populates -- `IdentityLogonEvents` for authentication activity captured against on-prem AD, `IdentityQueryEvents` for queries performed against AD objects, and `IdentityDirectoryEvents` for events involving an on-prem domain controller including password changes, expirations, UPN changes, scheduled tasks, and PowerShell activity [@mslearn-xdr-identitylogon][@mslearn-xdr-identityquery][@mslearn-xdr-identitydirectory]. Cross-product context is available from the unified `AlertInfo`, `AlertEvidence`, and `DeviceLogonEvents` tables.
The worked example below is the structural DCSync detector that catches the encrypted-channel case the alert can miss. The runner in this environment cannot execute KQL directly, so the block is annotated rather than runnable -- a non-runnable KQL detector is stronger pedagogy here than a hand-rolled Python simulation, because the query as written is exactly what an operator would paste into the Defender XDR advanced-hunting console against the actual `IdentityDirectoryEvents` table.
```kql
// Structural DCSync detector -- DRSUAPI from non-DC IPs
// Run against the Defender XDR advanced-hunting IdentityDirectoryEvents table.
IdentityDirectoryEvents
| where Timestamp > ago(24h) // tune window per triage cadence
| where ActionType == "DRSReplicate" // the DRSUAPI replication call
| extend SourceIP = tostring(parse_json(AdditionalFields).SourceIPAddress)
| where SourceIP !in ("10.0.1.10", "10.0.1.11", "10.0.1.12") // tenant DC IPs go here
| where AccountName !startswith "MSOL_" // Entra Connect Cloud Sync FP class
| where AccountName !in ("ADConnectSync") // Entra Connect on-prem FP class
| project Timestamp, AccountName, SourceIP, TargetDeviceName, AdditionalFields
| order by Timestamp desc
```
The output rows that survive the filters are the operator's investigation queue: DRSUAPI replication requests against a DC from a source that is not itself a DC, and not a recognised hybrid-identity sync principal. The two cleanup principals -- `MSOL_*` (the Microsoft Entra Connect Cloud Sync service account, with a stable `MSOL_` prefix and an 8-character random suffix) and `ADConnectSync` (the on-prem Entra Connect service account) -- are the two most common false positives every MDI tenant sees. Adding them to the `!startswith` and `!in` clauses cuts the FP rate by an order of magnitude in most environments. The third FP class that operators tune for is **legitimate vulnerability scanners** triggering the LDAP / SMB reconnaissance alerts -- the scanner's authenticated enumeration looks behaviourally identical to a SharpHound collector unless the scanner's source IP is in an allowlist.
flowchart LR
A["IdentityDirectoryEvents (DRSReplicate)"] --> B["Filter: source IP not in known_dc_ips"]
B --> C["Filter: account not in sync allowlist"]
C --> D["Suspect rows (operator triage)"]
Beyond the three identity tables there is one more surface worth naming. The April 2026 *Identity Explorer* Preview in the Defender XDR Identity page builds on the Microsoft Sentinel data lake -- Microsoft's 2026 cross-product cold-storage and analytics layer with up to 12 years of retention in Parquet format [@mslearn-sentinel-datalake][@mslearn-mdi-whats-new]. Identity Explorer uses the Defender XDR hunting graph to visualise identity attack paths as interactive graphs with predefined scenarios for lateral movement, privilege escalation, and credential-access risk [@mslearn-xdr-hunting-graph][@mslearn-xdr-investigate-users].
The query language is the operator's last-mile coverage layer. Everything in section 6 so far is what MDI gives you. KQL is what you do when MDI does not.
### 6.4 The graph layer in transition
The graph that began as ATA 1.9's Lateral Movement Paths report no longer exists in the form most operators remember. The history is a clean three-step arc and a transition still in progress.
ATA 1.9 (March 2018) shipped the *Lateral movement paths to sensitive accounts* report, built on SAM-R-based local-administrator discovery: the sensor remotely enumerated each member host's local-administrators group and computed the chain of "who can become whom" through cached credentials [@mslearn-ata-1-9][@atadocs-lmp-usecase]. That report carried through Azure ATP, through the Microsoft Defender for Identity rename, and through the Microsoft Defender XDR rebrand essentially unchanged for seven years.
In May 2025, Microsoft disabled the SAM-R-based discovery via Message Center notice MC1073068, citing alignment with the broader [Windows NTLM-deprecation roadmap](/blog/ntlmless-the-death-of-ntlm-in-windows/) [@handsontek-mc1073068]. The message body is explicit: *"Disabling this feature will impact the ability to map potential lateral movement paths (using SAM-R queries) because the data used to calculate potential lateral movement paths will no longer be collected by the Defender for Identity sensor."* SAM-R as a remote-discovery primitive had become a security debt as much as a feature; the deprecation brought MDI's collection behaviour into line with Restricted SAM and Microsoft's NTLM-deprecation posture, but it left the LMP surface without its primary data source.
The replacement is in two pieces. The first is the unified **attack-path exploration** surface in Microsoft Defender XDR, driven primarily by Microsoft Defender for Cloud's Cloud Security Posture Management (CSPM) attack-path engine [@mslearn-defenderforcloud-attack-path], with MDI feeding identity signal into the same correlation. The second is the **Identity Explorer** Preview that launched in April 2026 on the Microsoft Sentinel data lake, specifically for identity attack paths -- visible from the Identity page in Defender XDR for tenants with a Sentinel data lake licence [@mslearn-mdi-whats-new][@mslearn-xdr-hunting-graph][@mslearn-xdr-investigate-users]. The honest framing in 2026 is that the post-SAM-R LMP coverage is **not yet fully closed** by either replacement -- the Defender XDR hunting graph is rich, the Identity Explorer is improving, but the seven-year-old SAM-R-derived LMP report had operator workflows around it that the new surfaces have not all reproduced.
MDI's graph layer is in transition. The cloud rewrite handed Microsoft the platform to ship a better graph than ATA ever could; in 2026 the build-out is still in progress. Section 9 will name this as one of the article's open problems. First, though, we have to look at the competitive market the watcher sits inside.
## 7. Competing Approaches -- the 2026 Identity-Detection Market
If MDI is the watcher on the DC, what is everybody else? Five named methods share the 2026 identity-threat detection market with MDI, each optimising for a different trade-off. The table below is the six-column shorthand; the prose that follows is the per-method analysis.
| Vendor / project | On-DC sensor model | Data-input mix | Alert taxonomy | Graph model | Pricing model |
|---|---|---|---|---|---|
| MDI | On-DC sensor (v2.x standalone or v3.x MDE-integrated) | Wire + event log + ETW + AD CS audit | MITRE-aligned alert catalogue + nine ESC posture | Hunting graph + Identity Explorer Preview | Bundled with M365 E5 / E5 Security / F5 Security |
| CrowdStrike Falcon Identity Protection | Connector on/near DC + endpoint agent | Wire (via connector) + endpoint telemetry | ITDR-style alerts, less granular ATT&CK mapping | Identity attack-path view (inline enforcement) | Falcon ITDR module add-on |
| Semperis DSP + ADFR | Off-DC change-tracking agent | AD object-change events (LDAP / replication) | IoC and IoE runtime alerts plus drift / tamper alerts | Tier 0 exposure graph + rollback graph | Standalone licence per AD object |
| SpecterOps BloodHound Enterprise | Off-DC collector (SharpHound CE) | AD permissions graph + Azure / Okta / Mac extensions | Attack-path exposure findings | Pure graph (Cypher over Postgres / Neo4j) | Standalone SaaS licence |
| Microsoft Sentinel native UEBA | None on DC (consumes MDI + other sources) | Sentinel data lake (cross-product) | UEBA risk scores, anomaly events | None on identity graph directly | Sentinel ingestion + UEBA add-on |
| Sigma + SIEM (open source) | None on DC (event forwarder agents) | Windows event logs, ETW via OSQuery / Velociraptor | Custom rule library | None | Free (rule library); SIEM cost separate |
**CrowdStrike Falcon Identity Protection** is the post-acquisition rename of *Preempt Platform*, the product line CrowdStrike bought when it completed the **Preempt Security acquisition on September 30, 2020** [@businesswire-cs-preempt]. Architecturally distinct from MDI: rather than relying on an on-DC sensor that parses wire traffic and event logs, Falcon Identity Protection inspects authentication traffic via a connector deployed on or near each DC and correlates it with Falcon-agent telemetry already collected from every protected endpoint. Identity-policy enforcement is *inline* -- the product can require an MFA challenge or block an authentication at the point of decision rather than emit a post-hoc alert [@crowdstrike-falcon-id]. This is the only commercial product in the survey that does inline enforcement on AD Kerberos and NTLM authentications; it is also the only one that is not bundled with a Microsoft 365 licence.
The product category that combines runtime detection of identity-targeted attacks (Kerberos forgery, credential theft, lateral movement) with response capabilities (force MFA, disable user, revoke session). Gartner formalised the term in 2022. CrowdStrike Falcon Identity Protection and SentinelOne Singularity Identity are the largest ITDR-positioned products outside the Microsoft stack; MDI plus the Defender XDR remediation actions surface effectively functions as Microsoft's ITDR offering for tenants already inside the Microsoft 365 estate [@mslearn-mdi-remediation-actions].
**Semperis Directory Services Protector (DSP)** and the companion **Active Directory Forest Recovery (ADFR)** product are best known for change-tracking and recovery, layered over a runtime Indicators-of-Compromise and Indicators-of-Exposure detection set that overlaps with MDI's alert taxonomy on classes like DCSync, DCShadow, and Golden Ticket replay [@semperis-dsp][@semperis-adfr]. DSP tracks AD object changes in near-real-time, fires IoC and IoE alerts on the same primitives MDI watches, and offers post-attack rollback as its primary differentiator; ADFR handles malware-free forest recovery in minutes-to-hours rather than days-to-weeks. The pair is partly complementary, partly overlapping with MDI: DSP catches the post-attack drift (the unauthorised group membership change, the rogue ACL) and offers a rollback path MDI does not have; MDI's per-principal behavioural baselines and unified Defender XDR incident queue are the differentiator on the in-flight detection axis; ADFR handles "the worst day of your career" forest-recovery scenarios where rebuilding the directory is the only remediation. Many tenants run all three.
**SpecterOps BloodHound Enterprise (BHE)** is the commercial form of the BloodHound 2016 graph model that Andy Robbins, Rohan Vazarkar, and Will Schroeder published at DEF CON 24 [@defcon-six-degrees][@bloodhound-github-specterops][@neo4j-bh]. Pure graph attack-path exposure model: BHE maps the paths that *exist* (Tier Zero hygiene, principal-to-principal cross-domain trust paths, Entra to on-prem pivots) rather than alerts on attacks in flight [@specterops-bhe]. Complementary to MDI: BHE tells you the attack path exists in the directory, MDI tells you someone is walking it right now. The SpecterOps team's *Certified Pre-Owned* whitepaper (June 2021) by Will Schroeder and Lee Christensen is the source of the [ESC1-ESC8 vocabulary](/blog/certified-pre-owned-ad-cs-and-active-directorys-second-trust/) that downstream MDI ADCS posture assessments map to [@specterops-cpo-pdf][@specterops-cpo-blog].
**Microsoft Sentinel native UEBA** is the SIEM-side behavioural-baselines product over the broader event corpus that Sentinel ingests. Sentinel UEBA uses machine learning to build dynamic behavioural profiles for users, hosts, IP addresses, applications, and other entities, with named data-source connectors including Defender for Identity [@mslearn-sentinel-ueba]. Sentinel UEBA is the "outside the identity tables" layer -- detection that needs to correlate identity signal with email, endpoint, network, and SaaS signal lives there rather than in the identity tables themselves. The Defender XDR-to-Sentinel connector unifies the surfaces [@mslearn-sentinel-defender-connector].
**Open-source detection stacks** -- Sigma rules deployed against Sentinel, Splunk, or Elastic, plus Velociraptor and Wazuh -- can match many of MDI's pattern-based alerts but cannot match MDI's per-principal behavioural baselines without significant in-house investment [@sigmahq-github]. The SigmaHQ rule corpus contains over 3,000 detection rules in a vendor-neutral SIEM format. Olaf Hartong's FalconForce team publishes the *FalconFriday* hunting-query repository (MDE-schema KQL queries for DLL injection, COM hijacking, LOLBins, LDAP anomalies, and SMB NULL sessions) -- the operator-side companion to community-built detection libraries [@github-falconfriday][@falconforce-blog].
MDI is the high-coverage, low-effort identity-threat detection product if you already have Microsoft 365 E5 or E5 Security. The third-party products in this market win on differentiation -- inline enforcement, change-tracking, exposure-graph mastery -- rather than baseline coverage. The interesting question for an architect in 2026 is not which to buy. The interesting question is what MDI, by design, cannot see at all.
## 8. Theoretical Limits -- the Five Structural Ceilings
There are attacks no version of MDI will ever detect. Not because Microsoft has not shipped the alert yet, and not because the engineering team has not gotten around to it. Because the alert is structurally impossible.
Five named ceilings, each anchored to a primary source. Together they are the residual blind-spot inventory every operator should be able to name from memory.
flowchart TD
subgraph causes ["Attacker-side cause"]
C1["OS does not expose the credential operation"]
C2["Forged ticket is cryptographically identical"]
C3["Wire traffic is wrapped in an encrypted channel"]
C4["Attack pivots through a forest without a sensor"]
C5["Attacker uses real DA real credentials"]
end
subgraph gaps ["Defender-side gap"]
G1["Credential Guard wall"]
G2["Sapphire Ticket class"]
G3["Encrypted-channel DCSync"]
G4["Cross-forest tail"]
G5["Legitimate principal non-detection"]
end
C1 --> G1
C2 --> G2
C3 --> G3
C4 --> G4
C5 --> G5
**Ceiling 1 -- the Credential Guard wall.** Anything the operating system itself cannot see is invisible to MDI. The DCSync class is the canonical example with a twist: [Credential Guard](/blog/the-empty-hash-credential-guard-the-lsaiso-trustlet-and-the-/) isolates the LSASS process so that credentials in memory cannot be scraped from a compromised endpoint, but it does not prevent DRSUAPI-level secret extraction against the DC because the DRSUAPI replication interface is *supposed* to return password hashes to legitimate replication partners. MDI catches DCSync by detecting the wire-side pattern (DRSUAPI from a non-DC source), not by Credential Guard's protection. Anything the OS does not expose in event log, wire traffic, or instrumented API -- a custom kernel driver that reads secrets through a side channel, a hypervisor-level credential extraction on a non-Secured-core host -- is, by construction, outside MDI's data layer.
**Ceiling 2 -- forged-ticket cryptographic indistinguishability, the Sapphire Ticket.** This is the most important ceiling, and the one whose permanence the rest of this section orbits.
A forged Kerberos Ticket Granting Ticket whose Privileged Attribute Certificate (PAC) is a verbatim copy of a legitimate principal's PAC, obtained via the S4U2self plus User-to-User PAC-copy flow against the target principal and then encrypted with the stolen `krbtgt` key. The technique was disclosed by Charlie Bromberg (Synacktiv / Shutdown) in October 2022 and documented on The Hacker Recipes wiki [@hackerrecipes-sapphire]. The defining property: every byte of the forged ticket's PAC matches the byte pattern of a ticket the genuine KDC would have issued for the legitimate principal, including the group SID set, the user ID, the logon time, and the authorisation-data fields. The classic Golden Ticket leaves PAC anomalies that MDI's *Suspected Golden Ticket usage (forged authorization data)* alert fires on; the Sapphire Ticket leaves no PAC anomaly because there is no anomaly to leave.
> **Key idea:** Cryptographic indistinguishability is a permanent class. No future MDI release fixes the Sapphire Ticket without breaking Kerberos itself.
Rotate `krbtgt` twice on a defined cadence -- 90 days is common; some Tier Zero playbooks rotate every 30 days. The "twice" is non-optional: a single rotation leaves the prior `krbtgt` key valid for the duration of any tickets the KDC has previously issued, so the stolen key is still usable for up to 10 hours (or longer, on `MaxRenewAge` extensions). Combine with Authentication Policy Silos for Tier Zero service accounts, Tier Zero access reviews, and Privileged Access Workstations for any administrator who can read `krbtgt`. None of these closes the Sapphire Ticket; together they shrink the window in which a stolen key remains weaponisable. Sample PowerShell for the double rotation is in the Microsoft-published `Reset-KrbTgt` script in the GitHub samples repository [@msdefender-id-github].
**Ceiling 3 -- the encrypted-channel DCSync class.** When DRSUAPI is wrapped in a transport the on-DC capture cannot decode -- DCSync over LDAPS via a SPN-bound impersonation chain, for instance -- the wire-side pattern recognition that powers the External ID 2006 alert degrades. The structural detector in Section 6.3 catches the unencrypted case; the encrypted case requires either a different observation surface (the DRSUAPI handler's own instrumentation) or behavioural baselining on the post-fact replication-log signal. MDI's coverage in this case is partial, not complete.
**Ceiling 4 -- the cross-forest under-instrumentation tail.** MDI sees the forests its sensors are deployed in. Pivot through an external trust to a forest without MDI coverage and the signal is incomplete -- the attacker's pre-pivot reconnaissance, the actual trust traversal, and any post-pivot actions on the trusting side that do not also touch an MDI-monitored forest will be invisible. This is a deployment property, not a product property: a tenant with MDI on every forest in its environment does not have this ceiling. A tenant whose acquisition portfolio includes three forests it does not yet monitor does.
**Ceiling 5 -- legitimate-principal compromise non-detection.** When the attacker uses a real Domain Admin's real credentials, every action is behaviourally indistinguishable from the legitimate principal unless timing, geolocation, or device fingerprint breaks the baseline. The 2025 and 2026 *Suspected session cookie theft* and related XDR-format alerts close part of this gap by adding behavioural side channels that the older Azure ATP alert catalogue did not cover [@mslearn-mdi-alerts-xdr]. The residual is permanent: a sufficiently disciplined attacker operating from the legitimate principal's normal workstation, during the legitimate principal's normal hours, doing things the legitimate principal might plausibly do, is, by construction, indistinguishable from the legitimate principal.
A sixth honourable mention sits adjacent to these five: **out-of-band physical access** -- a stolen `Ntds.dit` backup, an attacker-controlled DC's offline export, supply-chain firmware compromise on the DC hardware -- is outside the data layer MDI operates over. The hardware-trust-root community owns this class of mitigation, not the identity-threat detection community.
> **Note:** The five structural ceilings are knowable, not surprises. A SOC that names them ahead of time has a better incident-response runbook than one that does not -- specifically, the runbook for "we just realised the attacker used a Sapphire Ticket" is fundamentally different from the runbook for "MDI fired and we ignored it." The first runbook starts with `krbtgt` rotation and Tier Zero hygiene review; the second starts with disciplinary review and SOAR-rule tuning. Knowing which runbook to pick depends on naming the ceiling correctly.
These five named residuals are why the rest of the article exists. If MDI caught everything, the operator playbook in Section 10 would be unnecessary. Because MDI does not, and because the gaps are knowable, the playbook in Section 10 is the difference between MDI as a licence line item and MDI as a working part of the SOC's day. But before the playbook, one last open-problem inventory: where is the research roadmap actually working?
## 9. Open Problems -- What the Research Roadmap Is Working On
Five open problems sit between the 2026 floor and a hypothetically perfect identity-threat detector. Each one has a current best partial result and a citation. None of them is closed.
**Open Problem 1 -- the post-PKINIT NTLM-relay class beyond ESC8.** Synacktiv's *Understanding and evading Microsoft Defender for Identity PKINIT detection* paper (Guillaume Andre, 2024) reverse-engineered MDI's PKINIT-class detection: MDI fingerprints offensive-tool-generated AS-REQ messages by the encryption types they advertise, which differ from the encryption-type list a legitimate Windows API PKINIT request generates [@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. The companion `Invoke-RunAsWithCert` PowerShell tool generates AS-REQ messages via the Windows API itself, producing requests structurally identical to legitimate enterprise PKINIT authentication and bypassing the fingerprint-based detection [@synacktiv-runascert-gh][@deepwiki-runascert]. Aura Security's follow-on writeup confirms the technique against the current MDI version and walks through modifying Certipy to produce matching AS-REQ shapes [@aurainfosec-mdi-pkinit]. The partial mitigation in 2026 is the additional posture-side coverage in the nine MDI Certificates assessments, which closes some of the configurations the offensive tools target [@mslearn-mdi-certificates-posture]. The runtime detection arms race continues.
**Open Problem 2 -- the graph-layer transition from SAM-R LMP to Identity Explorer.** Section 6.4 covered the deprecation of SAM-R-based LMP discovery in May 2025 (MC1073068) and the two replacement surfaces: the Defender XDR attack-path exploration driven by Defender for Cloud's CSPM engine, and the April 2026 Identity Explorer Preview on the Sentinel data lake [@handsontek-mc1073068][@mslearn-defenderforcloud-attack-path][@mslearn-mdi-whats-new][@mslearn-xdr-hunting-graph]. The honest open question is whether either surface reproduces, in 2026, the operator workflows the seven-year-old SAM-R-derived LMP report had built up around itself. The Defender XDR hunting graph is richer than the LMP report ever was, but its data model is different; the Identity Explorer is closer in spirit but in Preview rather than GA.
**Open Problem 3 -- the Sentinel data lake correlation and the Identity Explorer GA path.** Microsoft Sentinel data lake, the cross-product cold-storage and analytics layer, went public preview in 2025 and ships with up to 12 years of retention in Parquet format, a clean separation of storage and compute, and KQL plus Jupyter notebook query surfaces [@mslearn-sentinel-datalake][@mstc-sentinel-datalake-preview]. Identity Explorer is the first identity-specific surface built on top of the data lake; it is in Preview as of April 2026 with no GA date published. The open problem is whether the data-lake-tier correlation can match the alert-tier MDI quality for long-running attacker dwell -- the *months between Sapphire Ticket use and discovery* class -- without producing more noise than signal.
**Open Problem 4 -- the MDI evasion research arms race.** Synacktiv's two papers (the sensor primer by Andre and Benassouli in 2022; the PKINIT evasion paper by Andre in 2024) plus the operator notes on alert-timing exploitation that show up in adsecurity.org and SpecterOps content are the public record of the offensive-research community's targeting of MDI specifically [@synacktiv-primer-mdi][@synacktiv-primer-mdi-archive][@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. FalconForce's reverse-engineering of the MDE sensor (via Olaf Hartong's MDE Internals series) is the methodological precedent for the same approach against MDI; the FalconForce blog and the FalconFriday hunting-query repository are the operator-facing primaries [@falconforce-mde-0x02][@falconforce-mde-0x03][@falconforce-blog][@github-falconfriday][@github-olafhartong]. The Charlie Bromberg Sapphire Ticket disclosure (October 2022) is the cryptographic-attack-class research that Section 8's third ceiling rests on [@hackerrecipes-sapphire]. The arms-race property is permanent; the defensive product team's job is to keep the detection-shipping cadence faster than the evasion-shipping cadence, which the cloud rewrite (see Section 5) made structurally possible.
**Open Problem 5 -- the non-Windows directory coverage tail.** MDI covers Active Directory and (via the Microsoft Entra Connect sensor) the on-prem-to-Entra-ID sync surface. Native Entra ID attacks (token theft against Entra ID itself, OAuth consent phishing, Conditional Access bypass) are covered by Defender for Cloud Apps and Entra ID Protection, not by MDI. The boundary between MDI's scope and the adjacent products is operationally meaningful: a SOC operator reading "MDI did not fire" on an Entra-ID-only attack should not conclude the attack went undetected -- another product likely did fire, in another part of the same Defender XDR portal. The unified incident queue stitches the alerts together; the operator's mental model has to know which sensor surface to look at when triaging.
The article does *not* claim "BloodHound CE forced MDI to add ADCS detections in 2024." The framing is parallel evolution: as BloodHound CE expanded ADCS attack-path coverage in 2024-2025, MDI extended its ADCS posture assessments and PKINIT-class runtime detections during the same window. The two product communities watch each other; neither one "forces" the other.
The roadmap is real, the build-out is in progress, and the operator decision in 2026 is not "wait for the perfect product." It is "deploy what works now, and cover the residuals with KQL."
## 10. The MDI Deployment and Triage Playbook
Four lanes, mapped to four operator personas: the architect who designs the sensor footprint, the SOC analyst who triages the alerts, the threat hunter who writes the KQL that fills the gaps, and everyone who needs to know what does not work.
### Lane 1 -- sensor placement and prerequisite hygiene
Deploy the **v3.x sensor on every domain controller running Windows Server 2019 or later**, paired with the MDE agent. The deployment path is the Microsoft Defender portal's migration wizard or the standalone install via the MDE agent's onboarding flow [@mslearn-mdi-deploy-sensor-v3][@modernsec-v3x][@jeffreyappel-v2v3].
Deploy the **v2.x sensor** on every AD FS federation server, every AD CS online issuing certificate authority, and every Microsoft Entra Connect server (both active and staging), unless those roles already run on a domain controller covered by a v3.x sensor with the May 2026 identity-role extension enabled [@mslearn-mdi-prereq-sensor-v2][@mslearn-mdi-whats-new].
Configure the **required Windows audit subcategories** via the Group Policy *Subcategory Settings* path that the MDI event-collection page enumerates -- *Audit Credential Validation*, *Audit Kerberos Authentication Service*, *Audit Kerberos Service Ticket Operations*, *Audit Logon*, *Audit Directory Service Access*, *Audit Computer Account Management*, plus the additional subcategories for AD CS and AD FS roles. The v3.x sensor includes an *Automatic Windows auditing configuration* toggle that uses the Windows LSA audit-policy APIs to set the subcategories directly, eliminating the GPO step [@mslearn-mdi-event-collection].
Set the **MDI Action Account** in the Defender portal. The default is LocalSystem impersonation on the sensor host, which works for response actions targeting AD objects (force password reset, disable user). A gMSA-based Action Account is the alternative for tenants that want least-privilege response identities scoped per workspace [@mslearn-mdi-action-accounts][@mslearn-mdi-remediation-actions]. Avoid configuring the same gMSA across multiple sensor hosts -- the documented anti-pattern is to use one Action Account for DC-side actions only.
Verify the **Microsoft Defender portal role assignments** so that SOC analysts have the correct read-and-respond permissions on identity alerts. The Microsoft Defender for Identity enterprise application (ID `60ca1954-583c-4d1f-86de-39d835f3e452`) is the consent surface for the response actions; tenants that have not granted consent will see "remediation action unavailable" on identity-targeted incidents [@mslearn-mdi-remediation-actions].
### Lane 2 -- alert triage SLAs
The triage matrix maps alert category to response-time target and the named SOC role that owns triage. Numbers below are typical Tier 1 / Tier 2 SOC targets; tune to your environment's incident-response policy.
| Alert category | Response-time target | Owning SOC role | Notes |
|---|---|---|---|
| DCSync, DCShadow, Golden Ticket | 1 hour | Tier 2 (privileged-account-compromise specialist) | Treat as confirmed compromise pending evidence to the contrary |
| AS-REP Roasting, Kerberoasting | 4 hours | Tier 2 | Higher-FP class; verify offending principal pattern before escalation |
| NTLM relay (ESC8 class) | 4 hours | Tier 2 | ADCS-aware; coordinates with CA team |
| Reconnaissance (LDAP / SMB / DNS) | 24 hours | Tier 1 | Highest-FP class; allowlist legitimate scanners |
| Honeytoken activity | 1 hour | Tier 1 plus Tier 2 escalation | Near-zero FP; any hit is investigation-worthy |
Two false-positive cleanup patterns appear in nearly every tenant. The Azure AD Connect Cloud Sync service principal -- `MSOL_` plus an 8-character random suffix -- legitimately performs DRSUAPI-like operations as part of the hybrid identity sync flow, and will fire DCSync-class alerts unless allowlisted. Legitimate vulnerability scanners (Tenable, Rapid7, Qualys) perform authenticated enumeration that triggers the LDAP and SMB reconnaissance alerts; scanner IPs go in an exclusion list per the Defender XDR portal's identity-alert tuning surface.
The **MDI Action Accounts and Remediation Actions** surface lets the responder disable a user, force a password reset, revoke an Entra ID session, or mark an account as compromised -- triggered manually from the alert flow or automatically via the Defender XDR *automatic attack disruption* engine, which requires 99 percent or higher detector precision before taking containment action [@mslearn-xdr-attack-disruption][@mslearn-mdi-remediation-actions][@mslearn-xdr-investigate-users]. Automatic attack disruption is opt-in per containment action; the conservative default leaves analyst confirmation in the loop for password-reset-class actions and automates disable-user only on the highest-precision detector classes.
> **Note:** The cloud-side analytics pipeline aggregates signal across the per-principal baseline window before deciding to emit. Empirically the alert latency is **minutes-cadence, not seconds-cadence**. Incident response runbooks that assume sub-second alert arrival will be wrong; the operator clock starts when the alert hits the Defender XDR queue, which is itself minutes after the wire-side event. Plan for this in the SLA matrix above -- the "1 hour" target for DCSync starts from the alert timestamp, not the attack timestamp, and the attack itself may have happened five or ten minutes earlier. The Microsoft alerts-overview page is explicit that MDI is "not designed to serve as an auditing or logging solution that captures every single operation or activity on the servers where the sensor is installed; it only captures the data required for its detection and recommendation mechanisms" [@mslearn-mdi-alerts-overview].
### Lane 3 -- advanced-hunting queries that fill the gaps
Three structural detectors in KQL form, each one targeting a class the named alerts can miss. Each query names the table, the columns, and the threshold tuning the operator will need.
The **structural DCSync detector** runs against `IdentityDirectoryEvents` and catches the encrypted-channel case the External ID 2006 alert may miss:
```kql
IdentityDirectoryEvents
| where Timestamp > ago(24h)
| where ActionType == "DRSReplicate"
| extend SourceIP = tostring(parse_json(AdditionalFields).SourceIPAddress)
| where SourceIP !in ("10.0.1.10", "10.0.1.11", "10.0.1.12") // tenant DC IPs
| where AccountName !startswith "MSOL_" and AccountName !in ("ADConnectSync")
| project Timestamp, AccountName, SourceIP, TargetDeviceName, AdditionalFields
| order by Timestamp desc
```
Threshold tuning: keep the time window short (24 hours) for daily triage. Cleanup principals (`MSOL_*`, `ADConnectSync`, plus any per-tenant sync identities) go in the `!startswith` and `!in` clauses. The query produces a clean queue of "DRSUAPI replication from a host that should not be doing DRSUAPI." False-positive class: legitimate Azure AD Connect Cloud Sync service principals; resolve by adding the principal to the allowlist.
The **slow-burn Kerberoasting detector** runs against `IdentityLogonEvents` and catches the rate-limited Kerberoast pattern that modern attackers use to stay below the MDI behavioural-baseline threshold:
```kql
IdentityLogonEvents
| where Timestamp > ago(7d)
| where Protocol == "Kerberos"
| where ActionType == "ServiceTicketRequest"
| extend EncType = tostring(parse_json(AdditionalFields).EncryptionType)
| where EncType in ("RC4-HMAC", "DES-CBC-MD5")
| summarize SpnCount = dcount(TargetSpn), SpnList = make_set(TargetSpn) by AccountName, bin(Timestamp, 1d)
| where SpnCount > 5 // tune per tenant baseline
| order by Timestamp desc, SpnCount desc
```
Threshold tuning: the `SpnCount > 5` threshold is the load-bearing knob. Tenants with legitimate operational accounts that request many SPNs per day (privileged service accounts running scheduled tasks across many target hosts) will need a higher threshold and an allowlist. The seven-day window catches the slow-burn pattern that a one-hour window misses.
The **PKINIT-relay structural detector** runs against `IdentityLogonEvents` and watches for AS-REQ with PA-PK-AS-REQ pre-auth coming from unexpected client subnets:
```kql
IdentityLogonEvents
| where Timestamp > ago(24h)
| where Protocol == "Kerberos"
| where ActionType == "InitialAuthentication"
| extend PreAuth = tostring(parse_json(AdditionalFields).PreAuthType)
| where PreAuth == "PA-PK-AS-REQ"
| extend ClientSubnet = strcat(split(IPAddress, ".")[0], ".", split(IPAddress, ".")[1])
| where ClientSubnet !in ("10.0.5", "10.0.6") // legitimate smartcard subnets
| project Timestamp, AccountName, IPAddress, DeviceName, AdditionalFields
| order by Timestamp desc
```
Threshold tuning: PKINIT is legitimate when smartcard logon is in use. Identify the legitimate smartcard-issuing subnets and add them to the `!in` clause. The residual queue is PKINIT from unexpected sources -- the structural pattern behind both the post-ESC8 NTLM-relay class and the Synacktiv `Invoke-RunAsWithCert` evasion class.
Tenants that want the alert and event corpus in their SIEM as well as in Defender XDR should configure the **MDI to Microsoft Sentinel connector** through the Defender XDR-to-Sentinel integration; the connector is auto-enabled when Sentinel is onboarded to the Defender portal [@mslearn-sentinel-defender-connector].
### Lane 4 -- what does NOT work
Five named operator myths, each refuted with a one-paragraph structural reason.
**Myth 1: "MDI without the DC sensor still catches Kerberos attacks via the Entra ID side."** Wrong. The Kerberos protocol layer is on-prem; the analytics require on-DC capture of the AS-REQ / TGS-REQ / AP-REQ exchange. Entra ID's side of the hybrid auth flow does not carry the same protocol detail. A tenant with MDI licensed but the sensor not deployed on the DCs has no Kerberos detection at all -- the licensed state is necessary but not sufficient.
**Myth 2: "Disabling the v2.x sensor on AD FS is fine since it is covered by the DC sensor."** Wrong. The AD FS authentication flow generates federation-side events (SAML assertions, OAuth tokens, the Application and Security event logs that AD FS itself writes) that the DC sensor does not see. AD FS deserves its own sensor unless the AD FS role is collapsed onto a domain controller, in which case the May 2026 v3.x identity-role extension covers it.
**Myth 3: "Defender for Endpoint covers what MDI covers."** Wrong. MDE catches endpoint behaviour -- process creation, file access, network connections, registry writes. MDI catches protocol-level Kerberos, NTLM, LDAP, and DRSUAPI patterns. The two products share an agent surface in the v3.x architecture, but the *signal classes* are different. An MDE-only deployment will not catch a DCSync from a workstation if MDI is not licensed and the sensor is not deployed; the MDE agent on the DC sees the local process activity but not the wire-side replication call's source.
**Myth 4: "MDI alerts are real-time."** Wrong. As Callout in Lane 2 above. The cloud-side batched-emission cadence is minutes-not-seconds, and incident response runbooks need to account for it.
**Myth 5: "MDI requires no tuning."** Wrong. Every environment has unique false-positive patterns from internal tooling that need exclusions. Microsoft ships the default detector thresholds; tenants tune them through the Defender XDR portal's identity-alert configuration surface. A tenant that has not tuned the recon-alert allowlist for its vulnerability scanners will receive far more noise than signal.
Coverage, triage, KQL, and humility about what does not work. The four lanes are the difference between MDI as a licence item on a renewal sheet and MDI as a working part of the SOC's day.
## 11. Frequently Asked Questions and Closing
Six questions that come up every time MDI is on a whiteboard, each in the misconception-removal pattern: wrong answer named first, then refuted.
No. See the *common misreading worth fixing* Callout in Section 4: graph-anchored attack-path evaluation in Microsoft's defensive stack originates in ATA 1.9 (March 2018), and the 2022 anchor in operator memory is the start of the SAM-R-discovery deprecation arc that culminated in MC1073068 in May 2025 [@mslearn-ata-1-9][@handsontek-mc1073068].
Not as one alert per ESC class. The MDI Certificates posture page documents **nine ADCS posture assessments** -- ESC1 (Preview), ESC2, ESC3, ESC4 (template-owner and template-ACL variants), ESC6 (Preview), ESC7, ESC8, ESC11, and ESC15 [@mslearn-mdi-certificates-posture]. The runtime detection surface for the ESC8 NTLM-relay class is the *Suspected NTLM relay attack* alert in the XDR catalogue [@mslearn-mdi-alerts-xdr]. PKINIT-class runtime detection (the post-ESC8 chain) is the AS-REQ encryption-type fingerprint that Synacktiv documented and partially evaded; the August 2023 AD CS sensor release is the prerequisite for posture coverage [@mstc-adcs-sensor][@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. Coverage is "nine posture assessments plus one runtime alert," not "one alert per ESC1 through ESC15."
Microsoft has never published the canonical list; community reverse-engineering is the only source. See the *honest provenance of the ETW provider list* Aside in Section 5 for the full provenance (Synacktiv's November 2022 primer; Olaf Hartong's FalconForce MDE Internals 0x02 methodology; the Get-TraceLoggingMetadata + Sealighter toolchain) and the snapshot-not-ground-truth framing [@synacktiv-primer-mdi][@falconforce-mde-0x02].
In the cloud since Azure ATP went GA in March 2018 [@mstc-azureatp-ga][@mstc-azureatp-intro]. The on-DC sensor is a thin parser that captures Kerberos / NTLM / LDAP / DRSUAPI on the wire, parses the protocols into structured events, and streams the parsed signal to the multi-tenant cloud backend over HTTPS. The detection logic, the per-principal behavioural baselines, and the alert-emission pipeline all run in the cloud. The legacy on-prem ATA Center model ended with Azure ATP; ATA itself shipped its last release (1.9.3) in September 2020 and Extended Support ends January 2026 [@mstc-ata-eol][@atadocs-versions].
No. The framing is parallel evolution, not a "forcing" relationship. BloodHound CE expanded ADCS attack-path coverage substantially in 2024 and 2025; during the same window MDI extended its ADCS posture assessment surface and added the AD CS sensor release in August 2023 [@mstc-adcs-sensor][@dirteam-sander-aug2023]. Both product communities watch each other -- the Defender team uses BloodHound to red-team its own environments, the SpecterOps team uses MDI when consulting in enterprise Microsoft shops -- but the causal claim "BloodHound forced MDI" is not supported by the public release record. The two communities' work has been concurrent and mutually informing.
Almost. The MITRE-aligned alert catalogue in Section 6.2 covers the most-prevalent offensive primitives. Section 8 names the five structural ceilings that remain by-construction unclosable; *almost* is the load-bearing word.
Friday, 14:35. The watcher on the domain controller has written three named alerts into the Defender XDR queue. The red-team contractor's `Rubeus.exe asreproast` fired *Suspected AS-REP Roasting attack* (T1558.004). The junior auditor's `bloodhound-python -c All` fired *Security principal reconnaissance (LDAP)*. The Mimikatz DCSync against the SQL host's service account fired *Suspected DCSync attack -- replication of directory services*, External ID 2006, T1003.006. Three alerts. Three MITRE technique IDs. Three rows in a Tier 1 analyst's queue.
The watcher's job is done. Whether the analyst opens the right one first, whether the Tier 2 escalation happens inside the one-hour SLA, whether the response action gets approved before the attacker has moved on -- none of that is MDI's problem to solve. It is yours.