BitUnlocker: Leveraging Windows Recovery to Extract BitLocker Secrets

Overview: Alon and Netanel from Microsoft's Security Testing and Offensive Research (STORM) team disclose BitUnlocker, a series of novel vulnerabilities in the Windows Recovery Environment (WinRE) that permit local BitLocker encryption bypass and sensitive data extraction. The researchers analyze the delicate trust boundaries governing WinRE, where the operating system volume is automatically decrypted to allow automated self-healing without user intervention. By identifying parsing flaws in unprotected configuration files residing on the unencrypted EFI and recovery partitions, the speakers demonstrate full extraction of BitLocker-protected secrets and discuss the corresponding security updates.

Key Topics: - Windows Recovery Environment (WinRE) automated repair and BitLocker auto-unlock architecture - Attack surfaces in unencrypted partitions: boot.sdi, ReAgent.xml, and Boot Configuration Data (BCD) - Executing unauthorized Windows Imaging Format (WIM) payloads via boot.sdi offset manipulation - Bypassing UI lockouts via scheduled recovery operations and BCD volume enumeration confusion

Technical Details: BitLocker provides full-volume encryption to protect data at rest against device theft. To allow unattended recovery operations without prompting the user for a 48-digit recovery key, Windows implements an auto-unlock state: during startup, the boot manager automatically unlocks the encrypted OS volume for WinRE, provided winre.wim passes hash validation and no risky diagnostic tools are invoked. However, the researchers discovered that during this auto-unlock phase, WinRE parses external configuration files residing on unencrypted, unprotected storage volumes—specifically the Recovery partition and the EFI System Partition (ESP). Because an attacker with physical access can mount and modify these unencrypted partitions, parsing logic within WinRE represents a critical privilege boundary crossing.

The researchers identified three primary attack vectors. First, WinRE boots into a RAM disk via the System Deployment Image (boot.sdi) container format. The SDI header prepends virtual disk structures and defines an offset pointing to the appended winre.wim. Crucially, while the kernel validates the cryptographic hash of winre.wim, the boot.sdi header itself underwent no integrity validation. The authors appended an untrusted, custom WIM containing an administrative command shell to the SDI and altered the internal offset; the hash check passed against the legitimate WIM, but the system executed the attacker's custom WIM in the auto-unlocked state, granting unhindered access to C:\. Second, the authors targeted ReAgent.xml, which directs scheduled recovery tasks executed before WinRE displays interactive UI options. By abusing scheduled operations—such as configuring an offline antimalware scan or designating SetupPlatform.exe as a trusted recovery utility with a crafted SetupPlatform.ini—the authors triggered a blocking UI dialog before the OS volume re-lock occurred, enabling interactive access via Shift+F10 to spawn an administrative shell with the drive still unlocked.

Finally, the authors analyzed Boot Configuration Data (BCD) parsing. WinRE queries the BCD to determine the location of the target OS volume using FindFirstVolume and FindNextVolume. Due to internal filtering inconsistencies, these APIs iterate over the unprotected recovery volume before checking the EFI partition. By planting a rogue BCD store on the recovery volume, the boot manager uses the authentic EFI BCD to auto-unlock the BitLocker volume, while WinRE ingests the rogue BCD, establishing an OS volume confusion primitive that allows attackers to subvert configuration queries.

Key Takeaways: Physical security architectures must not evaluate external, unverified configuration files from unencrypted disk volumes while cryptographic keys are held active in memory. Microsoft addressed these vulnerabilities by enforcing strict signature and integrity validation on boot.sdi, sanitizing ReAgent.xml scheduled recovery execution flows, and restricting BCD store lookups exclusively to authenticated EFI volumes. Enterprise security administrators should consider configuring BitLocker to require a pre-boot PIN or startup key via TPM+PIN protectors, ensuring that drives remain fully encrypted during early boot phases even if recovery environments are manipulated.

(AI summary — Gemini Flash)