The YellowKey and GreenPlasma Zero-Days: Rethinking Windows Security and BitLocker Encryption
*I know the adage is Blue & Green. but it didn’t fit the title!
On the 12th of May, the cybersecurity landscape experienced a seismic shift with the publication of two unpatched zero-day vulnerabilities targeting native Windows components.
These vulnerabilities, named YellowKey and GreenPlasma, challenge the fundamental assumptions many organisations make about full-disk encryption and the security of trusted operating system features.
The two zero-days were released strategically right after Microsoft’s May Patch Tuesday, and leave organisations without an official fix until at least the next patch cycle, compressing the timeline for defenders to react.
Who is Nightmare-Eclipse?
The person behind these zero-day disclosures operates under the aliases Nightmare-Eclipse on GitHub, and Chaotic Eclipse or Dead Eclipse on various other platforms. Every blog post published by this person is PGP-signed, ensuring each release is mathematically tied to a unique private key so the public can verify the content’s authenticity and unmodified state.
It appears that their campaign began in early 2026, reportedly stemming from a violated disclosure agreement that left them with nothing. There are even unverified rumours circulating online (reported by The Register), suggesting Nightmare-Eclipse is a former Microsoft employee.
This researcher/threat actor has a proven track record of delivering working, high-impact exploits however – In early April 2026, they published BlueHammer, a zero-day exploiting a race condition in Windows Defender’s threat remediation engine, which was actively exploited by real attackers just days after its release.
This was quickly followed by RedSun and UnDefend on April 15th and 16th, which both saw immediate active exploitation. Nightmare-Eclipse has promised yet another “big surprise” for the June 2026 Patch Tuesday, and to date, every promise made by them has been delivered.
So what is YellowKey?
Deep Dive into YellowKey: Bypassing BitLocker
BitLocker is Microsoft’s native full-volume disk encryption feature. Its core premise is that if a device is lost or stolen, the encrypted drive remains completely unreadable to unauthorised users.
On most Windows 11 machines, BitLocker operates in TPM-only mode by default, meaning a chip soldered to the motherboard (the Trusted Platform Module, or TPM) automatically hands over the decryption key during boot, unlocking the drive without requiring a users password.
YellowKey completely shatters this security control for attackers with brief, physical access to a machine.
With just a few minutes of unsupervised physical access and a standard USB stick, an attacker can completely bypass BitLocker encryption on Windows 11, Windows Server 2022, and Windows Server 2025. Windows 10 devices are not affected.
The attack exploits the Windows Recovery Environment (WinRE), a lightweight, stripped-down repair environment designed to diagnose and fix system failures. Because WinRE needs to repair the disk, the TPM cooperates and automatically hands over the decryption key during recovery boots.
Normally, a configuration file called winpeshl.ini instructs WinRE to launch the standard blue-screen recovery interface, however, If this file is deleted, WinRE falls back to a plain command prompt with unrestricted access to the already-unlocked BitLocker volume. Nice!
The Mechanics of the Exploit
YellowKey successfully deletes winpeshl.ini by abusing a legacy Windows feature introduced in 2007 called Transactional NTFS (TxF).
Although Microsoft marked TxF as deprecated years ago, it was never fully removed from the Windows operating system. Inside the WinRE environment, there is a binary called autofstx.exe that processes TxF log files stored in a folder named FsTx.
The critical flaw is that autofstx.exe does not restrict its operations to the drive where the logs originated; it applies those log transactions across other connected volumes.
So, all an attacker needs to do is simply format a USB drive with NTFS, FAT32, or exFAT containing the FsTx folder at a specific path, plug it into the target machine, and boot into the recovery environment.
By holding the Shift key to restart and then holding the CTRL key, the system drops the attacker into a command prompt with full access to the unencrypted data.
A variant of this attack requires no USB stick at all, allowing an attacker to copy the FsTx folder directly into the hidden EFI partition of the boot drive.
Deliberate weakness?
Security researcher Will Dormann independently reproduced the exploit, pointing out that this cross-volume modification behaviour is a massive, independent security flaw on its own. Furthermore, the autofstx.exe binary in regular Windows installations and Windows 10 recovery environments does not exhibit this behaviour. It only behaves this way inside the WinRE images for Windows 11 and the newer Server editions, leading Nightmare-Eclipse and other independent researchers, like Kevin Beaumont, to claim this looks like a deliberate backdoor.
GreenPlasma: From compromise to PrivEsc.
Disclosed alongside YellowKey, GreenPlasma is a local privilege escalation flaw that targets CTFMON (ctfmon.exe), a trusted native Windows component responsible for handling text input. CTFMON runs with full SYSTEM privileges in every interactive session.
GreenPlasma manipulates object manager permissions and registry settings to plant an arbitrary memory section object inside a directory that is normally only writable by the SYSTEM. It then tricks the trusted CTFMON process into interacting with this object. Because the process is natively trusted by Windows, this interaction successfully provides a pathway for an unprivileged user account to achieve full SYSTEM-level execution.
While Nightmare-Eclipse published GreenPlasma as a “challenge” with an intentionally incomplete proof-of-concept that still triggers a User Account Control (UAC) prompt, it remains highly dangerous. When combined, YellowKey and GreenPlasma form a devastating attack chain: YellowKey unlocks the encrypted physical drive, and GreenPlasma elevates the attacker to complete SYSTEM-level privileges.
The Real-World Threat to Businesses
The discovery of YellowKey (and GreenPlasma) drastically shifts the threat model for modern businesses, particularly Small and Medium-sized Businesses (SMBs). Traditionally, IT departments assumed that a lost, stolen, or temporarily unattended laptop was secure simply because BitLocker was enabled. YellowKey proves that the “encrypted-disk-equals-safe” assumption is demonstrably wrong for the default Windows 11 configuration.
The risk is not one which can be conducted remotely though – it requires an attacker to be physically at the device. However, laptops left in hotel rooms, Gym lockers, undergoing border-security inspections, or intercepted during courier shipments are all highly vulnerable.
Add to this the fact that the exploit relies on exploiting the recovery environment before the main operating system even loads, traditional Endpoint Detection and Response (EDR) tools are completely blind and cannot mitigate the threat.
YellowKey is not alone
It does look like YellowKey is not an isolated incident. The French security firm Intrinsec recently published a completely separate attack called BitUnlocker (utilizing CVE-2025-48804). This separate attack reaches the decrypted drive in under five minutes by exploiting an old PCA 2011 boot manager signing certificate that Microsoft failed to mass-revoke due to fears of breaking the Windows ecosystem.
With two separate, highly effective BitLocker bypasses publicly available, physical device security has never been more critical.
Defence and Mitigation Strategies
There is currently no CVE or official patch from Microsoft, so organisations must rely on aggressive hardening and physical security measures.
- Pre-Boot Authentication (TPM+PIN): The most immediate digital mitigation is moving away from TPM-only mode. Adding a BitLocker PIN requires a user to enter a secret before the OS loads, preventing the TPM from automatically releasing the decryption key to the recovery environment. However, this is not a guaranteed fix. Nightmare-Eclipse has publicly claimed that a withheld variant of the exploit successfully bypasses TPM+PIN configurations as well. Until Microsoft patches the underlying flaw, TPM+PIN should be viewed as a strong hurdle rather than total immunity.
- Firmware Controls: Organizations should configure BIOS/UEFI settings to require an administrator password and completely disable booting from external USB devices. This neutralizes the most straightforward delivery method of the YellowKey payload.
- Disabling WinRE: The attack relies heavily on the Windows Recovery Environment. On endpoints where recovery is managed centrally via Mobile Device Management (MDM) or Intune, administrators can completely disable WinRE (using the
reagentc /disablecommand). However, defenders must remain vigilant; updates to Windows may push new WinRE images containing the vulnerableautofstx.exebinary, potentially re-enabling the environment. - Physical Security: Ultimately, the only guaranteed protection against every known variant of YellowKey—including the EFI partition method—is preventing physical access to the device. Clean desk policies, server room locks, and strict control of field devices are essential.
- Application Allowlisting and Ringfencing: To combat the GreenPlasma privilege escalation, security teams should implement Application Allowlisting to ensure unauthorized binaries cannot execute in the first place. Additionally, Ringfencing can restrict what trusted processes like
ctfmon.exeare allowed to interact with, reducing the attack surface for manipulation.
Final thoughts
YellowKey and GreenPlasma expose a dangerous paradigm in modern cybersecurity: the inherent trust placed in native operating system components.
Tools like WinRE and CTFMON were built for system repair and text input, not to act as security boundaries. Yet, attackers increasingly abuse these signed, trusted binaries – often referred to as “Living off the Land” (LOLBas) attacks – because security tools frequently exempt them from heavy scrutiny.
Security teams must stop treating native components as inherently safe and move toward models that strictly define what any component, trusted or not, is permitted to do.
As threat actors strategically time their zero-day releases to exploit the gaps between Patch Tuesdays, relying solely on reactive patching and signature-based detection is no longer sufficient to protect sensitive data.
