SharpHound for Windows and Active Directory Collection

SharpHound's Role in a BloodHound CE Collection

SharpHound solves the collection side of BloodHound Community Edition. It gathers data from Active Directory and Windows computers, writes that data into output files, and can package the files for transfer into the BloodHound environment. The available collection methods include Container, Group, LocalGroup, GPOLocalGroup, Session, LoggedOn, ObjectProps, ACL, ComputerOnly, Trusts, RDP, DCOM, DCOnly, UserRights, CARegistry, DCRegistry, CertServices, Site, WebClientService, NTLMRegistry, SMBInfo, and LdapServices. This is useful for administrators or security engineers who have authorization to inspect directory relationships and host state and need that evidence available to BloodHound.

The collector is specifically tied to BloodHound compatibility. The README directs users to the BloodHound CE settings screen, then to Download Collectors, so the collector version should come from the deployed BloodHound CE instance rather than being selected only by recency.

SharpHound is not a replacement for BloodHound's analysis interface. Its documented job is to collect and produce data for that platform. The repository does not describe a hosted service, a graphical analysis suite, or a permanent agent installed as a Windows service.

Collection Methods and Output Data

The default collection method is named Default. Operators can select a more explicit set, restrict enumeration to a domain, search an entire forest, or provide a computer list. The data flow begins with directory and computer targeting, continues through the selected collection methods, and ends in output files controlled by output and compression options. LDAP-derived collection covers directory objects and relationships, while computer-oriented methods can add sessions, local groups, ACLs, rights, RDP, DCOM, registry information, services, SMB data, and other supported categories.

The CLI exposes both broad and targeted controls. `--searchforest` changes the scope from a specified domain to all available domains in the forest. `--distinguishedname` moves the LDAP search base, while `--computerfile` limits computer enumeration to names contained in a file. `--collectallproperties` requests all LDAP properties from objects, which can substantially increase the amount of collected data compared with predefined property collection. The README does not publish output schemas or quantitative size estimates, so operators should not assume that selecting every method is harmless or inexpensive.

Collection can run continuously through `-l, --Loop`, with `--loopduration` and `--loopinterval` controlling duration and delay between loops. This is operationally different from a one-time inventory tool. A looped collector repeatedly contacts computers and produces additional output, so storage, transfer windows, and execution duration need to be planned. The default thread count is 50, while `--throttle` and `--jitter` provide request pacing. These controls expose the collector's concurrency model, but the repository does not guarantee a particular performance level.

Building SharpHound from the Default Branch

The repository provides source-build instructions for environments with a .NET SDK. A normal build restores dependencies and compiles the project. The README says the project targets .NET Framework 4.7.2, so the build host must have a compatible development environment. This source tutorial builds the current default branch rather than downloading a release binary.

Run the documented restore and build commands:

dotnet restore
dotnet build

The default build does not necessarily use the latest stable SharpHoundCommon package. According to the README, it tracks the next prerelease `-dev` version from the SharpHoundCommon v4 branch. That choice can be useful for contributors working against current library changes, but it is a material deployment distinction. A release deployment should normally follow the version offered by BloodHound CE rather than reproducing the repository's default source build.

The default CLI help entry is available through the documented `--help` option:

--help

The README does not show the executable filename or a complete first-collection invocation, so it would be misleading to invent one here. The linked BloodHound CE collection documentation is the authoritative next source for the exact command form and the collection workflow appropriate to the deployed server.

Selecting SharpHoundCommon for Local and Stable Builds

Builds can change where SharpHoundCommon comes from through the `CommonSource` property. The default is `Dev`, which follows prerelease or next-patch development packages. `Stable` uses the current `CommonLibsVersion`, while `Local` expects `_CommonLibPath` and `_RPCPath` to point at the correct local DLLs. This distinction lets contributors test three dependency states without changing SharpHound's source code.

The documented stable build is:

dotnet build -p:CommonSource=Stable

A local-source build uses the same build operation with a different property:

dotnet build -p:CommonSource=Local

For local builds, the README says `_CommonLibPath` and `_RPCPath` must point to the correct DLLs. It does not define their command-line syntax, so no unverified path example is included here. If `CommonLibsVersion` already carries a prerelease tag such as `4.6.0-rc1`, that exact version is used for both `Stable` and `Dev`.

Package resolution logs can be requested with the documented build switch:

dotnet build --tl:off

This flag is useful when diagnosing which SharpHoundCommon package was selected. It is especially relevant when the default build and an expected BloodHound CE deployment appear to use different library versions.

Downloading a Release and Preparing Its Domain Context

