Adalanche: an attack graph for Active Directory permissions, and which half is free

It answers who can take over what

The project's description poses the question directly: who is really Domain Admin. Adalanche collects data from a directory, works out every path by which one account or machine can end up controlling another, and renders that as a graph you can move through in a browser. The README's framing is that this shows what permissions users and groups actually have, and it is useful for finding who can take over accounts, machines or the whole domain, and for showing the misconfigurations that an attacker would use.

The problem it addresses is real and unglamorous. The README argues it in two paragraphs: small organisations generally have no idea what they are doing and too many people end up in Domain Admins, while large organisations delegate access to varying degrees of power until someone makes a mistake. Neither of those is a vulnerability in the sense of an unpatched CVE. It is ordinary accumulated permission sprawl, and no amount of patching fixes it. A tool that makes the sprawl visible has to model delegation as a graph, because the danger is in the paths, not in any single ACL.

Repository topics match that framing: acl, acl-audit, active-directory, ad-audit, ldap-audit, graph-theory, infosec, reconnaissance and blueteam. The primary language is Go, and the sample graph in the README is generated from the GOAD lab, which is the standard deliberately vulnerable Active Directory test environment. That detail matters for evaluation: the project's own screenshot is a graph built against a machine designed to be attacked.

The asterisk marks six paid capabilities

This is the single most important thing to understand before installing, and the README handles it honestly rather than burying it. The feature list separates collection from integration, and every asterisked item is paid, with a pointer to the vendor's site.

Collection, which the README describes as something Adalanche can do, covers three sources: Active Directory, Windows machines, and VMware vSphere. The vSphere source is asterisked, so two of the three collectors are free.

Integration is a longer list of six, and five of them are asterisked: Active Directory, Windows machines whether domain joined or standalone, VMware vSphere, CyberArk, password hashes and cracked passwords, tiering models, and custom nodes and edges. Only the first two are free. CyberArk integration, the ability to bring in password hashes and cracked passwords, tiering models that encode how your organisation actually segments privilege, and custom node and edge types are all paid. The README also states that the reporting feature is in development, with an asterisk, which reads oddly until you notice that in-development and paid are being tracked in the same column.

The practical consequence is that the free version can answer the core question from Active Directory alone. Anything that requires correlating a vault, a credential store or your own internal privilege tiers needs the commercial build, and there is no way to tell from the repository alone what those cost. The homepage of record is the vendor's site rather than a documentation site, which tells you where to go next.

AQL for when clicking through the graph stops working

Adalanche ships a query language of its own, called Adalanche Query Language, described in the README as a GQL-like language offering comprehensive search abilities in the graph. That is the part of the tool that scales past a small domain.

A graph viewer works well when you are investigating one hypothesis, following edges from a suspect account to see where it leads. It works badly when you want to enumerate every path longer than two hops, or every principal that can reach a specific group, or every session that has write access to anything. Those are questions a query language answers and a human clicking does not. GQL is an open standard for property graph querying, and the README's framing suggests AQL borrows its shape rather than inventing a syntax from nothing, which would make queries portable to some degree and the learning curve smaller.

The documentation is served from inside the product as well as from the repository, at `modules/frontend/html/docs/index.md` on GitHub and from the Adalanche UI itself. Serving docs from the binary is a sensible choice for a tool that gets copied onto a jump host, since the answer is available on the machine where you are running the queries.

Building it: Go 1.27, two PowerShell scripts, one module

The repository is a single Go module with a conventional layout: `adalanche/` for the command, `modules/` for the internals including the frontend assets and documentation, `test/` for tests, and `scripts/` alongside them. Linting is configured in `.golangci.yml` and there is a `CONTRIBUTING.md`.

The manifest is worth reading because it shows what the tool actually talks to:

module github.com/lkarlslund/adalanche

go 1.27.1

tool (
	github.com/dmarkham/enumer
	github.com/mailru/easyjson
	github.com/tinylib/msgp
)

