AI
WinRE as BitLocker’s Overlooked Attack Surface
BitLocker targets physical theft: full disk access, no credentials. When BitLocker was introduced, three architectural changes reshaped WinRE. The WIM file moved to an unprotected recovery volume. Trusted WIM boot validates the WIM hash before granting auto-unlock. Risky tools, like the command prompt, trigger volume relock. During auto-unlock, WinRE parses files from the unprotected EFI and recovery volumes. Any code execution inside WinRE at that point can bypass BitLocker and read all protected secrets. That parsing surface had seen almost no prior security research.
Boot SDI WIM Substitution
The boot.sdi file precedes the WIM in RAM disk and stores an offset pointing to the WIM image’s location. WinRE validates the WIM hash during loading to confirm it has not been tampered with. The SDI itself undergoes no validation. Nothing links the stored offset back to the validated WIM. An attacker appends a second, untrusted WIM after the legitimate one inside the SDI, then sets the offset to point at it. The trusted WIM passes hash validation; the malicious WIM boots instead, with the OS volume still unlocked and all secrets accessible.
Offline Scanning via TTTracer
Re-agent.xml controls WinRE’s startup state. Setting it to schedule an offline scan runs a Microsoft-signed application from the main OS before the WinRE UI appears. Three constraints apply: the binary must reside on the OS volume, carry a Microsoft or WHQL signature, and embed that signature in the binary. Ben Simon and Leviev found roughly 30 qualifying applications. One, TTTracer, is a time-travel debugging tool that traces any executable. Configured to trace cmd.exe, TTTracer spawns a command prompt during the scan while the OS volume remains auto-unlocked.
Setup Platform’s Leftover Trusted App Entry
WinRE trusts applications by hash, storing approved binaries in the registry inside the WIM. Windows upgrade installs Setup Platform as a trusted WinRE app, and that registry entry is never removed after the upgrade completes. Setup Platform registers Shift+F10 to launch cmd.exe, then reads a configuration file from the encrypted OS volume. That file is absent, so Setup Platform exits before the hotkey can be pressed. The researchers found it also reads setup platform.ini from the unprotected recovery volume. A crafted INI triggers a message box, blocking Setup Platform from exiting and holding the hotkey open.
BCD Store Impersonation and Full Volume Decryption
WinRE locates the BCD store by calling FindFirstVolume and FindNextVolume. Those APIs return volumes in an undocumented order: the recovery volume comes before the EFI volume. Planting a fake BCD store on the recovery volume causes WinRE to use it before ever reading the real EFI store. The fake store points the target OS location at the recovery volume. Chained with Push Button Reset scheduled via re-agent.xml, PBR reads its reset-session.xml from that attacker-controlled volume. That file contains a decrypt volume directive targeting the real OS volume. PBR runs, decrypts it, and BitLocker is disabled.
Notable Quotes
any code execution within win in the auto unlock state can be utilized to bypass Bit locker and extract all the protected secrets. Alon “alon_leviev” Leviev · ▶ 10:08
Notably, there is no verification linking between the whim being used to the one that was harshed earlier, Netanel Ben Simon · ▶ 12:36
With this iteration logic, the recovery volume is iterated over and checked for a BCD store before the EFI volume. Alon “alon_leviev” Leviev · ▶ 30:05
Key Takeaways
- Four BitLocker bypass techniques all exploit the auto-unlock window inside WinRE before the UI loads.
- Boot.sdi carries no integrity check; an appended malicious WIM executes while the trusted WIM passes validation.
- A single Windows upgrade leaves Setup Platform permanently in WinRE’s trusted-app registry with no cleanup.
- BCD store iteration order lets a recovery-volume fake store redirect WinRE before it reads the real EFI store.
- Enabling TPM plus PIN for pre-boot authentication blocks all WinRE-originating BitLocker bypasses entirely.
About the Speaker(s)
Alon Leviev is a self-taught security researcher on the Microsoft Offensive Research & Security Engineering (MORSE) team. He focuses on low-level vulnerability research covering hardware, firmware, and Windows boot components including secure boot and BitLocker. Before cybersecurity, he competed professionally in Brazilian jiu-jitsu, winning world and European titles.
Netanel Ben-Simon has spent over eight years in security research and is also on the Microsoft MORSE team. He specializes in low-level vulnerability research, fuzzing, and exploitation across Windows, Linux, and embedded devices. His recent work centers on UEFI components and Windows boot security, including bug hunting and mitigation development.