Overview

BloodHound-python delivers a fast, cross-platform way to map the attack paths hidden inside an Active Directory environment. Instead of manually querying LDAP, dumping group memberships, and correlating sessions by hand, a penetration tester runs a single ingestor that collects the raw relationship data and hands it to BloodHound for graph analysis. This article walks through the tool end to end inside an isolated lab built on the ignite.local domain. Each demonstration uses a different collection method or authentication mechanism, so by the end you will understand not only how to run the ingestor, but also which switch to reach for during a real assessment. Every command targets the domain controller at 192.168.1.9, and every run drops timestamped JSON files that BloodHound consumes directly.

Table of Contents:

• Introduction to BloodHound-Python
• Default Collection Method
• Output of the Default Collection
• LoggedOn Collection Method
• Output of the LoggedOn Collection
• DCOnly Collection Method
• Output of the DCOnly Collection
• Authentication with Pass-the-Hash
• Authentication with a Kerberos AES Key
• Authentication with a Kerberos Ticket (ccache)
• Packaging Output with the Zip Option
• Conclusion

Introduction to BloodHound-Python

BloodHound-python (also called bloodhound-python or the Python ingestor) is an open-source data collector that gathers Active Directory information over the network and serializes it into the JSON format that BloodHound expects. The original SharpHound collector runs natively on Windows, but the Python ingestor removes that constraint entirely: it runs on Linux, executes straight from a Kali attack box, and never requires a foothold on a domain-joined machine. It authenticates against LDAP and SMB using standard domain credentials and pulls users, groups, computers, group policy objects, organisational units, containers, trusts, sessions, and local administrator relationships.

Install it from the Kali repositories or pip with pip install bloodhound, then invoke it with bloodhound-python. The core switches used throughout this article are -u and -p for the username and password, -d for the target domain, and -ns to point the resolver at the domain controller acting as the DNS server. The -c flag selects the collection method, which controls exactly how much and what kind of data the tool retrieves.

The collection methods matter because each one balances stealth, speed, and completeness differently. Default performs a broad sweep that touches domain objects and live hosts. LoggedOn focuses purely on identifying which users are signed in to remote machines. DCOnly pulls everything obtainable from the domain controller through LDAP alone, never touching individual workstations, which makes it quiet and quick. All combines DC-based and host-based collection for the most complete dataset. The tool also supports several authentication modes beyond a cleartext password, including pass-the-hash with an NT hash, Kerberos AES keys, and cached Kerberos tickets, each of which this article demonstrates in turn. 

Default Collection Method 

The first run uses the Default collection method, which represents the most common starting point. Here the tester authenticates as the domain user raaz with the password Password@1, sets ignite.local as the target domain, and directs name resolution to the domain controller at 192.168.1.9. As the tool runs, it locates the AD domain, requests a Kerberos ticket-granting ticket, and connects to the LDAP server on DC1.ignite.local. The output confirms that it discovered one domain, three computers, thirty-one users, and fifty-three groups before enumerating each computer in turn and finishing in a single second.

bloodhound-python -u raaz -p Password@1 -ns 192.168.1.9 -d ignite.local -c Default

Output of the Default Collection

Listing the working directory after the Default run reveals the artifacts the ingestor produced. The tool writes four timestamped JSON files covering computers, domains, groups, and users. The shared timestamp prefix keeps every file from a single collection grouped together, which prevents confusion when multiple runs accumulate in the same folder. These files import directly into the BloodHound GUI to render the attack graph.

LoggedOn Collection Method

Switching the -c flag to LoggedOn narrows the focus to active user sessions. This method skips the broad object enumeration and instead queries each computer to discover who is currently signed in, which is invaluable for planning lateral movement toward a privileged account. In this run, the tool reports that a user with the SID ending in 500, the built-in Administrator, is logged in on DC1.ignite.local. Session data like this exposes exactly where high-value credentials sit in memory and are ripe for extraction.

bloodhound-python -u raaz -p Password@1 -ns 192.168.1.9 -d ignite.local -c LoggedOn

Output of the LoggedOn Collection

Because LoggedOn concentrates solely on session information tied to computers, it produces a single JSON file rather than the full set. The directory listing shows one computers.json file, confirming that this lightweight method carries a much smaller footprint than a full collection while still delivering the session intelligence a tester needs.

DCOnly Collection Method

