Go back

Breaking Down GreenPlasma and YellowKey: Windows Trust Boundaries Doing Windows Things

Updated:  at  10:35 AM
Suggest Changes

Hey everyone!

Windows security has had another completely normal week, which means someone on GitHub dropped two Windows-related vulnerabilities with dramatic names and the entire security community immediately stopped pretending to be productive.

This time, the releases are GreenPlasma and YellowKey, both published by Nightmare-Eclipse, the same account behind earlier Windows-focused releases like RedSun, BlueHammer, and UnDefend.

And honestly, the pattern is getting hard to ignore.

Nightmare-Eclipse is not just posting random “look I found a bug” snippets. The account keeps releasing research around the same kind of uncomfortable Windows behavior: trusted components, privileged services, recovery environments, object namespaces, and security products doing exactly what they were designed to do, except in a way that makes defenders want to stare silently at a wall.

GreenPlasma focuses on CTFMON and arbitrary section object creation, which can become a local privilege escalation path.

YellowKey focuses on BitLocker bypass through Windows Recovery Environment behavior, which is the kind of sentence that immediately makes laptop theft scenarios feel less theoretical.

This blog breaks both of them down from beginner level, without turning it into a copy-paste abuse guide. You will understand the technical ideas, why they matter, what the likely impact is, and what defenders should actually care about.

Ready to dive into Windows trust boundaries doing Windows trust boundary things? Let’s get started.

Table of Contents

Open Table of Contents

First, What Actually Happened?

Nightmare-Eclipse published two repositories:

At a very high level:

YellowKey is about getting access to a BitLocker-protected Windows volume through recovery environment behavior. This is not a remote exploit. It is a physical/local attack scenario. But that does not make it harmless. BitLocker exists specifically because physical access happens. Laptops get stolen. Drives get pulled. Employees leave devices in cars because apparently we still trust cars in 2026.

GreenPlasma is about tricking Windows into creating a memory section object somewhere a normal user should not normally be able to influence. The released code does not appear to include the final full SYSTEM shell path, and the author explicitly says they stripped that part. But the primitive itself is the interesting part, because in Windows exploitation, “I can create an object in a place I should not control” is often the beginning of a very bad afternoon.

At the time of writing, I am treating both as public disclosures that need independent validation and vendor confirmation. The repositories are public, but public GitHub code is not the same thing as a fully verified advisory. Welcome to modern vulnerability research, where half the internet becomes a peer review board with avatars.

The Nightmare-Eclipse Pattern

This is not the first Nightmare-Eclipse release.

The same GitHub profile has previously hosted Windows-focused projects like RedSun, BlueHammer, and UnDefend. Those earlier releases revolved around Microsoft Defender and Windows trust assumptions. Some third-party reporting also observed previous Nightmare-Eclipse tooling being used in real-world intrusion activity, which is the part where defenders stop laughing and start checking telemetry.

The interesting pattern is this:

  1. The bugs are not usually “classic memory corruption.”
  2. They often abuse legitimate Windows behavior.
  3. They chain trusted components together.
  4. They rely on weird edges between privilege boundaries.
  5. They are released publicly, quickly, and with a very specific tone of “Microsoft, explain this.”

That is what makes the account interesting.

A beginner might think hacking means shellcode, buffer overflows, and glowing green terminals. Sometimes, yes. But a lot of modern Windows exploitation looks more like this:

Find a privileged component. Understand what it trusts. Put attacker-controlled data where that component does not expect it. Let Windows attack itself.

It is less Hollywood and more bureaucracy with side effects.

Before the Bugs: Windows Concepts You Need

Before breaking down YellowKey and GreenPlasma, let’s build the basic mental model.

What is BitLocker?

BitLocker is Microsoft’s full-disk encryption feature. Its job is to protect data at rest.

If someone steals your laptop or removes your drive, BitLocker should prevent them from reading the disk without the right key material. In normal enterprise setups, BitLocker may use TPM-based protection, recovery keys, Secure Boot measurements, and policy configuration.

The important idea is simple:

BitLocker is supposed to protect your data even when the attacker has your device.

That is why bypass claims matter. A BitLocker bypass is not just another local bug. It attacks one of the last defensive layers left when physical possession is lost.

What is WinRE?

Windows Recovery Environment, or WinRE, is the recovery mode Windows uses when something goes wrong. It helps repair boot issues, reset systems, restore images, access troubleshooting tools, and recover from failures.

WinRE is useful. It is also sensitive.

Why? Because recovery environments often need deep access to the operating system. They are designed to fix broken machines, which means they sit near extremely sensitive trust boundaries.

That is always dangerous.

Anything with “recovery” in its name usually means:

In other words, it is security-critical plumbing. And like most plumbing, nobody thinks about it until something leaks.

What is CTFMON?

ctfmon.exe is tied to Windows text input and the Text Services Framework. Think input methods, keyboard layouts, language services, IMEs, handwriting, speech input, and the general mess of “how text gets into applications.”

It sounds boring.

That is exactly why it is interesting.

Security people have learned, painfully, that boring components are often the dangerous ones. CTFMON sits close to user sessions, desktop interaction, input handling, and cross-process communication. It is not supposed to be exciting. But Windows has a talent for making boring things load-bearing.

What is the Windows Object Manager?

Windows manages many internal resources as objects. Processes, threads, tokens, registry keys, sections, symbolic links, events, mutexes, devices, and more are all represented through the Windows object model.

The Object Manager maintains a namespace where these objects can have names, paths, permissions, and relationships.

Example idea:

\BaseNamedObjects\SomeSharedObject
\Sessions\1\BaseNamedObjects\SomeSessionObject
\KnownDlls\kernel32.dll

This object namespace is not the same as the normal filesystem, but the idea is similar enough for beginners:

Windows has internal named paths for system objects, and access to those paths matters.

If a standard user can influence an object path that a privileged process later trusts, things get spicy.

And by “spicy,” I mean “someone in Redmond gets a calendar invite titled Incident Review.”

What is a Section Object?

A section object represents shared memory or file-backed memory mapping. Processes can map sections into memory so they can share data or load file contents efficiently.

This is normal and heavily used across Windows.

But from a security perspective, section objects matter because they can be shared across privilege boundaries. If one process creates or trusts a section object in a sensitive namespace, and another lower-privileged process can influence it, you may get a security issue.

A rough beginner version:

A section object is like a shared memory room. The bug class appears when Windows lets the wrong person choose where that room is created or what it points to.

Windows object namespace supports symbolic links. These are not normal filesystem shortcuts. They are object namespace redirects.

If a privileged component tries to open one object path, but that path is actually redirected somewhere else, it may end up interacting with an attacker-chosen object.

That idea comes up a lot in Windows local privilege escalation research.

The pattern looks like this:

  1. Privileged process expects a safe object path.
  2. Attacker creates or influences a named object/symlink.
  3. Privileged process follows it.
  4. Sensitive object gets created/opened somewhere attacker controls.
  5. Congratulations, the trust boundary has been converted into modern art.

YellowKey: BitLocker Bypass in Plain English

YellowKey is the louder of the two releases because it targets BitLocker.

The repository claims that on affected systems, an attacker can use recovery environment behavior to get shell access with unrestricted access to the BitLocker-protected volume.

Let’s translate that carefully.

Normally, if BitLocker protects a volume, you should not be able to just boot into some alternate mode and read the disk. That would defeat the entire point. The encrypted volume should remain protected unless the system validates the required key material or recovery secret.

YellowKey claims there is a path inside WinRE where this protection boundary fails.

This is why the bug is conceptually serious:

That last point is important.

This is not “BitLocker crypto is broken.”

That would be a very different and much bigger claim.

This is more like:

The encryption may still be strong, but the surrounding recovery environment may create a way around the locked door.

And this is one of the most common lessons in security: cryptography is rarely defeated by attacking the math. It is usually defeated by attacking everything around the math, because everything around the math was built by humans, and humans invented printer drivers.

Why YellowKey Is Scary

