ADExplorerSnapshot, a parser for a proprietary snapshot format

AD Explorer writes a proprietary file, so the first job is parsing it

AD Explorer is a legitimate Microsoft tool that lets you connect to a domain controller and browse LDAP data, and it can create snapshots of the server you are attached to. Those snapshots are the interesting artefact, because they capture the directory in one pass. The catch is stated plainly in the project description: the format in which snapshots are stored is proprietary, and getting at the contents required a reverse engineering effort.

The project keeps the evidence of that work in the repository. A 010 editor template is included, the binary template format for mapping the snapshot into structures, and the author describes using it to iteratively work out what the file contains. The parsing itself is done with dissect.cstruct, a C-style binary struct parser.

So the problem this tool solves is not collection. You already have the data, in a file, on disk. The problem is that the file is in a format no open source tool reads, and the pipeline you want to use, BloodHound, wants JSON in a particular shape. This is the converter between the two.

The audience is red team and blue team operators who work with AD Explorer as their collection tool of choice and want the results to land in BloodHound's graph. The name of the input file, the snapshot .dat, is the only thing you have to supply.

Three output modes, and why the default is not the one you would guess

The tool offers three output modes, and the one you get by default is the most complete of them.

In BOFHound output mode, all attributes for every object are parsed and output in the BOFHound format, which the description calls similar to LDIF. The collections covered are users, groups, computers, trusts, OUs, GPOs and certificate templates. The documentation calls this the preferred output mode and the most complete collection approach, and the mode is the default when you do not pass a mode flag.

In Objects output mode, all attributes for every object are parsed and written as NDJSON, one JSON object per line. That is the escape hatch for processing elsewhere, and the point of the project description's mention of full-object dumping to NDJSON for easier processing.

The third mode, BloodHound output mode, is marked as deprecated in favour of the more complete BOFHound conversion. It processes everything it can from the snapshot, including ACLs, but outputs only the JSON that BloodHound can interpret, and GPO and OU collection is missing from it.

That default is the interesting design decision here. A tool named after a parser might be expected to output its own format, but this one defaults to an intermediate format designed for another tool, which keeps the transformation to a single, well documented hop.

Running it with uvx and a path to the snapshot file

The tool supports Python 3.12 and later, and dependencies are managed with pip. The installation section recommends running it directly with uvx, which means there is no clone and no virtual environment to manage.

uvx git+https://github.com/c3c/ADExplorerSnapshot

Passing the snapshot path is the whole invocation, and the mode and output folder are flags.

uvx git+https://github.com/c3c/ADExplorerSnapshot -m BOFHound snapshot.dat

The snapshot is a positional argument and has to be the .dat file itself. The output option takes a path to a JSON output folder, and the folder is created if it does not exist, defaulting to the current directory otherwise. The mode option accepts BOFHound, BloodHound or Objects, and the help text states that the default is the BOFHound mode.

The command line interface is otherwise plain argparse, with the usual help flag, which keeps it scriptable. The two console entry points declared in the project metadata are ADExplorerSnapshot.py and adexplorersnapshot, both pointing at the same main function, so the tool can be invoked by either name once it is installed as a package.

The parser is also implemented as its own module, which the description says means it can be used individually, so a project that only wants the snapshot reading can import it without adopting the command line tool.

The two step pipeline: BOFHound first, BloodHound second

The BOFHound mode is not the end of the line. The output it produces is intermediate, and the documented workflow is two steps: this tool converts the snapshot, then BOFHound ingests that conversion into BloodHound.

uvx git+https://github.com/c3c/ADExplorerSnapshot -m BOFHound snapshot.dat
uvx bofhound -i ./dc.server.com_1234567890_bofhound.log -o output

The second command takes an input file produced by the first, a log with a name built from the domain controller and a timestamp, and an output directory.

This split explains the design of the whole project. Rather than reimplementing the ingest logic, the author reuses the existing pieces: the BloodHound.py Python ingestor for processing LDAP data, the BOFHound project for the conversion step, and certipy for processing certificate template information. The dependency list in the project metadata matches that, with bloodhound-ce, dissect.cstruct, frozendict, requests, rich and certipy-ad named directly.

For an operator, the practical consequence is that the output of this tool is not the end product, and the end product is a BloodHound database you can query. Anyone planning a pipeline has to budget for both steps, and for the intermediate file that sits between them.

Certificate templates: cert_bh for the regular client, cert_ly4k for the fork

Certificate template support is the part of the tool with the fiddliest instructions, and the reason is that there are two BloodHound clients with different import expectations.

Certificate templates can be imported in BloodHound format or in the BloodHound-ly4k format. If you use the regular BloodHound version, the instruction is to import only the cert_bh JSON file, and those are imported as GPOs. If you use ly4k's fork, you import the cert_ly4k files instead. The project credits the FalconForce team with adding certificate template support.

