Parag Mali - tag: attack-paths

Microsoft Defender for Identity: The Defensive AD Stack That Sees What BloodHound Maps

noreply@paragmali.com (Parag Mali) — Wed, 27 May 2026 00:00:00 GMT

**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 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 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. 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 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 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].

Microsoft has never published the canonical list of Event Tracing for Windows providers that the MDI sensor subscribes to. Any specific list of providers a reader encounters traces back to community reverse-engineering: Synacktiv's *A primer on Microsoft Defender for Identity* by Guillaume Andre and Mickael Benassouli (November 2022) is the canonical operator-research primary [@synacktiv-primer-mdi][@synacktiv-primer-mdi-archive]. The methodological precedent is Olaf Hartong's *Microsoft Defender for Endpoint Internals* series, specifically the 0x02 entry on audit settings and telemetry, which documents the binary-side enumeration approach: run Matt Graeber's Get-TraceLoggingMetadata script against the sensor executable to enumerate the providers it registers, then use Sealighter to trace those providers to a file for further analysis [@falconforce-mde-0x02][@gist-tracelogging-metadata][@github-sealighter]. Hartong's 0x02 article reports "roughly 111 public and MDE-exclusive providers used" by MsSense.exe -- the MDI sensor binary is amenable to the same technique, and the provider mix differs (MDI subscribes heavily to LDAP, Kerberos, DRSUAPI, and SAM-R-class providers; MDE subscribes heavily to process, file, network, and image-load providers) but the methodology is shared [@falconforce-mde-0x03][@github-olafhartong]. Read any community-published MDI provider list as a snapshot of what the community has reverse-engineered, not as Microsoft-published ground truth. 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.

// 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 [@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 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 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. The Sapphire Ticket attack obtains a target principal's PAC via the S4U2self plus User-to-User PAC-copy technique -- a Kerberos protocol flow Microsoft published as part of MS-SFU and MS-KILE -- which extracts a genuine PAC into a usable form without ever needing to authenticate as the target. The attacker then forges a new ticket whose PAC is the captured PAC, encrypted with the stolen `krbtgt` key. The mechanical sequence is: S4U2self against the target produces a ticket containing the target's PAC; the U2U flow lets the attacker decrypt the embedded PAC blob; the attacker then mints a fresh TGT around that PAC with the genuine signing key. The KDC's signature checks pass because the signing key is real, and the PAC's structural fields pass because they were lifted from a ticket the genuine KDC just issued. Only the original credential compromise that produced the `krbtgt` hash leaves a trail.

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:

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:

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:

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.

AD Is a Graph: How BloodHound Made Defenders Think Like Attackers

noreply@paragmali.com (Parag Mali) — Tue, 26 May 2026 00:00:00 GMT

**AD is a graph.** In April 2015 John Lambert named the missing model in two sentences. In August 2016 Andy Robbins, Rohan Vazarkar, and Will Schroeder shipped the tool that made it operational: BloodHound treats Active Directory as a directed graph of privilege relationships, queries it with Neo4j's Cypher, and turns weeks of red-team whiteboard work into a 200 ms shortest-path lookup. By November 2024 Microsoft itself shipped the same mental model as Microsoft Security Exposure Management. This article is half tool history (1998 academic attack graphs through OpenGraph 2025) and half graph-theory exposition: property graphs, BFS shortest paths, the edge taxonomy, and the open problem of *weighting* what is currently treated as one BFS hop per privilege.

1. How do I get from this user to Domain Admin?

In 2014, a red-team analyst with a help-desk account inside a 40,000-user Active Directory forest asks the question every red-team analyst asks: is there a path from here to Domain Admins? The answer takes two analysts five days of PowerView scripts, hand-drawn whiteboard diagrams, and per-host RDP probing. The same question in 2024 is a ninety-character Cypher query that returns in 200 milliseconds.

What happened in those ten years is the story of one sentence -- defenders think in lists, attackers think in graphs -- becoming, in turn, a tool, a discipline, and a Microsoft product.

The 2014 reality was a stack of CSV files. PowerView, the PowerShell enumeration toolkit Will Schroeder first published in August 2014 [@powersploit-repo], could dump every group membership, every Access Control Entry, and every active session from a low-privilege account [@powertools-powerview]. The outputs were rows. Hundreds of thousands of rows. Composing them into a coherent attack path was a job for a marker and a whiteboard, and the join keys were Distinguished Names that wrapped twice across an analyst's notebook page. Five days to map a single 40,000-user forest was not unusual. It was the price of doing business.

The 2024 reality is a query. The analyst loads SharpHound's JSON dump into a Neo4j graph, opens the BloodHound web interface in a browser, types

MATCH p = shortestPath(
  (u:User {name:'HELPDESK@CORP.LOCAL'})-[*1..]->(g:Group {name:'DOMAIN ADMINS@CORP.LOCAL'})
) RETURN p

and clicks Run. The graph renders. The shortest path is highlighted. The pivot points are circled. Time elapsed: 200 milliseconds on the database, plus a second for the browser to draw the SVG [@bloodhound-ce-repo].

Whatever happened in those ten years has to be more than a software release. It has to be a change in how the entire community models the problem. The change has a date and a sentence. Both arrived in April 2015. Let us start with the sentence.

2. From ACL lists to graphs -- why the model matters

An access-control list is not the same as a graph -- and the difference is everything.

Consider five accounts in a hypothetical CORP.LOCAL forest. Bob, a help-desk operator, has been granted ForceChangePassword on Carol's account by a long-departed administrator who once needed to delegate password resets. Carol is a member of Server Operators. Server Operators, by default, can log on locally to Domain Controllers and back up the directory database. The Domain Controller hosts the krbtgt account.

Three rows in three different audit reports. One attack path.

A per-object Access Control List audit looks at Bob's row, sees a ForceChangePassword ACE, and flags it as "an over-broad delegation." It looks at Carol's row, sees that she belongs to Server Operators, and flags it as "a privileged group membership." It looks at the Domain Controller and sees that Server Operators has logon rights, which is the default. Nothing in the audit composes the three facts. Reachability is not a property the report computes.

A set of nodes (vertices) and directed edges (arrows) between them. Each edge points from one node to another. A *path* is a sequence of edges that can be traversed in the direction of their arrows. A node B is *reachable* from a node A if some path leads from A to B. A property of two nodes A and B in a directed graph: B is reachable from A if there exists a sequence of edges leading from A to B, regardless of length. Reachability is fundamentally a graph property and cannot be answered by inspecting any single edge in isolation.

Now draw the same five accounts as a directed graph. Bob is a node. Carol is a node. Server Operators is a node. The Domain Controller is a node. The krbtgt account is a node. There is an edge from Bob to Carol labelled ForceChangePassword. There is an edge from Carol to Server Operators labelled MemberOf. There is an edge from Server Operators to the Domain Controller labelled CanRDP. There is an edge from the Domain Controller to krbtgt labelled DCSync. Trace the arrows. Bob can reach krbtgt.

The graph form makes reachability visually obvious. The list form does not. This is not a presentation difference. It is a data-model difference, and it is the difference that decides whether a tool can answer the question "is there a path from A to B?" at all.

Key idea: Reachability is a property of the graph that the list does not, in general, express. This is not a UX difference. It is a data-model difference, and it is the entire reason BloodHound exists.

The sentence that named this gap appeared on April 26, 2015. John Lambert, then a Distinguished Engineer in the Microsoft Threat Intelligence Center, published a short essay to a personal GitHub repository [@lambert-2015-defenders-lists-attackers-graphs]. No peer review. No formal venue. Two declarative opening sentences that every defender attack-path product since has cited approvingly.

Defenders don't have a list of assets -- they have a graph. Assets are connected to each other by security relationships. As long as defenders use a list and attackers use a graph, attackers win. -- John Lambert, April 26, 2015.

Lambert then enumerated five concrete classes of "security dependencies" that constitute edges in any real network: shared local-admin passwords; logon scripts on file servers; print-driver propagation from print servers; certificate authorities that mint smart-card logon certificates; and database administrators who run code as a privileged DB process. The essay closed with a defender prescription: "The first step is to visualize your network by turning your lists into graphs."

If the diagnosis is so obvious in retrospect, why was every mainstream AD audit tool from 2000 through 2015 list-shaped? The answer is that the academic literature had the right model but the wrong substrate, and the operator community had the right substrate but the wrong model. The two did not meet until April 2015.

3. Attack graphs before BloodHound, 1998 to 2015

The phrase attack graph is older than Active Directory itself.

In September 1998, two researchers at Sandia National Laboratories presented a paper titled A Graph-Based System for Network-Vulnerability Analysis at the New Security Paradigms Workshop in Charlottesville, Virginia. The authors, Cynthia Phillips and Laura Painton Swiler, proposed that a network's worst-case attack was a graph traversal problem [@phillips-swiler-1998-nspw]. Nodes encoded network states (the set of attacker privileges across the set of hosts). Edges encoded atomic attack steps (an exploit that, given prerequisite privileges, granted new ones). The shortest path from "attacker outside the network" to "attacker has goal asset" was the worst-case attack.

Phillips and Swiler observed in a now-canonical sentence that "the security of a network is more than the sum of the security of its hosts." It is the conceptual ancestor of every attack-path tool that followed.

Four years later, at IEEE Symposium on Security and Privacy 2002, Oleg Sheyner (then a CMU PhD student) along with Joshua Haines and Richard Lippmann (MIT Lincoln Lab), Somesh Jha (Wisconsin), and Jeannette Wing (CMU) made the construction automatic [@sheyner-et-al-2002-attack-graphs]. They encoded the network and attacker model as an NuSMV model-checker specification, treated the negation of the security goal as a temporal-logic property, and let the model checker generate every counterexample. The union of counterexamples was the attack graph.

They also proved that the minimum set of edges whose removal disconnects the attacker from the goal is NP-hard, but admits an O(log n) approximation -- the first asymptotic bound for the defender-hardening problem.

Sheyner's companion 2004 thesis -- Scenario Graphs and Attack Graphs, CMU-CS-04-122 -- remains the most readable book-length treatment of the academic-attack-graph generation [@sheyner-2004-thesis].

By 2005 the academic line had a scale solution. Xinming Ou, Sudhakar Govindavajhala, and Andrew Appel at Princeton released MulVAL at USENIX Security 2005 [@mulval-usenix-2005], encoding network state and attacker rules as Datalog facts and running them through XSB Prolog. From the paper's abstract: "Once the information is collected, the analysis can be performed in seconds for networks with thousands of machines." NetSPA at MIT Lincoln Lab (2006) and TVA / CAULDRON at George Mason (2003 to 2005) achieved similar scale through different mechanisms.

In parallel, on the Windows operator side, Sean Metcalf was running adsecurity.org and documenting AD misconfiguration patterns one writeup at a time [@adsecurity-org]. Microsoft was rolling out its Enhanced Security Administrative Environment ("Red Forest") tiered-administration model -- the predecessor that the Enterprise Access Model later replaced [@ms-enterprise-access-model] -- which was implicitly graph-aware (the entire ESAE prescription is a tier diagram) but never exposed the tier graph as a queryable structure. ESAE was a deployment blueprint, not a tool.

gantt title Three parallel tracks converging on the attack-path graph dateFormat YYYY axisFormat %Y

section Academic CVE line
Phillips and Swiler NSPW   :a1, 1998, 1999
Sheyner et al. IEEE SP     :a2, 2002, 2003
MulVAL USENIX              :a3, 2005, 2006
NetSPA TVA                 :a4, 2006, 2008

section Windows operator line
adsecurity.org writeups    :b1, 2014, 2016
PowerView                  :b2, 2014, 2016
Lambert essay              :milestone, b3, 2015-04-26, 1d
BloodHound DEF CON 24      :b4, 2016, 2018
AzureHound BloodHound 4.0  :b5, 2020, 2023
BloodHound CE 5.0          :b6, 2023, 2024
ADCS attack paths          :b7, 2024, 2025
Butterfly v6.3             :b8, 2024, 2026
OpenGraph v8.0             :b9, 2025, 2026

section Microsoft defender stack
ESAE Red Forest blueprint  :c1, 2015, 2018
Azure ATP LMPs preview     :c2, 2018, 2020
Defender CSPM attack paths :c3, 2022, 2024
MSEM GA                    :milestone, c4, 2024-11-19, 1d

The April 2015 essay sat between the two tracks. Lambert was inside Microsoft. He had read the academic literature. He worked next to the threat-intelligence teams who watched real intrusions unfold. The essay was the moment the two communities' vocabularies met. The diagnosis was right. The cure was sixteen months away. It would not come from Microsoft, and it would not come from academia. It would come from a red-team consultancy and a free graph database, and it would debut on a Saturday in August at a hacker convention in Las Vegas.

4. Defenders evaluating Active Directory as a list of ACLs

If you were a Microsoft-aligned AD security engineer in 2013, your job was to read ACLs. One object at a time. Down a list.

The mainstream defender toolchain of the era was, almost without exception, list-shaped. Microsoft shipped dsacls.exe and PowerShell's Get-Acl; both produced row-oriented output that an analyst read sequentially. The commercial AD-audit market -- NetWrix Auditor [@netwrix-auditor], ManageEngine ADAudit Plus [@manageengine-adaudit-plus], Quest ActiveRoles [@quest-activeroles], and others -- produced HTML reports with one section per directory object, one row per non-default Access Control Entry, and severity classifications based on a fixed checklist of "dangerous rights" (GenericAll, WriteDacl, WriteOwner, and a handful of others).

Microsoft's own Best Practices for Securing Active Directory document codified this approach. Its central recommendation was per-object delegation review: walk the directory tree, evaluate each object's ACL against a hardening checklist, and remediate non-default ACEs that exceed the documented privilege model [@ms-best-practices-ad]. The document is excellent at what it sets out to do. What it does not do -- because the format does not permit it -- is compose multi-hop reachability.

This was the failure mode Lambert described. A help-desk operator with ForceChangePassword on a junior service account appears as one row in the audit. The junior service account's MemberOf Server Operators membership appears in a different report section. The Server Operators group's logon rights on the Domain Controller appear in the Domain Controller's own report. Three findings in three places, with no machinery to compose them. The data model cannot represent the question.

A reader trained on Phillips and Swiler, Sheyner et al., MulVAL, NetSPA, and TVA might object that *the field already had* graph-based attack-path analysis a decade before BloodHound. True -- in academia. The academic line solved the scale problem (MulVAL: *"seconds for networks with thousands of machines"*) but spoke the wrong vocabulary. Its atomic attack step was a CVE exploit -- a buffer overflow, a format-string bug, a daemon remote code execution. The dominant AD attack primitive is not a CVE. A user with `WriteDacl` on a group is not exploiting any vulnerability; they are using the system as designed. None of MulVAL, NetSPA, or TVA developed an AD-style privilege-graph input format, and the operator community never adopted them. The academic line was substrate-mismatched and delivered as research-PDF tarballs rather than as `git clone`-able tools.

