Thought Leadership
The zero-day exploit known as YellowKey bypasses BitLocker protection on Windows 11. Physical access alone is enough to instantly unlock encrypted drives.
The vulnerability known as YellowKey allows anyone with physical access to a Windows 11 system to completely bypass BitLocker’s default protection mechanisms within seconds. Attackers can gain unrestricted access to encrypted drives without possessing the actual recovery key. The exploit was published earlier last week by a security researcher operating under the pseudonym Nightmare-Eclipse and primarily affects default installations that rely solely on the Trusted Platform Module (TPM). Since BitLocker is considered mandatory protection across many enterprises and government agencies, security experts are classifying the threat as critical.
Risk for Organizations and Government Agencies
By releasing YellowKey, researcher Nightmare-Eclipse demonstrated that Windows 11’s default security architecture contains a serious flaw. BitLocker is designed to make drive contents inaccessible to anyone without the correct decryption key. In the standard configuration, this key is securely stored inside a hardware module known as the TPM. The exploit specifically breaks the trust relationship between the operating system and the hardware.
What makes the attack particularly alarming is its reliability. In test environments, researchers repeatedly bypassed the protection mechanism without any knowledge of passwords or recovery codes. Since many organizations working with government agencies are required to use BitLocker, the exploit represents an immediate threat to the confidentiality of both public-sector and corporate data. A lost or stolen laptop running the default configuration currently offers little effective protection against data extraction.
Manipulation Through Transactional NTFS
At the core of the YellowKey exploit is a specially crafted directory called FsTx. This folder is linked to the system file fstx.dll and abuses features of Microsoft’s Transactional NTFS (TxF). The technology was originally designed to allow developers to execute file transactions that either complete entirely or roll back in case of failure. Documentation regarding this specific directory is sparse, but analysis indicates that the exploit interferes deeply with Windows’ file system logic.
The directory is normally managed inside the protected System Volume Information area. YellowKey exploits the way Windows processes and reconciles transaction logs during system startup. By placing a manipulated FsTx directory on an external USB drive, the operating system is tricked into misinterpreting data during the boot sequence in the recovery environment. As a result, security prompts that would normally enforce BitLocker key entry are simply skipped.
No Advanced IT Skills Required
Once the malicious USB medium has been prepared, carrying out the attack requires no advanced technical expertise. An attacker copies the customized FsTx folder onto an NTFS- or FAT-formatted USB drive and connects it to the target device. During the Windows 11 startup process, only a key combination needs to be held down to enter the Windows Recovery Environment (WinRE). In some scenarios, repeatedly forcing the device to shut down during boot can trigger the same behavior.
Under normal circumstances, this environment is tightly secured. The system detects attempts to access the encrypted primary drive and demands the 48-digit BitLocker recovery key. However, YellowKey neutralizes this protection. Instead of the recovery prompt, a command prompt (CMD.EXE) with full administrative privileges appears immediately. At that point, the TPM has already unlocked the drive, allowing attackers to copy, modify, or delete all stored data. Multiple well-known security researchers have independently confirmed the exploit’s functionality.
Zero-Day Exploit YellowKey Puzzles Experts
Will Dormann, a veteran vulnerability analyst, described the exploit as deeply concerning. What puzzles experts is why the mere presence of an FsTx directory on one external volume can influence the contents of an entirely different volume. In the case of YellowKey, the USB drive manipulates the virtual X: drive that hosts the recovery environment.
Specifically, the exploit appears to tamper with the winpeshl.ini file on the X: drive or prevent its execution entirely. This file normally controls which processes are launched when the recovery environment starts. By default, it launches recenv.exe, which handles the BitLocker key prompt. Through manipulation, that process is interrupted, causing the system to fall back to the default command prompt. Because the TPM has already released the decryption key for the primary drive at this stage, the data is exposed in plain text. Experts consider the fact that an external file system log can compromise the integrity of the system drive to be a severe vulnerability in its own right.
Weaknesses in the Default Configuration
The root cause is believed to lie within the FsTxFindSessions() function inside fstx.dll. This function explicitly searches for paths such as System Volume Information\FsTx. It appears that the replay mechanism used by Transactional NTFS is insufficiently isolated when new drives are mounted during boot. The exploit itself contains paths referencing win.ini and winpeshl.ini, indicating deliberate manipulation of the startup sequence.
Security professionals have criticized Microsoft for years for shipping BitLocker in its default configuration without additional authentication. In this TPM-only mode, the hardware module releases the decryption key as soon as the integrity of early boot components has been verified. YellowKey now demonstrates that this integrity verification can be bypassed by manipulating file system transaction logic before the recovery environment’s actual security barrier becomes active. As a result, the TPM’s hardware-based security is effectively circumvented without attacking the hardware itself.
Immediate Measures for System Administrators
Microsoft has confirmed that it is investigating the reports. At the time of writing, no official patch securing the handling of FsTx transaction logs has been released. Until a fix becomes available, experts strongly recommend manually hardening BitLocker configurations across enterprise environments. The most effective defense against YellowKey is enabling a startup PIN.
When a system is configured to require both TPM and a PIN (TPM + PIN), the hardware module only releases the decryption key after the correct PIN has been entered. In that scenario, the exploit encounters only an encrypted drive inside the recovery environment and cannot access the data. Experts also recommend configuring BIOS or UEFI passwords to block booting from external media entirely or at least make hardware settings more difficult to modify. Administrators should immediately review their fleets of mobile devices, as the current default mode does not provide reliable protection against theft or unauthorized data access.
