hollows_hunter: a process-wide memory scanner built on PE-sieve

What hollows_hunter solves, and who actually needs it

Process hollowing and its relatives leave a trace that is hard to see from the outside. A legitimate executable starts, its image is replaced or patched in memory, and the on-disk file no longer matches what is executing. File-based antivirus sees a clean binary. hollows_hunter attacks that gap: it walks the running process list and looks inside each process for replaced or implanted PEs, shellcode, hooks and in-memory patches, then dumps what it finds.

The target user is a malware analyst or incident responder working on a live Windows host. The README frames the tool as a command-line application based on the PE-sieve passive memory scanner, and the difference from PE-sieve is targeting. PE-sieve takes a PID. hollows_hunter accepts a list of PIDs, a list of process names, or a time-of-creation filter relative to when hollows_hunter itself started. With no target selected it scans all available processes, which is the mode that makes it useful during triage: you do not have to guess which process to look at first.

It is not an endpoint agent. There is no service, no quarantine action and no verdict. The output is evidence for a human.

How the scan works: PE-sieve as a library, plus targeting and reporting

The repository layout makes the architecture fairly plain. pe-sieve is a git submodule, and the README says hollows_hunter uses the library version of PE-sieve. Around that library sit hh_scanner.cpp, hh_params.cpp and hh_report.cpp, which map to the three jobs the tool does: decide what to scan, run the scan, and write the report. paramkit is a second submodule, used for the command-line argument layer, and krabsetw is a third, used for the ETW listener that the README describes as a 64-bit-only mode.

Data flow is one-directional and passive. hollows_hunter enumerates processes, applies the selection criteria, and hands each target to the PE-sieve scanner, which reads the process memory and compares what it sees against expectations for a normally loaded image. Anything that does not fit (an image whose in-memory content diverges from the file, executable regions that are not backed by a module, patched code) is treated as an implant and written out. The report layer then produces the dumped artifacts.

Two consequences follow from that design. First, hollows_hunter inherits PE-sieve's detection logic entirely; if PE-sieve misses a technique, hollows_hunter misses it too. Second, the tool is passive: the README calls PE-sieve a passive memory scanner, so nothing is injected into the target and the process is not stopped for you. A process that exits mid-scan is simply gone.

Downloading and running a first scan

The README points to two distribution routes. The recommended one is the release page, where prebuilt binaries are published; the README also notes the package is available via Chocolatey. Building from source requires a recursive clone, because pe-sieve, paramkit and krabsetw are submodules and a plain clone leaves those directories empty. The README gives this exact command for that step:

git clone --recursive https://github.com/hasherezade/hollows_hunter.git

If you already cloned without the flag, the submodule directories will be empty and the build will fail. The repository ships CMakeLists.txt for a CMake build and a mingw_build.sh script for a MinGW build, so there are two build paths rather than one.

Once you have the binary, the first thing to run is the help output. The README states the available arguments can be listed with /help, and that the full documentation lives on the project wiki. Run with no arguments, the tool scans all available processes. That is the intended first real use, and it is also the slowest. Expect it to take time and to write dumps into an output directory rather than printing a clean list of verdicts. The README does not document the default output path or the exit codes, so treat /help and the wiki as the source for both.

Continuous scanning: /loop and the 64-bit-only /etw mode

A single sweep catches what is resident at that moment. The README describes two ways to keep watching. The /loop argument repeats the scan, which is the simple option: the same enumeration and the same PE-sieve logic, run again and again. The /etw mode makes hollows_hunter an ETW listener instead, reacting to events rather than polling, and the README states plainly that this mode is available in the 64-bit version only.

That asymmetry is worth taking seriously. If you build or download a 32-bit binary, the event-driven mode is not part of what you have, and the README does not describe a fallback. It also means the two modes are not equivalent in cost. Polling with /loop re-scans processes that have not changed, which is wasted work on a busy host; the ETW listener depends on krabsetw and on the events Windows chooses to emit.

Neither mode turns hollows_hunter into a real-time protection product. There is no documented alerting, no integration with a SIEM, and no automatic response. Continuous here means repeated collection, and the analysis still happens afterwards.

Where hollows_hunter is the wrong tool

The most obvious limit is the platform. The README carries a Windows badge and the repository contains a Windows manifest and a resource script; there is no indication of a Linux or macOS build. If your fleet is not Windows, this project has nothing for you.

Second, hollows_hunter does not tell you whether something is malicious. It recognizes and dumps potentially malicious implants. The word potentially is doing real work: a legitimate packer, a JIT engine, an injected accessibility tool or a security product's own hooks can all produce artifacts that look like implants. The output is a set of dumps that a human has to triage. If you want a yes/no answer, you are looking at the wrong layer of the stack.

Third, the documentation surface is thin in places. The README defers arguments to the wiki and to /help, and it does not document rollback, output directory layout, exit codes or performance characteristics. For an incident responder that is tolerable, because the wiki is the canonical reference. For anyone trying to automate hollows_hunter inside a pipeline, the missing machine-readable contract is a real obstacle.

Finally, scanning every process on a live machine has a cost, and the README does not quantify it. On a production server, a full sweep with dumps enabled is not something to schedule casually.

PE-sieve alone, and how the choice differs

The natural alternative is PE-sieve, the scanner hollows_hunter is built on. The difference is not detection quality, since hollows_hunter uses PE-sieve as a library; it is the targeting model and the scope of a run.

PE-sieve takes a single process, selected by PID. That is the right shape when you already suspect a process: you attach to that one target, get a focused dump, and move on. hollows_hunter inverts the workflow. It accepts lists of PIDs, lists of process names, or a creation-time filter, and with no target it sweeps everything. That is the right shape when you do not yet know where to look, which is the normal state at the start of a triage.

The trade-off is noise and time. A full sweep produces dumps from many processes, and the analyst pays for that in review effort. If you have a specific PID from an alert, PE-sieve is the smaller, faster answer. If you have a suspicious host and no PID, hollows_hunter is the one that enumerates for you. The README also notes that hollows_hunter adds the continuous modes, /loop and /etw, which are not described as features of the base scanner.

Maintenance, licence and upgrade cost

The repository is not archived and the last push was on 2026-06-06, so it is recently touched. Releases are infrequent rather than continuous: v0.4.0.2 in February 2025, v0.4.1 in February 2025, and v0.4.1.1 in September 2025. Plan on picking up prebuilt binaries from the release page rather than tracking a fast-moving branch.

The practical upgrade cost is low because the interface is a command line and the artifacts are files. There is no service to restart and no database schema. The dependency chain is the part that moves: pe-sieve, paramkit and krabsetw are submodules, so a source build tracks whatever those point at, and the detection behaviour you get is PE-sieve's behaviour at that revision. If you build from source, update the submodules deliberately rather than letting them drift.

The licence is BSD-2-Clause, which is permissive and generally easy to fold into internal tooling. That is the licence identifier in the repository, not legal advice; if you plan to redistribute a modified binary, read the LICENSE file and the licences of the submodules yourself, since pe-sieve, paramkit and krabsetw are separate projects with their own terms.

Editorial conclusion

Adopt hollows_hunter if you do live Windows triage and want a single binary that sweeps every process and writes dumps you can inspect offline. Skip it if you need a verdict, a GUI, or anything cross-platform: the README lists Windows only, and the tool reports implants rather than classifying them. Before relying on it, run it with /help to confirm the arguments your build supports, then test the /loop or /etw modes on a machine you can afford to slow down.

Frequently asked questions

Official sources

1. hasherezade/hollows_hunter on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases