A researcher says Microsoft built a secret BitLocker backdoor – what the evidence looks like

BitLocker has long been the default full‑disk encryption solution for Windows enterprises. In mid‑May, a user calling themselves Nightmare‑Eclipse uploaded a GitHub repository named YellowKey that claims to open a command shell on a BitLocker‑protected machine without requiring a recovery key or password. The researcher describes the flaw as “one of the most insane” they have seen and suggests the code path exists only in the official Windows Recovery Environment (WinRE) image, hinting at a purposeful backdoor.

---

How YellowKey is said to work

1. Copy the FsTx folder – The repository contains a directory named FsTx. When copied to a USB drive formatted with NTFS, FAT32, or exFAT, the files can be read by the Windows firmware during boot.
2. Reboot into WinRE – After the USB is attached, the attacker forces the system to boot into the Windows Recovery Environment. The same steps can be performed by placing the folder on the EFI system partition and temporarily disconnecting the encrypted drive.
3. Follow a precise input sequence – According to the posted instructions, a series of key presses triggers a hidden executable that spawns a command prompt with SYSTEM privileges.
4. Gain unrestricted access – From that prompt, the attacker can mount the BitLocker volume, read, copy, or modify any file without ever entering a recovery key.

The researcher claims the exploit works on Windows 11 and Server 2022/2025, but not on Windows 10. The GitHub page includes a short video demonstration and a script that automates the input sequence, but the full source for the privileged escalation component (named GreenPlasma) is withheld pending a future disclosure.

---

Community reaction and supporting evidence

• Independent verification – A handful of security analysts have reproduced the steps on fresh Windows 11 installations and reported the same command prompt appearance. Their write‑ups reference the same FsTx binary that lives inside Winre.wim.
• Microsoft’s WinRE image – The binary in question is present in the official WinRE image shipped with Windows 11. It is not part of the normal boot path, which explains why the behavior is invisible during regular operation.
• Historical context – Nightmare‑Eclipse previously released exploits such as Red Sun that targeted Windows kernel components. Those earlier disclosures were later patched after coordinated disclosure with Microsoft.

These points give the claim a veneer of credibility: the exploit is reproducible, the code lives in a Microsoft‑signed image, and the researcher has a track record of finding deep Windows bugs.

---

Counter‑perspectives

Microsoft’s response

Microsoft has not issued an official statement at the time of writing. In past incidents, the company has typically acknowledged the vulnerability, thanked the researcher for responsible disclosure, and released a patch within weeks. The lack of a direct comment fuels speculation, but it also leaves room for a measured internal investigation.

Technical skepticism

Several experts caution against jumping to the conclusion that the code is a deliberate backdoor:

• Legacy debugging tools – The FsTx component resembles a diagnostic helper used by Microsoft engineers to test BitLocker recovery flows. Such helpers are often left in recovery images for troubleshooting and are disabled under normal boot conditions.
• Accidental exposure – If a diagnostic routine is inadvertently left callable from WinRE, it could be abused without any malicious intent from Microsoft. This pattern has appeared before in other operating systems where debugging hooks were later hardened.
• Limited attack surface – The exploit requires physical access to the machine (or at least the ability to modify the EFI partition). In many enterprise environments, BitLocker is combined with TPM and secure boot, which would block the insertion of unauthorized files on the EFI system partition.

Industry viewpoint

Security professionals often advise a layered approach to data protection. Even if YellowKey works as described, relying solely on BitLocker for high‑value secrets may be insufficient. Alternatives such as VeraCrypt or hardware‑based encryption modules provide additional isolation from software‑level attacks.

---

What this means for users and administrators

• Check for updates – Keep Windows 11 and Server installations fully patched. Microsoft typically releases cumulative updates that address newly discovered WinRE bugs.
• Restrict physical access – Deploy chassis locks, BIOS passwords, and enable Secure Boot to reduce the chance an attacker can insert a malicious USB or edit the EFI partition.
• Audit recovery environments – Use tools like dism to inspect the contents of Winre.wim on critical systems. Removing unnecessary binaries can mitigate the risk without waiting for an official patch.
• Consider complementary encryption – For data that must survive a compromised OS, encrypt at the file level with a solution that stores keys outside the operating system, such as VeraCrypt containers or cloud‑based key management services.

---

Looking ahead

The researcher hinted at a follow‑up exploit (GreenPlasma) that could elevate privileges beyond the WinRE shell. If that code proves functional, the impact could extend to systems where BitLocker is disabled but the WinRE environment remains present. The security community will be watching Microsoft’s Patch Tuesday release closely; a timely fix would likely include hardening of the WinRE image and removal of the FsTx component.

Until then, the episode serves as a reminder that even trusted system utilities can become attack vectors when they are left accessible in recovery contexts. Vigilance, regular patching, and a defense‑in‑depth mindset remain the best safeguards.