YellowKey and GreenPlasma: How a Grudge Against Microsoft Broke BitLocker and Gave Attackers SYSTEM

"You defame me in public with your CVE-2026–45585 advisory even though you literally deleted the Microsoft account I used to report bugs to you with and I got zero pennies from doing so and I still happily did like an idiot." — Nightmare-Eclipse, May 2026

If you've been following the Nightmare-Eclipse saga, you already know the broad outline: a researcher with deep Windows internals knowledge, a personal grievance against Microsoft, and a pattern of dropping zero-day exploits the day after Patch Tuesday. I wrote about GreatXML — the BitLocker bypass through WinRE and unattend.xml — in an earlier piece. But that story started much earlier, and two of the most technically significant chapters in it are YellowKey and GreenPlasma: a BitLocker bypass and a privilege escalation vulnerability that, when chained together, turn a USB drive and sixty seconds of physical access into complete system compromise on a fully encrypted, fully patched Windows 11 machine.

Both were finally patched in the June 2026 Patch Tuesday, the largest single Patch Tuesday in Microsoft's history. This article is the full technical breakdown of what these two exploits actually do, how they chain together, and why the architectural problem behind them didn't disappear when the patches landed.

The Researcher Behind the Code

To understand the significance of YellowKey and GreenPlasma, you need context on how they fit into a larger, deliberate campaign.

Nightmare-Eclipse (also tracked as Chaotic Eclipse and Dead Eclipse) is an anonymous researcher who began releasing Windows zero-day exploit code in April 2026. According to investigative reporting from Brian Krebs and The Register, the individual is likely a former Microsoft security employee, someone who worked at the company from late 2022 until mid-2025. That background explains what quickly became obvious from the technical quality of each release: this is not someone learning Windows internals from the outside. Every disclosed vulnerability targets components that most external researchers would never think to probe.

The researcher's stated grievances are specific. Microsoft allegedly deleted the MSRC portal account they used to submit bug reports, cutting off access to their own vulnerability submissions. They received no bug bounty payments. When they attempted to communicate directly, they were, according to their own public statements, refused, humiliated, and ignored. Whether every element of this account is accurate is difficult to verify. What is verifiable is the output: seven Windows zero-day vulnerabilities disclosed publicly over roughly ten weeks, three of which were weaponized in real-world attacks before patches existed.

The release sequence was methodical. BlueHammer came first in April 2026, a Defender race condition that was eventually patched after active exploitation began. RedSun and UnDefend followed — one abusing Defender's cloud file rollback mechanism to overwrite a system binary, the other silently degrading Defender's detection capabilities while leaving the endpoint appearing healthy to management consoles. CISA added both to the Known Exploited Vulnerabilities catalog in May 2026. Then, on May 13, 2026 — one day after Microsoft's May Patch Tuesday — came YellowKey and GreenPlasma simultaneously. MiniPlasma, targeting a Cloud Files kernel driver vulnerability originally patched in 2020, arrived a few days later.

Microsoft's response was counterproductive. Rather than prioritizing patches and investigating the underlying disclosure dispute, the company published a statement through its Digital Crimes Unit that was widely read as a threat of criminal prosecution. The security community reacted immediately. Katie Moussouris, who pioneered Microsoft's own bug bounty program, warned of a chilling effect on future research disclosures. Kevin Beaumont, a former Microsoft security engineer, called it a dumpster fire of the company's own making. Microsoft later softened its position, clarifying it had no intention to pursue action against security researchers. By that point, GitHub had banned Nightmare-Eclipse's account on May 23, followed by GitLab on May 26. The researcher migrated to alternative infrastructure and kept publishing.

YellowKey: Breaking BitLocker Through the Recovery Environment

The Root Problem

BitLocker encrypts your drive and ties the decryption key to the TPM chip, bound to your machine's boot state. The idea is that if someone steals your laptop and pulls the drive, they get encrypted data with no path to decryption. What BitLocker's threat model explicitly accepts is that the Windows Recovery Environment must be able to access the drive. It has to — if your system needs repair, recovery tools need to read and write the volume. So BitLocker in TPM-only mode automatically releases the volume master key when the machine boots into WinRE. The drive unlocks before any user authentication happens.

This is expected and documented behavior. YellowKey exploits a component within WinRE that processes external storage in that already-unlocked context.