A lot of people hear “physical access required” and immediately downgrade the issue in their head.

That is a mistake.

Physical access is not rare. It happens constantly:

BitLocker exists because these scenarios exist.

So if a BitLocker bypass works reliably, the impact is not theoretical. It means the attacker may not need to phish credentials, exploit a browser, or bypass EDR. They can attack the device while it is offline.

That is a different category of risk.

The attacker does not need your VPN password if they can read local cached data, tokens, browser profiles, synced documents, SSH keys, source code, password manager artifacts, internal notes, and whatever else lives on the disk because apparently endpoints are now portable data centers.

YellowKey Technical Breakdown

Let’s keep this high-level and safe.

The YellowKey repository includes a folder structure intended to be placed where Windows Recovery Environment will interact with it. The author claims that when the system enters WinRE under the right conditions, a shell appears with access to the protected volume.

The technical heart appears to be this:

  1. WinRE loads recovery components from a trusted environment.
  2. A specific recovery-related component behaves differently inside WinRE than in normal Windows.
  3. That component appears to interact with attacker-controlled content from external or boot-adjacent storage.
  4. The result is a shell-like execution context with access to the BitLocker-protected volume.

That is the important model.

You do not need the exact reproduction steps to understand the bug class.

The security failure is not “someone guessed a recovery key.” The security failure is that a recovery path may be creating a trusted execution/access path where the encrypted volume becomes reachable without the normal expected barrier.

Why the WinRE Part Matters

WinRE is not just another Windows desktop session.

Recovery environments often run with special assumptions. They need to repair, unlock, mount, inspect, and modify system state. That makes them powerful.

But that also means every component inside WinRE must be treated like security-critical code.

If a component inside WinRE:

then BitLocker may become a victim of the recovery system around it.

This is the same kind of failure pattern we see repeatedly in security:

The main lock is strong. The side door has vibes-based access control.

About the “Backdoor” Claim

The YellowKey README uses strong language and suggests the responsible component feels suspicious, even backdoor-like.

That is worth mentioning, but carefully.

A bug can look suspicious without being intentionally malicious. Windows has decades of compatibility layers, recovery paths, duplicate components, weird historical baggage, and design decisions that probably made sense to someone in a meeting room in 2009.

So my take is simple:

We do not need conspiracy when architecture is perfectly capable of embarrassing itself.

GreenPlasma: CTFMON, Object Manager, and Weird Windows Internals

GreenPlasma is less flashy than YellowKey, but technically very interesting.

The repository describes it as a Windows CTFMON arbitrary section creation elevation-of-privilege vulnerability.

That sentence is doing a lot of work, so let’s break it down.

What Does “Arbitrary Section Creation” Mean?

It means the attacker can influence Windows into creating a section object at a location or namespace path the attacker chooses, including places normally writable only by SYSTEM or trusted components.

That does not automatically mean “instant SYSTEM shell.”

But it is a dangerous primitive.

In exploitation, a primitive is a building block. It may not be the full exploit by itself, but it gives you a capability you should not have.

Examples:

GreenPlasma’s primitive is interesting because Windows services, drivers, and privileged components may trust specific object namespace paths precisely because standard users are not supposed to control them.

If that assumption fails, privileged components may read from, map, write to, or synchronize with something the attacker influenced.

That is where privilege escalation can begin.

Why CTFMON Is Involved

CTFMON is related to input services and user session interaction. The GreenPlasma code interacts with session-specific object paths that appear tied to CTF/Winlogon behavior.

The simplified idea:

  1. Windows expects certain CTF-related objects to exist in a session namespace.
  2. The PoC creates an object manager symbolic link at a sensitive expected path.
  3. A higher-privileged Windows flow is triggered.
  4. That privileged flow attempts to create/open a section object.
  5. Because of the link, the object operation lands somewhere attacker-influenced.

That is the classic “you trusted a name, I changed what the name means” problem.

It is like telling a delivery person, “Drop this package at the secure office,” while someone quietly replaces the office sign with an arrow pointing to a basement full of raccoons.

The delivery person followed instructions. The system still failed.

What the Code Appears to Do

The GreenPlasma PoC uses Windows-native APIs and behavior around:

The code appears to build the conditions for Windows to create/open a section object through a path the attacker has influenced.

Again, the author says the final code needed for a full SYSTEM shell was stripped. That matters. This is not presented as a complete weaponized privilege escalation chain in the README. But it is still not “nothing.”

A reliable primitive in Windows internals is often enough for researchers to build the missing last mile.

And if history has taught us anything, it is that the internet treats “missing last mile” as a weekend challenge.

GreenPlasma Technical Breakdown

Let’s walk through the logic at a beginner-friendly level.

Step 1: Find the Current Session

Windows has sessions. A logged-in user usually lives in a non-zero session. Services may run elsewhere. Session separation matters because many named objects are session-specific.

The PoC checks the current process session ID. If it is not in an interactive user session, it stops.

That makes sense because CTFMON and input-related behavior live close to interactive desktop sessions.

Step 2: Build the Expected CTF Object Path

The code builds a path in the Windows Object Manager namespace that appears related to CTF and Winlogon behavior for that session.

This is important because privileged Windows components may later use the same path.

In Windows exploitation, predictable object names are often valuable. If a privileged process expects a named object to exist, and you can create something at that name first, you may be able to redirect or influence what happens next.

This is why named objects need proper access control. Names are not security. They are just labels. And labels can lie.

The PoC creates an object manager symbolic link from the expected CTF path to a target object path.

Beginner translation:

When Windows tries to use this trusted-looking internal name, it may actually end up at an attacker-chosen destination.

This is the core trick.

It is not “malware magic.” It is Windows object namespace behavior being used in a security-sensitive way.

Step 4: Trigger a Privileged Flow

The PoC then triggers behavior that causes Windows to create or open the relevant section object. The code uses an elevated execution path to involve a more privileged Windows context.

This is where the confused deputy pattern appears.

A confused deputy is when a privileged component performs an action on behalf of a lower-privileged attacker because it misunderstands the context.

The privileged component is not necessarily malicious. It is just confused.

Which is relatable, but not acceptable when it runs as SYSTEM.

Step 5: Hold the Section Handle

The PoC waits until the section exists and then obtains a handle to it. Holding a handle matters because Windows objects stay alive as long as references exist.

That means even if the system later cleans up a name, the attacker may still retain access to the object through the handle.

This is another common Windows exploitation theme:

Names are temporary. Handles are power.

Step 6: Why This Can Become Privilege Escalation

By itself, creating a section object does not automatically give you SYSTEM.

The real danger is what other privileged services or drivers do with that object later.

If a SYSTEM service assumes a certain object path is safe and maps, trusts, parses, or writes to that section, then attacker influence over the section can become:

This is why the GreenPlasma README says the full SYSTEM shell code was stripped, but the primitive can still be turned into a full escalation if someone finds the right trusted consumer.

Windows exploitation often works like this:

  1. Get a weird primitive.
  2. Find a privileged component that trusts the primitive.
  3. Turn trust into control.
  4. Pretend this was all inevitable in the postmortem.

What Makes These Bugs Interesting

GreenPlasma and YellowKey are interesting because they are not simple “bad input causes crash” bugs.

They live in trust boundaries.

YellowKey Attacks Recovery Trust

YellowKey appears to attack the boundary between:

That is a serious boundary because recovery flows often get special privileges. The entire point of recovery is to bypass normal broken state. But that convenience must not become a universal skeleton key.

GreenPlasma Attacks Namespace Trust

GreenPlasma appears to attack the boundary between:

That is subtle. It is also very Windows.

A lot of Windows local privilege escalation research is basically:

Can I make a privileged component touch an object, path, file, registry key, pipe, section, link, or handle that I influenced first?

GreenPlasma fits that style.

What This Means for Attackers

From an attacker perspective, these are valuable because they hit different parts of the chain.

YellowKey Is About Physical Data Access

YellowKey is relevant when the attacker can physically access a machine or its storage path.

Potential scenarios:

It is not a remote domain compromise tool. But in environments with sensitive endpoints, physical attacks matter.

GreenPlasma Is About Local Privilege Escalation

GreenPlasma matters after initial local code execution.

For example, an attacker already has code running as a standard user through phishing, malware, browser exploit, RMM abuse, developer tooling compromise, or some other initial access path.

A local privilege escalation bug then helps them move from:

standard user -> administrator/SYSTEM-level capability

That jump matters because SYSTEM access can allow:

The bug is local, but local bugs are how many real intrusions become serious.

Initial access gets you in the room. Privilege escalation gives you the keys to the building.

What This Means for Defenders

For defenders, the key lesson is not “panic because GitHub exists.”

The key lesson is:

Public primitives move fast from research curiosity to intrusion tooling.

We already saw this pattern with previous Nightmare-Eclipse releases. Once code is public, defenders and attackers both get access. The defenders write detections. The attackers test which EDRs blink. Everyone gets a new dashboard. Humanity advances sideways.

Do Not Treat These as Isolated Bugs

The bigger story is Windows trusted-component abuse.

Across these releases, the common theme is not one single component. It is the repeated abuse of Windows internals where privileged components trust paths, objects, files, recovery state, or security product behavior too much.

That means defenders should look beyond the exact PoC.

Look for the class:

Mitigation and Detection Ideas

There may not be a clean vendor patch at the time you read this, so treat this section as practical defensive guidance, not magic dust.

For YellowKey

1. Track official Microsoft guidance

Check MSRC, Windows release notes, and endpoint security advisories. Public GitHub disclosures are useful, but vendor confirmation matters for patch status, affected versions, and mitigations.

2. Review BitLocker policy posture

For high-risk devices, review:

TPM + PIN can improve protection in many stolen-device scenarios because it adds a user secret before unlock. It is not a guaranteed fix for every recovery-path issue, but it is stronger than silently trusting the machine state alone.

3. Control physical boot paths

Where practical:

Yes, attackers with enough physical access can still do ugly things. But security is about making the ugly things harder, slower, and more detectable.

4. Treat lost devices seriously

Do not assume “BitLocker was enabled” means the incident is automatically low risk. If a credible BitLocker bypass exists for the affected platform, lost or stolen endpoints deserve more serious review.

5. Protect recovery keys

Recovery keys should be escrowed properly in enterprise systems like Entra ID, Active Directory, or your endpoint management stack. Access to recovery keys should be logged, reviewed, and restricted.

A recovery key that everyone can view is not a recovery key. It is a group project for disaster.

For GreenPlasma

1. Watch for suspicious process chains

Look for unusual relationships involving:

You may need EDR telemetry for this. Basic Windows logs will not always expose object manager abuse cleanly.

2. Monitor registry policy locations touched by the PoC

The public GreenPlasma code manipulates current-user policy paths around Cloud Files and system policy settings. Watch for suspicious changes under policy-related HKCU locations, especially if paired with unusual process execution.

Useful areas to review include:

HKCU\Software\Policies\Microsoft\CloudFiles
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System

Do not treat those paths alone as proof of exploitation. Treat them as signals when combined with process behavior.

3. Detect native API-heavy tooling

The PoC uses lower-level native APIs around object symbolic links and section objects. Mature EDRs may surface this behavior. If you have custom detection capabilities, look for suspicious creation of object manager symbolic links followed by section object operations in user context.

This is not easy with vanilla logs. Windows internals rarely send you a nicely formatted “someone is doing cursed object namespace activity” event. That would be too kind.

4. Block untrusted binaries with application control

Use WDAC, AppLocker, or equivalent controls to reduce arbitrary executable launch from user-writable paths.

Application control will not fix the vulnerability, but it can make exploitation and post-exploitation harder.

5. Reduce the value of local privilege escalation

Assume local privilege escalation bugs will keep appearing. Reduce blast radius through:

Local privilege escalation is most damaging when endpoints are already full of reusable secrets. Do not leave domain admin power lying around on laptops like snacks in a meeting room.

General Defensive Checklist