The fork exists for a reason, and the documentation says so. Some information will be omitted, for example whether Web Enrollment is enabled for ESC8, because it cannot be collected with AD Explorer. The snapshot simply does not contain it, so the omission is a property of the source rather than a gap in the parser.

This is a good illustration of the tool's central limitation, which the project states directly. AD Explorer snapshots contain only the information retrievable from the LDAP server, so features like session and localadmin collection are not available, and the tool does not interact with systems on the network. You get the data of the LDAP server and domain controller you ran the snapshot against, and nothing else.

Memory, network noise and the shape of the data you get

Two operational realities sit behind the tool and are worth planning around.

The first is memory. The tool creates caches of information for quicker lookups while processing the data, and the author states that for larger snapshots, for example 4GB and up, you need sufficient RAM available, with about half the snapshot file size required in RAM in the author's tests. A large snapshot is therefore a large Python process, and the footprint scales with the file.

The second is what the domain controller sees while you collect. The notes section says making snapshots in AD Explorer is more network-intensive than the traditional BloodHound ingestors, because it attempts to retrieve all objects it can from LDAP. On the OPSEC side, the tool points out that AD Explorer is a legitimate Microsoft tool, and that when performing a snapshot only limited queries are made to the LDAP server, with the filter (objectGuid=*). The limited query count is deceptive: the result set is huge, since all objects and their associated attributes are retrieved, and the output is correspondingly voluminous.

A third detail is smaller but relevant to interpretation. Trust collection contains the view as visible from the LDAP domain controller you are connected to, not a global truth about the trust topology.

Detection is documented rather than hidden

There is a section on OPSEC and detection, and its honesty is a mark in the project's favour.

The project does not pretend the collection is invisible. Detection of this tool is possible in multiple ways, and for the method the author points at a blog post by FalconForce, Detecting Active Directory Data Collection, referenced by its series name and number, FalconFriday 0xFF21. The recommendation is to read that write-up rather than to guess.

The framing matters. The tool does not present itself as something that operates covertly, and it does not claim to defeat monitoring. It states that AD Explorer is a legitimate Microsoft tool, and it points out that the collection behaviour visible to defenders comes from AD Explorer rather than from this converter. The parser itself runs on a file that already exists on your disk and issues no LDAP queries of its own, which is a meaningful distinction for anyone reasoning about what a defender will actually see.

For a defender on the other side, the read is the reverse of the operator's. A voluminous LDAP result set with that filter is a signal worth looking at, and the project is effectively pointing defenders at the same evidence it warns operators about.

Packaging, licence and the mismatch between Python 3.12 and the container image

The project is packaged as a normal Python distribution. The project metadata declares version 2.0.0, a requirement of Python 3.12 or newer, the MIT licence, and classifiers for information technology, science and research, and system administrators audiences. The build backend is setuptools with setuptools_scm for versioning, and the package layout is two modules, adexpsnapshot and adexpsnapshot.parser, which is the split between the command line entry point and the parser you can import on its own.

A Dockerfile is included, and it carries a decision worth noting. The base image is Python 3.10 on Alpine, with a comment explaining that 3.10 is used to avoid a 3.11 incompatibility, with a link to an issue in the certipy project. The image installs a set of Alpine packages including git, bash, cmake, build-base, python3-dev, py3-capstone, py3-psutil and py3-unicorn, then installs the requirements with pip, and its entrypoint runs ADExplorerSnapshot.py with --help as the default command.

So the container runs a different Python minor version from the one the project declares, on purpose. That is a reasonable engineering trade, and it is documented in the file itself rather than left for you to discover.

The licence is MIT and the code reuses MIT licensed code, and the project thanks Deloitte for providing the environment in which the tool was developed. There are no GitHub releases, the version 2.0.0 lives in the project metadata, and the last push was on 2026-07-10.

Editorial conclusion

Adopt ADExplorerSnapshot.py if you already collect with AD Explorer and want the snapshot loaded into BloodHound through BOFHound without querying the domain again, and if you are comfortable handling a proprietary binary format and a large memory footprint. Do not adopt it as a replacement for the standard BloodHound collectors, since it sees only what LDAP returned and has no session or local admin data, and do not use the deprecated BloodHound mode expecting parity, as GPO and OU collection are missing there. Before you commit, run `uvx git+https://github.com/c3c/ADExplorerSnapshot -m BOFHound snapshot.dat` on a copy of the snapshot, keep in mind that processing a 4GB snapshot needs several gigabytes of RAM, and check the FalconForce detection write-up for what your domain will see.

Frequently asked questions

Official sources

1. c3c/ADExplorerSnapshot on GitHub
2. Issues
3. README