Two communities, both wrong in different ways. The academic one had the right algorithm with the wrong substrate. The operator one had the right substrate with no algorithm at all. The fix was to fuse them. That happened on August 6, 2016.

5. The breakthrough -- BloodHound and Six Degrees of Domain Admin

Saturday, August 6, 2016. 1:00 PM. DEF CON 24, Track 2, Paris and Bally's hotel-casinos in Las Vegas [@defcon-24-archive]. Three speakers from Veris Group's adaptive threat division step on stage: Andy Robbins, Rohan Vazarkar, Will Schroeder. The talk is titled Six Degrees of Domain Admin: Using Graph Theory to Accelerate Red Team Operations [@defcon24-bloodhound-slides]. The Veris Group team would spin out as SpecterOps the following year, but the August 2016 attribution -- Robbins (@_wald0), Vazarkar (@CptJesus), and Schroeder (@harmj0y) -- is the canonical one [@bloodhound-legacy-repo].

The talk demonstrated three design decisions that in retrospect look obvious and at the time were not.

First, model Active Directory as a directed property graph. Nodes are typed security principals (User, Computer, Group, Domain, OU, GPO). Edges are typed privilege relationships (MemberOf, AdminTo, HasSession, GenericAll, GenericWrite, WriteDacl, ForceChangePassword, and others). This was Lambert's framing made concrete: every ACE that grants a dangerous right becomes an edge from the trustee to the target.

Second, reuse Neo4j as the engine. Do not build a custom graph database; piggyback on Cypher's pattern-matching query language. The cost of building a path-finding engine from scratch was non-trivial; the cost of standing up Neo4j was a single Docker container.

Third, ship a collector that emits typed JSON edges, not raw NTSecurityDescriptors. The collector's value is the interpretation of an ACE as a graph edge -- the mapping from a binary security descriptor to the typed edge that says "trustee X has GenericWrite on object Y" is the hard part, and a defender re-creating that mapping per query would lose. SharpHound (initially SharpHound.ps1, then a C# binary) does the interpretation once at collection time and writes the edges to disk [@bloodhound-ce-repo].

SharpHound's enumeration calls are visibly descended from PowerView. The November 2020 SpecterOps blog announcing BloodHound 4.0 acknowledges the lineage explicitly, naming Schroeder's joint authorship of both projects and crediting PowerView as the data-collection precursor [@specterops-2020-bloodhound-4]. PowerView's August 2014 release was the substrate that made BloodHound's August 2016 synthesis possible. The chain is unbroken: enumeration in 2014, framing in April 2015, graph synthesis in August 2016.

The five-day-of-whiteboard-work figure comes from the SpecterOps team's own internal benchmark from the original DEF CON 24 talk. The 200 ms query latency is the typical 2024 figure on a mid-size enterprise forest of roughly 10^5 nodes and 10^6 edges, retained as the company's marketing framing across subsequent blog posts.

Key idea: BloodHound's breakthrough was neither an algorithm nor an architecture. It was the decision to interpret Active Directory's access-control data as a typed graph and ship that interpretation as a tool the operator community could actually run.

Crucially, the choice to use Neo4j's free shortestPath() function rather than building a custom path-finder was a delivery decision as much as a technical one. Neo4j already did breadth-first shortest paths. The team did not need to invent anything. The hard work was in the edge taxonomy and the collector, not in the graph database.

The talk made a promise the rest of the article must now cash: that there is a real algorithm under the hood, that the algorithm has a name, and that the name is not Dijkstra.

6. The algorithmic core -- property graphs, Cypher, and shortest paths

If you have never written a Cypher query in your life, the next ninety seconds is the entirety of the syntax you need.

A graph in which both nodes and edges are typed and can carry key-value properties. A node might have type `User` and properties `name='BOB@CORP.LOCAL'`, `enabled=true`, `pwdlastset=1719234234`. An edge might have type `GenericWrite` and properties `source='ACE'`, `isacl=true`. This is the data model Neo4j implements and the model BloodHound uses.

A Cypher pattern is a parenthesised node, a bracketed edge, and a parenthesised node, with arrows showing direction. (u:User)-[:MemberOf]->(g:Group) reads "find a node u of type User connected by a MemberOf edge to a node g of type Group." A full query has four parts: MATCH for the pattern, optional WHERE for filters, RETURN for the output. That's it.Cypher patterns visually mimic ASCII graph drawings: parentheses are nodes, square brackets are edges, and the arrow direction matches the edge direction. The syntax was deliberately designed to look like the diagram you would sketch on a whiteboard.

The pattern-matching query language originally created for the Neo4j graph database. Cypher's syntax is declarative: you describe the shape of the data you want, and the engine plans the traversal. Since April 2024 Cypher has been the basis of the ISO/IEC 39075:2024 GQL standard -- the first ISO-standardised graph query language [@iso-39075-2024-gql] [@opencypher-home].

Here is the canonical BloodHound query, with annotations:

MATCH p = shortestPath(
  (u:User {name:'BOB@CORP.LOCAL'})       // start node: Bob
    -[*1..]->                            // any number of typed edges
  (g:Group {name:'DOMAIN ADMINS@CORP.LOCAL'})  // end node: Domain Admins
)
RETURN p

The shortestPath() wrapper tells Neo4j to short-circuit at the first solution. The variable-length quantifier [*1..] says "one or more edges of any type." The p = binds the entire matched path to the variable p, which the RETURN then emits as a sequence of node-edge-node triples that the BloodHound frontend renders as an SVG.

What does shortestPath() actually run? Here is where the misconception that BloodHound uses Dijkstra needs to die. The current Neo4j Cypher manual is explicit that shortestPath() runs an unweighted bidirectional traversal -- BFS in the classical sense -- between the source and target nodes [@neo4j-cypher-shortest-paths]. Not Dijkstra. Not A*. BFS.

A graph-traversal algorithm that explores all nodes at the current depth before proceeding to the next depth. Starting from the source, it visits all 1-hop neighbours, then all 2-hop neighbours, and so on. For unweighted graphs, BFS is guaranteed to find a shortest path (in number of edges) the first time it reaches the target. Worst-case time is O(V + E) where V is the node count and E is the edge count -- the trivial information-theoretic lower bound for any algorithm that must read the input.

Cypher does support weighted shortest paths via the Neo4j Graph Data Science library, but the BloodHound CE distribution does not enable it. There is no natural cost metric on Active Directory privilege edges in 2026; every edge is treated as one hop.

Why BFS rather than Dijkstra? Dijkstra is BFS's generalisation to weighted graphs. If your edges have natural costs -- road distances, link latencies, dollar prices -- Dijkstra (with a Fibonacci heap, $O(E + V\log V)$) gives you shortest paths under that cost metric. Active Directory privilege edges do not have a natural cost metric. MemberOf, GenericAll, and CanRDP are all "the attacker can take this step." Some are easier than others, but quantifying how much easier is itself an unsolved problem (see Section 11). Treating every edge as one hop is the load-bearing simplification that makes the model tractable.

Of a binary relation R: the relation R+ that contains the pair (a, c) whenever there is a chain a R b R ... R c. For a graph, the transitive closure tells you, for every pair of nodes, whether one is reachable from the other. BloodHound's `shortestPath()` queries can be thought of as on-demand evaluation of the transitive closure restricted to one source-target pair.

The per-query complexity is $O(V + E)$, the standard BFS bound from any algorithms textbook. On a mid-size enterprise forest -- roughly 10^5 nodes and 10^6 edges -- a single user-to-group shortest path returns in sub-second wall-clock time.

The variable-length quantifier [*1..N] for general path enumeration is a different matter. Cyclic graphs admit exponentially many paths in N, and Neo4j's documentation explicitly warns that quantified path patterns can return exponentially many results in the worst case [@neo4j-cypher-variable-length]. The shortestPath() short-circuit avoids this by returning on the first hit; allShortestPaths() enumerates only paths tied for shortest; unbounded enumeration is intractable on any non-trivial graph.

A concrete demonstration is in order. The runnable snippet below is a 35-line implementation of unweighted BFS over a six-node toy graph. It returns the shortest path from a helpdesk user to the domain-admin group. This is, structurally, the same algorithm Neo4j's shortestPath() runs. The numerical answer ("path of length 4") is the same number BloodHound would report on the same graph.

{` // Edges modelled as a typed adjacency list. const edges = { helpdesk: [{ to: 'carol', via: 'ForceChangePassword' }], carol: [{ to: 'serverops', via: 'MemberOf' }], serverops: [{ to: 'dc01', via: 'CanRDP' }], dc01: [{ to: 'krbtgt', via: 'DCSync' }], krbtgt: [{ to: 'domain-admin', via: 'GoldenTicket' }], domain_admin: [] };

function shortestPath(start, goal) { const queue = [[start]]; // queue holds candidate paths const seen = new Set([start]); // each node enqueued at most once

while (queue.length) { const path = queue.shift(); // BFS = FIFO const node = path[path.length - 1]; if (node === goal) return path; for (const e of (edges[node] || [])) { if (!seen.has(e.to)) { seen.add(e.to); queue.push([...path, e.to]); } } } return null; // unreachable }

const path = shortestPath('helpdesk', 'domain-admin'); console.log('Path:', path.join(' -> ')); console.log('Length:', path.length - 1, 'hops'); `}

The algorithm fits on a single screen. The hard work of BloodHound is not in this loop. The hard work is in deciding which edges to insert into the graph in the first place. That decision -- the edge taxonomy -- is what makes BloodHound a security tool rather than a graph-database demo.

sequenceDiagram participant Client as Cypher client participant Planner as Cypher planner participant Engine as BFS engine participant Graph as Property graph Client->>Planner: MATCH shortestPath(u to g) Planner->>Engine: plan(start=u, end=g, bidirectional=true) Engine->>Graph: expand 1-hop frontier from u Engine->>Graph: expand 1-hop frontier from g Graph-->>Engine: neighbours of u, neighbours of g Engine->>Graph: expand 2-hop frontier (both sides) Engine->>Graph: expand 3-hop frontier (both sides) Graph-->>Engine: frontiers intersect at node m Engine-->>Planner: reconstruct path u to m to g Planner-->>Client: return path

7. The edge taxonomy -- what Active Directory actually looks like as a graph

The BloodHound graph is not every privilege relationship in Active Directory. It is the set of relationships that the SpecterOps team has decided -- by iterative discovery, often in response to specific community-reported abuse primitives -- to model. The taxonomy has grown roughly monotonically since 2016; the rate has accelerated since the BloodHound CE 5.0 reboot in August 2023 [@specterops-2023-bloodhound-ce].

Eight families dominate the 2026 graph. They map, family by family, onto the substrates of a modern hybrid enterprise.

1. Group membership. MemberOf is the simplest edge. Cypher's variable-length quantifier ([:MemberOf*1..]) walks transitive memberships in one expression, which is why nested-group reachability is a one-liner.

2. ACL write-equivalents. GenericAll, GenericWrite, WriteDacl, WriteOwner, Owns, AllExtendedRights, ForceChangePassword, AddSelf, AddMember, and AddKeyCredentialLink (the shadow-credentials primitive). Each names a specific dangerous-right pattern on a directory object's security descriptor. SharpHound's interpreter scans the nTSecurityDescriptor attribute and emits one typed edge per matching ACE.

3. Sessions. HasSession is the dynamic edge that goes stale fastest. SharpHound enumerates active sessions via NetSessionEnum and SAMR; the resulting edges describe "user U is currently logged into computer C." The graph is whatever the most recent collection captured.

4. Remote execution rights. AdminTo, CanRDP, ExecuteDCOM, CanPSRemote, SQLAdmin. Each describes a code-execution primitive granted to a principal on a computer object.

5. Kerberos delegation. AllowedToDelegate (constrained delegation), AllowedToAct (resource-based constrained delegation, via msDS-AllowedToActOnBehalfOfOtherIdentity), unconstrained delegation surfaced as node properties on Computer objects, and -- from BloodHound CE v6.3 in December 2024 [@bloodhound-v6-3-release] -- a CoerceToTGT edge that replaces the older UnconstrainedDelegation finding for BHE customers.

6. ADCS edges (early-access January 2024). ADCSESC1 through ADCSESC10, plus the CoerceAndRelayNTLMToADCS edge for ESC8 [@specterops-2024-adcs-bloodhound]. These edges land in BloodHound roughly thirty months after Will Schroeder and Lee Christensen first published the ESC1 to ESC8 catalog in Certified Pre-Owned: Abusing Active Directory Certificate Services [@specterops-2021-certified-preowned]. Each ADCS edge in BloodHound is the most complex in the taxonomy because each is composed from multiple raw facts (see the traversable / non-traversable discussion below).

7. Azure / Entra ID edges (via AzureHound, November 20, 2020) [@specterops-2020-bloodhound-4]. AZGlobalAdmin, AZRoleAssignment, AZContains, AZOwns, AZUserAccessAdministrator, AZAddSecret, AZMGAddOwner, plus AzureRM-side resource roles. Microsoft Entra Privileged Identity Management (PIM) role coverage was added in BloodHound v8.0 in July 2025 [@specterops-2025-opengraph].

8. OpenGraph custom edges (v8.0, July 29, 2025). User-defined edges for arbitrary substrates: GitHub, Snowflake, Microsoft SQL Server, ServiceNow, Tailscale, Duo. The schema is intentionally generic so that a community contributor can ship edges for any system whose privilege model can be drawn as a graph [@bloodhound-opengraph-library].

Family	Representative edges	Underlying AD mechanism	What it gives the attacker
Group membership	`MemberOf`	`member` attribute on group object	Inherits all permissions held by the group
ACL write-equivalents	`GenericAll`, `GenericWrite`, `WriteDacl`, `WriteOwner`, `ForceChangePassword`, `AddKeyCredentialLink`	Specific dangerous-right ACE patterns in `nTSecurityDescriptor`	Take control of the target principal (reset password, modify object, plant shadow credentials)
Sessions	`HasSession`	`NetSessionEnum` and `SAMR` enumeration on member computers	Pivot via credential theft from the logged-in user's memory
Remote execution	`AdminTo`, `CanRDP`, `ExecuteDCOM`, `CanPSRemote`, `SQLAdmin`	Local-admin membership, RDP / DCOM / WinRM / SQL group rights	Run arbitrary code as the target principal on the target host
Kerberos delegation	`AllowedToDelegate`, `AllowedToAct`, `CoerceToTGT`	Constrained and resource-based delegation attributes	Forge service tickets and impersonate other accounts
ADCS composite	`ADCSESC1` through `ADCSESC10`, `CoerceAndRelayNTLMToADCS`	Certificate template misconfigurations plus CA trust plus enrollment ACEs	Obtain a certificate usable for authentication as a privileged account
Azure / Entra	`AZGlobalAdmin`, `AZRoleAssignment`, `AZAddSecret`, `AZOwns`, `AZMGAddOwner`	Entra role assignments, AzureRM RBAC	Cross the on-prem to cloud boundary; pivot via tenant or subscription privileges
OpenGraph	User-defined	Any substrate the contributor models	Anything the contributed schema encodes

