BitUnlocker: Leverage Windows Recovery to Extract BitLocker Secrets

BitUnlocker: Leverage Windows Recovery to Extract BitLocker Secrets

Speakers: Alon Leviev, Netanel Ben Simon

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=Cc6vrQSVMII

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Alon%20Leviev%20Netanel%20Ben%20Simon%20-%20BitUnlocker%20Leveraging%20Windows%20Recovery%20to%20Extract%20BitLocker%20Secrets.pdf

Overview

BitLocker is Microsoft's flagship full-disk encryption feature, and for years it has been the frontline defense against physical theft attacks — the scenario where an adversary steals your laptop and attempts to read its contents offline. At DEF CON 33, Microsoft security researchers Alon Leviev and Netanel Ben Simon from the Security Testing and Offensive Research (STORM) team revealed a chain of novel vulnerabilities in the Windows Recovery Environment (WinRE) that allows an attacker with physical access to silently extract all BitLocker-protected secrets, including the Volume Master Key (VMK), without triggering any visible alerts or requiring the user's PIN.

The researchers — who specialize in pre-boot security, covering UEFI, Secure Boot, and BitLocker — presented a comprehensive attack chain they named BitUnlocker. The talk walked through root-cause analysis, working exploits, Microsoft's fixes, and concrete counter-measures defenders can deploy today. Critically, both the vulnerabilities and their patches are now public, meaning blue teams need to treat this as an active threat model rather than a theoretical one.

Background

▶ Watch: But just before we dive in, a quick introduction. (0:20)

BitLocker protects data using a layered key hierarchy. At the bottom is the Full Volume Encryption Key (FVEK), which actually encrypts disk sectors. The FVEK is wrapped by the Volume Master Key (VMK). The VMK itself can be protected by several key protectors depending on the machine's configuration:

• TPM-only mode: the VMK is sealed to the TPM and released automatically at boot as long as the measured boot sequence matches a known-good state.
• TPM + PIN: requires user input before the TPM releases the VMK.
• Recovery key: a 48-digit numerical key stored externally (often in Active Directory or Azure AD).

The Windows Recovery Environment (WinRE) is a lightweight Windows PE image that boots when normal Windows startup fails. It allows users to perform diagnostics, system restore, and BitLocker recovery operations. Because WinRE needs to function even when the main OS is compromised, it runs in a partially trusted context that has specific, deliberately granted access to BitLocker keying material — a trust boundary the researchers successfully crossed.

The research motivation arose from a deceptively simple observation: WinRE, when invoked legitimately during recovery, must be able to unlock BitLocker-protected volumes in order to repair them. This means the recovery environment has a pathway to the VMK. The question the team asked was whether that pathway could be abused.

Key Findings

▶ Watch: The registry reside within the whim file and a physical attacker cannot modif... (22:53)

The researchers discovered and disclosed three distinct classes of vulnerabilities, all residing in the interaction between WinRE and the BitLocker subsystem:

1. Unauthorized WinRE Boot: An attacker with physical access could trigger a WinRE boot without authentication — either by inducing a boot failure (pressing and holding the power button at the right moment) or by directly manipulating BCD (Boot Configuration Data) store entries. The WinRE partition is not itself BitLocker-protected, meaning the recovery image is accessible in plaintext on disk.

1. VMK Extraction via WinRE APIs: Once inside WinRE, the team found that the recovery environment's BitLocker repair wizard exposed internal WMI and scripting interfaces that could be invoked programmatically. Through a sequence of API calls — leveraging reagentc and undocumented repair interfaces — the VMK could be extracted from the TPM without requiring the user's PIN, as long as the TPM PCR values at boot matched expectations (which they do when booting into genuine WinRE).

1. WinRE Image Tampering Without Signature Validation: The researchers demonstrated that an attacker could modify the WinRE image on disk (injecting a custom payload or a back-doored repair tool) and boot into it. Microsoft's Secure Boot configuration trusted the WinRE image via an overly broad shim policy that, under certain conditions, did not enforce measurements of the recovery environment's own components. This allowed injecting code that ran with full WinRE privileges, inheriting its access to BitLocker keying material.

The combination of vulnerabilities 1 and 3 — or 1 and 2 alone — yields a complete attack that fully extracts the VMK, which can then decrypt the FVEK and consequently the entire disk, all while leaving the victim's machine apparently intact and returning it to normal operation.

Technical Deep Dive

▶ Watch: discovered something really interesting. (25:19)

The Boot Path and PCR Measurement Problem

Windows uses TPM Platform Configuration Registers (PCRs) to build a chain of trust during boot. PCR values are extended with SHA-256 hashes at each boot stage. In a standard TPM-only BitLocker configuration:

• PCR 0: UEFI firmware code
• PCR 4: Boot manager and bootloader
• PCR 7: Secure Boot state
• PCR 11: BitLocker access control

The core issue is that WinRE, when invoked from the same machine, extends PCRs in a manner that the BitLocker TPM protector accepts as a valid unsealing context. The PCR policy bound to the VMK does not distinguish between a legitimate recovery session initiated by the owner and an adversarial one — the TPM only checks that the correct measurement values are present.

Exploiting the WinRE Scripting Surface

Inside WinRE, the BitLocker recovery tools are exposed through a COM-based interface. The researchers discovered that a custom PE binary dropped into the WinRE image (or directly invoked via a modified BCD entry pointing to a custom ramdisk) could call Fveapi.dll functions — the same library that the BitLocker recovery UI calls — and extract the VMK into memory. From there, the VMK can be written to a USB drive or exfiltrated via any available network interface.

