bloodyAD: an Active Directory privilege escalation toolkit built on MSLDAP

An LDAP client for specific actions, not an enumeration tool

The README describes bloodyAD as an Active Directory privilege escalation swiss army knife, and the description underneath is precise about what that means: the tool performs specific LDAP calls to a domain controller in order to perform AD privesc.

That word choice, specific, sets the boundary. This is not a replacement for a discovery tool. It does not enumerate the domain, dump shares, or produce a map of who can escalate to what. It executes the calls that change or claim privilege, and it expects you to already know which one you want.

The project is Python, MIT licensed, and its last push was on 2026-09-15. Releases are frequent but shallow: v2.5.5 on 2026-08-05, v2.5.4 on 2026-01-31 and v2.5.3 on 2026-01-19, all three with empty release bodies. The package version in `pyproject.toml` matches v2.5.5. An empty changelog is a real gap for a security tool, because the only record of a change is the commit history and the wiki.

The tree is compact: `bloodyAD.py` sits alongside a `bloodyAD/` package, with `Makefile`, `pyproject.toml`, `requirements.txt`, `requirements-dev.txt` and a `tests/` directory. There is no `docs/` tree, which is consistent with documentation living in the wiki rather than the repository.

Four authentication paths, and no requirement for LDAPS

The authentication story is where the tool differentiates itself. The README lists four ways in: cleartext passwords, pass-the-hash, pass-the-ticket, and certificates. Each of those becomes a bind to the LDAP services of a domain controller.

Two further lines in the README matter as much. Exchange of sensitive information without LDAPS is supported, which is an explicit choice rather than an omission, and the tool is designed to be used transparently with a SOCKS proxy.

Put together, those two sentences describe an operational posture. A traditional Active Directory tool assumes you have a host inside the network and can reach the domain controller over LDAPS on port 636. bloodyAD is built for the case where you have neither: you are on a pivoted host, traffic egresses through a SOCKS proxy, and the only reachable endpoint is plain LDAP. The four authentication methods are all LDAP bind mechanisms, so the same transport carries all of them.

The certificate option is worth singling out, because it is the least common of the four in this class of tool. Binding with a certificate rather than a password removes the credential-replay pattern entirely, which matters when you are operating inside a domain where that behavior is monitored.

Running the first command

The README gives one command as simple usage, and it is a password reset against a named account:

bloodyAD --host 172.16.1.15 -d bloody.local -u jane.doe -p :70016778cb0524c799ac25b439bd6a31 set password john.doe 'Password123!'

Reading it tells you the shape of the interface. The connection details come first as flags: `--host` for the domain controller, `-d` for the domain, `-u` for the user, and `-p` for the password. Then comes the operation as a pair of words, `set password`, followed by the target account and the new secret.

The `-p` value in that example is prefixed with a colon, which is the marker for a hash rather than a cleartext password, and it is a 32 character hex string, so it is an NT hash. That single character is the whole difference between the four authentication modes at the command line.

The subcommand vocabulary is where the README stops. It points to the wiki for more, and the wiki is where the full list of operations and their flags lives. Anyone evaluating this tool needs that page open next to the repository.

Entry points, pinned dependencies and the engines underneath

The packaging is modern and worth reading, because it tells you what the tool is standing on. `pyproject.toml` builds with hatchling, requires Python 3.8 or later, and installs two console scripts, `bloodyAD` and `bloodyad`, both pointing at `bloodyAD.main:main`. The lowercase alias means a Windows shell where the case is not preserved still resolves the command.

The dependency list is short and pinned tightly where it matters: `cryptography` at exactly `44.0.2`, `asn1crypto` at `1.5.1`, `winacl` at `0.1.9`, with `badldap` at `0.7.6` or later and `kerbad` at `0.5.10` or later. Exact pins on the cryptographic packages are the right instinct for a tool that handles Kerberos tickets and certificate operations.

The acknowledgements section names the engines. The README credits `@skelsec` for MSLDAP, describing it as the engine on which bloodyAD is now running, so the LDAP protocol work lives in another project and this repository is the privesc logic on top. It also credits impacket contributors for structures and several LDAP attacks, `PowerView.ps1` from PowerShellMafia for inspiration, `adidnsdump.py` and Powermad for the DNS functionality, and `p0dalirius` for pydsinternals, which helped build the shadow credential attack.

That provenance is the honest way to evaluate the tool: this is an interface and an operation set over existing libraries, not a from scratch protocol implementation.

A test suite that assumes you own a lab

The `Makefile` is the most instructive file in the repository, because it explains what testing this tool requires. The help target lists install, install-dev, test-unit, test-functional, test-auth, lint and clean, and the comment at the top gives the developer setup as a virtual environment on Python 3.13 with an editable install plus the dev requirements.

The three test tiers are separated by what they need from you. `test-unit` runs AD free unit tests that require no lab at all, and it is the only tier that works on a laptop with no network. `test-functional` needs `tests/secrets.json` and a running domain controller, and the target refuses to run without the secrets file, printing instructions to copy `tests/secrets.json.example` and to see `tests/lab/README.md` for lab setup. `test-auth` needs a domain controller and AD CS, which is a certificate services role, so the authentication tests exercise certificate binding against a real issuance environment.

That split is a good sign about how the project is maintained. Someone wrote a lab setup guide, made the no-lab tier runnable by default, and made the lab-dependent tiers fail loudly rather than silently skip. The cost to you as an evaluator is that you cannot run two thirds of the suite without building a lab first.

Where it sits against impacket and PowerView

The honest comparison is against the tools it credits. Impacket offers LDAP attacks in Python and is the more general framework, covering relay, named pipe and SMB work far beyond Active Directory privilege escalation. bloodyAD is narrower: a set of specific privesc calls with four authentication methods and proxy transparency. If you need breadth, impacket already has it.

Against PowerView, the difference is transport and discovery. PowerView is PowerShell, which means it runs natively anywhere PowerShell runs with no Python environment to arrange, and it is built for querying and enumerating. bloodyAD makes specific state-changing calls instead. Teams that already run PowerShell on every endpoint often stay with PowerShell for enumeration and reach for a tool like this when they need one operation through a proxy.

There is also the autobloody note at the top of the README, which says that project has been moved to its own repository. The author is splitting the tooling: bloodyAD for the privesc operations, autobloody elsewhere. If you are evaluating the pair, they are separate installs now.

What bloodyAD does not offer is what a framework offers. No plugin system, no session persistence, no detection of the local domain automatically. You supply the host, the domain and the credentials.

Editorial conclusion

bloodyAD makes sense for a tester or defender who already has a foothold in a domain and wants specific LDAP operations against a domain controller, particularly from a position where LDAPS is not reachable. It is the wrong tool for a first step, for enumeration at scale, or for environments where you need a maintained set of release notes, since the newest tag is v2.5.5 from 2026-08-05 with empty notes and the real reference is the wiki. Start with `make test-unit`, which needs no lab, and read `tests/lab/README.md` before attempting the functional or authentication suites, since those require a running domain controller and a secrets file you have to create yourself.

Frequently asked questions

Official sources

1. CravateRouge/bloodyAD on GitHub
2. Issues
3. License: MIT
4. README
5. Releases