The ADCS family deserves a closer look because it introduced an important new modelling vocabulary.

A *traversable* edge is one the shortest-path query can step through directly: `MemberOf`, `ForceChangePassword`, `CanRDP`. A *non-traversable* edge is a precondition relationship that is only exploitable when several others appear together. A certificate template's `Enroll` ACE is non-traversable on its own; combined with eight other facts about the template, the issuing CA, and the domain's trust posture, it composes into `ADCSESC1`. The post-processor scans for the full pattern and synthesises a single traversable edge that the BFS can then treat as one hop [@specterops-2024-adcs-bloodhound].

For ESC1 the pattern has nine numbered prerequisites: six template and CA requirements, two enterprise-CA trust facts, and one implicit constraint. None of the nine raw facts is exploitable in isolation. All nine together are. The post-processor's job is to walk the candidate sub-graphs, check every requirement, and write the composed ADCSESC1 edge when the pattern holds.

This is a non-trivial graph-modelling contribution because it gives the field a vocabulary for "an edge that is real only as a join over several facts." It also generalises beyond ADCS: any future attack primitive composed from a fixed pattern of raw facts can be modelled the same way.

ESC8 -- the NTLM relay primitive against an HTTP-enrollment certificate authority -- is the most delicate case, and the one most commonly mis-modelled in early secondary writeups.

Note: The CoerceAndRelayNTLMToADCS edge is a Group(Authenticated Users) to Computer(coerced target) edge, not a Computer to Computer edge as some early secondary writeups described. The relay-target CA and the certificate template are carried as edge metadata, not as additional graph nodes. The canonical edge documentation is explicit: Source: Authenticated Users [Group] / Destination: Computer / Traversable: Yes [@bloodhound-coerce-relay-edge].

The schema correction matters because the source-principal choice affects every shortest-path query that crosses ESC8. If the edge is mis-modelled as Computer to Computer, queries that begin from a low-privilege user account miss the path entirely. The Group-to-Computer schema correctly captures that any authenticated principal can coerce.

What the graph does not yet model is also worth naming. The SpecterOps/TierZeroTable README states it verbatim: "DISCLAIMER: The table does not include all Tier Zero assets yet." [@specterops-tier-zero-table] Several edge classes remain partially or fully out of scope; the full enumeration appears in Section 11 (open problems). Coverage expansion is iterative and community-fed; OpenGraph (Section 9) is the structural answer to "where does the graph end?"

