SilentHarvest_BOF: The registry dumper that makes BOF code feel normal
A niche Cobalt Strike module that sidesteps LSASS, leans on SeBackupPrivilege, and hides its own complexity behind a post-build symbol patching workflow.
- SilentHarvest_BOF is interesting because it reduces friction twice, once for the operator through SeBackupPrivilege and once for the developer through post-build symbol patching.
- The repo’s real novelty is not just registry harvesting, but a quieter access path that avoids the usual LSASS-centered workflow.
- Its codebase is intentionally narrow, which makes it easier to read, easier to port, and more specialized than broad credential dumpers.
- The project shows where offensive tooling is heading: less boilerplate, fewer obvious artifacts, and more ergonomic tradecraft.
Most registry dumpers earn attention by being loud. This one earns it by being tidy. SilentHarvest_BOF is built around a simple idea: if you can make the access path quieter and the code path cleaner, you get a tool that is easier to run and easier to maintain.
That second part matters more than it sounds. The repo is not only about reading protected hives. It is also about making BOF development feel less like a pile of linker hacks and more like ordinary C, which is a rare design win in this corner of the ecosystem.
The hidden trick is not the dump. It is the build
The most unusual part of the repo shows up before the first registry call. Instead of burying the code under Cobalt Strike boilerplate, the author writes normal-looking C and then patches symbols after compilation. The result is a BOF that reads like software, not a stunt.
// Simplified shape of the workflow
// Source stays readable.
CAPI(NtOpenKeyEx)(...);
CAPI(RegQueryMultipleValuesW)(...);
// Build step rewrites symbols for BOF resolution.
// The source stays close to standard C.That is a developer-experience move, not just a compilation trick. In BOF land, readability is often the first thing sacrificed. SilentHarvest_BOF tries to keep it intact, which makes the rest of the code easier to audit and easier to extend.
In this blog post, I’ll share a new, simple approach I developed that successfully bypasses almost all EDRs I’ve tested.
SeBackupPrivilege changes the access path
The operational idea is narrower than a full SYSTEM-level dump. With SeBackupPrivilege, an administrator can use native registry APIs to read protected hives without the usual LSASS-centered workflow. That changes the access path, the telemetry, and the shape of the artifact trail.
| Dimension | SilentHarvest_BOF | LSASS dumpers | Hive-copy approaches |
|---|---|---|---|
| Access path | Registry read via SeBackupPrivilege and native APIs | Process memory access | Copy hives to disk first |
| Typical footprint | Lower registry-centric noise | High scrutiny around LSASS | Disk artifacts and file handling |
| Developer ergonomics | Readable C plus symbol patching | Usually separate tooling and boilerplate | Simple concept, but not BOF-native |
| Scope | Specialized for modern Windows secrets | Broad but noisy | Useful, but more artifact-heavy |
What the registry is hiding, and where
The secret anatomy is the part that makes the technique legible. The BootKey is reconstructed from the LSA subkeys JD, Skew1, GBG, and Data. Once that key material is recovered, the code can locate the structures that point to password material stored inside the hives.
That is why the repo can stay focused. It does not need to handle every credential path in Windows history. It needs to understand one chain well: privilege, boot key reconstruction, value parsing, then decryption.
The implementation keeps that chain explicit. The code maps registry blobs into named structures, then follows offsets instead of guessing. That makes the project more readable than many tools in the same category, even when the underlying objective is the same.
How the modern crypto layer fits
The repository is also intentionally modern. It focuses on newer Windows secret handling rather than legacy RC4-era paths, and it uses the Windows CNG stack for the cryptographic work. That keeps the code narrower, but it also makes the supported environment more specific.
This is a design tradeoff. Narrow support means fewer branches, less clutter, and less compatibility baggage. It also means the repo is not a universal credential platform. It is a specialized tool for a specific target profile.
My working hypothesis is that vendors concentrated on the far more common single-value APIs (RegQueryValueExW, NtQueryValueKey, etc.) and simply never added this rarer interface to their hook lists.
Why this beats louder alternatives
The best comparison is not against one competing tool. It is against the default habits of credential dumping. LSASS-based workflows are broader, but they are also more watched. Traditional hive-copy approaches are familiar, but they leave more obvious file artifacts.
| Approach | Strength | Weakness |
|---|---|---|
| SilentHarvest_BOF | Quiet access path and BOF-native ergonomics | Specialized and not universal |
| LSASS dumping | Broad coverage and well-known tooling | Highly monitored and noisy |
| Hive copy to disk | Conceptually simple | Leaves disk-backed artifacts |
That is the real niche. SilentHarvest_BOF is optimized for operators who care about minimizing obvious signals and for developers who care about not fighting BOF boilerplate every time they touch the code. Those are different problems, solved in the same repo.
What this repo is really for
This is not a general-purpose credential platform, and it does not pretend to be one. It is a narrow, specialized BOF for modern Windows environments, and that narrowness is part of the point. The code is cleaner because the scope is tighter.
The bigger implication is easy to miss. Offensive tooling is getting more ergonomic, not just more evasive. SilentHarvest_BOF shows that the next layer of tradecraft is not only about stealth. It is about reducing friction for the person writing and running the tool.