The DCOnly method gathers everything reachable through the domain controller over LDAP without ever connecting to individual workstations, which makes it both fast and comparatively stealthy. This run retrieves thirty-one users, fifty-three groups, three GPOs, two OUs, nineteen containers, and three computers, then completes almost instantly. Because it never reaches out to endpoints, DCOnly avoids the network noise that host-based session collection generates, making it a strong choice when evasion is a priority.

bloodhound-python -u raaz -p Password@1 -ns 192.168.1.9 -d ignite.local -c DCOnly

Output of the DCOnly Collection

The DCOnly run produces a far richer set of files than the earlier methods. The listing now shows seven JSON files covering computers, containers, domains, GPOs, groups, OUs, and users. This breadth of object data, all pulled from the domain controller alone, gives BloodHound enough structure to map organizational units, policy links, and group nesting without any host interaction.

Authentication with Pass-the-Hash

BloodHound-python does not require a cleartext password. When a tester has recovered an NT hash but not the plaintext, the –hashes switch enables a pass-the-hash authentication. Here the run supplies the NT hash for the raaz account, leaving the LM portion empty, and pairs it with the All collection method to grab the complete dataset. The tool authenticates successfully, enumerates the full range of objects, and writes seven JSON files, proving that a stolen hash is just as effective as a password for driving the ingestor.

bloodhound-python -u raaz --hashes :64FBAE31CC352FC26AF97CBDEF151E03 -ns 192.168.1.9 -d ignite.local -c All

Authentication with a Kerberos AES Key

For environments that rely on Kerberos AES encryption, the tool accepts a raw AES key through the -aesKey switch. This run authenticates the raj account using its AES256 key and again requests the All collection method. Authenticating with an AES key can blend in more naturally with legitimate Kerberos traffic than an NTLM-based approach, and the output confirms a full enumeration with the familiar set of seven JSON files written to disk.

bloodhound-python -u raj -aesKey af5c68f9c15325a03f0cc4b0833f7a1bf4a5607377f7a2412d0dcf8b6ad4a75e -ns 192.168.1.9 -d ignite.local -c All

Authentication with a Kerberos Ticket (ccache)

The tool also consumes a cached Kerberos ticket directly. After exporting the ticket path into the KRB5CCNAME environment variable, the tester runs the ingestor with -k -no-pass so it authenticates using the ticket rather than any credential on the command line. The output shows the tool reading the TGT from cache, confirming the correct principal, and completing a full All collection. It even reports that the Administrator is logged on to DC1.ignite.local from 192.168.1.17. The resulting directory contains the seven JSON files alongside the Administrator.ccache ticket used for the run.

export KRB5CCNAME=Administrator.ccache
bloodhound-python -u administrator -k -no-pass -ns 192.168.1.9 -d ignite.local -c All

Packaging Output with the Zip Option

Managing seven separate JSON files per collection quickly becomes tedious, so the tool offers a –zip switch that compresses every output file into a single archive. This final run performs an All collection and then bundles the results, printing a message that it is compressing the output into a timestamped zip file. The directory listing confirms one tidy bloodhound.zip archive, which imports into BloodHound in a single drag-and-drop and keeps engagement evidence neatly organised.

bloodhound-python -u raaz -p Password@1 -ns 192.168.1.9 -d ignite.local -c All --zip

Conclusion

BloodHound-python proves itself as an indispensable ally for any Active Directory assessment. Across these demonstrations, it collected domain data in several distinct modes and authenticated through four separate mechanisms, all from a single Linux attack box and without ever needing a Windows foothold. The Default method offered a balanced first pass, LoggedOn pinpointed active sessions for lateral movement, DCOnly delivered a quiet LDAP-only sweep, and All produced the most complete picture available. Just as importantly, the tool accepted passwords, NT hashes, Kerberos AES keys, and cached tickets interchangeably, which means a tester can keep collecting no matter what form of credential the engagement yields.

The practical takeaway is to match the collection method and authentication mode to the situation at hand. Reach for DCOnly when stealth matters, choose All when completeness outweighs noise, and lean on pass-the-hash or ticket-based authentication whenever plaintext credentials are out of reach. Wrapping the results with the zip option keeps the output portable and ready for immediate import. Feeding these JSON files into BloodHound transforms raw directory data into a visual graph of attack paths, turning a tangle of permissions and sessions into a clear route toward domain dominance. Defenders should study the very same output, because the paths BloodHound reveals to an attacker are exactly the paths that demand hardening. Always run these techniques only within environments you are explicitly authorized to test.