Those three tool directives generate string enums and JSON and MessagePack code, which is what a project of this shape needs when it serialises object slices back to a browser. Further down, `github.com/gorilla/websocket` is the live connection for the graph UI, `github.com/gin-gonic/gin` is the web server, `github.com/jcmturner/gokrb5/v8` is Kerberos, and `github.com/lkarlslund/ldap/v3` is a maintained fork of a Go LDAP library. The presence of a forked LDAP client and a Kerberos library in the dependency list is the honest signature of a tool that has to authenticate to a domain controller rather than talk to a plain directory.

There are also Windows-specific dependencies, `github.com/Microsoft/go-winio` and `github.com/lkarlslund/go-win64api`, which line up with the fact that the tree contains `build.ps1` and `prereqs.ps1`. Building from source is a Windows-first workflow by the look of it, and that makes sense given what it connects to, though it does mean the source build is not obviously a cross-platform exercise.

The release gap between the tag and the last push

The release history has a gap that matters if you plan to pin a version. The newest tag is v2025.2.6 from 2025-02-06, and before that came v2024.1.11 from 2024-01-12 and v2023.5.3 from 2023-05-03. The last push to the repository was on 2026-09-28, which is roughly nineteen months after the newest tag.

Both facts are in the repository and neither is hidden, but they point in different directions. Work has continued on master well past the last release, so building from the current source gets you code that is newer than anything downloadable from the releases page. Whether that code is as tested as a tag is a different question, and the release notes give no way to answer it.

The content of the v2025.2.6 notes is characteristic of the project. It is a commit list rather than a curated changelog, and several entries are the kind of thing you only see in the log of a tool maintained by one person: a partial fix for AD Explorer imports that fixes negative offsets, hexifying unreadable binary output and truncating long values in the web interface, a first attempt at an NTDS.DIT reader where timestamps and objectClass are still not working, and the removal of non-working SACL parsing. Alongside those are substantive additions: a DCsync node, service SID objects for local machine services, parsing of msPKIRoamingTimeStamp, and a fix to KerberosCache pre-checking.

That mixture tells you what to expect from the code. The graph analysis is mature, and individual parsers for the more exotic parts of Active Directory are still being worked on.

How it differs from ADRecon and PlumHound

The honest comparison is with the tools a defender is more likely to already have. ADRecon collects from Active Directory across a whole forest and prints structured reports: accounts, groups, trusts, sessions and ACL findings as readable text. PlumHound collects data in BloodHound-compatible formats so that the graph analysis happens in BloodHound, typically with Neo4j behind it.

The difference in approach is where the graph is computed. ADRecon keeps the analysis in the report, which means you read rather than query, and it is extremely good at enumerating facts across many domains. Adalanche computes paths itself and puts them in the graph immediately, with AQL available when you need to ask a question the view did not anticipate. PlumHound pushes the analysis into BloodHound, which means you inherit BloodHound's query language, its UI and its Neo4j infrastructure, but you also gain a mature ecosystem of prebuilt queries written by other people.

The tradeoff is setup. Adalanche is one Go binary that collects and serves its own web interface, so there is no database to run. BloodHound requires Neo4j, which is real infrastructure to operate and back up. In exchange for the simpler deployment, you get a query language that only exists in Adalanche and a graph engine maintained by one author, whose release tags have not moved in nineteen months. If your team already runs BloodHound with working queries, PlumHound plus that existing knowledge is the lower-risk path. If you want a path query in five minutes with nothing to install but the tool, Adalanche is the faster answer.

Editorial conclusion

Adalanche is a strong choice for a defender who needs to answer a specific question, who can reach Domain Admin through this service account, and who wants to answer it by reading a graph rather than reading a report. It is a weaker choice for an organisation that wants every data source wired up on day one, because vSphere, CyberArk, password hashes, tiering models, custom node and edge types and the reporting feature are all marked as paid in the README. The last tagged release is v2025.2.6 from 2025-02-06 while the last push was on 2026-09-28, so treat the build from source as the current version rather than the release page. Before anything else, confirm your LDAP bind has the rights to read the domain and then run AQL for the shortest path to a privileged group, since that single query is the reason to install the tool.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. lkarlslund/Adalanche on GitHub
3. Project website
4. README
5. Releases