Zero-day exploit completely defeats default Windows 11 BitLocker protections

A zero-day exploit circulating online allows people with physical access to a Windows 11 system to bypass default BitLocker protections and gain complete access to an encrypted drive within seconds.

The exploit, named YellowKey, was published earlier this week by a researcher who goes by the alias Nightmare-Eclipse. It reliably bypasses default Windows 11 deployments of BitLocker, the full-volume encryption protection Microsoft provides to make disk contents off-limits to anyone without the decryption key, which is stored in a secured piece of hardware known as a trusted platform module (TPM). BitLocker is a mandatory protection for many organizations, including those that contract with governments.

When one disk volume manipulates another

The core of the YellowKey exploit is a custom-made FsTx folder. Online documentation of this folder is hard to find. As explained later, the directory associated with the file fstx.dll appears to involve what Microsoft calls the transactional NTFS, which allows developers to have “transactional atomicity” for file operations in transactions with a single file, multiple files, or ones that span multiple sources.

The steps for carrying out the bypass are simple:

Copy the custom FsTx folder from the Nightmare-Eclipse exploit page to an NTFS- or FAT-formatted USB drive
Connect the USB drive to the BitLocker-protected device
Boot up the device and immediately press and hold down the [Ctrl] key
Enter Windows recovery

There are at least two ways to accomplish the third step. One way is to boot into Windows, hold down the [Shift] key, click on the power icon, and click restart. Another is to power on the device and restart it as soon as Windows starts booting.

In either case, a command (CMD.EXE) prompt appears. The prompt has full access to the entire drive contents, allowing an attacker to copy, modify, or delete them. In a normal Windows Recovery flow, the attacker would need to enter a BitLocker recovery key. Somehow, the YellowKey exploit bypasses this safeguard. Multiple researchers, including Kevin Beaumont and Will Dormann, have confirmed the exploit works as described here.

It’s unclear what in the custom FsTx folder causes the bypass. Dormann said that it appears to be related to Transactional NTFS, which itself uses command-log file system under the hood. Dormann further noted that by looking at the Windows fstx.dll, one will see code that explicitly looks for \System Volume Information\FsTx in the FsTxFindSessions() function.”

The contents of this FsTx directory used in the YellowKey exploit reveal no strings related to RecoverySimulation.ini. It does, however, show the files and paths \??\C:\Windows\win.ini and
\??\X:\Windows\System32\winpeshl.ini, “where X:\Windows\System32\winpeshl.ini is what controls what WinRE [Windows Recovery] does when it fires up.”

Dormann, who is a senior principal vulnerability analyst at Tharros Labs, continued:

But what’s intriguing to me is: Why can the presence a \System Volume Information\FsTx directory on one volume affect the contents of ANOTHER VOLUME when it’s replayed? 🤔

In a normal WinRE session, you have a X:\Windows\System32 directory that has a winpeshl.ini file in it:

[LaunchApp]
AppPath=X:\sources\recovery\recenv.exe

However, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the winpeshl.ini file on ANOTHER DRIVE (X:). And we get a cmd.exe prompt, with bitlocker unlocked instead of the expected Windows Recovery environment. While the TPM-only Bitlocker bypass is indeed interesting, I think the buried lede here is that a \System Volume Information\FsTx directory on one volume has the ability to modify the contents of another volume when it is replayed. To me, this in and of itself sounds like a vulnerability.

A Microsoft representative declined to answer questions sent by email about the reported vulnerability other than to say the company is investigating.

People should know that at the moment, BitLocker on Windows 11 isn’t providing the protection it’s supposed to. That means stolen or lost devices can still be accessed even when BitLocker is enabled.

This bypass works only in the Windows 11 default mode of BitLocker, which stores decryption keys in the TPM. This TPM-only configuration has long been considered insufficient by many security professionals, who instead advise that a PIN should be required before the key can be retrieved from the TPM. Beaumont advised people to enable a BIOS password lock to prevent YellowKey attacks. While using BIOS password locks is a good practice, it’s unclear how they provide any protection against this particular exploit.