Parag Mali - tag: bloodhound

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.

Two Checkmarks and the Keys to the Kingdom: How Active Directory's Replication Protocol Became the Longest-Lived Credential Attack on Windows

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

Active Directory's replication protocol (MS-DRSR) lets any domain controller pull every secret in the directory from any other domain controller, and the access check gates on an ACL, not on whether the caller is actually a DC. Mimikatz's `lsadump::dcsync` (August 11, 2015) and `lsadump::dcshadow` (January 2018) are the read and write sides of this loophole; both remain in active operational use eleven years later because the protocol cannot be amended without breaking AD replication. Credential Guard cannot help -- the secret moves from a remote DC's NTDS.dit over the network, never touching the attacker's LSASS. The 2026 defender response is four parallel detection layers (posture, behavioral, network, graph) because no single layer catches every case, and the architectural fifth layer that would close the class is not coming.

1. Two Checkmarks and the Keys to the Kingdom

A non-admin service account, created during a 2017 file-server migration and never cleaned up, holds exactly two access-control entries on the contoso.local domain object: Replicating Directory Changes and Replicating Directory Changes All. From a Windows 11 workstation -- not a domain controller, not a tier-zero admin host, just a desk -- the attacker opens a Mimikatz prompt and types:

lsadump::dcsync /domain:contoso.local /user:krbtgt

Sixty seconds later they have the krbtgt NT hash and Kerberos AES keys, and they own the domain. Credential Guard, enabled on every workstation in the building, never saw the credential transit anywhere in its scope.

That last sentence is the punchline of the entire field. The secret never touches the attacker's LSASS, so Credential Guard's design has nothing to say. The keys move from a remote domain controller's on-disk database, over an RPC channel, into the attacker's process memory. Credential Guard isolates LSASS on the local machine. It has no jurisdiction over what a remote DC chooses to send when asked nicely.

Note: Credential Guard isolates LSASS-resident secrets in a separate virtual trust level. DCSync reads secrets from a remote DC's NTDS.dit over MS-DRSR -- a network protocol attack, not a local-memory attack. Microsoft's Credential Guard documentation does not claim protection against MS-DRSR-based credential extraction [@credential-guard-considerations].

The 60-second timeline is not a marketing number. One RPC round trip per principal is the protocol's per-principal cost, fixed by specification. For a single high-value target -- and krbtgt is the highest-value target in any Active Directory forest, because its long-term key signs every Kerberos ticket -- the attack is over before a typical SOC operator has finished pouring coffee.

The four people whose names recur in this story are worth meeting now. Benjamin Delpy (gentilkiwi) wrote Mimikatz and authored both the DCSync read primitive (2015) and, with Vincent Le Toux, the DCShadow write primitive (2018). Vincent Le Toux built the original DCShadow implementation and the PingCastle posture-assessment tool. Sean Metcalf (Trimarc / ADSecurity) translated DCSync into operator vocabulary in the weeks after its release. Microsoft's Defender for Identity team ships the canonical first-party detections that fire on this attack class today.

This story is what happens when a 23-year-old domain-controller-to-domain-controller protocol's access check turns out to gate on an ACL, not on whether the caller is a domain controller. Two ACEs on one object should not give an attacker the entire credential trove. The fact that they do is not a bug in the implementation. It is a 1999 design assumption -- that nobody who is not a DC would ever speak this protocol -- that survived twenty-five years as a social convention and was nowhere written down in the access-check code.

The next section explains why Microsoft built this protocol in the first place, and why its access check forgot to ask the one question that would have closed the loophole.

2. Why the Protocol Exists at All

Rewind to February 17, 2000. Microsoft ships Windows 2000 Server, and Active Directory replaces the old NT 4.0 PDC/BDC model [@microsoft-windows-2000-launch]. NT 4.0 was single-master: one Primary Domain Controller held the authoritative account database, every Backup Domain Controller held a read-only copy, and a password change on the PDC propagated to BDCs through a hub-and-spoke replication channel. AD inverts the model. Every domain controller in an AD domain holds a writable copy of the directory; a password change on any DC must propagate to every other DC within minutes; the replication topology is a mesh, not a star.

Multi-master replication is the design constraint that forces MS-DRSR's existence. If any DC can accept a write, then every DC must be able to pull every change -- including secret attributes like unicodePwd, dBCSPwd, ntPwdHistory, lmPwdHistory, and supplementalCredentials -- from every other DC. There is no second protocol. Replication of secrets is replication, and replication is MS-DRSR [@ms-drsr-spec].

The RPC protocol by which any Active Directory domain controller can replicate any object, including secret attributes, from any other DC in the same forest. Layered over DCE/RPC; the current public specification is revision 46.0 dated March 9, 2026 [@ms-drsr-spec]. MS-DRSR is the mechanism that makes AD's multi-master replication invariant work. The MS-DRSR method (opnum 3) that returns changed objects within a naming context. A calling DC supplies a target DN and a set of replication flags; the called DC returns the object's attribute values, with secret attributes encrypted under a session-derived key. This is the protocol method that DCSync invokes. flowchart LR subgraph Domain["contoso.local domain"] DCA[DC-A
NTDS.dit] DCB[DC-B
NTDS.dit] DCC[DC-C
NTDS.dit] end DCA -- IDL_DRSGetNCChanges
unicodePwd, ntPwdHistory --> DCB DCB -- IDL_DRSGetNCChanges
supplementalCredentials --> DCA DCB -- IDL_DRSGetNCChanges
dBCSPwd --> DCC DCC -- IDL_DRSGetNCChanges
unicodePwd --> DCB DCA -- IDL_DRSGetNCChanges
ntPwdHistory --> DCC DCC -- IDL_DRSGetNCChanges
krbtgt keys --> DCA

The access check that gates IDL_DRSGetNCChanges is defined in [MS-DRSR] §4.1.10. It asks one question: does the calling principal hold the appropriate extended rights on the naming-context root being replicated? Extended rights are AD's mechanism for control-access permissions that do not fit into the standard ACL bit set [@ms-drsr-spec].

A schema-defined access-control right identified by a GUID rather than by a standard ACL bit. Extended rights are granted via an access-control entry on a target object and checked at runtime by the operation that requires them. The three replication extended rights are the canonical example: each is identified only by GUID, and each is checked by `IDL_DRSGetNCChanges` against the caller's effective rights on the naming-context root. A top-level replication partition of the Active Directory database. Every AD forest has at least three NCs: the Schema NC, the Configuration NC, and one Domain NC per domain (plus optional Application NCs). DCSync operates against the Domain NC root.

Three extended rights together form what practitioners call the rights triad. The two-checkmark version from §1 is the most-common configuration; the third right unlocks a smaller set of attributes flagged confidential. Microsoft's own AD schema documentation enumerates each one [@ad-schema-get-changes][@ad-schema-get-changes-all][@ad-schema-get-changes-filtered-set]:

The combination of three replication extended rights on a naming-context root: `DS-Replication-Get-Changes` (the baseline read), `DS-Replication-Get-Changes-All` (unlocks secret attributes), and `DS-Replication-Get-Changes-In-Filtered-Set` (unlocks attributes with the confidential flag). The first two are what most operators mean when they say "DCSync rights"; the third is sometimes required for completeness.

Right	Display name	Rights-GUID	What it unlocks	Introduced
`DS-Replication-Get-Changes`	Replicating Directory Changes	`1131f6aa-9c07-11d1-f79f-00c04fc2dcd2`	Baseline replication read	Windows 2000 Server [@ad-schema-get-changes]
`DS-Replication-Get-Changes-All`	Replicating Directory Changes All	`1131f6ad-9c07-11d1-f79f-00c04fc2dcd2`	Secret attribute replication (`unicodePwd`, `ntPwdHistory`, etc.) [@ad-schema-get-changes-all]	Windows Server 2003
`DS-Replication-Get-Changes-In-Filtered-Set`	Replicating Directory Changes In Filtered Set	`89e95b76-444d-4c62-991a-0facbeda640c`	Confidential-flag attributes [@ad-schema-get-changes-filtered-set]	Windows Server 2008

In a freshly-installed AD domain, four principal sets hold the rights triad by default on the Domain NC root: the Domain Controllers group, the Domain Admins group, the Enterprise Admins group, and the built-in Administrators group [@sean-metcalf-dcsync-2015]. Every other ACE on that object is a deliberate delegation choice made by some operator at some point in the domain's history.