flowchart TD subgraph OnPrem["On-prem Active Directory"] Members["MemberOf, Owns"] ACL["ACL write-equivalents
GenericAll, WriteDacl, ForceChangePassword,
AddKeyCredentialLink"] Sessions["HasSession"] Exec["AdminTo, CanRDP, ExecuteDCOM,
CanPSRemote, SQLAdmin"] Krb["Kerberos delegation
AllowedToDelegate, AllowedToAct, CoerceToTGT"] end subgraph Entra["Entra ID and AzureRM"] EntraRoles["AZGlobalAdmin, AZRoleAssignment,
AZAddSecret, AZUserAccessAdministrator,
PIM roles"] AzureRM["AZContains, AZOwns,
AzureRM resource roles"] end subgraph ADCS["ADCS composite edges"] ESC["ADCSESC1 to ADCSESC10,
CoerceAndRelayNTLMToADCS"] end subgraph Open["OpenGraph user-defined"] Custom["GitHub, Snowflake, SQL Server,
ServiceNow, Tailscale, Duo, custom"] end OnPrem --> Cypher((Cypher query layer)) Entra --> Cypher ADCS --> Cypher Open --> Cypher

If this is what one community modelled, the natural question is: what did Microsoft model? And when?

8. The defender adoption -- Microsoft catches up, 2018 to 2024

The defender vendor whose product BloodHound was mapping is also a defender vendor with a graph product of its own. Three of them, in fact, shipped in three different years for three different substrates. They are easy to confuse; press releases sometimes do.

The first arrived on November 27, 2018, when Tali Ash (then a Program Manager on the Azure Advanced Threat Protection team) announced a preview feature called Lateral Movement Paths (LMPs) in a Microsoft tech-community post [@ms-azure-atp-lmp-2018]. LMPs were a graph-shaped visualisation, but a constrained one: restricted to "sensitive accounts" (a configurable set defaulting to Domain Admins and similar) plus non-sensitive accounts that had shared a session on the same host as a sensitive account.

The portal rendered one- and two-hop credential-theft pivots as a static SVG. There was no Cypher equivalent, no LMP-export API, and no way to write a custom query. Azure ATP was rebranded Microsoft Defender for Identity in 2020, and the LMP feature came along under the new name [@ms-mdi-lmp-docs].

Several secondary sources date Lateral Movement Paths to "June 2019," which corresponds to the general-availability and rebrand window rather than the original preview announcement. The primary Microsoft tech-community post is November 27, 2018; treat the year-not-month for any third-party claim and prefer the November 2018 preview date as the canonical first ship.

The second arrived in October 2022, when Microsoft Defender for Cloud's Defender CSPM plan added a cloud security graph with attack-path analysis (public preview at Ignite October 2022; generally available March 28, 2023) [@ms-defender-cloud-attack-path]. This product is a cloud attack-path graph: Azure plus AWS plus GCP asset inventory, with inferred edges for permissions, network reachability, vulnerability presence, and internet exposure. It is explicitly not the Active Directory identity graph; it covers the multi-cloud workload surface.

A common mistake conflates this 2022-2023 product (Defender for Cloud) with Microsoft Defender for Identity (the LMP product from November 2018). The substrate, the team, and the year are all different. Worth flagging here because secondary writeups repeat the confusion often.

The Microsoft Defender XDR product family is a naming minefield. *Defender for Identity* (MDI) is the on-prem AD identity-threat product; LMPs are its graph view. *Defender for Cloud* (MDC) is the multi-cloud workload-protection product; its CSPM plan ships cloud-security-graph attack-path analysis. *Defender for Endpoint* (MDE) is the EDR product; it does not ship its own attack-path graph but feeds telemetry into MSEM. *Microsoft Security Exposure Management* (MSEM, GA November 19, 2024) is the unified exposure-graph layer that subsumes the others. Four products, four substrates, four ship dates. The naming overlap is unfortunate but the distinctions are real.

The third arrived on November 19, 2024, at the Ignite 2024 keynote in Chicago. Satya Nadella, in the opening keynote, announced that Microsoft Security Exposure Management (MSEM) had reached general availability [@ms-ignite-2024-msem]. MSEM is the product whose attack-path model is structurally equivalent to BloodHound's: cross-substrate (identity plus endpoint plus multi-cloud), first-class attack-path objects with choke-point and blast-radius dashboards, and continuous data feed via the Defender XDR signal plane.

Microsoft's unified exposure-graph product, generally available November 19, 2024, at Ignite 2024 in Chicago. MSEM ingests telemetry from Defender for Endpoint, Defender for Identity, Defender for Cloud, Entra ID, and the Defender XDR plane into a single graph. Attack paths are first-class objects with three dashboard views: an attack-path list, choke-point analysis (small sets of nodes whose compromise enables disproportionately many downstream paths), and blast-radius (downstream reach of a selected node) [@ms-msem-attack-paths].

The MSEM docs page introduces the model verbatim: "Attack paths in Microsoft Security Exposure Management help you to proactively identify and visualize potential routes that attackers can exploit using vulnerabilities, gaps, and misconfigurations across endpoints, cloud environments, and hybrid infrastructures." And, on choke points: "By focusing on these choke points, you can reduce risk by addressing high-impact assets."

The query interface is the Defender XDR portal plus KQL (Kusto Query Language), not Cypher. The graph engine is proprietary; Microsoft does not publish per-query latency numbers or the underlying algorithms. But the model -- nodes, typed edges, attack paths as the unit of analysis, choke-point and blast-radius views -- is the model BloodHound shipped at DEF CON 24 in August 2016.

The arc takes eight years. From the August 6, 2016 BloodHound talk to the November 19, 2024 MSEM general-availability announcement is eight years and three months. The defender vendor whose product the original BloodHound was mapping ships a defender product whose attack-path model is structurally equivalent to the one a red-team consultancy shipped in a conference talk eight years earlier.

Microsoft adopted the model. The community kept extending it. By 2026 the frontier is no longer "does the graph exist?" It is "how do we make the graph weighted, complete, and substrate-independent?" That is the state of the art.

9. State of the art -- Tier Zero, ADCS edges, and OpenGraph, 2023 to 2026

By the time MSEM shipped, SpecterOps had already moved past "is there a graph?" and was asking three sharper questions. Where does the graph end? How do we model attack primitives that compose from raw facts? And does the AD-specific schema even matter?

The first question is what "Tier Zero" means. On June 22, 2023, Jonas Bülow Knudsen, Elad Shamir, and Justin Kohler at SpecterOps published What is Tier Zero -- Part 1, which reframed Microsoft's tiered-administration concept -- introduced in the 2012-2014 Securing Privileged Access guidance and renamed the Enterprise Access Model with the "Control Plane" vocabulary in December 2020 [@ms-enterprise-access-model] -- as a property of the graph [@specterops-2023-tier-zero].

A Tier Zero asset (see Definition below) reframes Microsoft's tiered concept from the set of things in the high-privilege tier to the set of things from which the high-privilege tier is reachable. Microsoft's own Tier 0 definition -- "Direct Control of enterprise identities... and all the assets in it" -- becomes a graph property. The two formulations are equivalent if and only if the graph is complete. If the graph is incomplete (which it is), the Tier Zero set computed from the graph is the floor, not the ceiling.

Any node in the attack-path graph whose compromise lets an attacker reach an administrative privilege in the forest. The companion `SpecterOps/TierZeroTable` GitHub project is the community-maintained inventory; the README discloses that the table is the floor, not the ceiling [@specterops-tier-zero-table].

The Tier Zero definition is the answer to "shortest path to what?" -- the target side of every BloodHound shortest-path query. Without a defined Tier Zero set, the question has no endpoint.

The second question is how to model attack primitives that compose. The January 24, 2024 SpecterOps blog by Knudsen formalised this with the traversable / non-traversable edge distinction discussed in Section 7. The mechanism generalises: any attack primitive whose exploitability is a conjunction of raw facts can be encoded as a composed edge that the post-processor synthesises when the pattern is present.

ESC1, walked through in Section 7, is the canonical example: nine numbered prerequisites that the post-processor checks before writing the composed ADCSESC1 edge [@specterops-2024-adcs-bloodhound]. Subsequent posts in the series extended the same machinery to ESC3, ESC4, ESC6, ESC7, ESC8 (the CoerceAndRelayNTLMToADCS edge), ESC9, ESC10, and -- on February 14, 2024 -- ESC13 [@specterops-2024-esc13].

In December 2024 BloodHound v6.3 introduced an early-access "improved analysis algorithm" internally referred to as Butterfly [@bloodhound-v6-3-release]. Butterfly is the first production attempt at bi-directional impact analysis. Pre-v6.3 BloodHound Enterprise quantified risk as "who can reach this node?" (incoming attack-path count). v6.3 also quantifies "who can this node reach if compromised?" (outgoing blast radius).

The release notes describe the outcome but not the algorithm: "Improve risk scoring fidelity for all finding types... Measure risk at each individual finding... Support the inclusion of hybrid paths in risk scoring (Azure assets will now contribute to measured risk in AD and vice versa)."

The same release also announced that BloodHound Enterprise had begun migrating off Neo4j onto PostgreSQL as the graph database, with the release notes reporting ">50% improvement in the time it takes to perform post-processing during the Analysis process." Cypher continues to be the query language; the engine underneath changed.

The third question -- whether the AD-specific schema matters -- got its answer on July 29, 2025, when SpecterOps released BloodHound v8.0 with OpenGraph [@specterops-2025-opengraph]. OpenGraph decouples the graph engine from the AD-specific schema. Users (and SpecterOps partners) define their own node and edge kinds and ingest attack-path data from arbitrary substrates. The initial release included GitHub organisations, Snowflake role hierarchies, Microsoft SQL Server logins, ServiceNow groups, and Tailscale ACLs. Subsequent community contributions extended the library.

BloodHound OpenGraph is a foundational shift toward... identity risk management across the entire enterprise. -- Justin Kohler, SpecterOps Chief Product Officer, July 29, 2025.

OpenGraph is the closing observation of an arc that began with Phillips and Swiler in 1998: the model is the abstraction; the substrate is whatever your enterprise runs. The same shortestPath() that finds Active Directory attack paths now finds attack paths over a GitHub organisation, a Snowflake role hierarchy, or a Microsoft SQL Server login graph, with no engine change. The 2026 BloodHound release (v9.1.0, May 6, 2026, per the public release-notes index [@bloodhound-release-notes-index]) extends OpenGraph and adds incremental edge updates -- the first step toward a streaming graph rather than a snapshot.

10. Competing approaches -- BloodHound versus Microsoft versus the alternatives

In 2026 no single product covers every substrate. The field is plural.

A practitioner choosing among attack-path tools answers four questions, in order. What substrate do you need to cover? Self-host or SaaS? Snapshot or continuous? Open query language or vendor portal? The table below assembles the answers on the dimensions a 2026 practitioner actually uses.

Tool	Substrate	Engine	Query language	Deployment	Licensing	Edge weighting	ADCS coverage	Best fit
BloodHound CE 9.x	AD + Entra + AzureRM + OpenGraph	Neo4j + Postgres app DB	Cypher	Self-hosted Docker Compose	Apache-2.0	No (unweighted BFS)	Yes -- ESC1 through ESC10 + ESC8 composite	Authorised offensive testing + DIY blue team
BloodHound Enterprise	Same as CE	PostgreSQL-as-graph (in-progress migration off Neo4j)	Cypher	SaaS	Commercial	Bi-directional (Butterfly v6.3+); weighting function not public	Yes	Continuous AD/Entra attack-surface management at enterprise scale
Adalanche	AD (on-prem; LDIF or live LDAP)	In-memory Go	AQL (GQL-like)	Single Go binary	Open source	No	Yes (per README)	Offline / air-gapped analysis from LDIF
Microsoft Security Exposure Management	Defender XDR signal: identity + endpoint + multi-cloud + Entra	Proprietary	KQL + portal	SaaS	Microsoft licensing	Implicit (filter against exploitability oracle)	Indirect via MDI signals	Hybrid Microsoft-substrate unified exposure
MDI Lateral Movement Paths	On-prem AD (sensitive-account paths only)	Proprietary	None -- portal only	SaaS	Microsoft licensing	n/a	Implicit via separate MDI alerts	Default-on credential-hopping detection
Defender for Cloud CSPM attack-path analysis	Multi-cloud (Azure + AWS + GCP)	Proprietary	Cloud Security Explorer + KQL	SaaS	Microsoft licensing	Implicit	n/a	Multi-cloud workload protection
PingCastle / Semperis DSP / ADAudit Plus	On-prem AD (+ limited Entra)	None -- list-of-findings	None -- HTML / portal	Self-hosted or SaaS	Commercial / mixed	n/a	Single-finding hygiene only	Compliance auditing and change tracking

A few rows deserve commentary.

Note: BloodHound CE ships under Apache-2.0 per the current repository [@bloodhound-ce-repo]. The GPL-3.0 license you may see in older treatments applies only to the deprecated BloodHound Legacy v4 repository [@bloodhound-legacy-repo], which was last updated in 2023 and is no longer maintained. The licensing difference is material: GPL-3.0 is copyleft, Apache-2.0 is permissive. Downstream use cases that need permissive licensing should rely on the current CE.

Older blog posts and conference talks frequently call BloodHound CE GPL-3.0. The CE-Legacy LICENSE block does carry the GPL-3.0 copyright header, which is the source of the confusion. The current CE codebase at github.com/SpecterOps/BloodHound is Apache-2.0; the GPL-3.0 LICENSE applies only to the deprecated Legacy v4 repository.

Adalanche, by Lars Karlslund, is the load-bearing counter-example to the claim that "the graph model requires Neo4j" [@adalanche-repo]. Adalanche reads AD data from an LDIF dump or live LDAP, builds the graph entirely in process memory, and exposes a web GUI plus an Adalanche Query Language (AQL) -- described in the README as "a GQL-like language that allows for complex queries."

The README's headline claim is verbatim: "Adalanche gives instant results, showing you what permissions users and groups have in an Active Directory." The trade is no continuous monitoring, no multi-user web app, and a smaller community in exchange for zero deployment friction. The model is identical; the engine is replaceable.

MSEM is the closest Microsoft analogue to BloodHound (see Section 8 for substrate and query interface). Reasonable defenders run both MSEM and BloodHound (CE or Enterprise) on the same forest. The tools are complementary rather than substitutionary: MSEM brings the EDR plus workload-protection telemetry that BloodHound does not natively ingest, while BloodHound brings the precise AD edge semantics that SpecterOps's research community has validated. Running both is not double-counting.

The hygiene scanners -- PingCastle [@pingcastle], Semperis DSP [@semperis-dsp], ManageEngine ADAudit Plus [@manageengine-adaudit-plus] -- are the surviving descendants of the per-object ACL-inspection generation, with risk-scoring layered on top. They are valuable for compliance auditing and change tracking. They do not expose a queryable attack-path graph. The compliance auditor and the attack-path analyst are different personas with different tools.

If the field is plural and every tool has a gap, what is the shape of the problem that no tool yet solves? The next section is the honest answer.

11. Theoretical limits and open problems

Some of the gaps in attack-path analysis are engineering gaps. Others are not.

The single most consequential open problem is edge weighting. BloodHound's BFS treats every edge as one hop. In reality, MemberOf is effectively free; ForceChangePassword requires the attacker to log in as the changed principal afterwards; AddKeyCredentialLink requires shadow-credential infrastructure; CoerceAndRelayNTLMToADCS requires an active SMB-coercion primitive, NTLM relay tooling, and an ESC8-vulnerable certificate authority. A shortest-hop path is not in general the shortest-exploitation-cost path.

BloodHound Enterprise v6.3 shipped the Butterfly analysis as the first production attempt to relax this assumption. As the v6.3 release notes acknowledge (see Section 9), Butterfly's weighting function is not publicly documented [@bloodhound-v6-3-release].

Academic intuition suggests weighting edges by an exploitation-success probability and computing most-likely-exploited paths via shortest paths under negative-log-probability weights. The complexity ceiling is well-known: Dijkstra (with non-negative weights) runs in $O(E + V\log V)$ time with a Fibonacci heap; Bellman-Ford handles negative weights at $O(VE)$. Either fits comfortably inside the per-query budget BloodHound already operates within.

The unsolved part is the empirical calibration: what numerical weight is the right weight on a ForceChangePassword edge versus a CoerceAndRelayNTLMToADCS edge? There is no published peer-reviewed answer.

The second open problem is coverage. The TierZeroTable README is the authoritative self-disclosure: file-system ACLs on member servers, fine-grained GPO delegation, on-host service-account permissions, some Entra conditional-access logic, and cross-tenant Entra B2B trust paths remain partially or fully out of scope [@specterops-tier-zero-table]. This is an engineering problem -- more collectors, more edge definitions -- rather than an algorithmic one. OpenGraph is the structural answer: shift coverage from "what edges has SpecterOps modelled?" to "what edges has the community contributed to the shared library?" [@bloodhound-opengraph-library].

The third is graph privacy. A continuously-collected, complete AD privilege graph shipped to a third-party SaaS backend is, in adversarial hands, a pre-computed attack plan for the customer's forest. Tenant isolation, encryption at rest, SOC 2 and FedRAMP attestation, and customer-managed key encryption do not eliminate the structural risk: a compromised SaaS backend yields the customer's graph regardless of compliance posture.

Cryptographic approaches -- homomorphic graph queries, secure multi-party computation for path enumeration -- exist in the theoretical literature but are not in production attack-path products at time of writing. Adalanche and self-hosted BloodHound CE remain the privacy-preserving options at the cost of forgoing continuous monitoring.

The fourth is the the graph is alive problem. Session edges (HasSession) go stale in hours. New ACEs, new group memberships, new sessions appear continuously. SharpHound's snapshot model is yesterday's view; continuous collectors (BloodHound Enterprise, MSEM agent streams) trade stealth for freshness. The May 6, 2026 release notes describe BloodHound CE's first move toward a streaming model: "incremental edge updates that reduce unnecessary writes during post-processing" [@bloodhound-release-notes-index]. No production attack-path tool yet ships a fully streaming graph.

The fifth is combinatorial intractability. These are not engineering gaps; they are complexity-theoretic facts.

Counting all attack paths is #P-complete. Leslie Valiant's 1979 result on the complexity of counting solutions to combinatorial problems applies directly: counting the simple paths between two nodes in a general graph cannot be done in polynomial time unless P = #P [@valiant-1979-permanent]. BloodHound's path-count UI is necessarily an approximation or a length-truncation; this is the theoretical reason why.
The minimum-edge-cut "defender hardening" problem is NP-hard. Choose the smallest set of edges whose removal disconnects the attacker from the goal. Sheyner et al. 2002 proved the result is NP-hard but admits an $O(\log n)$ approximation [@sheyner-et-al-2002-attack-graphs]. BHE choke-point ranking and MSEM choke-point analysis necessarily implement heuristic approximations.
Finding regular simple paths is NP-complete. Mendelzon and Wood 1995 proved that finding a simple path matching a regular expression over edge labels in a graph database is NP-complete [@mendelzon-wood-1995-dblp]. Cypher's shortestPath() does not enforce simple-path semantics, which is why it remains in P; quantified path patterns with DIFFERENT RELATIONSHIPS semantics (available since Neo4j 5.x and documented in the current Cypher manual [@neo4j-cypher-variable-length]) do enforce simple paths and so cross into the NP-complete regime.

Key idea: BloodHound's per-query algorithm (BFS, $O(V + E)$) is optimal up to constants. The frontier of the field is no longer the algorithm. It is what question we ask the algorithm: weighted? regular-path? simple-path? bi-directional? cross-substrate? Each open question is a different model, not a different implementation.

Three further honest framings deserve a mention.

First, the standardisation of OpenGraph edge taxonomies is unsettled. Without community convergence on edge naming, different contributors may model the same substrate with incompatible schemas. Historical precedent (MITRE ATT&CK technique IDs, CVE identifiers) suggests that convergence happens when a single high-trust curator becomes the de-facto registry; whether SpecterOps will operate OpenGraph as a vendor-neutral standards body or as a SpecterOps-owned artefact is a governance question, not an algorithmic one.

Second, the adversarial robustness of the collector is an open question: SharpHound runs as an authenticated principal, and an attacker with prior compromise can poison the collection. There is no closed-form defence.

Third, the absence of any public head-to-head benchmark of BloodHound CE versus BHE versus Adalanche versus MSEM on the same forest under controlled conditions is structural: Microsoft does not publish per-query latency, SpecterOps publishes only relative improvement claims, and the academic line uses 2005-era hardware figures that are not comparable.

12. Practical guide -- running BloodHound today

If the previous sections sold you on the model, the next few paragraphs are the minimum you need to stand it up.

Stand up BloodHound CE with the Docker Compose file in the repository [@bloodhound-ce-repo]. The stack is four containers: a PostgreSQL application database (users, roles, sessions, audit logs, saved queries); a Neo4j graph database holding the property graph; a Go REST API; and a React plus Sigma.js single-page frontend. Five minutes to first boot on a developer laptop. The repository README is the authoritative deployment reference.

Run SharpHound on a domain-joined Windows host as the collection identity. The default invocation -- SharpHound.exe --CollectionMethods all,GPOLocalGroup -- enumerates every group membership, every recognised ACL pattern, every active session, every local-admin relationship, and every Kerberos delegation. Run AzureHound with appropriate Entra ID credentials for Entra and AzureRM coverage. Both emit JSON dumps in the same envelope; the BloodHound CE upload tab in the web UI ingests both.

Open the web UI. The stock pre-built queries are a reasonable starting palette: Find Shortest Paths to Domain Admins, Find Principals with DCSync Rights, Find Computers with Unsupported Operating Systems, and Shortest Paths from Owned Principals to High-Value Targets (after marking some accounts as owned). Custom Cypher goes in the Cypher tab at the top right; the Section 6 query is a good template.

The most important interpretation discipline: treat the result as a risk register, not a vulnerability list. A finding is "Bob can reach Domain Admins via a four-hop path." The edge is "Bob has GenericWrite on Carol." Closing the edge breaks the finding and every other path that passed through it. Edges are the unit of remediation, not findings. SpecterOps's own 2021 customer-anonymous essay Active Directory Attack Paths -- Is It Always This Bad? reports findings from hundreds of engagements, and the recurring observation across forests is that a small number of high-blast-radius edges explain most of the discovered paths [@specterops-2021-ad-attack-paths].

A few pitfalls are worth naming. HasSession collection generates measurable LDAP and SAMR traffic that Microsoft Defender for Identity alerts on; coordinate with the blue team or expect detections. The stealth collection mode trades coverage for traffic volume.

Unconstrained variable-length Cypher queries (MATCH p=(a)-[*]->(b)) can pin Neo4j's heap; CE's "protected Cypher" cost limits help but do not eliminate the problem, so prefer shortestPath() or bound the path length explicitly. The wildcard-principal post-processing for Authenticated Users and Everyone requires v6.0 or later to be correct; older versions miscount these edges [@bloodhound-v6-0-release]. And the CoerceAndRelayNTLMToADCS edge is Group to Computer, not Computer to Computer, as discussed in Section 7.

```cypher MATCH (n) WHERE n.system_tags CONTAINS 'admin_tier_0' WITH collect(n) AS tier_zero MATCH p = shortestPath((u:User {enabled:true})-[*1..6]->(t)) WHERE t IN tier_zero AND NOT u.system_tags CONTAINS 'admin_tier_0' RETURN u.name AS source, t.name AS target, length(p) AS hops ORDER BY hops ASC LIMIT 25 ```

This returns up to 25 enabled non-Tier-Zero users with the shortest paths into Tier Zero. The [*1..6] bound prevents the pathological cyclic-graph cost explosion. Bound length aggressively until you have indexed your graph.

BloodHound is dual-use. Authorised defensive use on your own forest, or contracted penetration testing within written scope, is the standard legal posture. Running it against a directory you are not authorised to assess is unlawful in most jurisdictions: the Computer Fraud and Abuse Act in the United States; the Computer Misuse Act 1990 in the United Kingdom; equivalents in most EU jurisdictions. The dual-use posture is fundamental to the tool; the legal posture depends on you.

The tool is the easy part. The hard part is what you do with the answer.

13. Frequently asked questions

The misconceptions worth disposing of, in order of how often they recur.

No. BloodHound is the SpecterOps-maintained, evolving set of edge families. File-system ACLs on member servers, fine-grained GPO delegation, on-host service-account permissions, and some Entra conditional-access logic remain partially or fully out of scope. The `SpecterOps/TierZeroTable` README is explicit about this limitation [@specterops-tier-zero-table]. Coverage expansion is iterative and community-fed; OpenGraph is the structural answer to scope generalisation. The original BloodHound (2016) shipped Neo4j only. The modern BloodHound CE uses *both*: PostgreSQL as the application database (users, roles, sessions, audit logs) and Neo4j as the graph layer [@bloodhound-ce-repo]. BloodHound Enterprise has begun migrating entirely off Neo4j onto PostgreSQL-as-graph (announced in v6.3, December 2024) [@bloodhound-v6-3-release]; Cypher continues to be the query language on the new backend. The model is engine-independent; Adalanche proves the same point by doing it all in process memory in Go [@adalanche-repo]. Authorised defensive use on your own forest, yes. Contracted penetration testing within written scope, yes. Running it against a directory you are not authorised to assess is unlawful in most jurisdictions: the Computer Fraud and Abuse Act in the United States, the Computer Misuse Act 1990 in the United Kingdom, and equivalents in most EU jurisdictions. The dual-use posture is fundamental to the tool; legal compliance is the operator's responsibility.

Epilogue

The 2014 analyst with the whiteboard and the 2024 analyst with the Cypher query are doing the same work. The unit of analysis has shifted, and once the unit shifts, the field does not go back.

John Lambert diagnosed it in two sentences in April 2015 [@lambert-2015-defenders-lists-attackers-graphs]. Andy Robbins, Rohan Vazarkar, and Will Schroeder shipped it as BloodHound in August 2016 [@bloodhound-legacy-repo]. SpecterOps extended it through AzureHound in 2020, the CE 5.0 web architecture in 2023, the Tier Zero formalisation in 2023, ADCS composed edges in 2024, Butterfly bi-directional analysis in 2024, and OpenGraph in 2025 [@specterops-2025-opengraph].

Microsoft validated the model with Lateral Movement Paths in 2018, cloud security graph attack-path analysis in 2022 to 2023, and Microsoft Security Exposure Management at Ignite in 2024 [@ms-msem-attack-paths]. The community that shipped the graph won; the community that kept shipping lists is selling compliance reports to the auditors.

The frontier in 2026 is not whether to model attacks as a graph -- that argument is settled. The frontier is how to make the graph weighted (so the shortest path approximates the easiest), how to make it complete (so the unmodelled edges shrink toward zero), and how to make it substrate-independent (so the next enterprise primitive worth modelling -- whatever it turns out to be -- can be ingested without changing the engine). Each of these is a research direction with its own asymptotic ceiling, its own engineering practice, and its own community of contributors.

What started as a sentence in a 1,100-word essay on a personal GitHub repository is now an ISO-standardised query language [@iso-39075-2024-gql], a shipped Microsoft product family, an open-source repository with hundreds of thousands of downloads, and a discipline taught at most major security conferences. The graph wins because the graph is the right model. The right model wins because, eventually, the right model always does.