BloodHound Legacy: what the deprecated v4 repository still tells you

What BloodHound Legacy actually answers

The question BloodHound was built around is not "is this account an administrator" but "how many hops separate this ordinary user from domain admin." The README states the project "uses graph theory to reveal hidden relationships and attack paths in an Active Directory environment." That framing matters. Directory tools that list group membership tell you what is true right now; they do not tell you which chain of rights, sessions and delegations composes into a route an attacker could walk.

BloodHound Legacy is aimed at red teamers and defensive engineers who already have a directory to reason about. It is not a scanner that finds vulnerabilities by itself. The value comes from the collected edges: who is logged into which machine, which group can control which object, which ACL grants write access to a target. The graph is only as good as the collection that fed it, which is why the Collectors directory sits at the top level of this repository rather than inside the application source.

The package metadata describes the project as "Graph Theory for Active Directory" and lists Active Directory and Azure among its keywords. That is the scope: an identity graph, not a network map.

How the collector and the Electron app fit together

The repository layout makes the data flow fairly explicit. Collectors/ holds the ingestion side. The JavaScript application (main.js, server.js, renderer.js, src/, plus the webpack development and production configs) is the analysis side. Data moves from the collector into a database that the client queries.

The packaging script in package.json is informative here: it ignores BloodHoundExampleDB.db when building a release. That tells you the shipped application expects a database file to be supplied or created, and the example database is a development artifact rather than something end users receive. The engines field pins node to ~16, so the client is an Electron application running against an older Node runtime.

What this means in practice is that BloodHound Legacy is two products with one name. The collector runs where the directory data lives. The client runs on an analyst workstation and reads the resulting graph. Treating them as a single installable unit is the most common source of confusion, and the README does not walk through the split; it points to the deprecated documentation at bloodhound.readthedocs.io for detail.

Installing BloodHound Legacy and running a first query

The README does not give installation steps for v4. It states the repository is deprecated and links to the BloodHound Community Edition installation instructions at bloodhound.specterops.io/get-started/quickstart/community-edition-quickstart instead. Anyone installing Legacy today is working from the deprecated documentation, not from this README.

What the repository does define is how the application is started from source. The scripts block in package.json exposes a development entry point:

npm install
npm run dev

The dev script runs the client and server together via run-p, with the client started as cross-env NODE_ENV=development electron . and the server as babel-node server.js. The engines field requires Node 16, so a newer Node release is not what this project was built against. Expect to see an Electron window open against a local server process.

For a packaged build rather than a source run, the same file defines platform targets:

npm run package:linux
npm run package:macos
npm run package:win32

These wrap electron-packager with per-platform flags and icons. The packaging command explicitly ignores the example database, the docs directory and the Ingestors directory, so a packaged build is the client only. Collection is a separate step performed by the tools under Collectors/.

The deprecation is the headline, not a footnote

The first line of the README says the repository "has been deprecated," that Legacy "was last updated in 2023 and is no longer maintained," and that it "will be archived in the near future." The most recent release listed is v4.3.1 from 2023-05-23, which matches the package version 4.3.1. The last push to the repository was on 2026-03-02, but the release history and the README agree that substantive work stopped in 2023.

This is the limitation that should decide most adoption questions. A tool that maps attack paths is only useful if its model of the directory keeps pace with how directories change. Read-only domain controllers, new delegation types, changes to how sessions are recorded: each of those shifts what the collector sees and what edges the graph should contain. When the project states it is no longer maintained and will be archived, you are accepting that whatever the v4 model covers is what it will always cover.

The README also names the replacement directly: BloodHound Community Edition, with a repository at github.com/SpecterOps/BloodHound and documentation at bloodhound.specterops.io. It notes that BloodHound "is maintained by the BloodHound Enterprise team," which is a clear signal about where engineering effort now sits.

BloodHound Legacy versus Community Edition

The difference between Legacy and CE is not a feature list; it is an ownership model. Legacy is a desktop Electron application with a bundled database workflow, packaged per platform through electron-packager. Community Edition is distributed from a separate repository with its own quickstart documentation, and the README treats it as the supported path rather than an upgrade option.

That distinction changes what you are maintaining. With Legacy you are responsible for the client runtime, the Node 16 dependency, the packaging step and the database file. With CE the installation procedure lives in the published documentation, and the project is the one SpecterOps points new users toward.

There is a second, quieter difference. Legacy's README still carries the Azure keyword and the 4.2.0 release was labeled "Azure Refactor," so Azure collection existed in the v4 line. But the README's own framing of the current product is BloodHound Enterprise as an Attack Path Management solution that "continuously maps and quantifies Active Directory attack paths." Continuous mapping is a different posture from running a collector and loading a database, and it is the direction the project moved after v4.

Licence and the cost of keeping v4 alive

BloodHound Legacy is GPL-3.0, stated in both the README and package.json. The README reproduces the standard grant: you may redistribute and modify under the terms of the GNU General Public License as published by the Free Software Foundation, version 3 or later, and the program comes with no warranty. There is also a LICENSE-3RD-PARTY.md at the top level, which means the dependency licences are tracked separately from the project licence.

For a security tool this matters in two directions. Redistribution inside an organisation is permitted under GPL-3.0, but the copyleft terms apply to derivative works, and the third-party file exists precisely because the whole dependency tree is not under one licence. If you intend to ship a modified build, read LICENSE.md and LICENSE-3RD-PARTY.md together rather than assuming the top-level identifier covers everything.

Upgrade cost is the harder number. Because the README directs users to a different repository and a different documentation site, there is no migration guide in this material. The practical cost of staying on v4 is not patching; it is the absence of patching, plus the eventual archive of the repository. The copyright line reads 2016 to 2025, which is longer than the release history suggests active work continued.

Editorial conclusion

BloodHound Legacy is for engineers who need to read or reproduce work against an existing v4 deployment, or who are studying how the graph model was built before the rewrite. It is not for anyone standing up a new Active Directory attack path program: the README states the repository was last updated in 2023, is no longer maintained, and will be archived in the near future, with installation instructions for BloodHound Community Edition published separately at bloodhound.specterops.io. Before you spend time on v4, confirm which edition your target environment expects, check that Node 16 is available if you intend to run the Electron client from source, and read LICENSE.md if you plan to redistribute a packaged build. The repository itself is the boundary: once it is archived, the code stays readable but nothing in it will change.

Frequently asked questions

Official sources

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