Now read the access check carefully. It asks whether the caller holds the rights. It does not ask anything about who the caller is. The protocol does not check whether the caller's Service Principal Name is GC/... or ldap/... or anything else. It does not check whether the caller's machine account is in the Domain Controllers group. It does not check whether the caller's Kerberos service ticket was issued for a DC service. The whole gate is the ACL on one object.

This is the most consequential design omission in any Microsoft network protocol. Every other replication-style protocol in Windows ships some form of caller-machine-identity assertion. MS-DRSR shipped without one because, in 1999, nobody on the design team imagined an unprivileged workstation would speak the DC-to-DC protocol.

The 1999 closed-population design assumption is the load-bearing fiction underneath this whole story. The protocol's designers assumed -- entirely reasonably for the deployment universe of that decade -- that the only software that would ever implement an MS-DRSR client was the DC role itself, which Microsoft shipped, signed, and audited. No defender in 1999 was thinking about a Python script speaking DRSUAPI from a desk. The assumption was a social convention dressed as a security model, and it survived for fifteen years.

If the protocol exists to replicate every secret in the directory, and the access check is the ACL on one object, what stopped anyone from abusing it for the protocol's first fifteen years? That accidental safety period is the subject of the next section.

3. The Fifteen-Year Accidental Safety Period

Between 2000 and 2015, attackers who wanted the entire credential trove of an Active Directory domain had exactly one road open to them: reach a domain controller and steal its database. The reasons are not subtle. The credentials lived in one file -- C:\Windows\NTDS\NTDS.dit, an Extensible Storage Engine database protected by a Password Encryption Key wrapped under the BootKey scattered across four registry values in the SYSTEM hive [@ntdsxtract-repo]. Without code execution on a DC, there was no obvious way to ask the directory for its secrets in bulk.

The on-disk Extensible Storage Engine ("Jet Blue") database that holds every Active Directory object, including secret attributes. Located at `C:\Windows\NTDS\NTDS.dit` on every domain controller. The file is locked while AD DS is running; offline copying requires either Volume Shadow Copy snapshots, `ntdsutil ifm` bundling, or DC downtime [@mitre-t1003-003].

Three sub-techniques bloomed inside this constraint, and MITRE catalogs them collectively as T1003.003 OS Credential Dumping: NTDS [@mitre-t1003-003]. Each is operationally distinct, and each requires the same precondition.

G1a -- Volume Shadow Copy plus offline parse. The attacker runs vssadmin create shadow /for=C: on a domain controller, creating an instant point-in-time snapshot. They copy NTDS.dit and SYSTEM out of the shadow path, exfiltrate both files, and parse them offline with Csaba Barta's ntdsxtract toolkit [@ntdsxtract-repo] or Impacket's secretsdump.py running in offline mode. The parse walks the datatable ESE table row by row, decrypts the PEK with the BootKey, and decrypts each principal's secret attributes with the PEK.

G1b -- ntdsutil Install From Media. The built-in command ntdsutil "activate instance ntds" "ifm" "create full C:\Temp\IFM" packages NTDS.dit and the SYSTEM hive into a clean bundle, intended for legitimate seeding of a new replica DC. With local admin on any DC, an attacker invokes it without involving VSS.

G1c -- LSASS injection of the long-term DC secrets. Mimikatz's pre-DCSync technique reads cached long-term secret material (including the krbtgt key) directly out of lsass.exe memory on a domain controller via lsadump::lsa /inject /name:krbtgt. The variant that turned this surface into a persistence implant was Skeleton Key, disclosed by the Dell SecureWorks Counter Threat Unit on January 12, 2015 [@skeleton-key-wayback]. Skeleton Key patches the NTLM and Kerberos validation routines in LSASS on a DC so that a single master password works for any account.

Skeleton Key sits at the boundary between credential dumping and persistence. It does not produce usable NT hashes or Kerberos keys for offline forging; it gives the attacker a backdoor at the authentication step. The 2015 community debate over Skeleton Key versus the (then-imminent) DCSync technique was settled decisively by DCSync's August release: dumping the hashes is more useful than backdooring the auth path, because dumped hashes survive a DC reboot and are forge-ready material [@skeleton-key-wayback].

Sub-technique	Mechanism	Canonical tool	Emitted artifact	Host artifact on DC
G1a VSS + offline parse	Point-in-time snapshot, file copy, offline ESE parse	`vssadmin` + `secretsdump.py` / `ntdsxtract`	NT hashes, Kerberos keys, password history	VSS event in system log
G1b `ntdsutil` IFM	Built-in admin command produces clean bundle	`ntdsutil "ac i ntds" "ifm"`	Identical to G1a	IFM staging directory
G1c LSASS inject	Read long-term secrets from `lsass.exe` memory	`mimikatz lsadump::lsa /inject`	`krbtgt` key and other LSA-cached secrets	Process access of `lsass.exe`

The structural cost across all three is the same: code execution as SYSTEM on a domain controller. Read that requirement slowly. In a mature enterprise with even a basic tiered-administration model -- no interactive logon to DCs from workstations, restricted-admin RDP, Privileged Access Workstations for Domain Admin sessions, Protected Users group membership for Tier Zero principals -- DCs are the most defended boundary in the network. An attacker who has crossed that boundary has, in operational terms, already won. The credential dump is the trophy lap.

flowchart TD Start[Attacker foothold
on workstation] Start --> VSS[G1a: VSS snapshot
+ offline parse] Start --> IFM[G1b: ntdsutil IFM
create full] Start --> Inject[G1c: LSASS inject
on DC] VSS --> Gate[SYSTEM on DC] IFM --> Gate Inject --> Gate Gate --> Creds[All domain credentials
NT hashes, Kerberos keys, krbtgt]

This is what made the closed-population design assumption survive its first fifteen years. The protocol's design was open to abuse from any joined workstation that held the rights triad, but nobody noticed because the cheaper attack road -- compromise a DC, parse the database offline -- still passed through a defended chokepoint. The ACL on the Domain NC was nowhere on a defender's risk register, because no offensive tooling existed that treated the ACL as the gate.

There was a question waiting to be asked, though. What if you could ask the DC to send you the credentials, using a protocol the DC already speaks fluently with its peers? The protocol's wire format is published. Microsoft Learn hosts the IDL. The DCs trust each other's calls by ACL. The only missing piece was a client implementation that any attacker could run from any joined machine.

In August 2015 the missing piece arrived.

4. Generation by Generation

August 11, 2015, 01:27 Central European Time. Benjamin Delpy commits 47,132 insertions to the Mimikatz repository in a single push titled "DCSync in mimikatz & for XP/2003." The diff introduces four new modules -- kull_m_rpc_drsr.c/.h and kull_m_rpc_ms-drsr.h/_c.c -- generated from the [MS-DRSR] IDL. They are an MS-DRSR client surface, slotted into kuhl_m_lsadump.c as the new lsadump::dcsync command [@mimikatz-dcsync-commit][@mimikatz-repo]. Vincent Le Toux is credited as co-author.

Six weeks later Sean Metcalf writes the canonical operator post and presents the technique at DerbyCon V on Friday, September 25, 2015, in the Track 1 (Break Me) slot from 3:00 to 3:50 pm [@sean-metcalf-dcsync-2015][@sean-metcalf-derbycon-2015]. The closed-population assumption shatters in a weekend.

A commit hash widely cited in operator forums for the DCSync introduction -- `79b3577aed999baac0352cb1ba3a5f86b6d29f34`, dated 2015-07-20 -- does not exist in the Mimikatz repository. A `git --no-pager log --all` against a fresh clone returns `fatal: bad object` for that hash; the GitHub commit URL returns 404; the GitHub API returns 422. The actual introducing commit is `7717b7a7173fa6a6b6566bbbc3e7372b464d988f`, authored by Benjamin DELPY at 2015-08-11 01:27:13 +0200, with the subject line *"DCSync in mimikatz & for XP/2003"* [@mimikatz-dcsync-commit]. Sean Metcalf's contemporary writeup at ADSecurity confirms August 2015 as the release month [@sean-metcalf-dcsync-2015]. The lesson for verifying any third-party claim about a Mimikatz commit is the same lesson Stage 1 of this article's research pipeline applied: clone the repo, run `git show`.

What follows is the story of four generations of attacker approaches against this protocol, each motivated by the operational limit of the previous one.

Generation 2: DCSync (2015-08-11 onward)

Mimikatz becomes a DRSUAPI client. Operator invocation is one line:

lsadump::dcsync /domain:contoso.local /user:krbtgt

Behind that line, six wire steps fire:

sequenceDiagram participant A as Attacker workstation participant DC as Target DC (DRSUAPI) A->>DC: 1. resolve target DC by domain A->>DC: 2. IDL_DRSBind (interface UUID DRSUAPI) DC-->>A: 3. bind reply (handle, session key) A->>DC: 4. IDL_DRSGetNCChanges (opnum 3, MTX_ADDR DN, EXOP_REPL_OBJ) DC-->>A: 5. DRS_MSG_GETCHGREPLY (encrypted secret attributes) A->>A: 6. decrypt with session key, emit NT hash and Kerberos keys

The wire format is one round trip per principal. To dump every account in the domain, Mimikatz's /all /csv mode iterates the request server-side via the same opnum with paginating up-to-date vectors. Per-call wire size is a few kilobytes for a single user; full-domain bulk dumps run to tens of megabytes. Wall-clock time is dominated by network latency to the target DC [@sean-metcalf-dcsync-2015][@trellix-silent-domain-hijack].

The Generation-1 precondition is gone. The attack runs from any joined workstation. The Generation-1 host artifacts -- VSS events, IFM staging directories, multi-megabyte file copies -- all disappear. The only on-the-wire signature is "an IDL_DRSGetNCChanges call from an IP that is not a domain controller" -- which has to be detected at the protocol layer, not the host layer.

Sean Metcalf's 2015 post named the detection recipe in the same breath as the attack: "Configure IDS to trigger if DsGetNCChange request originates an IP not on the 'Replication Allow List' ..." [@sean-metcalf-dcsync-2015]. Every network detection rule in this space, including Microsoft's own ATA "Unusual Protocol Implementation" category two years later, descends from that one sentence [@ata-v17-release-notes].

DCSync is read-only. The ACL pair the attack exploits does not include directory-write rights. An attacker who wants to plant SID-history backdoors, modify userAccountControl flags, or write to AdminSDHolder needs a different primitive. The same trust loophole that gave them read access turns out to support a symmetric write side.

Generation 3: DCShadow (2018-01-24)

January 23-24, 2018. Benjamin Delpy and Vincent Le Toux present at BlueHat IL in Tel Aviv. The talk is titled "Active Directory: What can make your million dollar SIEM go blind?" [@youtube-bluehat-2018-dcshadow]. Four days later, on January 27, 2018, Delpy pushes the mainline merge to Mimikatz with commit ab18bd1, subject "Pushing @vletoux DCShadow in current branch with some adaptations" [@mimikatz-dcshadow-commit].

Vincent Le Toux contributed the original implementation; the BlueHat IL talk shared joint Delpy/Le Toux billing; the Mimikatz mainline merge commit ab18bd103a5cd7e26fb8d475c5ea0157d6633ca9 is dated 2018-01-27 01:37:55 +0100, four days after the conference disclosure. Le Toux is the same author behind PingCastle's posture-assessment tooling and the canonical dcshadow.com reference site [@mimikatz-dcshadow-commit][@dcshadow-com].

DCShadow inverts DCSync. Where DCSync makes the attacker a DRSUAPI client, DCShadow makes the attacker a DRSUAPI server. The mechanism: temporarily register an nTDSDSA object plus the associated SPNs in the Configuration NC; signal to a legitimate DC that the new "DC" wants to push changes via IDL_DRSReplicaAdd followed by IDL_DRSReplicaSync; the legitimate DC pulls the attacker's pre-staged writes through the replication channel as if they were legitimate peer replication; deregister to clean up [@mitre-t1207][@dcshadow-com].

sequenceDiagram participant A as Attacker (rogue DC) participant Cfg as Configuration NC participant T as Target DC A->>Cfg: 1. create nTDSDSA + server object A->>Cfg: 2. add SPNs (GC, DRS UUID) to machine account A->>T: 3. IDL_DRSReplicaAdd (dsaSrc = attacker) T->>A: 4. IDL_DRSGetNCChanges callback (target pulls) A-->>T: 5. staged writes returned as replication payload A->>T: 6. IDL_DRSReplicaDel A->>Cfg: 7. delete nTDSDSA, remove SPNs A directory operation that does not generate the standard Event ID 4662 / 4738 / 5136 object-modification events that the Domain Services Auditing subsystem emits for normal writes. Legitimate DC-to-DC replication is SACL-silent by design -- the audit subsystem intentionally suppresses change events on the replication channel to avoid drowning every DC in audit traffic on every directory change. DCShadow writes are SACL-silent because they ride the same channel.

That last design fact is the entire point of the talk title. A SIEM watching object-modification events sees nothing when a DCShadow write lands, because the modifications arrive on the replication channel that the SIEM intentionally ignores as routine DC chatter. The original 2018 framing -- "your million-dollar SIEM goes blind" -- was correct for SIEMs that monitored only object-modification events. We will see in §6 how that framing has aged.

