Active Directory Attack Paths: ACL Abuse and the BloodHound View

The problem is not that Active Directory has too many objects. It is that Active Directory attack paths turn ordinary permissions into routes to domain control.

An ACL entry, nested group, service account, or administrator session may look harmless alone. BloodHound connects those facts. A standard user can control a help desk group, the group can reset a service identity, that identity can administer a server where a domain administrator has a session, and the path ends at Tier 0.

Finding the route is only half the work. Defenders need to decide which edge to remove, who owns it, what business process depends on it, and how a fresh collection will prove the route is gone. A graph without that operating discipline becomes another alarming dashboard.

What are Active Directory attack paths?

Active Directory attack paths are chains of relationships that let one principal gain control over a more powerful object. Principals include users, computers, groups, and service identities. Relationships include membership, local administration, sessions, delegated rights, Group Policy control, password reset authority, replication rights, and trust between domains.

A path does not require a software vulnerability. Every edge may be an intended feature. Trouble starts when separate permissions compose into authority nobody meant to grant. The directory answers each narrow access check correctly while the whole chain produces a result the organization never approved.

This is one part of a lateral movement and attack paths program. Network reach and endpoint state still matter. BloodHound can show that an account is allowed to administer a computer. It cannot prove the computer is reachable from the current foothold, that the account still has a live session, or that another control blocks the action. Operators have to join those facts.

How does BloodHound show Active Directory attack paths?

BloodHound models directory objects as nodes and abusable relationships as directed edges. SharpHound collects the relevant directory, local group, session, trust, and certificate data. BloodHound stores the result as a graph, then answers path questions that are painful to solve with spreadsheets.

Start with a controlled source set. Mark test accounts, standard users, exposed service identities, or principals tied to a known incident as owned. Define Tier 0 and other high consequence targets. Then ask for paths between those sets. Shortest paths help an analyst understand the route. Repeated edges across many paths help the remediation team decide what to change.

Collection scope creates limits. Session data is transient. Local group data can age. ACLs may change between snapshots. Hybrid routes can cross Active Directory, Entra ID, cloud roles, management agents, and secret stores. Write the collection time beside every decision. A path based on a session from last month is a lead, not proof.

Which ACL abuse paths matter most?

ACL abuse is dangerous because the permission often looks administrative rather than hostile. GenericAll can grant broad control. GenericWrite can let a principal change useful attributes. WriteDACL can change who has rights over an object. WriteOwner can become control of the object's permissions. Password reset rights can take over another user without knowing the old password.

Replication rights deserve immediate attention because they can expose credential material for the domain. Control over a Group Policy Object can become code execution on every linked computer. Rights over certificate templates, enrollment services, or certificate authorities can create indirect routes to privileged authentication. The edge name is not the priority. The reachable target and current prerequisites set the priority.

Nested groups hide ownership. A user may not appear in Domain Admins and still inherit a path through two operational groups and one delegated reset right. Review effective control, not direct membership. The least privilege operating model explains how to replace inherited standing access with narrower roles and approved elevation.

Why do sessions and credentials change the graph?

A privileged session can turn an ordinary server into a bridge. If an administrator signs into a lower trust host and leaves reusable material behind, anyone who controls that host may gain a route to the administrator's authority. That is why the source device of an administrative session matters as much as the destination.

Password reuse creates another invisible edge. One local administrator password shared across 200 servers turns one compromised host into 199 possible next hops. A service account used across application and management tiers does the same thing. BloodHound models some of these relationships, but endpoint telemetry and authentication logs are needed to confirm which credentials and sessions exist now.

Microsoft's 2025 Digital Defense Report, published in October 2025, found that password spray accounted for 97 percent of identity attacks. Microsoft also analyzed 38 million identity risk detections on an average day. Those numbers make a plain point: weak and reusable identity paths remain cheaper for attackers than exotic code.

How can defenders audit privileged group membership safely?

Start with a read only inventory before changing permissions. Microsoft's official Get-ADGroupMember documentation confirms that the cmdlet accepts a group identity and the -Recursive switch expands nested membership. Run it from an approved administrative workstation with an account allowed to read the directory.

Get-ADGroupMember -Identity "Domain Admins" -Recursive |
  Select-Object Name, ObjectClass, DistinguishedName

Export the result with the domain, collection time, and command used. Compare it with the previous approved list. Then trace who can change the group, reset its members, edit linked policy, or control the administrative devices those members use. Membership is one path. Authority over membership is another.

What changed in BloodHound during 2026?

BloodHound's open query ecosystem changed how it marks privileged targets. The official BloodHound Query Library notes that Privilege Zones became generally available in version 2026.03.23. On August 4, 2026, its maintainers removed legacy system_tags compatibility checks and moved the queries to the simpler Tag_Tier_Zero node label.

That is more than query cleanup. A hard coded search for Domain Admins misses certificate authorities, identity connectors, backup control, synchronization accounts, and other objects that can control the environment indirectly. Privilege zones let defenders define the control plane they need to protect, then query paths to the whole zone. Older tutorials that only target one group now understate the problem.

How should Tier 0 change remediation order?

Tier 0 contains anything that directly or indirectly controls enterprise identity. Domain controllers belong there, but so do certificate services, federation, privileged access systems, forest recovery, and tools that can act across the directory. A monitoring or backup agent with domain rights can drag ordinary servers into the Tier 0 trust boundary.

Microsoft's current AD DS tier model guidance recommends fewer than five people with equivalent Domain Admin access and no Domain Admin service accounts as a common target. It also treats any jump server used to reach domain controllers as Tier 0. The keyboard sets the trust level of the session, not the label on the destination.

Rank any path into Tier 0 above a similar route to an ordinary server. Next, rank shared edges that expose several Tier 0 objects. Then address routes with current sessions, reusable credentials, broad source populations, or recent change. This produces a queue that reflects possible control, not only directory neatness.

What does Active Directory path reduction look like in simple math?

Suppose 24 help desk staff can reset passwords for 80 service accounts. Twelve of those accounts administer servers where Tier 0 operators sign in. The obvious relationship count is 1,920 reset opportunities, calculated as 24 times 80. The dangerous subset is 288 possible bridges into privileged sessions, calculated as 24 times 12.

Removing one inherited reset right from the help desk group can close all 288 bridges. Resetting one service account closes at most 24. The group change has more reach, but it also carries more outage risk. Build a narrow reset role for the accounts help desk must support, test the workflow, preserve emergency access, then remove the broad edge.

This math is intentionally plain. A graph can calculate more advanced centrality scores, but an owner needs to explain why a specific change comes first. Paths removed, serious targets protected, effort, and disruption are enough to force a useful decision.

How should teams fix Active Directory attack paths?

First, confirm the path prerequisites with current evidence. Check effective ACLs, nested membership, logon rights, source reach, session age, and the target's role. A BloodHound edge is a question to verify. Do not begin a disruptive change from a stale graph.

Next, choose the cheapest safe edge. Remove an unused group membership, split a service identity, narrow a delegated right, move administration to a dedicated workstation, deny a privileged account from lower tiers, or remove a route between trust zones. Assign the change to the team that owns that edge. Directory teams cannot fix firewall reach, and server teams cannot approve business access they do not understand.

Stage the repair. Record the dependency, approver, rollback, test identity, expected denial, and telemetry that should appear. Recollect BloodHound after the change and repeat the effective access check. Keep the ticket open until both the graph and the running environment agree.

How do you verify that an AD attack path is gone?

Verification needs two answers. The intended business task still works, and the dangerous route does not. Test them separately. A help desk operator should still reset an approved user. The same operator should fail against a service or Tier 0 account outside the new scope.

Recollect directory ACLs, group membership, local administrators, and sessions. Query the path again. Inspect alternate edges such as a nested group, certificate route, Group Policy control, cached session, or another remote management channel. The attack path analysis guide provides the evidence and closure workflow, while the Kerberoasting guide covers service account routes that survive weak password and SPN decisions.

Watch the edge after closure. Alert on the group membership returning, a privileged session appearing on a lower tier host, a new reset delegation, or a service identity crossing tiers. Directory drift is normal. Silent drift is the problem.

Which BloodHound mistakes waste the most time?

Treating every path as equally urgent floods the repair queue. Trusting stale sessions creates false urgency. Targeting only Domain Admins misses indirect control. Deleting groups before tracing business use causes outages. Closing one visible edge without recollection leaves alternate routes untouched.

Red team framing creates another problem. A path that can be abused in a lab may be blocked by network policy, device trust, authentication controls, or missing prerequisites in production. Preserve the adversary view, then add defensive evidence. The pass the hash defense guide shows why credential material, logon type, source, and target have to be evaluated together.

Artemes uses deep endpoint context with AI driven analysis to help validate whether the host and credential conditions behind a path exist now. Directory owners still decide the change. Automation should present evidence and exact remediation, then make verification easy.

Frequently asked questions

Is BloodHound only a red team tool?

No. Red teams use it to find routes. Defenders can use the same graph to rank permission cleanup, define privilege zones, assign edge owners, and prove that changes removed paths to sensitive control.

Does a BloodHound path prove an attacker can reach Domain Admin?

It proves the collected relationships compose into a possible route. Current network reach, session state, authentication controls, endpoint state, and required skill still need validation. Treat the path as evidence to investigate, not a verdict.

How often should SharpHound data be collected?

Match collection to directory change. Privileged groups, ACLs, sessions, and certificate services may need daily or more frequent data. Always recollect the affected scope after a repair before calling the path closed.

What should teams fix first in an AD attack graph?

Start with verified shared edges into Tier 0, especially broad reset rights, powerful ACLs, reused service identities, and privileged sessions on lower trust hosts. Choose the repair that removes the most serious paths without breaking an approved workflow.

The executive takeaway

Run one current collection, define Tier 0 beyond Domain Admins, and pick the shared edge that creates the most credible routes to it. Give that edge a named owner, test the business dependency, remove the access, and recollect. Do not report fewer permissions. Report fewer verified paths to control.