The Vulnerable Component: autofstx.exe

Inside the WinRE image there is a binary called autofstx.exe, known as the FsTx Auto Recovery Utility. It is registered in the WinRE system registry under Session Manager\BootExecute, which means it runs automatically and very early during every WinRE boot, before most security controls are initialized. Its purpose is legitimate: to detect and replay any incomplete Transactional NTFS (TxF) log files from the previous boot. TxF is Windows' mechanism for making filesystem operations atomic — if a write was interrupted by a power failure, autofstx.exe can replay the transaction log to bring the filesystem to a consistent state.

The flaw is not in what autofstx.exe does. It's in what it considers a valid source for those transaction logs.

The binary scans for a directory called FsTx under \System Volume Information\ across all attached storage volumes — including external USB drives. If it finds TxF log files in that directory on any attached volume, it replays them, in the privileged early-boot context, cross-volume. The logs from a USB drive the attacker controls can affect files on the encrypted internal drive.

How the Attack Unfolds

The attacker creates the directory structure \System Volume Information\FsTx\ on a USB drive and populates it with specially crafted TxF transaction log files. These logs, when replayed by autofstx.exe, instruct the transaction mechanism to delete winpeshl.ini from the WinRE volume on the encrypted internal drive.

That file matters. winpeshl.ini tells WinRE what shell or recovery process to launch at startup. When it's present, WinRE loads the configured recovery interface. When it's absent, WinRE has no configured startup process and falls back to a default: cmd.exe, running at SYSTEM privilege.

The attack sequence then becomes:

The attacker inserts the prepared USB drive and reboots the target machine into WinRE. This can be done by holding Shift while clicking Restart and navigating through the Advanced Options menu — a sequence that takes under ten seconds on a standard machine. Once WinRE begins its boot process, the attacker holds the CTRL key. This activates a conditional branch in the WinRE version of the FsTx component — a HID interrupt check that the standard Windows OS version of the same binary does not have — that causes the component to process external TxF logs rather than proceeding with the normal automated recovery.

autofstx.exe processes the attacker's crafted logs from the USB. The transaction replay deletes winpeshl.ini from the WinRE volume. WinRE, finding no startup configuration, falls back to cmd.exe. Because the machine uses TPM-only BitLocker, the volume master key was already released when the boot began. The drive is fully unlocked. The attacker now has a SYSTEM-level command prompt with unrestricted access to every file on the encrypted drive.

No credentials. No recovery key. No specialized hardware beyond the USB drive. Independent researcher Will Dormann verified the exploit shortly after its release and noted the cross-volume file manipulation appeared to be a separate vulnerability of its own.

The entire physical-access phase, from inserting the USB to having an active SYSTEM shell, takes under two minutes on a physical machine.

Why Windows 10 Is Not Affected

The vulnerable version of autofstx.exe appears to have been introduced or significantly changed in Windows 11. Windows 10 uses a different WinRE configuration that does not exhibit the same cross-volume TxF replay behavior. The affected systems are Windows 11 versions 24H2, 25H2, and 26H1 on x64 systems, along with Windows Server 2025 and Windows Server 2025 Server Core. Windows Server 2022 may also be exposed under specific WinRE deployment conditions, though Microsoft's initial advisory did not formally address it.

The Windows 11 exposure is particularly significant because Windows 11 enables BitLocker with TPM-only mode by default on compatible hardware. Microsoft made this change to improve user experience — no startup PIN required. YellowKey turns that usability decision into an attack surface.

The CVSS Score Conversation

YellowKey carries a CVSS base score of 6.8 — considerably lower than the scores assigned to remote exploitation vectors. Microsoft rated exploitation as "Exploitation More Likely" despite the score, which reflects the reality that a public working proof-of-concept was available from day one. The score is technically correct: physical access is required, there is no remote vector, and the CVSS physical-access modifier pulls the score down. But CVSS was not designed to capture what matters in physical-access scenarios: a laptop left on a conference room table, a device seized at a border crossing, a machine in an unattended office. For those threat models, a physical-access requirement is not a meaningful barrier.

The researcher noted publicly that a technique exists to bypass TPM+PIN configurations as well but chose not to release that PoC, citing personal reliance on BitLocker. That claim has not been independently verified.

GreenPlasma: From Foothold to SYSTEM Through ctfmon.exe

Why ctfmon.exe Runs as SYSTEM

ctfmon.exe is the Windows Collaborative Translation Framework monitor — a process responsible for managing text input services in interactive sessions. It handles IMEs (input method editors), speech recognition, on-screen keyboards, and accessibility input services. It runs as SYSTEM in every active desktop session, automatically restarted by a watchdog service called MsCtfMonitor if it's terminated.

The fact that a text input manager runs as SYSTEM in every session is not a design accident — text services need elevated access to inject keystrokes and assist input across all application contexts. But that privilege level is exactly what makes ctfmon.exe an attractive target.

GreenPlasma's core insight, building on James Forshaw's 2019 Google Project Zero research into the CTF protocol, is that the Windows Object Manager namespace contains structures tied to ctfmon.exe that can be influenced by unprivileged users under the right conditions.

The Object Manager Attack Surface

The Windows Object Manager is the kernel-mode component responsible for tracking and managing all system resources — files, registry keys, sections, events, and more — as named objects in a hierarchical namespace. Most directories in that namespace are only writable by SYSTEM. Section objects are kernel-level structures representing contiguous blocks of shared memory. When a privileged service creates a section object and maps it, it does so under the assumption that the namespace location where it placed that object is protected.

GreenPlasma breaks that assumption.

The exploit chain works in several stages. The attacker, operating as an unprivileged standard user, first manipulates the registry using SetPolicyVal() to set DisableLockWorkstation=1 among other values. It then abuses the CloudFiles policy registry structure to create a registry link redirect — the registry key the exploit needs to manipulate points somewhere it controls. With these in place, the attacker plants a symbolic link in the Object Manager namespace at the path \Sessions\<id>\BaseNamedObjects\CTF.AsmListCache.FMPWinlogon<id>, pointing it to \BaseNamedObjects\CTFMON_DEAD — a location the attacker can influence.

The timing matters. This symbolic link must be in place just before a Winlogon desktop switch occurs — the transition between the secure desktop and the user's interactive desktop. During that switch, ctfmon.exe initializes its session objects and attempts to access the CTF.AsmListCache structure in the namespace. It finds the attacker's planted symbolic link and follows it to the attacker-controlled section. Because ctfmon.exe is trusted and runs as SYSTEM, it interacts with the attacker's section as though it were a legitimate system object.

This interaction is the bridge. Once SYSTEM-level code is touching attacker-controlled memory, the path to privilege escalation is open.

The released proof-of-concept is deliberately incomplete. Nightmare-Eclipse stripped the final stage — the actual shell spawning — and presented the remainder as a CTF challenge, publicly stating that the exploit was a "huge challenge for CTF lovers." Under default configurations, the current public PoC still triggers a UAC consent prompt rather than silently elevating. What the PoC does demonstrate is the core primitive: the section object interception, the timing, and the manipulation of ctfmon.exe. A researcher with moderate Windows internals knowledge can complete the chain from there.

GreenPlasma affects a broader range of systems than YellowKey — Windows 10, Windows 11, and Windows Server with active interactive sessions where ctfmon.exe is running.

Chaining the Exploits: A Complete Attack Scenario

When YellowKey and GreenPlasma are considered together with the earlier Nightmare-Eclipse disclosures, they form a coherent attack chain against a fully encrypted, fully patched Windows 11 target.

The first phase is physical and takes under two minutes. The attacker uses YellowKey to boot into WinRE, receives a SYSTEM shell with the decrypted volume fully accessible, and stages a small payload — an executable or a modified system binary — on the now-readable drive. The machine then boots normally.

At the next user logon, the staged payload executes at whatever privilege level the attacker chose. If they modified a startup item, a scheduled task binary, or a file in a user's startup path, the execution is automatic and user-transparent. If the payload runs as a standard user, GreenPlasma (or the earlier BlueHammer or RedSun escalation paths) can elevate it to SYSTEM without triggering visible alerts.

Once SYSTEM access is established on the live system, UnDefend degrades Defender's detection and signature update capabilities while the endpoint appears healthy to remote management. Credential harvesting, lateral movement, and persistent backdoor installation follow as standard post-exploitation steps.

The complete chain requires no remote exploitation, no phishing, no social engineering, and no specialized hardware. A prepared USB drive and physical access to an unattended machine are the only requirements. Against a target device like an executive laptop left in a hotel room or a workstation in an unlocked server room, this is not a theoretical attack path — it is an operational one.

The Patch and What It Did Not Fix

Microsoft patched both YellowKey and GreenPlasma in the June 2026 Patch Tuesday, the same release that contained a record 208 CVEs. YellowKey received a formal fix in the WinRE image itself. GreenPlasma was addressed through a fix in the Collaborative Translation Framework. Microsoft acknowledged YellowKey's CVE-2026–45585 with its own advisory, noting the fix for "GreenPlasma" (CVE-2026–45586) under an anonymous researcher credit that BleepingComputer subsequently confirmed was actually Nightmare-Eclipse.

For YellowKey specifically, Microsoft had already released interim mitigation guidance on May 20, 2026, a month before the patch. The mitigation removes the autofstx.exe entry from the Session Manager\BootExecute registry value inside the mounted WinRE image, preventing the FsTx Auto Recovery Utility from executing during WinRE boot. Microsoft provided an automation script that handles the mounting, editing, and recommitting of the WinRE image, including re-sealing BitLocker trust for the updated image. The second mitigation path is enabling TPM+PIN rather than TPM-only BitLocker protection, which prevents the volume master key from being released during WinRE boot and blocks the entire attack.

There is an important caveat administrators should be aware of: Windows Update can silently reintroduce the BootExecute entry when cumulative updates are applied, restoring the vulnerable configuration even after the mitigation has been manually applied. Building WinRE validation into post-patch verification routines is necessary to catch this.

The deeper architectural issue was not resolved. The recovery environment still operates with elevated trust on unlocked volumes. The specific mechanism autofstx.exe used to process external TxF logs was blocked, but the structural property that allows WinRE to access encrypted drives before authentication — a property that is necessary for recovery to function — remains unchanged. YellowKey and GreatXML exploited different components in the same trust model. The patch for YellowKey does not prevent a future researcher from finding a third component in the same environment that exhibits similar behavior.

Microsoft's Bug Bounty Problem

The Nightmare-Eclipse case is not just a technical story. It is a stress test for the coordinated disclosure model and for Microsoft's specific implementation of it.

The researcher's core claim — that Microsoft deleted their MSRC portal account and that submitted bug reports went unacknowledged and unrewarded — is specific enough to investigate and specific enough to refute, if it were false. Microsoft has not publicly addressed this specific claim. The company's response focused exclusively on the principle of coordinated disclosure, arguing that public release of exploit code is never acceptable regardless of circumstances.

The security research community's reaction reflected the gap between that principle and the practiced reality of vendor disclosure programs. Katie Moussouris, who built Microsoft's first bug bounty program, pointed out that threatening criminal prosecution against researchers creates exactly the chilling effect that makes the internet less safe — researchers who cannot trust vendor channels will stop reporting bugs altogether, or will route them through channels Microsoft has no visibility into. Kevin Beaumont's observation that Microsoft has historically hired researchers with public disclosure histories added a useful dimension: the company's tolerance for aggressive disclosure has never been consistent.

The GitHub and GitLab bans on Nightmare-Eclipse's accounts removed the primary hosting platforms for the proof-of-concept code. They did not remove the code. Code distributed for eleven days before a ban is already archived, mirrored, and circulating in private channels. The bans succeeded in reducing public accessibility; they did not reduce attacker accessibility.

Nightmare-Eclipse threatened a major additional disclosure on July 14, 2026, timed to Microsoft's next Patch Tuesday and described with the phrase "make sure your bones are shattered that day." In subsequent posts, the researcher walked back this threat, noting that writing RoguePlanet — the seventh zero-day in the series, a Windows Defender race condition disclosed the day of the June Patch Tuesday — had exhausted them. Whether July 14 brings additional disclosures remains uncertain as of this writing.

Defensive Recommendations

For organizations and individuals running affected systems, the steps are clear, though some require ongoing attention.

Apply the June 2026 Patch Tuesday updates. Both YellowKey and GreenPlasma are patched in these updates. For YellowKey specifically, also apply Microsoft's WinRE mitigation script if the patch has not yet been deployed, as the patch and the mitigation address the same issue through different mechanisms.

After applying Windows updates, verify the WinRE BootExecute configuration. Use reagentc /info to confirm WinRE status and, where possible, mount and inspect the WinRE image's offline SYSTEM hive to confirm autofstx.exe is not present in the Session Manager\BootExecute value. Patch deployment does not guarantee WinRE configuration integrity on all systems.

Move BitLocker configurations from TPM-only to TPM+PIN, particularly on mobile devices, executive laptops, field hardware, and any machine that may be outside direct physical control. This change can be made on already-encrypted volumes through PowerShell:

Add-BitLockerKeyProtector -MountPoint "C:" -TpmAndPinProtector

Add-BitLockerKeyProtector -MountPoint "C:" -TpmAndPinProtector

Pair this with a BIOS/UEFI boot password to prevent an attacker from simply booting a different OS, and configure boot order to prevent USB boot without the UEFI credential.

For GreenPlasma, the June Patch Tuesday fix is the correct remediation. The mitigation of disabling ctfmon.exe through Image File Execution Options carries significant side effects on systems using non-Latin input methods, accessibility services, or specialized IMEs, and should not be used as a production workaround.

Physical access controls remain foundational. Neither YellowKey nor GreenPlasma Phase 1 can be exploited remotely. If your threat model includes adversaries with the ability to physically touch machines — insider threats, targeted theft, border device inspections — technical controls on the device itself are insufficient without physical security measures.

Monitor WinRE usage. Normal users rarely boot into recovery environments. WinRE boot events in your endpoint telemetry, particularly outside scheduled maintenance windows, warrant investigation.

What This Research Exposes

YellowKey and GreenPlasma are technically distinct vulnerabilities in different components. What connects them, beyond the researcher who found them, is a shared attack philosophy: trusted, native, signed Windows components becoming the actual attack surface.

autofstx.exe is a legitimate Windows binary, signed by Microsoft, executing with the full trust of the early-boot recovery environment. ctfmon.exe is a legitimate Windows process, signed by Microsoft, running as SYSTEM to support text input. The attacks succeed precisely because these components are trusted — not despite it. Security models that ask "is this signed by Microsoft?" will keep producing blind spots when the answer is yes and the signed component is already being weaponized.

The pattern extends beyond this researcher's work. LOLBin attacks abuse certutil.exe, mshta.exe, wscript.exe, and dozens of other signed Windows utilities. Signed driver abuse disabled Defender on machines that should have been protected. Supply chain compromises weaponize legitimate package distribution channels. The defense against this class of attack is not signature verification — it is behavioral monitoring, allowlisting that goes beyond signature to include expected behavior, and isolation of trusted components from attacker-controlled inputs.

For BitLocker specifically, the architectural tension identified by YellowKey — that WinRE must access encrypted volumes and must process configuration from those same volumes — does not have a clean resolution that preserves full recovery functionality. The patches for YellowKey and GreatXML addressed specific exploitation paths. The underlying trust model that made those paths possible has not been redesigned.

That is the part worth watching as the research in this area continues.

References:

• CVE-2026–45585 (YellowKey) — Microsoft Security Update Guide
• CVE-2026–45586 (GreenPlasma) — Microsoft Security Update Guide
• LevelBlue / SpiderLabs: "From WinRE to SYSTEM: Hunting CVE-2026–45585 Exploitation and the MiniPlasma Attack Chain"
• Hive Security: "YellowKey: The BitLocker Bypass Hidden in Windows Recovery"
• Guardsix: "Inside the Latest Chaotic-Eclipse Releases: Mini-Plasma, GreenPlasma, and YellowKey"
• Barracuda Networks: "Nightmare-Eclipse: Six Zero-Days, Six Weeks and One Big Grudge"
• The Hacker News: "Microsoft Releases Mitigation for YellowKey BitLocker Bypass CVE-2026–45585 Exploit"
• Blackfort Technology: "GreenPlasma: Arbitrary Section Creation on Windows — Analysis and Detection"
• Zero Day Initiative: "The June 2026 Security Update Review"
• BleepingComputer: "Microsoft June 2026 Patch Tuesday Fixes 6 Zero-Days, 200 Flaws"
• Nightmare-Eclipse Blog: deadeclipse666.blogspot.com

GitHub: github.com/alisalive | LinkedIn: linkedin.com/in/camalzads