ADPathFinder: OpenGraph Attack Path Mapping in BloodHound CE

Introduction

You are two days into an internal assessment. Certipy came back clean. Kerberoasting pulled a handful of service accounts using AES, and hashcat is still running. Responder and mitm6 have been quiet all day.

Snaffler turned up the usual ghosts: a passwords.txt from 2019, a script with credentials for a host decommissioned years ago. A glimmer of hope, a low-privileged domain account whose password had been sitting in a config file for nobody knows how long. You spray it across the estate. Nothing.

Point it at a BloodHound graph and it maps escalation paths from users and computers to high-value targets, grouping the ones that share edges. It unifies SharpHound data with OpenGraph collectors, so AD, ADCS, MSSQL, and SCCM relationships all get queried together. MSSQLHound and ConfigManBearPig are supported natively.

One path across many datasets

BloodHound is excellent, and its built-in queries cover a lot of ground. It makes it easy to ask, “Can this principal reach that target?” On an internal, you usually need the inverse: “Which paths affect the most users, cross the most important systems, and deserve attention first?”

OpenGraph adds another challenge. A path that moves through AD, MSSQL, and SCCM can still mean custom queries and manual reporting before the full chain is clear. ADPathFinder queries the combined graph, groups paths that share edges, and reports cross-dataset paths as one finding instead of separate pieces you have to join by hand.

The example below shows that in practice. Using SharpHound and MSSQLHound, ADPathFinder starts with the AD user J.REPORTER, follows its MSSQL_HasLogin edge to the SQL login j.reporter, impersonates ReportSvc, then reaches the linked server sccmdb.training.local.

ConfigManBearPig supplied the final SCCM edge, as the host sccmdb.training.local has powerful SCCM assigned privileges (SCCM_AssignAllPermissions) over the SCCM site (SCCM_Site(TRN)).

Example from ADPathFinder report:

J.REPORTER > MSSQL_HasLogin > j.reporter > MSSQL_ExecuteAs > ReportSvc >
  MSSQL_Connect > lab-sql01.training.local > MSSQL_LinkedAsAdmin > sccmdb.training.local >
  MSSQL_ExecuteOnHost (as DA@TRAINING.LOCAL) > SCCMDB.TRAINING.LOCAL >
  SCCM_AssignAllPermissions > SCCM_Site(TRN)

Adding new checks works the same way. Each one declares the data it needs and queries the combined graph, so new detections can drop in as OpenGraph collectors mature.

What ADPathFinder does

ADPathFinder does two things: attack path mapping and password auditing. Both work from the same BloodHound graph.

Attack Path Mapping

It maps shortest paths from low-privileged accounts to Domain Admins, Domain Controllers, and similar targets across AD, ADCS, MSSQL, and SCCM.

Users and computers that reach the same target through the same chain are grouped together. In a 20,000-user graph that means one finding with the full list of affected principals attached, rather than hundreds of near-duplicates to wade through, and the busiest paths surface at a glance.

Standalone issues get their own findings too: SMB signing disabled, delegation misconfigurations, WebClient on servers, plus ADCS, SCCM, and MSSQL checks.

The ADCS coverage is explicit rather than implied: ESC1, ESC2, ESC3, ESC4, ESC6, ESC7, ESC8, and ESC9.

SCCM covers TAKEOVER-1, TAKEOVER-2, TAKEOVER-4, TAKEOVER-5, TAKEOVER-6, TAKEOVER-7, TAKEOVER-8, and ELEVATE-1, plus SCCM privilege escalation, anonymous policy access, and PXE-enabled distribution point findings.

MSSQL checks cover SQL logins, linked servers, login impersonation, privilege escalation paths, and servers vulnerable to NTLM relay.

These rank higher when they sit on an escalation path. SMB signing disabled is a medium on its own. The same host with an onward path to a high-value target is a high, and a different conversation.

Password Auditing

If an NTDS dump and hashcat potfile are provided, it takes the cracked passwords and adds BloodHound context that a standalone password audit misses. It checks enabled accounts for blank passwords, password reuse, passwords similar to the username, LM hash use, and common weak patterns such as company names, password, welcome, months, days, and seasons. It also flags Kerberoastable and AS-REP roastable accounts where the password has been cracked.

Where it differs from a standalone audit is the graph context. A cracked password on a standard user account and a cracked password on an account that’s a member of Domain Admins (or sits on an escalation path) are not the same finding. The report separates them rather than leaving the tester to cross-reference a flat list of hashes against group memberships and path data manually.

What you get

ADPathFinder writes an HTML report per domain, organised by severity and grouped by shared path. Findings include attack path graphs and PowerShell commands to confirm each step. Hover a node or edge for group memberships, account status, and last logon.

Text and JSON outputs sit alongside the HTML for review or automation. Password audits get their own report set with charts covering cracked categories, policy compliance, and shared password groups.

/ AD-PathFinder / Sample Reports

( HTML ) – Attack Path | Password Analysis

( TXT ) – Domain Audit | Password Audit

git clone https://github.com/NetSPI/AD-PathFinder.git
cd AD-PathFinder
python3 -m venv .venv
source .venv/bin/activate
pip install -e .

ADPathFinder uses the BloodHound CE API to import and clear BloodHound data. When you first start BloodHound CE, it generates an initial admin password in the terminal output. That’s the password --setup-bloodhound-api needs. If you’ve already changed it through the BloodHound UI, use whatever you changed it to.

adpathfinder --setup-bloodhound-api

adpathfinder -i SharpHound.zip MSSQLHound.zip ConfigManBearPig.zip --ad --pwd Contoso,ContosoIT --ntds ntds.txt -p hashcat.potfile

adpathfinder -i SharpHound.zip --ad

NTDS dumps, potfiles, and the reports the tool writes are all sensitive material and should be handled accordingly. The --unsafe-report flag includes cleartext passwords in the output, which some deliverables need and most don’t, so it’s off by default. The resulting _unsafe files want the same care as the source NTDS.

Pentest your Internal Networks with NetSPI Experts

Internal Network Penetration Testing

Penetration Testing as a Service