DCShadow is write capability. An attacker who reaches it can plant SID-history backdoors (write S-1-5-21-...-519 for Enterprise Admins into a low-privileged account's sIDHistory), modify userAccountControl to clear ACCOUNTDISABLE on dormant high-privilege accounts, add ACEs to AdminSDHolder (which then propagate via the SDProp process to every protected admin account every 60 minutes), or set msDS-AllowedToActOnBehalfOfOtherIdentity on a target computer to enable resource-based constrained delegation chains.

Generation 4: Permission-graph attacks (2018-present)

By 2018 the attack-side question had shifted. Holding the rights triad directly was no longer the interesting precondition; the interesting question was how to reach it transitively, through whatever chain of ACL delegations a real-world domain happened to contain. The umbrella term that emerged is permission-graph attack. Its terminal edge is still DCSync; its novelty is the path that gets you to the terminal.

Three primitives anchor this generation. Elad Shamir's Wagging the Dog (January 28, 2019) showed how writing msDS-AllowedToActOnBehalfOfOtherIdentity on a target computer object enables S4U2Self plus S4U2Proxy impersonation of any user to that computer [@shenaniganslabs-wagging-the-dog]. Shamir's Shadow Credentials (June 21, 2021) demonstrated that writing msDS-KeyCredentialLink on a target account adds an attacker-controlled certificate trust, enabling Kerberos PKINIT authentication as that account without resetting its password [@eladshamir-shadow-credentials]. And Sean Metcalf's earlier work on AdminSDHolder template abuse showed that writing the AdminSDHolder ACL causes SDProp to propagate the new ACL onto every protected admin account every 60 minutes -- self-healing persistence that survives defender cleanup [@sean-metcalf-adminsdholder].

The unifying observation: DCSync is a terminal in a permission graph. The graph's nodes are AD principals; its edges are individual access-control entries (WriteDACL, WriteOwner, GenericAll, WriteProperty, AddMember, ForceChangePassword). Whoever can traverse the graph to the rights triad on the domain root has DCSync transitively. The attacker's job is no longer to invoke IDL_DRSGetNCChanges; it is to find the shortest path through the graph from a foothold to the rights triad. The defender's mirror job is to enumerate all paths into the rights triad and either prune them or monitor them.

gantt title Domain replication attack class evolution dateFormat YYYY-MM-DD axisFormat %Y section Attack Gen 1 NTDS.dit theft :a1, 2000-02-17, 2015-08-11 Gen 2 DCSync :active, a2, 2015-08-11, 2026-12-31 Gen 3 DCShadow :active, a3, 2018-01-24, 2026-12-31 Gen 4 Permission-graph chains :active, a4, 2018-06-01, 2026-12-31 section Defense BloodHound 1.0 DEF CON 24 :d1, 2016-08-06, 30d ATA 1.7 release :d2, 2017-04-01, 30d Azure ATP DCShadow alerts :d3, 2018-07-24, 30d Azure ATP rebrand to MDI :d4, 2020-09-22, 30d BloodHound v6.0 :d5, 2024-09-30, 30d BloodHound v6.3 Butterfly :d6, 2024-12-09, 30d BloodHound v8.0 OpenGraph :d7, 2025-07-29, 30d Trellix NDR Silent Hijack :d8, 2025-12-08, 30d

To make the read-side access check decision concrete -- and to expose how thin it actually is -- here is the logic of the gate written as a runnable function. This is pseudocode for the decision, not the protocol bytes:

{` // Illustrative model of the MS-DRSR access check on IDL_DRSGetNCChanges. // Returns "secrets returned" or "ACCESS_DENIED" given a caller's effective // rights on the naming-context root. function dcsyncAccessCheck(callerRights, ncRootDn, requestedAttrs) { const GET_CHANGES = '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'; const GET_CHANGES_ALL = '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'; const GET_CHANGES_FILTERED = '89e95b76-444d-4c62-991a-0facbeda640c';

const SECRET_ATTRS = new Set(['unicodePwd', 'dBCSPwd', 'ntPwdHistory', 'lmPwdHistory', 'supplementalCredentials']); const wantsSecrets = requestedAttrs.some(a => SECRET_ATTRS.has(a));

// Baseline read requires GetChanges. if (!callerRights.has(GET_CHANGES)) return 'ACCESS_DENIED'; // Secret attributes require GetChangesAll. if (wantsSecrets && !callerRights.has(GET_CHANGES_ALL)) return 'ACCESS_DENIED';

// Notice what is NOT checked: caller's SPN, machine-group membership, // ticket service, source IP. The access gate is the ACL, full stop. return 'secrets returned'; }

const attacker = new Set([ '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2', '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2', ]); console.log(dcsyncAccessCheck(attacker, 'DC=contoso,DC=local', ['unicodePwd', 'ntPwdHistory'])); `}

Four generations, eleven years, no Generation 5 in sight. What is the single insight that lets all of this exist, and why has nobody patched it?

5. There Is No DC Check

The whole structural error of this protocol is one missing question. Specification [MS-DRSR] §4.1.10 defines the access check on IDL_DRSGetNCChanges as: does the calling principal hold the rights triad on the naming context being replicated? [@ms-drsr-spec] That is the whole gate. There is no second check that asks "is the caller's service principal name a domain-controller SPN?" or "is the caller's machine account in the Domain Controllers group?" or "was the caller's Kerberos service ticket issued for a DC service?" The spec is empirically and literally just an ACL check on the NC root.

The empirical proof that a non-DC client succeeds lives in Mimikatz's kuhl_m_lsadump.c and its DRSUAPI client surface in kull_m_rpc_drsr* [@mimikatz-repo]. Mimikatz is software running on a workstation. It binds to the DRSUAPI interface UUID, calls IDL_DRSGetNCChanges, and the call returns. The protocol's behavior is correct by specification. The security model is the bug.

A major feature added to Mimkatz in August 2015 is 'DCSync' which effectively 'impersonates' a Domain Controller and requests account password data from the targeted Domain Controller. DCSync was written by Benjamin Delpy and Vincent Le Toux. -- Sean Metcalf, ADSecurity, September 2015 [@sean-metcalf-dcsync-2015]

Read Metcalf's verb carefully: impersonates. The scare quotes are doing work. The Mimikatz client is not pretending to be a DC in any cryptographic sense. It is not forging a machine-account ticket. It is not spoofing an SPN. It is not bypassing any signature check.

It is honestly making an authenticated call as the principal it actually is -- some user or service account that happens to hold the rights triad -- and the protocol honestly responds because its gate is satisfied. The "impersonation" framing is operator vocabulary borrowed from the social model the protocol was written under.

The 1999 designers assumed only DCs would speak. By that social contract, anyone who speaks must be a DC. The spec encoded the social contract by way of not encoding it at all. The ACL was the whole gate because, in 1999, the ACL was always satisfied by something that was always a DC.

flowchart TD Start[IDL_DRSGetNCChanges request arrives] Start --> Q1{"Caller holds rights triad
on the NC root?"} Q1 -- yes --> Return[Return encrypted
secret attributes] Q1 -- no --> Deny[ERROR_DS_DRA_ACCESS_DENIED] Start -.-> Absent["What the check does NOT ask:
Is the caller a domain controller?
Is the SPN a DC SPN?
Is the machine in Domain Controllers?"] Absent -.-> Nothing[no second gate exists]

This is the article's intellectual fulcrum. The 1999 closed-population assumption -- only DCs speak this protocol -- survives in 2026 as an open-population reality (anyone with the rights speaks it), and the closed-population assumption is nowhere written down in the access-check code. The fix that would close the model would require a second gate. The spec did not write one. The implementation cannot synthesize one without breaking every legitimate consumer that already operates without one (more on this in §8).

Key idea: The protocol's design is correct. The security model is the bug. No patch can fix this without breaking Active Directory replication itself.

There is a temptation, on first encountering this, to assume the missing gate is an oversight that Microsoft will eventually fix. That intuition is wrong, and it is wrong for a deeper reason than "Microsoft has not gotten around to it." If the protocol is the bug and the protocol cannot be amended, what defenses can possibly work in 2026? That question carries us into the next section.

6. What 2026 Actually Ships Against This

If the protocol cannot be fixed, the defender's question is no longer "how do I prevent DCSync?" but "which layer catches which class of attempt?" Four production detection layers ship against this attack class in 2026. None of them is individually sufficient. A fifth layer -- the architectural one that would close the structural error -- does not exist and is not coming.

Posture: enumerate who holds the rights

The posture layer reads the static ACL on the Domain NC root and surfaces every principal that holds any of the three rights. Microsoft Defender for Identity ships this as an Accounts security posture assessment family, computed continuously from MDI's per-DC sensors [@mdi-security-posture-accounts]. Vincent Le Toux's PingCastle exposes it as the C-DCSync finding in its critical-risks section. Tenable Identity Exposure exposes it as an indicator of exposure. Christopher Keim's 2025 practitioner guide documents the PowerShell pattern that AD administrators without a posture-tool license can run on demand [@keim-dcsync-rights]:

Illustrative model of the posture-layer check. In production, replace SAMPLE_ACL with output from Get-Acl in PowerShell or python-ldap against the live Domain NC root.

GET_CHANGES = '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' GET_CHANGES_ALL = '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' GET_CHANGES_FILTERED = '89e95b76-444d-4c62-991a-0facbeda640c' TRIAD = {GET_CHANGES, GET_CHANGES_ALL, GET_CHANGES_FILTERED}

DEFAULTS = { 'BUILTIN\\Administrators', 'CONTOSO\\Domain Controllers', 'CONTOSO\\Domain Admins', 'CONTOSO\\Enterprise Admins', 'NT AUTHORITY\\ENTERPRISE DOMAIN CONTROLLERS', }

SAMPLE_ACL = [ {'principal': 'CONTOSO\\Domain Admins', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\Domain Admins', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\Enterprise Admins', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\Enterprise Admins', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\backup_svc_2017', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\backup_svc_2017', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\MSOL_a1b2c3', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\MSOL_a1b2c3', 'right': GET_CHANGES_ALL}, ]

residual = {} for ace in SAMPLE_ACL: if ace['right'] in TRIAD and ace['principal'] not in DEFAULTS: residual.setdefault(ace['principal'], set()).add(ace['right'])

for principal, rights in residual.items(): print(f"{principal}: {len(rights)} of 3 replication rights") `}

The residual set is the operational unit of work. In a freshly-installed domain it is empty. In a ten-year-old forest with a history of mergers and migrations it typically contains five to twenty entries -- a mix of legitimately delegated identity-sync products and forgotten service accounts from projects nobody on the current operations team remembers.

In Microsoft's Enhanced Security Administrative Environment and the BloodHound conventions, the set of principals and assets whose compromise yields domain-wide control. The `krbtgt` account, members of `Domain Admins` and `Enterprise Admins`, the Entra ID Connect MSOL_ sync account, and any non-default principal holding the rights triad on the domain root are all Tier Zero by construction. The Microsoft Entra ID (formerly Azure AD) Connect synchronization service account, created on-premises during Entra Connect installation. The account name uses an `MSOL_` prefix followed by a hex suffix. It legitimately holds the rights triad on the Domain NC root because it must replicate password hashes to the cloud directory; treating it as Tier Zero is the standard hardening recommendation. Microsoft Defender for Identity's (and ATA's earlier) internal baseline of which computers in the domain legitimately speak DRSUAPI to which DCs. Incoming `IDL_DRSGetNCChanges` requests are matched against this baseline; a request from a source outside the list fires the External ID 2006 alert.

An earlier scope document for this article quoted an MDI assessment titled verbatim "Remove non-admin accounts with DCSync permissions." That exact title does not appear on the live MDI Accounts security-posture-assessment page in 2026 [@mdi-security-posture-accounts][@mdi-security-posture-hybrid]. The surface exists -- MDI's Accounts and Hybrid security posture-assessment families together cover non-default principals with replication rights -- but the verbatim title was not reproducible.

Behavioral: catch the act after it fires

The behavioral layer watches network traffic and event logs for the act of DCSync or DCShadow as it happens. Microsoft's first-party stack lives in Defender for Identity and ships three canonical alerts [@mdi-alerts-classic]:

External ID 2006 -- "Suspected DCSync attack (replication of directory services)." Credential Access (TA0006), Persistence (TA0003). Technique T1003.006. Severity High. Trigger: a replication request is initiated from a computer that is not a domain controller.
External ID 2028 -- "Suspected DCShadow attack (domain controller promotion)." Defense Evasion (TA0005). Technique T1207. Trigger: a machine in the network tries to register as a rogue domain controller.
External ID 2029 -- "Suspected DCShadow attack (domain controller replication request)." Defense Evasion (TA0005). Technique T1207. Trigger: a suspicious replication request is generated against a genuine domain controller, indicative of DCShadow.

The product lineage is Microsoft Advanced Threat Analytics 1.7 (April 2017, where DCSync was covered under the umbrella "Unusual Protocol Implementation enhancements" detection category [@ata-v17-release-notes]); Azure Advanced Threat Protection (2018, where Tali Ash's July 24, 2018 Microsoft Tech Community post announced the two named DCShadow detections that became 2028 and 2029 [@tali-ash-azure-atp-dcshadow]); and Defender for Identity (the Microsoft Ignite 2020 rebrand, week of September 22-24, 2020 [@rcpmag-defender-rebrand]). The detection content carries forward unchanged across product renamings; what changes is the portal it surfaces in [@mdi-whats-new].

Open-source SIEM equivalents implement the same detection via Event ID 4662 on the domain object. The Sigma rule Mimikatz DC Sync (id 611eab06-a145-4dfa-a295-3ccc5c20f59a) fires on Event ID 4662 where Properties contains any of the three rights GUIDs or the literal string Replicating Directory Changes All, with AccessMask=0x100 [@sigma-rule-dcsync]. Splunk's parallel detection Windows AD Replication Request Initiated by User Account (rule 51307514-1236-49f6-8686-d46d93cc2821) implements the equivalent SPL search with the same MITRE T1003.006 annotation and the same known-false-positive list (Azure AD Connect, dcdiag.exe /Test:Replications) [@splunk-research-dcsync].

The SACL-event detection layer (Sigma + Splunk + every other SIEM-side implementation) requires that the operator first enable Advanced Security Audit policy Audit Directory Services Access under DS Access, with SACLs on the domain root auditing the three rights against Everyone, Domain Computers, and Domain Controllers. A fresh-install AD does not have these SACLs by default [@splunk-research-dcsync]. The detection rule's documentation calls out the prerequisite explicitly; many operators discover it only after wondering why their Splunk dashboard is silent.

Network: NDR on the DRSUAPI interface

The network layer parses DCE/RPC traffic on the wire, identifies the DRSUAPI interface by its UUID, and fires when an IDL_DRSGetNCChanges call originates from a source outside the legitimate-DC baseline. The canonical 2025 reference is Trellix Advanced Research Center's "Silent Domain Hijack: Uncovering the DCSync Attack and Detecting with Trellix NDR", published in week 50 of 2025 [@trellix-silent-domain-hijack]. Equivalent capability ships in Microsoft Defender for Identity's network analytics layer (the same sensor that powers External ID 2006) [@mdi-alerts-classic].

The Trellix writeup is explicit about the architecture: "Trellix NDR detects replication protocol abuse by analyzing abnormal DCE/RPC and MS-DRSR traffic. It detects DCSync-like behavior when replication requests are sent from non-DC hosts or unusual users" [@trellix-silent-domain-hijack]. The detection is independent of host-side telemetry, so it survives EDR tampering and works in environments where a DC is un-sensored from MDI's perspective.

Graph: BloodHound traverses the permission graph

The graph layer was built specifically for Generation 4. BloodHound, originally released by Andy Robbins, Rohan Vazarkar, and Will Schroeder at DEF CON 24 on August 6, 2016, models "you have DCSync rights to the domain" as a directed edge from a principal to the domain node, computed by combining the separately-collected GetChanges and GetChangesAll ACEs through nested-group membership [@wald0-bloodhound-intro][@defcon24-bloodhound-pdf][@bloodhound-edge-dcsync]. An operator queries "shortest path from any compromised principal to the DCSync edge into a Domain node" and gets back every transitive route into the rights triad.

The 2024-2026 release cadence is dense and matters:

BloodHound v6.0 (September 30, 2024) improved logic for identifying and creating complex edges requiring multiple permissions, including DCSync, when Authenticated Users or Everyone groups are involved [@bloodhound-v6-0-release-notes]. This closed a long-standing blind spot in which rights granted to a wildcard principal (the worst kind of delegation drift, often dating from compatibility settings in pre-2003 forests) were not surfaced as DCSync edges.
BloodHound v6.3 (December 9, 2024) introduced the Butterfly algorithm -- bi-directional risk analysis. Where the historical query was "which principals can attack this target?", Butterfly adds "which targets can be attacked from this compromised principal?" SpecterOps describes the algorithm in their blog post Unwrapping BloodHound v6.3 with Impact Analysis: "This is a massive upgrade to BloodHound Enterprise's risk analysis capability with a new algorithm we call 'Butterfly'" [@specterops-butterfly-blog][@bloodhound-v6-3-release-notes].
BloodHound v8.0 (July 29, 2025) introduced OpenGraph, generalizing the graph engine to model attack paths across non-AD systems (GitHub, 1Password, NPM, Snowflake) using the same Cypher front-end. The DCSync edge remains AD-specific; OpenGraph's relevance is that hybrid-cloud principals can now be modeled end-to-end [@bloodhound-v8-0-release-notes].

The graph layer is the only one that catches multi-hop chains to the rights triad. A principal A with GenericAll on group B, where B has the DCSync triad, is invisible to MDI's posture assessment but stands out as a one-hop path in BloodHound.

flowchart TD subgraph Posture[Posture layer] P1[MDI Accounts assessments] P2[PingCastle C-DCSync] P3[Keim PowerShell pattern] end subgraph Behavioral[Behavioral layer] B1[MDI 2006 / 2028 / 2029] B2[Sigma 611eab06] B3[Splunk 51307514] end subgraph Network[Network layer NDR] N1[Trellix NDR] N2[MDI per-DC sensor] N3[CrowdStrike DCE/RPC IoA] end subgraph Graph[Graph layer] G1[BloodHound DCSync edge] G2[v6.3 Butterfly Impact] G3[v8.0 OpenGraph] end P1 --> SOC[SOC alert queue] P2 --> SOC P3 --> SOC B1 --> SOC B2 --> SOC B3 --> SOC N1 --> SOC N2 --> SOC N3 --> SOC G1 --> SOC G2 --> SOC G3 --> SOC

The full layer-by-layer comparison is the load-bearing matrix of the entire 2026 SOTA:

Layer	What it inputs	What it detects	What it misses	False-positive class	Detection latency	Cost
Posture	NC-root ACL	Direct grant of the rights triad to a non-default principal	Multi-hop transitive paths; legitimate-principal abuse	Identity-sync products (Entra Connect MSOL_, third-party HR-IDM); legitimately delegated backup agents	24h score recomputation; ACE changes near real time	Built in to MDI; PowerShell variant free
Behavioral	Event ID 4662 or sensor-captured DRSUAPI traffic	The act of DCSync, or the DCShadow registration / replication, after it happens	Pre-attack staging; compromised-DC speaker; un-sensored DC blind spot	Azure AD Connect syncs; `dcdiag.exe /Test:Replications`	Minutes (alert "after the fact")	MDI license; Sigma / Splunk free with SACL config
Network	DCE/RPC packet capture	Wire signature of `IDL_DRSGetNCChanges` from non-DC source	Encrypted RPC payloads (per-principal granularity); sub-DC replicas misclassified	Same as behavioral plus Samba-DC peers	Seconds (passive inspection)	Commercial NDR appliance
Graph	LDAP-collected ACEs and group nesting	Multi-hop graph paths that could reach the rights triad	Net-new ACEs created after the last collection	Stale data showing principals that no longer hold the right	Hours to weeks (collection cadence)	BloodHound CE free; BHE commercial
Architectural (un-shipped)	TPM-attested DC machine identity	Pre-empts non-DC speaker entirely	Compromised DC speaker; rogue `nTDSDSA` registration	N/A	N/A (preventive)	Requires Microsoft protocol amendment

Four layers, dozens of products, no shortage of detections. Why isn't the problem solved?

7. Which Gap Does Each Defense Close?

The matrix in §6 has one structural observation that earns its keep. Read down the What it misses column. Each detection layer has a class of cases it cannot see. The posture layer cannot see transitive paths. The behavioral layer cannot see pre-attack staging or compromised-DC speakers. The network layer cannot see encrypted RPC payloads. The graph layer cannot see net-new ACEs created after the last collection. That is the load-bearing reason a mature defender runs all four in parallel instead of picking one.

Run a thought experiment. Suppose you ship only the posture layer. Your MDI assessment is green: no non-default principals hold the rights triad. An attacker compromises a workstation belonging to an unrelated business unit, finds that the BU has GenericAll on a group LegacyApp_Operators that itself has WriteDACL on the BackupOperators group, and adds themselves to BackupOperators. BackupOperators inherits a forgotten 2014 delegation of the rights triad through three levels of nesting. Then DCSync runs.

The posture layer never saw this because the residual list at the NC root is the four defaults. The graph layer would have surfaced the path. The behavioral or network layer would have fired the moment the DCSync call hit the wire. Without those layers, your green dashboard is a single-layer fantasy.

Now consider the inverse. You ship only the behavioral layer. MDI fires External ID 2006 -- but only after the request hits the DC. Your SOC's mean response time is twelve minutes. The attacker's mean complete-the-extraction time is sixty seconds. The detection is real; the response window is not.

The same structural observation applies on the attack side. The four attack primitives have very different precondition costs:

Attack primitive	Pre-condition	Output	Default detection layer	Tier of damage
DCSync via Mimikatz	Rights triad on NC root	Every secret-attribute value for one or all principals	MDI 2006; Sigma 611eab06; Splunk 51307514; NDR	Domain takeover (via Golden Ticket from `krbtgt`)
DCSync via Impacket	Same as Mimikatz; no on-target binary footprint	Same as Mimikatz, plus PtH / PtT auth modes	Same as Mimikatz (wire signature is identical)	Domain takeover
DCShadow	Domain Admin, local administrator on a DC, or `KRBTGT` hash (for rogue-DC registration) [@mitre-t1207][@dcshadow-com]	Arbitrary directory write, SACL-silent	MDI 2028 + 2029	Domain persistence (SID-history, AdminSDHolder ACE re-grant)
Gen-4 chains	Any ACE that transitively leads to the triad	Reach DCSync, then DCSync's output	BloodHound DCSync edge inbound paths	Domain takeover (composite)

DCSync via Mimikatz and via Impacket [@impacket-secretsdump] share the output (domain takeover via credential theft) and the default detection (the wire signature is the same). Their pre-conditions are identical. The Hacker Recipes documents Impacket's invocation surface for both pass-the-hash and pass-the-ticket modes [@hacker-recipes-dcsync]. This is why Impacket's secretsdump.py -just-dc has become the universal red-team and IR tool, while Mimikatz remains the reference implementation that every blue-team detection still names.

The Generation-4 row is the interesting one. Its pre-condition is dramatically cheaper than the other three (any ACE that leads to the triad, rather than the triad in hand). Its detection is by graph traversal, not by wire signature. This is why the 2024-2026 frontier in this space has been the graph layer: the attack-side cost asymmetry favors the chain-finding problem, so the defense-side investment has landed there.

A reader who has internalized the "no DC check" observation will naturally ask: surely the obvious architectural fix is to add a caller-machine-identity check? CVE-2020-1472, popularly known as Zerologon, is the counterexample. Secura's September 2020 whitepaper, published approximately one month after Microsoft's August 11, 2020 patch, documented that the Netlogon protocol's `ComputeNetlogonCredential` AES-CFB8 implementation used an all-zero initialization vector. An attacker who sends an all-zero `ClientChallenge` exploits the IV bug to authenticate with roughly 1-in-256 probability per attempt, then calls `NetrServerPasswordSet2` to reset the DC's machine account password (commonly to all zeros) and becomes that DC for protocol purposes [@secura-zerologon-whitepaper]. After Zerologon-class compromise, the attacker *is* a DC. Any architectural caller-machine-identity check on `IDL_DRSGetNCChanges` would have been satisfied. Zerologon is the canonical worked proof that promoting the access-check from "rights" to "rights and DC identity" raises the bar but does not change the class.

Note: Every detection layer in this space has a class of cases it cannot see. Mature defenders run all four (posture, behavioral, network, graph) because each layer is the only answer for a specific class of inputs, and accept that the un-shipped fifth layer (architectural) would only narrow the gap, not close it. Single-layer deployments produce confident but incomplete coverage.

If even the hypothetical perfect architectural fix would not close the class, what are the actual theoretical limits of any possible defense?

8. Why the Protocol Cannot Be Fixed

Two structural ceilings bound any conceivable MS-DRSR amendment. Both are provable from the specification's own definition of what it must do; both have been corroborated by the post-2018 industry consensus that detection (not prevention) is the only viable defender posture.

Ceiling 1: replicated secret material is the data the protocol exists to carry. MS-DRSR is the mechanism by which Active Directory's multi-master replication invariant holds. If IDL_DRSGetNCChanges did not return secret attributes -- unicodePwd, dBCSPwd, ntPwdHistory, lmPwdHistory, supplementalCredentials -- then a password change on DC-A would not converge to DC-B within the replication interval. AD's "any DC accepts any write and the others catch up within minutes" property would collapse [@ms-drsr-spec]. The protocol cannot stop returning secrets without ceasing to be the protocol. This is why "disable MS-DRSR" appears on every list of options that look attractive in a slide deck and break replication in production within minutes of being applied.

Ceiling 2: a machine-identity check on the caller would shift the attack class, not close it. Suppose Microsoft amended the access check on IDL_DRSGetNCChanges to require, in addition to the rights triad, a cryptographic proof that the caller's machine account is in the Domain Controllers group -- for example, that the call was made under a Kerberos service ticket issued for a DC SPN. This would defeat the Mimikatz-from-workstation case. It would also defeat every legitimate integration that today holds the rights triad on a non-DC service account: the Entra ID Connect MSOL_ account, third-party HR identity-management connectors, every backup and disaster-recovery tool that integrates at the AD level.

Worse, the new check would shift the attack class to compromising a DC's machine account -- CVE-2020-1472 Zerologon being the canonical worked example (see the §7 Aside for the mechanism). After a Zerologon-class compromise the attacker is a DC, so promoting the speaker check from (rights) to (rights and DC-identity) raises the bar but does not change the class [@secura-zerologon-whitepaper].

flowchart TD Fix[Proposed MS-DRSR fix] Fix --> A[Stop returning secrets
in IDL_DRSGetNCChanges] Fix --> B[Add machine-identity check
on the caller] A --> A1[AD multi-master replication breaks
password changes do not propagate] B --> B1[Legitimate integrations break
MSOL_ account, HR IDM, backup tools] B --> B2[Attack shifts to compromised DC
machine accounts e.g. Zerologon
CVE-2020-1472]

The honest structural fix would require a different replication architecture: a TPM- or HSM-attested DC machine identity, bound to a sealed replication key, with secret attributes encrypted under that key on the wire. No caller without the sealed key (or its hardware-bound equivalent on a different DC) could ever decrypt the response.

Microsoft has not announced any such architecture. Its closest published precedent in the Windows security stack is the LSAIso trustlet that Credential Guard uses for LSASS isolation -- a per-host isolation primitive applied to a per-host secret store. Applying the same idea to a multi-party wire protocol that must interoperate with twenty-five years of installed identity-sync tooling is a different engineering problem at a different scale. Microsoft has not committed to it.

Key idea: The replication attack class is structurally permanent. The honest defender response is detection-and-response, not prevention.

This is the article's humility moment. The reader who arrived at §5 thinking "this is fixable" should now understand why eleven years of attack/defense iteration have produced detection layers, not protocol revisions. The four-layer detection architecture is not a placeholder while we wait for Microsoft to ship the real fix. It is the real fix, conditional on the constraint that the protocol's job description does not change.

If the protocol is structurally unfixable, what exactly does 2026 still not solve operationally?

9. What 2026 Still Cannot Do

Five problems sit on the open-questions register in 2026. Each is documented in the literature. None has a satisfying answer.

The DCShadow gap window. MDI's External ID 2029 alert fires on the rogue DC's replication request, which is structurally after the rogue nTDSDSA registration has been committed. The alert documentation describes the detection as firing after the fact [@mdi-alerts-classic]. An attacker who completes the register-replicate-deregister cycle inside the alert's batch interval commits the persistence write before any SOC responder sees the alert. External ID 2028 (rogue promotion) fires earlier in the kill chain and partially closes the gap, but the gap is structural to the alert-batch model. The directory write that DCShadow lands -- a SID-history injection, an AdminSDHolder ACE re-grant -- survives the alert.

Encrypted-channel DCSync. DRSUAPI clients that negotiate AUTH_LEVEL_PKT_PRIVACY on the RPC binding (the modern hardened-DC default) encrypt the request and response bodies on the wire. Passive NDR sensors that depend on parsing the IDL_DRSGetNCChanges request to determine which principal is being targeted lose per-principal granularity.

The interface-bind packet is still in clear, so the existence of a DRSUAPI call is still visible, but the payload is not. The Microsoft channel-binding rollout that began in late 2023 (targeting LDAP rather than DRSUAPI, but cementing the broader trend toward encrypted directory traffic) makes this gap permanent on the wire side [@microsoft-ldap-channel-binding-kb4520412]. Detection moves into the DC itself via the MDI sensor model.

The legitimate-principal-compromise non-detection. A hijacked Domain Admin session that uses its rightful DCSync ability triggers no layer. The posture layer sees a default principal. The behavioral layer sees a request from a DC or admin workstation that the Replication Allow List baseline accepts. The network layer sees the same. The graph layer sees the principal as a default Tier Zero member. The MDI alert is explicit: the trigger is "a computer that isn't a domain controller" -- a compromised legitimate principal acting from a legitimately-baselined workstation does not fire it [@mdi-alerts-classic].

This is the failure mode that catches mature SOCs. The attacker who already has Domain Admin does not need to attack DCSync detection because DCSync detection is not designed for legitimate principal abuse. UEBA-style per-principal anomaly detection ("this DA has not run DCSync in 90 days; this DA running DCSync at 03:00 from a workstation it has not used before is anomalous") is the partial answer. No production product currently delivers it with low enough false-positive rates to be operationally useful for already-Tier-Zero principals.

Cross-forest replication abuse is under-instrumented. The interaction of DS-Replication-Get-Changes-In-Filtered-Set with the SPN-suffix routing matrix in multi-forest environments is poorly covered in public detection guidance. Large enterprises with M&A history hold dozens of trusts; the cross-trust edges are the least-audited surface in their identity architecture. BloodHound's SharpHound collector can enumerate cross-trust data, and v6.0's wildcard-principal fix improves the picture, but no fully automated detection pattern exists [@bloodhound-v6-0-release-notes].

Delegation-drift residual long tail. Even with the MDI Accounts security posture assessment perfectly tuned, the long tail of forgotten ACE delegations across a twenty-five-year-old forest with mergers, acquisitions, decommissioned products, and migrations remains the canonical entry point. Christopher Keim frames it unambiguously [@keim-dcsync-rights]:

"The defaults aren't the problem. The problem is delegation drift, backup agents, identity sync products, and application service accounts accumulate these rights over time, often with no documentation and no review." -- Christopher Keim, *"DCSync Attack: Finding and Fixing Replication Rights in Active Directory"* (2025) [@keim-dcsync-rights]

The posture-layer detection is necessary but not sufficient; the human-process loop -- documented ownership, periodic review, removal of unjustified ACEs -- is what closes the residual. Most enterprise SOCs are not staffed to run this loop at the cadence the residual requires.

Open problem	Why it matters	Current best partial result
DCShadow gap window	Persistence write commits before SOC sees the alert	Configure MDI to surface External ID 2028 (rogue promotion) with automated investigation and response to block RPC traffic from the suspected source [@mdi-credential-access-alerts]
Encrypted-channel DCSync	Passive NDR loses per-principal granularity	Hybrid deployment: NDR for cross-DC visibility, MDI on-DC sensor for per-principal granularity [@trellix-silent-domain-hijack]
Legitimate-principal compromise non-detection	The Tier Zero principal who already has DCSync rights triggers nothing	Reduce the count of DCSync-capable principals to a number a human can monitor; surface their DCSync activity to a high-severity review queue
Cross-forest replication abuse	Cross-trust DCSync paths are not enumerated by default	SharpHound trust-collection methods; manual BloodHound inspection of foreign-domain principals
Delegation-drift residual long tail	Posture surfaces the principals; humans still have to decide which are legitimate	Quarterly posture review with documented justification per non-default principal

What can a defender actually do on Monday morning, given all of the above?

10. What a Defender Does on Monday Morning

Three action lanes, in priority order.

Lane 1: inventory the rights triad

Read the Domain NC root's ACL. Filter on the three rights GUIDs. Subtract the four default principal sets plus any legitimately delegated identity-sync product (Entra ID Connect's MSOL_ account is the canonical exclusion). Every entry that remains gets a documented owner and a documented justification, or the ACE gets removed.

Operator-facing inventory script. The browser-runnable demo uses a hardcoded SAMPLE_ACL; in production, replace the SAMPLE_ACL with output from one of: PowerShell: Get-Acl "AD:$( (Get-ADDomain).DistinguishedName )" python-ldap: ldap_search(ncroot_dn, attr='nTSecurityDescriptor')

DEFAULT_OK = { 'BUILTIN\\Administrators', 'CONTOSO\\Domain Controllers', 'CONTOSO\\Domain Admins', 'CONTOSO\\Enterprise Admins', 'NT AUTHORITY\\ENTERPRISE DOMAIN CONTROLLERS', }

MSOL_ accounts: legitimate Entra ID Connect sync principals. Exclude by prefix, never by exact name (the suffix is random).

def is_known_legitimate(principal): return principal in DEFAULT_OK or '\\MSOL_' in principal

SAMPLE_ACL = [ {'principal': 'CONTOSO\\Domain Admins', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\MSOL_a1b2c3d4', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\backup_svc_2017', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\hr_idm_connector', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\fileserver_old$', 'right': GET_CHANGES_ALL}, ]

findings = [] for ace in SAMPLE_ACL: if ace['right'] not in TRIAD: continue if is_known_legitimate(ace['principal']): continue findings.append(ace['principal'])

print("Principals to investigate:") for p in sorted(set(findings)): print(f" - {p} -> document owner or remove ACE") `}

Anything in the Principals to investigate output is either a legitimately delegated service (document the owner and add to your exclusions; treat as Tier Zero) or a forgotten ACE from a project nobody remembers (remove it). Christopher Keim's framing is the operationally useful one: every common culprit is a backup tool, an identity-governance tool, or a service account from a long-dead migration [@keim-dcsync-rights].

The Microsoft Entra ID Connect synchronization service account, created on-premises during Entra Connect installation with an `MSOL_` prefix and a random hex suffix, legitimately holds the rights triad on the Domain NC root. It must -- it has to replicate password hashes to the cloud directory so that Entra ID can validate cloud logons against on-premises credentials. Removing its ACE breaks Entra ID password hash sync within a single replication interval, and your help desk will know about it.

The right answer is not to remove the ACE. It is to treat the MSOL_ account as Tier Zero. Dedicated host (the Entra Connect server itself, hardened as a DC-tier asset). No interactive logon. Multi-factor authentication on any privileged use. Conditional access policies that block sign-in from anything other than the Entra Connect service identity. The MDI Hybrid security posture-assessment family documents the surrounding controls [@mdi-security-posture-hybrid].

Lane 2: enable the canonical alerts and audit

Three configuration items.

First, ensure Microsoft Defender for Identity (or an equivalent identity-threat-detection product) is deployed with a sensor on every DC. The un-sensored-DC gap that the MDI alert documentation explicitly warns about creates a structural blind spot that an attacker will preferentially target [@mdi-alerts-classic].

Second, enable Advanced Security Audit policy Audit Directory Services Access under DS Access and apply SACLs on the Domain NC root that audit the three replication rights against Everyone, Domain Computers, and Domain Controllers. This is what makes Event ID 4662 fire on the request, which is what the Sigma 611eab06 and Splunk 51307514 rules consume [@sigma-rule-dcsync][@splunk-research-dcsync]. A fresh-install AD does not have these SACLs by default; the most common reason a SIEM dashboard for DCSync is silent is that the SACL never got applied.

Third, deploy or configure NDR coverage on the inter-DC subnet, with a rule that fires on DRSUAPI bind requests originating from source IPs outside the legitimate-DC baseline. Trellix NDR, Microsoft's MDI sensor, CrowdStrike Falcon, and community Zeek/Suricata rulesets all implement this [@trellix-silent-domain-hijack]. Where commercial NDR is out of budget, Sysmon with the SwiftOnSecurity or Olaf Hartong modular configuration surfaces Event ID 3 (NetworkConnect) and Event ID 22 (DnsQuery) outbound from non-DC hosts to DC RPC endpoints; a SIEM correlation rule can combine this endpoint-side signal with Event ID 4662 on the DC to approximate the network-plus-host signature without an appliance budget.

Lane 3: run BloodHound on the domain quarterly

Collect with SharpHound at minimum quarterly. Continuous collection if BloodHound Enterprise is available. Run the canonical query for the DCSync edge into the domain node. Trace inbound paths. Close the longest path first -- the longest paths are the ones a human operator is least likely to have noticed and most likely to have been delegated decades ago for a reason nobody remembers.

The v6.0 wildcard-principal fix is particularly worth a re-run on any forest that has been operated since before 2003: legacy Authenticated Users or Everyone ACEs on the domain root are exactly the kind of thing that survived a Server 2003 upgrade silently and never showed up in any subsequent audit [@bloodhound-v6-0-release-notes]. The v6.3 Butterfly algorithm lets you query the inverse view -- which targets fall if this principal is compromised? -- which is the right question to ask about any newly-discovered non-default DCSync holder [@specterops-butterfly-blog][@bloodhound-v6-3-release-notes].

What does not work

Four common misbeliefs are worth naming.

Note: See §1 -- Credential Guard does not stop DCSync. The secret transits remote-to-remote (a DC's NTDS.dit to the attacker's process), never local-to-LSASS, so the trustlet's isolation boundary has no jurisdiction over the call [@credential-guard-considerations]. Credential Guard is the right control for the local-memory attack surface and the wrong control for the network-protocol attack surface.

Note: After a confirmed DCSync of krbtgt, rotate the krbtgt account password twice, with at least ten hours between rotations. The first rotation invalidates the old key after the current Kerberos ticket lifetime expires. The second rotation invalidates the previous old key, which the directory stores alongside the current key for compatibility during replication convergence. Rotating only once leaves Golden Tickets forged from the dumped key valid for the duration of the second key. Rotating twice ten hours apart is what closes the window [@microsoft-new-krbtgtkeys]. (And neither rotation removes the ACE that allowed the dump in the first place: come back to Lane 1.)

Renaming krbtgt does nothing. The account's Relative Identifier (RID 502) is fixed by AD's design and is what the TGT signing key derives against, not the sAMAccountName [@microsoft-well-known-sids]. Renaming it to krbtgt-old-do-not-use confuses operators, not attackers.

Disabling MS-DRSR is not an option. The protocol is what makes AD replication work. Blocking opnum 3 at the RPC layer or refusing the DRSUAPI bind stops DCSync and stops every DC in the forest from talking to every other DC. Replication grinds. Password changes do not propagate. Domain joins fail. Within hours, the directory is split-brain across DCs, and within days, it is unrecoverable without DR-grade restore from backup: Microsoft's own AD-replication troubleshooting documentation walks the lingering-object pathology that produces exactly this split-brain when DCs stop replicating for longer than the tombstone lifetime [@microsoft-ad-lingering-objects].

On any DC, run `auditpol /get /subcategory:"Directory Service Access"` from an elevated prompt. If the output reads `No Auditing`, your Sigma / Splunk SACL-event detection will not fire because Event ID 4662 is not being generated. Enable with `auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable`, then apply the SACL on the domain root as described in the Splunk rule's implementation notes [@splunk-research-dcsync].

The six FAQ items in the next section cover the misconceptions that did not fit into any single lane.

11. Frequently Asked Questions

No. The access check on `IDL_DRSGetNCChanges` requires both the baseline `DS-Replication-Get-Changes` right *and* `DS-Replication-Get-Changes-All` to read secret attributes [@ad-schema-get-changes][@ad-schema-get-changes-all]. The *All* suffix unlocks the secret attribute set given the baseline right; it is not a self-sufficient gate. Christopher Keim's PowerShell pattern filters on both GUIDs together [@keim-dcsync-rights]. Confidential-flag attributes additionally require `DS-Replication-Get-Changes-In-Filtered-Set`. Some detection rules (Sigma 611eab06 included) accept either GUID in the SACL event because the operational cost of a false positive on the broader filter is lower than the risk of missing one of the two required ACEs being present without the other [@sigma-rule-dcsync]. No. Credential Guard isolates LSASS-resident secrets in a separate virtual trust level so that local-memory attacks (Mimikatz `sekurlsa::logonpasswords`, comsvcs.dll mini-dumps of `lsass.exe`, and similar) cannot read cached credentials. DCSync does not touch the attacker's LSASS at all. The secret transits from a remote DC's NTDS.dit, over an encrypted MS-DRSR session, into the attacker's process memory. Microsoft's Credential Guard documentation lists the scenarios Credential Guard does and does not cover; MS-DRSR-based network credential extraction is not in scope [@credential-guard-considerations]. This is one of the clearest examples in the Windows security model of a control that is right for one attack surface and orthogonal to another. Not anymore. The BlueHat IL 2018 "your million-dollar SIEM goes blind" framing was correct in 2018 against SIEMs that monitored only object-modification events: the replication writes are SACL-silent. By July 24, 2018, Tali Ash announced Azure ATP's two new preview detections, which fired on the rogue-DC promotion fingerprint (creating an `nTDSDSA` object in the Configuration NC) and the replication request from the rogue, respectively [@tali-ash-azure-atp-dcshadow]. Those detections carried forward as Microsoft Defender for Identity External IDs 2028 and 2029 [@mdi-alerts-classic]. The writes themselves remain SACL-silent; the *registration* fingerprint that has to precede them is not. The honest contemporary statement is "DCShadow's writes are silent, but the rogue-DC scaffolding is not, and a sensored DC catches the scaffolding." A skilled attacker who completes the register-replicate-deregister cycle inside the alert batch interval may still commit the persistence write before SOC response. No. The protocol's design is the issue. Microsoft has not announced any MS-DRSR amendment that would change the `IDL_DRSGetNCChanges` access check, because amending the access check breaks legitimate non-DC consumers (the Entra ID Connect MSOL_ account is the most prominent) and shifts the attack class to compromised DC machine accounts (Zerologon is the worked example [@secura-zerologon-whitepaper]). The "fixes" that have shipped since 2015 are all detection: ATA 1.7 (April 2017) [@ata-v17-release-notes], Azure ATP (2018) [@tali-ash-azure-atp-dcshadow], Microsoft Defender for Identity (post-Ignite 2020 rebrand) [@rcpmag-defender-rebrand][@mdi-whats-new], and the posture-assessment families that surface non-default rights triad holders [@mdi-security-posture-accounts]. The protocol itself is the same protocol it was in Windows 2000 Server. The MSOL_ sync account legitimately holds the rights triad on the Domain NC root because it must replicate password hashes to Entra ID. Treat it as Tier Zero with the hardening profile listed in §10's MSOL_ Aside (dedicated hardened host, no interactive logon, MFA on privileged use, conditional access restricted to the Entra Connect service identity) [@mdi-security-posture-hybrid]. Critically, do *not* remove the ACE from the Domain NC root: doing so breaks Entra ID password hash sync within one replication interval, and your help desk will know about it within hours. No. DCSync is over DRSUAPI/MS-DRSR, not over LDAP. The directory's LDAP service refuses to return `unicodePwd` and related secret-attribute values regardless of caller privilege, because the attribute is marked confidential and the LDAP read path does not honor the replication extended rights. There is no "DCSync over LDAP" technique because LDAP simply does not return the data; MITRE T1003.006 names DRSUAPI explicitly as the protocol vector [@mitre-t1003-006]. Operators occasionally confuse this with LDAPS (LDAP over TLS) or with the November 2023 LDAP signing and channel-binding rollout, both of which are channel-protection concerns rather than credential-read concerns.

A final observation, since the closing should add something new. The protocol that this article calls structurally unfixable is not unusual. Most Microsoft security primitives that survive long enough enter the same regime -- the LSASS surface, the Kerberos delegation surface, the SMB authentication surface -- where the only honest answer is detection in depth because the protocol's job description and its abuse surface are the same surface viewed from different chairs.

The thing that makes MS-DRSR notable is the clarity with which the structural error is visible. Read §4.1.10 once and you are done. Everything from §6 onward is the industry's slow accumulation of detection layers around a gate that cannot be moved. Twenty-five years in, the gate is still where it was on February 17, 2000, and the four layers around it are still under active engineering.