YellowKey & GreenPlasma: Two Windows Bypasses, Explained for Defenders

Two Windows vulnerability disclosures crossed my desk this week, both published openly on GitHub, both already getting attention from security researchers, and both squarely in the category of "bugs that small business owners should at least understand the shape of." One bypasses BitLocker on a stolen laptop. The other turns a normal user account into the operating system. I'm going to walk through what each one actually does, why they work, and what a small business should do about them.

This post is for defenders. I'm explaining publicly disclosed bugs that are already in the wild as research write-ups. I'm not publishing exploit code, I'm not giving step-by-step replication instructions beyond what the original researcher already put on GitHub, and the only systems anyone should be testing this on are ones they own. The point is for you to understand the shape of the threat well enough to make good decisions about your fleet.

The setting

A researcher posting under Nightmare-Eclipse dropped two proof-of-concept repos on GitHub over the last few weeks. The first is called YellowKey. It is a BitLocker bypass that works on Windows 11 and Windows Server 2022/2025 and explicitly does not work on Windows 10. The second is GreenPlasma. It is a privilege-escalation proof-of-concept that abuses Windows' Text Services Framework, also on Windows 11 and Windows Server 2022 and 2026.

Between them they have several hundred stars on GitHub, which in research-community terms means a lot of people are taking them seriously. The author credits Microsoft's MORSE, MSTIC, and Microsoft GHOST teams on the YellowKey disclosure, which is what you would expect for a coordinated report to Microsoft. As of publication, neither has a public CVE number assigned that I can locate, and Microsoft has not yet shipped a patch. That is normal for the early window of a coordinated disclosure. I will update this post when those numbers land.

YellowKey: how a BitLocker bypass through WinRE actually works

What BitLocker is supposed to do

BitLocker is the full-disk encryption built into Windows. On a typical business laptop, when you turn the machine on, the Trusted Platform Module (TPM) measures the boot chain, decides everything looks right, and releases the disk encryption key automatically. The user logs in normally and never sees the encryption. The protection only kicks in if the disk is pulled out and read on another machine, or if the boot chain is tampered with: in those cases the TPM refuses to release the key and the data on the disk is just ciphertext.

That is the threat model BitLocker was designed for: a stolen laptop, where the thief should not be able to read the data. It is also the threat model that has been quietly eroding for years. Researchers have shown sniffing the TPM bus, attacking sleep states, and abusing Windows Recovery Environment to get at the unlocked volume. YellowKey is the newest entry in that lineage.

Where Windows Recovery Environment fits in

Windows Recovery Environment, or WinRE, is the small Windows image that boots when normal Windows cannot. It is what you land in when you hold Shift and click Restart, when the operating system fails to boot three times in a row, or when you boot from recovery media. WinRE has its own minimal Windows on top of which troubleshooting tools (System Restore, Startup Repair, the command prompt, Reset This PC) run. By design, WinRE has to be able to touch the BitLocker-protected volume to do its job, because most of what it does is repair a system drive that is otherwise encrypted.

The way Microsoft has historically handled that is to require a BitLocker recovery key, or to only release the key inside WinRE when the boot chain measurements still match the TPM's expectations. The recovery environment is also supposed to be a signed image: tampering with WinRE should trip Secure Boot and refuse to launch.

What YellowKey actually does

The YellowKey disclosure shows a way to slip past those checks. The high-level shape, lifted straight from the public README:

1. The attacker prepares a USB stick. A specific folder structure is created at System Volume Information\FsTx\ on the USB, containing a specific payload directory whose name matches a system GUID. (The folder name and GUID are in the public repo. I am intentionally not repeating them here, although a determined reader can look them up. The point is that the contents are not magic; they are a small, specific layout that triggers the bug.)
2. The USB stick is plugged into a target Windows 11 or Server 2022/2025 machine. The attacker triggers a reboot into WinRE: Shift-Restart from a logon screen, or, if the machine is powered off, by interrupting the normal boot a few times to force WinRE to launch on its own.
3. During the WinRE-initiated reboot, a specific keyboard combination is held. The README describes it as Ctrl held during the restart sequence. Under normal conditions this does nothing. With the staged payload on the USB stick, it lands the attacker in a shell that has full read/write access to the BitLocker-protected system drive.

The researcher also notes that the same effect can be achieved without external media by writing the same files to the machine's own EFI System Partition. That is significant because the EFI partition is not protected by BitLocker and, on most fleet machines, is reachable from a live-boot USB or any administrative shell.

Why this works at all, in one paragraph

The mechanism the researcher exposes is that a component used by WinRE checks for a specific input combination at boot, and when it sees one, it accepts an external configuration written to the FsTx folder. That configuration ends up steering the recovery image toward launching a privileged shell with the BitLocker volume already mounted in cleartext. The bug, in the author's reading, is that this codepath should not exist in a production WinRE image, or if it does, it should require a signed configuration. The author goes further and notes that the same-named component exists in normal Windows installations but does not contain the trigger; only the WinRE image does. They speculate, without proof, that this is a leftover engineering or recovery interface that was never supposed to ship.

For the purposes of running a small business, the speculation does not matter. The shape of the bug does: any attacker with brief physical access to a Windows 11 machine can read the BitLocker-protected disk, unless the disk is locked behind something the TPM cannot release on its own.

What this means for a stolen laptop

If you hand a thief a Windows 11 laptop with TPM-only BitLocker, the thief can now plausibly read every file on it. Customer data. QuickBooks files. Saved Outlook profiles. Cached SharePoint files. The cached Azure AD primary refresh token, which in many configurations is enough to impersonate the user against Microsoft 365 from another device. That last one is the one that should focus a small business owner's attention. The data on the laptop is bad enough; the keys to the cloud accounts the laptop was already signed into is worse.

It is also worth being honest about the historical context. BitLocker with TPM-only protection has been considered marginal against a determined physical attacker for several years. Microsoft's own guidance has been moving toward TPM plus PIN, particularly for portable devices. YellowKey is not the first reason to add a pre-boot PIN; it is just the loudest recent one.

GreenPlasma: how a CTFMON bug becomes a building block for SYSTEM

What CTFMON even is

CTFMON.exe is one of those Windows processes that runs on every machine, that almost no one thinks about, and that has been quietly responsible for security bugs for two decades. The "CTF" stands for Collaborative Translation Framework. It is the back end of the Text Services Framework, or MSCTF, which is what Windows uses to route input from keyboards, alternative input methods, handwriting, speech, and the on-screen keyboard into every application that accepts text. Every text box in every application on a Windows machine, from Notepad to a UAC password prompt to a SYSTEM-owned service console, is wired into CTFMON.

The reason it shows up in security research is that CTFMON sits across a lot of trust boundaries. A standard user process talks to it. A SYSTEM process talks to it. A locked desktop talks to it. A logon screen talks to it. Any process that can convince CTFMON to do something on its behalf inherits a little bit of CTFMON's reach into those other contexts.

Where kernel object directories come in

Windows has a kernel-level namespace for "objects": named pipes, mutexes, events, memory section objects, and so on. These objects live inside object directories, which are arranged into a tree very similar to a filesystem. You can browse it with tools like Sysinternals' WinObj. Some of these directories are writable only by SYSTEM, like \KnownDlls, \BaseNamedObjects in the appropriate session, and various device and driver namespaces. The reason they are SYSTEM-writable is that the kernel and many privileged services assume the names inside them are trustworthy: a kernel driver that opens \Device\Foo implicitly trusts that nobody but SYSTEM could have created it.

"Trustworthy" is doing a lot of work in that sentence. The trust model is that if you can put something in a SYSTEM-only directory, you must have been SYSTEM, so whatever you put there is fine to use. That assumption is what GreenPlasma breaks.

What GreenPlasma actually does

The proof-of-concept code in the repo, as a standard user, gets CTFMON to create an arbitrary memory section object inside one of those SYSTEM-writable directories. A section object is a kernel object that represents a region of memory that can be mapped into a process's address space. The attacker, who normally cannot place anything in a SYSTEM-only directory, now has a named object sitting where SYSTEM-owned code expects to find SYSTEM-owned data.

On its own, this is not root. The PoC stops at "I created the object." What turns it into a privilege escalation is the next step the author deliberately leaves to the reader: find a SYSTEM-owned service or kernel driver that opens that name and reads from it, and you have a primitive for influencing that privileged code. Depending on the consumer, that can be a controlled memory disclosure, a controlled code path, or in the worst case a controlled write into kernel memory. The author frames the missing step as a CTF challenge; in practice, people will write it, and some of them will publish.

Why this kind of bug matters even when it is "just" local

Local privilege escalation is the unglamorous workhorse of every modern intrusion. A phishing email or a browser exploit gives the attacker code running as the user. By itself, that is annoying. Stack a local privilege-escalation primitive on top, and the attacker becomes SYSTEM. Once they are SYSTEM on one machine, they can dump credentials from memory, register a persistence mechanism, disable defenses, and start moving laterally. In every ransomware case study I've written about, there is a local-privesc step in the chain. GreenPlasma is the kind of building block that ends up in that step.

So while the PoC by itself does not pop a SYSTEM shell, the right way for a defender to read it is: this is a primitive that lowers the cost of building a SYSTEM-level exploit on every supported Windows 11 and Server 2022/2026 build, until Microsoft fixes the CTFMON path.

What's actually at risk for a small business

YellowKey: every laptop that leaves the building

The threat is physical. A laptop left in a car, a laptop forgotten at a customer site, a laptop that an employee hands to a "technician" for a fake repair. The attacker needs a few uninterrupted minutes with the device powered on or off, a USB stick, and the public disclosure. There is no remote variant. If your fleet stays inside the office and never leaves, your exposure is small. If your fleet is half a dozen sales laptops driving up and down US-101, your exposure is real.

The harder cost is not the data on the drive. It is the credentials. A modern Windows laptop signed into Microsoft 365 stores cached tokens and refresh tokens that let an attacker impersonate the user against your tenant for hours to days. The same is true of cached VPN credentials, saved passwords in browsers, and any local copies of work files. The drive being readable means the cloud accounts are functionally readable too, unless you have additional controls in place.

GreenPlasma: every Windows 11 endpoint, every Server 2022/2026 host

The threat is remote-then-local. An attacker has to first land code on the machine as a standard user, which they typically do through phishing, a malicious document, a browser bug, or stolen credentials. GreenPlasma then gives them a faster path from "code as a user" to "code as SYSTEM," and from there to the full toolkit of post-exploitation. Servers matter most. A Windows Server 2022 file server, terminal server, or RDS host that lets the wrong user reach a shell is a worse exposure than a laptop, because there is more privileged data sitting on it.

What to do, in order

1. Turn on a BitLocker pre-boot PIN on portable devices

This is the single most important control specifically for YellowKey, and a good idea regardless. With TPM plus PIN, the TPM will not release the BitLocker key until the user types the PIN at boot. Holding Ctrl during a WinRE reboot does not help an attacker who cannot get the drive unlocked in the first place. You set it through Group Policy under Computer Configuration › Administrative Templates › Windows Components › BitLocker Drive Encryption › Operating System Drives, with "Require additional authentication at startup" set to enabled and a PIN required. Pair this with a recovery key escrowed to Microsoft Entra ID or Active Directory so a forgotten PIN does not become a stuck laptop.

The trade-off is user friction: people will have to type one more thing at boot. In my experience, owners agree to it once they see what a stolen laptop costs them in incident response and notification. For C-TPAT and similar compliance regimes, a pre-boot PIN is increasingly assumed.

2. Harden or disable Windows Recovery Environment on the fleet

WinRE is useful but it is also the attack surface YellowKey lives on. For a managed fleet that does not rely on local WinRE recovery (because you reimage from MDT, Intune, or a vendor image instead), you can disable it: reagentc /disable from an elevated prompt, optionally followed by removing the WinRE image. For machines where you want to keep recovery available, make sure the WinRE partition is up to date, Secure Boot is enforced, and the recovery image is the one Microsoft ships, not a vendor variant that may carry the vulnerable component longer. When the patch ships, apply it to the WinRE image too: WinRE has its own update path, and the cumulative monthly update does not always cover it without an extra step (reagentc /info shows the current image; DISM applies updates).

3. Patch fast when Microsoft ships

Microsoft is aware of both disclosures. When the cumulative updates land that address them, you want to be on a patch cadence that absorbs them within days, not months. I wrote about this at length in the post on why patch cadence is shifting from quarterly to continuous. The TL;DR is that auto-patch through your endpoint management tool, plus someone whose job is to watch the CVE feed, is the only configuration that keeps up with current disclosure volume.

4. Reduce blast radius: identity hardening

Both bugs hurt less in environments with disciplined identity. Conditional Access policies that block sign-ins from unmanaged devices mean a stolen primary refresh token gets you less. Phishing-resistant MFA (FIDO2 keys, Windows Hello for Business) means cached passwords are not the keys to the kingdom. No persistent local administrators on user laptops means a local-privesc primitive lands in an account that is already constrained. The list overlaps heavily with the cybersecurity mistakes I see in almost every small business. Closing those gaps is the durable answer, not a per-CVE fire drill.

5. Physical security, the unglamorous part

A laptop in a locked office is a much harder target than a laptop in the back of a car. A server in a locked rack with logged physical access is harder than a server on a shelf in a closet. Asset tags, cable locks, and a clear policy about devices off-premises are not exciting controls, but they cut the population of attackable machines down to the ones that actually need additional engineering.

How to think about this kind of disclosure in general

It is easy to read about a BitLocker bypass and conclude that BitLocker is broken, or to read about a CTFMON bug and conclude that Windows is broken. Neither conclusion is useful. The honest reading is that complex systems leak attack surface over time, that public researchers are getting better and faster at finding the leaks (a theme I covered in the Claude Mythos post last week), and that the defenses that matter are the ones that survive any individual bug: defense in depth, fast patching, hardware-backed identity, and a physical posture that matches the threat model.

YellowKey and GreenPlasma are interesting because they are accessible. The README on each repo is short enough that a smart undergraduate can follow it. That is the new normal. The window when a disclosure is "researchers only" used to be months. It is now days. The defender response that worked for the old window does not work for the new one.

FAQs about YellowKey and GreenPlasma

What is YellowKey and what does it bypass?

YellowKey is a publicly disclosed BitLocker bypass that uses Windows Recovery Environment to gain unrestricted access to an encrypted system drive on Windows 11 and Windows Server 2022/2025. It requires physical access. The attacker stages files on a USB stick (or the EFI partition) and triggers a specific key combination during a WinRE-initiated restart to land in a shell with read/write access to the BitLocker volume. Windows 10 is not affected.

What is GreenPlasma?

GreenPlasma is a proof-of-concept that abuses CTFMON, the Text Services Framework process, to create memory section objects inside Windows kernel object directories that are writable by SYSTEM. By itself the PoC does not yield SYSTEM, but it gives an attacker a low-cost primitive for placing data where privileged code expects to find it. The published code is intentionally partial; the author left the final escalation as a research exercise.

Does YellowKey work without physical access?

No. YellowKey requires the attacker to either insert a USB stick into the target machine or write to the EFI System Partition. That means a stolen laptop, an office walk-in, a service drop-off where the device is left unattended, or a malicious insider. For a small business, this maps to physical security and pre-boot PIN policy, not to perimeter or email controls.

If my laptop has BitLocker turned on, am I safe from a thief?

BitLocker alone with TPM-only protection has been considered marginal against a determined physical attacker for years. YellowKey is the latest data point. The defensible posture is TPM plus a pre-boot PIN, with WinRE either hardened or disabled on managed fleets. A stolen laptop with TPM-only BitLocker should be treated as a potential data breach until proven otherwise.

Is there a patch yet?

As of publication, Microsoft has acknowledged both disclosures and triage is in progress. We will update this post when patches ship. The mitigations above (pre-boot PIN, WinRE hardening, physical security, fast patching) are the durable answers regardless of patch status.

Does this affect macOS or Linux?

No. Both bugs are specific to Windows components: WinRE in the YellowKey case, the Windows Text Services Framework in the GreenPlasma case. macOS FileVault and Linux dm-crypt/LUKS have their own histories of physical-access research, but neither shares the WinRE codepath. On the local-privesc side, every operating system has its analog; the relevant question is patch cadence, not the existence of bugs.

Why publish the bugs publicly at all?

Coordinated public disclosure is how the security community pressures vendors to fix things and how defenders learn what to look for. The researcher credited Microsoft's MORSE, MSTIC, and Microsoft GHOST teams on YellowKey, which is consistent with coordinated reporting. The GreenPlasma PoC is intentionally incomplete for the same reason: the author wants the bug fixed, not weaponized. The reason a small business owner should care is not the ethics of disclosure; it is that you should be on the patching side of the disclosure curve.

Prefer to talk first? Email sales@ghosxt.com or call (831) 204-0501.

About this post. This article discusses publicly disclosed Windows vulnerabilities for defensive and educational purposes. It does not contain working exploit code or detailed replication steps beyond what the original researcher has already published. Any testing of physical-access techniques should be performed only on systems you own or are explicitly authorized to assess. If you believe a vulnerability affects your organization, follow your incident-response plan and coordinate with your IT provider before taking action.