For normal use, the README directs users to the GitHub releases page rather than requiring source compilation. It gives a more specific compatibility procedure: sign in to BloodHound CE, open Settings, choose Download Collectors, and download the displayed SharpHound release or select that version from the release list. Compiling the corresponding release commit is presented as an alternative.

A release binary must run from the context of a domain user. The README permits a direct logon or another method such as RUNAS, but it does not document a service installation procedure. That is an important boundary. The documented usage centers on an operator-run executable with a direct logon or another explicit domain-user context.

The first planning check is therefore version compatibility, not download speed. Record the version displayed by BloodHound CE and obtain the matching SharpHound release. Then define whether collection will target one domain or an entire forest, because `--searchforest` changes the enumeration boundary. Finally, review whether the selected methods require computer access, LDAP properties, registry data, or credentials beyond the baseline domain-user context. The README does not publish a permission matrix, so exact access requirements must be verified in the linked BloodHound documentation and the target environment.

LDAP Overrides That Can Break Collection

SharpHound can override LDAP credentials, controllers, ports, DNS names, and transport behavior. The README includes a strong warning that `--domaincontroller` can result in data loss. An operator can also select `--secureldap`, `--disablecertverification`, and `--disablesigning`. These flags affect trust and protocol handling, so they should not be treated as routine tuning options.

Setting `--ldapport` overrides the LDAP port, and its default is `0`. `--secureldap` switches the connection to LDAP SSL rather than regular LDAP. Certificate verification can be disabled, while Kerberos signing and sealing can also be disabled. The CLI does not frame these as security improvements. They are compatibility or troubleshooting controls with direct consequences for transport protection and the authenticity of the LDAP endpoint.

A safer interpretation is that the documented defaults should remain in place unless the target environment requires an explicit exception. If an override is necessary, verify the intended controller, DNS name, port, certificate path, and signing policy before running a broad collection. The repository does not document recovery procedures for partial output or rollback after an incorrect domain-controller override. That absence makes preflight validation more important, not less.

SharpHound Boundaries for Looping, Caching, and Targeted Runs

SharpHound includes operational controls for repeated collection, caching, throttling, and output handling. `-l, --Loop` defaults to a two-hour duration, while `--loopinterval` adds a delay between loops. The cache can remain in memory through `--memcache`, and `--rebuildcache` removes existing entries before rebuilding it. A machine-specific cache name is used by default unless `--cachename` sets another filename.

These options can reduce repeated setup work or alter the collector's local footprint, but the README does not state cache expiry, cache compatibility rules, or recovery behavior. `--rebuildcache` is therefore a deliberate reset rather than a harmless retry option. It explicitly removes all entries.

Output is written to the current directory by default. `--outputdirectory`, `--outputprefix`, `--zipfilename`, and `--nozip` control placement and packaging. `--zippassword` can protect the generated ZIP. The documentation does not specify encryption parameters or key handling, so this review does not infer them. Passwords passed through `--ldappassword`, `--localadminpassword`, or other CLI options should also be considered operationally sensitive because process arguments can be exposed on many systems, although the README does not prescribe a secret-storage method.

SharpHound is the wrong tool when only a one-off host inventory is needed without BloodHound ingestion, or when Windows and Active Directory are outside scope. It is also unsuitable as a replacement for a documented remote-execution platform, a monitoring daemon, or a general Windows administration agent.

Release History, GPL-3.0, and Upgrade Work

The repository is not archived, and its last push was on 2026-10-01. The release list includes v2.17.0 on 2026-10-01, v2.17.0-rc1 on 2026-09-21, and v2.16.0 on 2026-09-08. This recent sequence indicates that releases and release candidates have been produced close together. It does not, by itself, document upgrade compatibility or migration requirements.

The project is licensed under GPL-3.0. That matters when organizations redistribute a modified SharpHound binary or incorporate source into another distributed work, because the license contains conditions concerning copyleft and source availability. This is not legal advice, and the README does not provide organization-specific compliance guidance. Review the repository's `LICENSE` file before redistribution.

Upgrades should be coordinated with BloodHound CE. The README's instruction to use the version displayed by Download Collectors is the clearest supported upgrade boundary. For source builders, also inspect the selected `CommonSource` and `CommonLibsVersion`, since default `Dev` builds follow prerelease development packages. For release users, compare the BloodHound CE collector version with the downloaded SharpHound artifact before replacing an existing binary.

Editorial conclusion

Adopt SharpHound when an authorized BloodHound CE deployment needs Windows or Active Directory data and an operator can manage the collector in domain-user context. Do not choose it as a standalone scanner, an unattended inventory agent, or a cross-platform collector. Before the first run, verify the BloodHound CE collector version, choose collection methods, confirm that the execution identity has the required access, and review LDAP routing and signing settings.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. SpecterOps/SharpHound on GitHub