BitLocker Attacks

A list of public attacks on BitLocker. Any public attack with the potential to attack BitLocker but where the exact method is still not public (like baton drop) is out of scope.

Most of the attacks are for where the VMK is sealed by TPM only, which is the default setting, and is what automatic BitLocker uses alongside recovery key escrow to a Microsoft account.

By default, starting from Windows 8, Secure Boot integrity validation is used if Secure Boot is enabled.

If you must seal the VMK by TPM only, the most secure configuration for this is to use legacy integrity validation with PCRs 0, 2, 4, 7, 11 (and also to keep your system fully updated).
Please note that this will only protect against software attacks.

Contents

• Hardware attacks
• Software attacks

Hardware attacks

Hardware attacks are typically only useful for when the attacker has physical access to a system where the VMK is sealed by TPM only.

Software attacks

Software attacks are typically vulnerabilities in bootmgr, or some other boot application where exploitation is possible with derived BitLocker keys in memory for an arbitrary volume.
Where code execution can be obtained inside a boot application, it may be possible for an "evil cleaner" attacker to install a bootkit which itself will run with derived keys in memory (or when keys can still be derived), and thus compromise a system where a password or startup key is used instead of or in addition to a TPM.

dangerous association

A vulnerable system will have the May 2022 or June 2022 updates installed, but not any later updates.

The associated options GUID is part of the hashed data, so the used device element must be marked as not verified.
There are no elements that can be used on Windows 7 and below (although when custom non-default settings are used, it could still be possible).
On Windows 8 and above, osloader!osdevice is not verified by default, and as such can be used.
The easiest way to exploit this is to use the BCD raw device editor, bcdeditmod (still not publicly released yet, it will happen eventually), although editing the BCD registry hive manually is also possible (figure it out yourself).

Exploitation involves:

• take the BCD from your target device, create two device elements
• copy the osdevice from {default} to the first one
• set the associated options GUID in {default}!osdevice to the first device element
• set the associated options GUID in {first}!osdevice to the second device element
• set whatever "dangerous" options (like debug) in the second device element
• boot the target device using that BCD and the same bootmgfw binary it was using

bitpixie

This vulnerability existed for over 17 years, the earliest known build it was introduced in being 6.0.5231.2 (winmain_idx03.051004-2120) from October 2005.
Where Secure Boot integrity validation is used, a downgrade attack would still work to exploit this vulnerability.

Set up a PXE boot server with a vulnerable bootmgfw.efi (where legacy integrity validation is used, this must be the bootmgfw.efi from the target device) renamed correctly for EFI booting.

For the BCD, set up one default entry where device is the BitLocker encrypted osdevice; path is "\"; and a recovery sequence.

The recovery sequence should point to a single startup entry, where device is boot, path points to an EFI application to run (from the PXE server); and pxesoftreboot is enabled.

When Secure Boot is disabled, that EFI application can just be an application to scan physical memory looking for a BitLocker keytable to dump.

When Secure Boot is enabled, that EFI application can use a known Secure Boot bypass (where physical access is required if needed).
For exploiting a Windows boot application in this way, you will need to replace the BCD with your second one on the PXE server.
This means pressing an arrow key during bootmgr startup to force the boot menu to show; and then replacing the BCD on the PXE server at that point.

push button decrypt

Exploitation involves:

• Dump the bitlocker protected osvolume to a disk image. This method to get the FVEK leads to actual data loss!
• Boot to WinRE using whatever means (force it by startup repair if needed, or just set bootsequence BCD element, etc).
• Start a reset (Troubleshoot -> Reset this PC -> Remove everything). It's quicker to choose "Local reinstall". Be sure to choose "Just remove my files".
  • Choosing to "keep files" will ask for recovery key.
  • If the system's WinRE is not vulnerable, it will also ask for a recovery key.
• When the reset gets to ~98%, shut the system down forcefully (via holding power button down 7 seconds / etc).
• Power the system back on, it should boot to WinRE again and show an error. Dismissing the error should reboot.
• When you see the blue "updating" screen, press Shift+F10 to get to a shell.
• Execute manage-bde -pause C: followed by manage-bde -protectors -delete C:
• Shut the system down forcefully (again).

At this point, the on-disk BitLocker metadata will contain a plaintext VMK.
Dump it, and use that VMK to decrypt the FVEK.
The decrypted FVEK can be used on the disk image made previously to decrypt the partition.

Please note: I only successfully exploited this issue on Windows 10 in very specific circumstances (TPM-only BitLocker with no recovery key). However, others have successfully exploited this issue using a vulnerable WinRE on Windows 11 (Nickel).