AI
BitLocker Threat Model and WinRE Attack Surface
BitLocker’s threat model assumes a thief: full physical access, no credentials. WinRE sits inside that model — anyone at the login screen holds Shift, clicks Restart, and boots straight into it. When BitLocker shipped, WinRE adapted: its WIM moved to an unprotected recovery partition, a hash check auto-unlocks the OS volume when the WIM is intact, and a relock fires if a risky tool like Command Prompt runs. Those changes created parsing paths from the auto-unlock window into attacker-controlled volumes — an attack surface prior research had barely touched.
“Before Bit Locker, even full code execution within Win didn’t grant a physical attacker any new capabilities.” — Alon Leviev
Boot SDI Offset Manipulation — Vuln 1
The boot.sdi file stores a WIM blob containing an offset that points to the trusted WinRE WIM in the RAM disk buffer. WinRE hashes the WIM on load, and if the hash fails, the OS volume locks. The SDI itself receives no validation.
“Notably, there is no verification linking between the whim being used to the one that was hashed earlier, allowing the offset to be set arbitrarily.” — Netanel
Netanel’s team appended a custom, untrusted WIM to the SDI, then set the offset to point at it instead of the trusted WIM. Hash validation runs against the trusted WIM and passes. The untrusted WIM executes. He walked through the Boot SDI exploit — untrusted WIM loads, C drive unlocked (13:13) live: the BitLocker status on C reads “unlocked,” protection still on, all files readable.
AR Agent XML Offline Scanning Abuse — Vuln 2
The reagent.xml file controls WinRE’s recovery state. Write a scheduled offline-scan operation into it before boot, and WinRE will execute that scan before the UI ever appears — while the OS volume is still in the auto-unlock state. Offline scanning is meant for AV tools, so it requires a Microsoft- or WHQL-signed binary with embedded signatures. CMD doesn’t qualify. Reviewing the roughly 30 binaries that do, Netanel landed on TTTracer, a time-travel debugger that traces an arbitrary executable. Trace CMD, get CMD.
Set reagent.xml to schedule the offline scan with TTTracer pointed at cmd.exe, reboot, and TTTracer offline-scan exploit — cmd spawns in auto-unlock state (17:29): TTTracer launches pre-UI, prompts for a EULA accept, and immediately spawns a shell. The C drive shows unlocked, BitLocker protection still on. No recovery key requested, no relock triggered.
Trusted WinRE App Abuse via Setup Platform — Vuln 3
Windows Update leaves SetupPlatform registered as a trusted WinRE app — and never cleans up that registry entry. Scheduling it via reagent.xml passes hash validation because the binary is legitimate, so the OS volume stays unlocked. SetupPlatform registers Shift+F10 as a cmd hotkey immediately on launch, then checks for a SetupPlatform INI file on the writable recovery volume. Plant that INI file with the right flags and the app triggers a blocking message box instead of exiting. The window that was milliseconds wide becomes indefinite. SetupPlatform trusted-app exploit — Shift+F10 spawns cmd (22:58) shows the message box appear, Shift+F10 fire, and cmd open with BitLocker status reading “unlocked, protection on.”
BCD Store Confusion and Full BitLocker Decryption — Vuln 4
Windows iterates volumes using FindFirstVolume / FindNextVolume, and the return order differs from physical layout: recovery comes before EFI. Plant a fake BCD store on the recovery volume and WinRE picks it up, skipping the real EFI store. The boot manager unlocks the OS volume normally, but WinRE treats the attacker-controlled volume as the BitLocker target.
Push Button Reset’s “online” mode schedules via reagent.xml, skips relock, and reads reset-session.xml from whatever it identifies as the OS. That file accepts a decrypt-volume directive. A fake BCD store and a crafted reset-session.xml naming the OS volume fully strips BitLocker on reboot. Full PBR decryption chain — BitLocker disabled on reboot (33:37)
“We went from a limited OS impersonation primitive to an arbitrary volume decryption primitive.” — Alon Leviev
Patches, CVEs, and Hardening Countermeasures
All four vulnerabilities were patched in a July Patch Tuesday update. The CVE numbers are on-screen in the talk. Enabling TPM+PIN pre-boot authentication removes the entire WinRE-originating attack surface — the attack requires BitLocker to auto-unlock during WinRE startup, and TPM+PIN blocks that. Enabling the revocation mitigation closes a separate angle: it enforces secure versioning across critical boot components, preventing downgrades that could reintroduce already-patched flaws in BitLocker and Secure Boot.
Notable Quotes
Before Bit Locker, even full code execution within Win didn’t grant a physical attacker any new capabilities. Alon Leviev · ▶ 9:55
Notably, there is no verification linking between the whim being used to the one that was hashed earlier, allowing the offset to be set arbitrarily. Netanel · ▶ 12:23
We went from a limited OS impersonation primitive to an arbitrary volume decryption primitive. Alon Leviev · ▶ 33:31
Key Takeaways
- WinRE is fully inside BitLocker’s threat model — treat every file it parses on unprotected volumes as an attack surface.
- Enable TPM+PIN pre-boot authentication to eliminate the entire WinRE-originating BitLocker attack surface.
- Leftover post-upgrade trusted-app registry entries and unvalidated format offsets are exploitable primitives; audit both.