If you are responsible for Windows endpoints, do this:

  1. Inventory Windows 11 and Windows Server 2022/2025 systems.
  2. Track Microsoft advisories for GreenPlasma/YellowKey-related fixes.
  3. Review BitLocker policy and recovery-key access.
  4. Restrict external boot where possible.
  5. Enable Secure Boot and firmware protections.
  6. Watch for unusual recovery events and endpoint tampering.
  7. Hunt for public PoC filenames, hashes, and renamed copies.
  8. Monitor suspicious CTFMON/conhost/elevation chains.
  9. Review EDR detections for object manager abuse and section object anomalies.
  10. Treat previous Nightmare-Eclipse tooling as relevant context, not old news.

My Take on Nightmare-Eclipse

Nightmare-Eclipse is becoming one of the more interesting Windows security accounts to watch.

Not because the releases are polished corporate research PDFs with diagrams, legal review, and twelve paragraphs thanking stakeholders for their collaboration.

They are interesting because they expose uncomfortable Windows trust assumptions in a very direct way.

The research style feels like:

Here is the weird primitive. Here is why it is absurd. Here is enough to make the point. Microsoft, kindly enjoy your week.

That tone is funny from the outside. It is probably less funny if you maintain the component.

But there is a serious discussion here.

Public disclosure of powerful primitives is messy. It helps defenders understand real risk. It also gives attackers a starting point. Previous Nightmare-Eclipse tooling reportedly moved into real intrusion activity, which means this is not just academic drama anymore.

My view is balanced:

Security people love to debate disclosure ethics forever. Meanwhile attackers just compile the code.

So defenders need to move with the reality we have, not the ideal process we wish existed.

What Microsoft Should Probably Look At

From a design perspective, these bugs point toward a few areas Microsoft should review deeply:

For YellowKey

For GreenPlasma

The bigger fix is not just patching one path. The bigger fix is removing unsafe assumptions around named objects, recovery components, and privileged service trust.

Because “standard users cannot write there” is not a security model if the path can be redirected by someone with enough creativity and too much free time.

Wrapping Up

GreenPlasma and YellowKey are good examples of why Windows security research remains fascinating, painful, and occasionally hilarious in the way only legacy platforms can be.

YellowKey targets the recovery side of BitLocker’s threat model. If valid as described, it is serious because BitLocker exists specifically to protect data when physical access is lost.

GreenPlasma targets a more subtle Windows internals boundary involving CTFMON, object manager symbolic links, and section object creation. It may not be a complete SYSTEM shell drop as released, but the primitive is still powerful because privileged Windows components often trust object namespace paths too much.

The key lessons:

  1. Physical access still matters — BitLocker is important, but recovery paths must be part of the threat model.
  2. Local privilege escalation is not “low impact” — it is often the bridge between initial access and full compromise.
  3. Windows object namespace abuse remains underrated — names, links, handles, and sections are security boundaries when privileged services trust them.
  4. Trusted components are dangerous when confused — the attacker does not need to be privileged if they can make a privileged process act for them.
  5. Public PoCs move fast — defenders should hunt early instead of waiting for a perfect advisory.

Nightmare-Eclipse keeps releasing the kind of research that makes Windows look less like an operating system and more like a historical archive of trust decisions stacked on top of each other until someone names a bug after a color.

And honestly, that is why this field never gets boring.

Stay curious, keep learning, and remember: in Windows, the weirdest path is usually the one with SYSTEM privileges.

Happy hacking ethically, and please do not test this on random laptops because “I read a blog” is not a legal defense.

— Het Mehta

Sources and references:

Disclaimer: This article is for educational and defensive awareness purposes only. Do not test these techniques on systems you do not own or do not have explicit written permission to test. Unauthorized access to computer systems and bypassing device encryption can be illegal.

Suggest Changes
Share this post on:
Share this post via WhatsApp Share this post on Facebook Share this post on X Share this post via Telegram Share this post on Pinterest Share this post via email
Next Post
Breaking Down CVE-2026-25049: How TypeScript Types Failed n8n's Security