From zero to Domain Admin: reading Active Directory attack paths with BloodHound

Almost every internal engagement we run ends the same way: not with a single exploit, but with a path — a chain of small, legitimate-looking permissions that leads from one ordinary user account to full control of the domain. BloodHound is the tool that makes that path visible. This article walks through how we use it on real assessments, and, just as importantly, how a defender shuts each step down.

Everything below is standard, well-documented methodology — the same material taught in OSCP, CRTO and CRTE, and the techniques are catalogued in MITRE ATT&CK. We're writing it up as a defender's guide as much as an attacker's: every section ends with the telemetry that catches it and the configuration change that removes it. If you run an Active Directory environment, the useful takeaway is not "attackers can do this" — it's "here is exactly what to hunt for and fix."

Why attack paths, not vulnerabilities

A traditional vulnerability scan thinks in terms of hosts: this server is missing a patch, that one runs an old TLS version. Active Directory doesn't break that way. In a mature environment there may be no unpatched "exploit me" box at all. What there is, always, is a sprawl of relationships built up over years: group memberships, delegated permissions, local-admin rights pushed by GPO, service accounts with more privilege than anyone remembers granting.

Individually, each of those relationships is intentional. Chained together, they form a route. BloodHound's core insight — originally from Andy Robbins, Will Schroeder and Rohan Vazarkar — was to model AD as a directed graph and let you ask the one question that matters: "from where I am now, what is the shortest path to Domain Admin?" It answers with graph theory, not guesswork.

The graph model: nodes and edges

BloodHound represents the directory as nodes connected by edges. The nodes are the objects you'd expect:

• Users — including service accounts
• Computers — workstations, servers, domain controllers
• Groups — security groups, nested arbitrarily deep
• OUs, GPOs, Domains and the AD CS objects (certificate templates, CAs)

The edges are where the interest lies. Each edge is a relationship that an attacker can traverse, and each has a concrete abuse technique behind it. A few of the ones we rely on most:

The attacker's job becomes a pathfinding problem: start at a node you control, follow edges you can abuse, arrive at Domain Admins. BloodHound draws that line for you.

Step 1 — Collection

You can't query a graph you haven't built. The first step on any engagement is collection: enumerating those objects and relationships from the directory. Any authenticated domain account — even the lowest-privileged user — can read the vast majority of this, because AD is designed to be readable by its members. That's not a bug; it's how clients find each other. It's also why a single phished account is so valuable.

