SrHollow is a PowerShell and C# toolkit that pulls LSA secrets and DPAPI keys from Windows registry hives via shadow copies, intended for authorized assessments and defensive research.
| Tool | ivancabrera02/SrHollow — extracts LSA secrets and DPAPI keys from SECURITY/SYSTEM hives read through VSS shadow copies |
| Primary Use | Demonstrating, on systems you administer, how SeBackupPrivilege plus a shadow copy of the SECURITY hive yields the BootKey, the LSA AES-256 key, and DPAPI_SYSTEM machine/user keys |
| Primary Use | Authorized red-team engagements and lab exercises where an operator already holds local admin and needs to audit which secrets are recoverable from Policy\Secrets |
| Safe Use | For authorized penetration tests, owned lab machines, and defensive research only; local admin with SeBackupPrivilege is required, so this validates containment on hosts you control |
| Telemetry Note | On an existing shadow, leaves only one CreateFileW on \?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\... and one AdjustTokenPrivileges call — the README notes this matches ordinary backup agents, so defenders should focus on shadow-copy creation events and DPAPI/LSA access auditing |
SrHollow is a compact Windows credential-audit tool from ivancabrera02, written in PowerShell with a single-file C# core, that demonstrates how the combination of SeBackupPrivilege and a Volume Shadow Copy of the SECURITY hive collapses into full recovery of LSA secrets and host-wide DPAPI master keys. What distinguishes it from the usual reg save-style approaches is that it never touches the live hive files directly and never shells out to vssadmin: everything from shadow enumeration to registry parsing to AES decryption happens inline, in roughly 350 lines of C#. This article is an educational and documentary analysis for authorized professionals assessing their own Windows estates.
The chain, as the README lays it out in six steps, begins with enumerating the NT object directory \GLOBAL?? using NtOpenDirectoryObject and NtQueryDirectoryObject, looking for the highest-numbered HarddiskVolumeShadowCopyN device symlink. This is a notably quiet discovery method compared to the more common WMI or vssadmin list shadows queries that EDR rules frequently pattern-match. If no shadow copy exists, the tool falls back to SRSetRestorePointW from SrClient.dll, deliberately faking a DEVICE_DRIVER_INSTALL restore-point event so the Volume Shadow Copy service spins one up through a legitimate restore API rather than through the shadow-copy WMI providers that get watched more closely.
With a target selected, the tool enables SeBackupPrivilege in its own token via AdjustTokenPrivileges — the privilege any local administrator already holds but rarely has enabled by default. It then opens the shadow-copied SECURITY and SYSTEM hives with CreateFileW using FILE_FLAG_BACKUP_SEMANTICS, reading them fully into memory as byte[]. The README is explicit about the OPSEC profile here: when a shadow copy already exists, the entire observable footprint is one file open against the GLOBALROOT device path plus one privilege-adjustment call, a profile it correctly describes as indistinguishable from ordinary backup software. The loud path is only when a shadow must be created.
The most technically interesting component is the inline regf parser inside src/SrHollow.cs. Rather than depending on an external library, the author implements the registry hive format from the base block down through cell types nk, vk, lf, lh, li, ri, db, and sk. The README documents the KeyNode layout in detail — flags at 0x02, subkey list at 0x1C, value list at 0x28, security key at 0x2C, class offset at 0x30 — and candidly admits that the first pass contained a bug in the class-length field, which sits as a u16 at 0x4A with the name length at 0x48 and the name itself at 0x4C. That admission is a useful signal: the author actually reverse-engineered the format rather than transcribing it, because Microsoft's own documentation is described as ambiguous on that field.
Key derivation follows the well-documented Windows internals route. The BootKey (SYSKEY) is assembled by concatenating the UTF-16 hex class names of ControlSet00N\Control\Lsa\{JD, Skew1, GBG, Data} into 16 raw bytes, then applying the classic permutation table [8,5,4,2,11,9,13,3,0,6,1,12,14,10,15,7]. The LSA AES-256 key comes from Policy\PolEKList\(default), a 172-byte structure whose salt at 0x1C..0x3C is stretched with 1000 rounds of concatenation against the BootKey into a SHA-256 temporary key, used for an AES-256-CBC decrypt with a zero IV of the remainder; the actual LSA key is bytes 68..100 of the plaintext. Each secret under Policy\Secrets\<name>\CurrVal\(default) uses the identical salt-stretch construction, with the LSA key in place of the BootKey.
The payoff documented in the README is the DPAPI_SYSTEM secret, whose body yields the 20-byte MachineKey at bytes[4..24] and the UserKey at bytes[24..44]. Those two values decrypt every SYSTEM-scoped DPAPI master key on the host, which in turn unlocks whatever machine-scoped protected data — scheduled-task credentials, Wi-Fi keys, browser-adjacent blobs on some configurations — has accumulated there. For a defender, this is the crux of why LSA secret exposure is rated as effectively a full-host credential compromise rather than a single leaked password: the DPAPI_SYSTEM values are the root of the machine's protected-storage hierarchy.
The repository layout reflects a staged workflow: stages/Stage1-Recon.ps1 does strictly read-only shadow enumeration, Stage1b-ReadShadowHives.ps1 auto-detects or auto-creates a shadow and copies the hives, Stage2-Decrypt.ps1 performs the BootKey and LSA key derivation plus secret decryption, and Stage3-Report.ps1 formats an operator report that the README says includes an explicit OPSEC footprint section. The C# core has zero dependencies beyond System.Security.Cryptography, which itself proxies to bcrypt.dll, and compiles as-is under Add-Type or csc.exe. That minimalism is deliberate: no NuGet packages, no Reflective loading frameworks, just Win32 API calls and FIPS-validated crypto primitives invoked the way any signed application would.
For authorized operators wanting only the safest first look, the recon stage can be run against a lab host with powershell.exe -ep bypass -File .\stages\Stage1-Recon.ps1, which simply lists existing shadow copies without modifying anything. The full source is at github.com/ivancabrera02/SrHollow for review. We are deliberately not walking through the hive-slurp and decrypt stages here; the value of the README is that it documents them precisely enough for study on systems you own, and reproducing the sequence adds nothing educational beyond what the repository already states.
From a blue-team perspective, the tool is arguably more useful as a detection-design exercise than as anything else. The README's own OPSEC analysis tells you where to focus: the file-open profile against \?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\ is benign-looking by design, so the higher-signal events are shadow copy creation through SRSetRestorePointW (an unusual trigger for a restore point), enablement of SeBackupPrivilege, and access auditing on C:\Windows\System32\config\SECURITY. Registry and object-access audit policies that flag reads of PolEKList and Policy\Secrets by unusual processes are the natural detection anchor, since the decryption itself is unremarkable userland crypto.
At 58 stars and with the repo written as a single-file educational implementation, SrHollow reads more as a well-documented internals reference than as a mature engagement framework. The value for authorized professionals is the completeness of the writeup: it connects NT object enumeration, SRP-based shadow creation, backup-semantics file access, raw regf parsing, and the documented LSA/DPAPI key schedule into one auditable codepath. If you administer Windows hosts and want a concrete demonstration of why local admin plus an enabled SeBackupPrivilege should be treated as equivalent to credential compromise, studying this repository on a lab machine is an efficient way to make that case to stakeholders.
ivancabrera02/SrHollow.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.