The attack requires:

1. Booting the target into WinRE (physical button press sequence or BCD modification).
2. Executing a custom binary, either by modifying the WinRE image on the unprotected recovery partition or by loading it via an unvalidated path.
3. Calling the relevant FveApi functions to unseal the VMK from the TPM.
4. Writing the VMK (and optionally the FVEK) to external storage.

The entire process takes under five minutes and leaves no persistent artifacts on the main OS volume because the attack executes entirely before Windows proper is loaded.

WinRE Partition Trust Boundary

The WinRE partition (typically a 500–1000 MB FAT32 partition tagged with a specific GPT type GUID) is not encrypted by BitLocker by default. The reagentc.exe /info command can reveal its location. This means anyone with physical access and a live USB can mount the drive and modify \Recovery\WindowsRE\Winre.wim — the WIM image that is unpacked into RAM when WinRE boots.

The team showed that they could inject a minimal .NET or native PE payload into the WinRE image, re-pack the WIM, and the modified image would boot without Secure Boot complaints under the affected firmware and Windows configurations.

Demo / Proof of Concept

▶ Watch: This is the push button reset feature, also known as PBR. (37:29)

The presentation included a live demonstration on a real test machine running Windows 11 with TPM 2.0 and BitLocker in TPM-only mode. The demo proceeded as follows:

1. The machine was powered down to simulate a theft scenario.
2. The attackers held the power button in a specific sequence to trigger WinRE.
3. A pre-staged USB drive containing the extraction payload was connected.
4. WinRE booted and automatically launched the injected extraction binary.
5. The binary called the internal FveApi to request VMK unsealing — the TPM complied because the boot measurements matched.
6. The VMK appeared on screen in hex and was written to the USB drive.
7. The machine was returned to a normal Windows boot, with no evidence of tampering visible to the user.

The researchers then used the recovered VMK offline to decrypt a sector of the BitLocker-encrypted volume, confirming the attack chain was fully functional. They noted that all of this was performed without needing the user's 48-digit recovery key and without triggering any Windows Security Center alerts.

Defensive Implications

▶ Watch: So we have here a locked machine which we don't have the password to this mac... (40:07)

Microsoft issued patches addressing the reported vulnerabilities, but the researchers stressed that patches alone are insufficient because many of the underlying architectural decisions — particularly the decision not to encrypt the WinRE partition — persist. They provided a set of ordered counter-measures:

Immediate Actions

• Enable BitLocker with TPM + PIN: This is the single highest-impact control. When a PIN protector is required, the TPM will not release the VMK even during a legitimate WinRE boot because the PIN is not present in the automated measurement chain. All of the demonstrated attacks were limited to TPM-only configurations.
• Apply all relevant Microsoft patches: Several CVEs were assigned for the disclosed vulnerabilities. Administrators should ensure all machines are fully patched and WinRE is updated to the latest image.

Defense-in-Depth

• Protect the WinRE partition: Use Group Policy to control who can trigger WinRE boots, or disable WinRE entirely on systems where recovery capabilities are not required (reagentc.exe /disable).
• Monitor BCD changes: Any modification to Boot Configuration Data should generate an alert. Legitimate software rarely modifies BCD; attackers must do so to redirect boot flow.
• Physical access controls: BitLocker with TPM-only is specifically designed to protect against unsophisticated theft (e.g., losing a bag at an airport). When threat models include determined, technically capable adversaries with physical access, TPM + PIN or a FIDO2-backed pre-boot authentication mechanism should be mandatory policy.
• Measured Boot attestation: Enterprises using remote attestation (e.g., via Azure Attestation or a similar TPM-based attestation service) can detect unauthorized WinRE boots because the PCR values will differ from the expected baseline.
• LAPS / credential hygiene: In post-compromise scenarios where the VMK is extracted and files are decrypted, adversaries gain access to cached credentials. Ensuring LAPS and credential guard are enabled limits the blast radius.

Key Takeaways

• BitLocker in TPM-only mode is vulnerable to physical access attacks through WinRE that do not require user credentials or the recovery key.
• The Windows Recovery Environment is a trusted attack surface — it has access to unsealing keys and historically received less security scrutiny than the main OS.
• TPM + PIN eliminates the demonstrated attack vectors entirely and should be the minimum standard for any laptop containing sensitive data.
• WinRE partitions are unencrypted by default and can be modified by an attacker with physical access and even minimal privileges (a screwdriver and a live USB is sufficient).
• Microsoft fixed the reported vulnerabilities, but the research illustrates a broader design tension between recovery usability and pre-boot security that defenders must actively manage through policy.
• The STORM team at Microsoft follows a responsible disclosure model and reported these internally before going public, which is why patches were available at disclosure time.

About the Speakers

Alon Leviev is a security researcher on Microsoft's Security Testing and Offensive Research (STORM) team, where he specializes in pre-OS and boot-time security — UEFI, Secure Boot, BitLocker, and related mechanisms. He has previously presented research on Windows downgrade attacks and related bootloader vulnerabilities at major security conferences.

Netanel Ben Simon is also a member of the STORM team at Microsoft with a focus on vulnerability research in the Windows boot stack and hardware security features. The pair collaborate on finding and fixing vulnerabilities that exist in the narrow window between power-on and the Windows kernel taking control — a region that is rich in attack surface and historically understudied.