Collection is done by a "SharpHound" collector (the C# collector, or the Python bloodhound-python for remote use). Conceptually it performs three kinds of enumeration:

1. LDAP queries against a domain controller for objects, group memberships and the ACLs on each object. This is the bulk of the data and is ordinary directory traffic.
2. Session enumeration — asking machines who is logged on, to populate HasSession edges. This is the noisy part (see detection below).
3. Local group enumeration — asking machines who is in their local Administrators group, to populate AdminTo.

The collector writes a set of JSON files, which you then import into the BloodHound UI. On a real engagement we tune collection to be quiet — spreading it out, avoiding session loops against every host at once — because the defender's best early-warning sign is exactly this enumeration.

Step 2 — Orienting from the foothold

Say the engagement started with one account — perhaps from a password-spray against the VPN, perhaps from a phishing simulation the client authorised. In BloodHound we mark that user as Owned (right-click → Mark as Owned). Now we run the pre-built query "Shortest Paths from Owned Principals to Domain Admins."

Three things typically come back:

• Nothing. Good — but it only means no path from this account. We widen the net: what can this user reach at all? Which groups is it in? What does it have a session near?
• A short, ugly path. On under-maintained domains it's not unusual to see a two- or three-hop route straight to Domain Admins. We've opened assessments and had the path on screen within the first hour.
• A long path with one or two interesting choke points. This is the common and interesting case, and the rest of the article follows one.

Our worked example — representative of real engagements, with names changed — looks like this:

[Owned] [email protected]
   │  MemberOf
   ▼
IT-SUPPORT (group)
   │  AdminTo
   ▼
WKS-DEV-04 (computer)
   │  HasSession
   ▼
svc-backup (service account)
   │  MemberOf
   ▼
SERVER-OPERATORS
   │  GenericAll
   ▼
DC01 ──► Domain Admins

Read top to bottom, that's the whole engagement. Now we walk it one edge at a time.

Step 3 — Hop one: a group that's local admin somewhere

Our foothold user j.doe is in IT-SUPPORT, and BloodHound shows IT-SUPPORT has an AdminTo edge to the workstation WKS-DEV-04. This is extremely common: a help-desk or IT group is granted local administrator on a class of machines through a GPO-deployed Restricted Group or a Group Policy Preferences setting, so support staff can fix them.

Because j.doe inherits that membership, j.doe is local admin on WKS-DEV-04. Local admin on a Windows host means the ability to read secrets held in the memory of the Local Security Authority process — in practice, the credentials or Kerberos tickets of anyone else currently or recently logged on to that machine. That's the whole reason the next hop exists.

Step 4 — Hop two: a session leaves credentials behind

BloodHound's HasSession edge tells us that svc-backup — a service account — has a session on WKS-DEV-04. Perhaps a backup agent runs there under that account, or an administrator used it to run a tool and the logon artefacts lingered.

This is the crux of lateral movement in AD and worth stating plainly: wherever a privileged account logs on, it leaves material behind that a local admin on that host can recover. Having become local admin on WKS-DEV-04 in the previous hop, we can now recover svc-backup's credentials from that machine. We don't need its password typed anywhere — the authentication material it left in memory is enough to act as it (the "pass-the-hash" / "pass-the-ticket" family of techniques). We now control svc-backup and mark it Owned too.

Step 5 — Hop three: a dangerous group membership

svc-backup is a member of SERVER-OPERATORS (or an equivalent custom group with similar rights). Backup software loves powerful groups, because reading and restoring files across servers genuinely needs broad access — and so these accounts quietly accumulate privilege. BloodHound flags the membership as part of the path because of where it leads next.

This is a good moment to point out a class of built-in groups BloodHound specifically highlights as dangerous: Account Operators, Backup Operators, Server Operators, Print Operators, DnsAdmins. Each has a legitimate purpose and each, through a different mechanism, can often be escalated toward control of a domain controller. Treat membership of any of them as nearly equivalent to Domain Admin.

Step 6 — The final edge: control over the domain

The last edge in our path is a GenericAll from SERVER-OPERATORS onto the domain-controller computer object (or, in other engagements, a GenericAll/WriteDacl directly on the domain object). Full control over an object means you can rewrite its security settings. Applied to the domain, that lets an attacker grant themselves the directory-replication rights that the domain controllers use to sync with each other.

Those replication rights are the keys to the kingdom. With them, an account can ask a domain controller to hand over the password hashes of any account in the domain — including krbtgt, the account whose key signs every Kerberos ticket. This is the technique BloodHound labels DCSync. At that point the engagement is effectively over: with the krbtgt key an attacker can forge tickets for any user, and recovery means resetting that key twice across the whole domain.

We don't publish a copy-paste weaponised chain here, and we don't need to — the point for both attacker and defender is the path, and you've now seen how five ordinary, individually-defensible permissions compose into total compromise.

Running BloodHound as the blue team

The single most useful thing we tell clients after an AD assessment is this: the attacker's best tool is also yours. BloodHound was built for offence, but nothing stops a defender from running the exact same collection against their own domain and asking the exact same questions — before anyone else does.

A practical blue-team routine:

1. Collect monthly. Run collection with a service account, on a schedule, and keep the data. Directories drift; a path that didn't exist last quarter appears the moment someone adds a convenient group membership.
2. Mark your crown jewels as "high value" and run "Shortest paths to high-value targets." Don't stop at Domain Admins — include the finance app's service account, the backup system, the PKI.
3. Diff over time. New edges into Tier-0 are the thing to watch. BloodHound Community Edition and the commercial version make this reporting much easier than the old releases did.
4. Fix the choke points, not every edge. You rarely need to remove hundreds of permissions. A path usually funnels through one or two choke-point nodes; cut those and dozens of paths disappear at once. BloodHound's "shortest path" view shows you exactly where to spend the effort.

Takeaways

• Active Directory compromise is almost never one exploit; it's a chain of legitimate permissions. You defend it by removing the chain, not by patching a box.
• The four highest-leverage controls, in order: tiered administration, LAPS, Credential Guard, and tightly-scoped local-admin and operator groups.
• DCSync from a non-DC and access to a honey object are two of the best-value detections you can deploy this week.
• Run BloodHound against yourself on a schedule. If you can't see your own attack paths, you're trusting that no attacker will look — and on our engagements, they always do.

References and further reading

• BloodHound documentation — SpecterOps
• MITRE ATT&CK — technique catalogue for the steps above
• Microsoft privileged-access / tier model
• Windows LAPS overview
• Windows Credential Guard