TL;DR

GreenPlasma (SB2026051378) is an unpatched Windows privilege escalation that chains a ctfmon.exe section creation bug with registry symlink hijacking and DACL relaxation to go from standard user → SYSTEM with zero interaction. No CVE assigned yet. No patch available.

  • Affected: Windows 11, Windows Server 2022/2026
  • Not affected: Windows 10 (different ctfmon implementation)
  • Requires: Standard user, interactive session
  • Impact: Full SYSTEM shell
  • Researcher: Chaotic Eclipse / Nightmare-Eclipse
  • Public PoC: github.com/Nightmare-Eclipse/GreenPlasma

The Context: Chaotic Eclipse’s Disclosure Campaign

This is the fifth zero-day from the researcher Chaotic Eclipse (aka Nightmare-Eclipse), who has been publicly releasing Windows vulnerabilities after disputes with Microsoft’s MSRC over bug bounty responses.

#NameDateTargetPatched?
1BlueHammerApr 3, 2026Windows Defender LPE✅ CVE-2026-33825
2RedSunApr 17, 2026Defender Admin EoP✅ Patched
3UnDefendApr 2026Defender DoS❌
4YellowKeyMay 12, 2026BitLocker bypass❌
5GreenPlasmaMay 12, 2026CTFMON EoP❌

The researcher stated in a PGP-signed disclosure:

“Microsoft has chosen to make this worse instead of resolving the situation like adults, they pulled every childish game possible. My patience is running out… The fire will go as long as you want, unless you extinguish it or until there’s nothing left to burn.”

They’ve also threatened a “big surprise” for the next Patch Tuesday.


How It Works: The 7-Stage Chain

GreenPlasma is not a single vulnerability — it’s a chain of logical flaws that compound into full SYSTEM code execution:

The exploit creates an NT Object Manager symbolic link at the path where ctfmon.exe will later create its CTF.AsmListCache section object:

\Sessions\{SessionID}\BaseNamedObjects\CTF.AsmListCache.FMPWinlogon{SessionID}
    → \BaseNamedObjects\CTFMON_DEAD

The bug: ctfmon.exe does not check for existing symbolic links before calling NtCreateSection. The Object Manager follows the symlink, and the section is created at the attacker’s chosen path — with SYSTEM-level trust.

Stage 2: Trigger ctfmon Elevation

CfAbortOperation() from cldapi.dll (Cloud Files API) forces ctfmon to restart in an elevated SYSTEM context. A secondary trigger launches conhost.exe with runas to ensure elevation.

Stage 3: Acquire SYSTEM Section Handle

The exploit polls NtOpenSection() until ctfmon creates the section at the symlink target. Once found, the attacker holds a MAXIMUM_ALLOWED handle to a section object created by SYSTEM — readable and writable from the standard user process.

RegCreateKeyEx(HKEY_CURRENT_USER,
    L"Software\\Policies\\Microsoft\\CloudFiles\\BlockedApps",
    REG_OPTION_CREATE_LINK | REG_OPTION_VOLATILE, ...);
// Points to:
\REGISTRY\USER\{SID}\Software\Microsoft\Windows\CurrentVersion\Policies\System

This creates a volatile registry symbolic link that redirects Cloud Files policy reads to the Policies\System key — which controls lock screen behavior.

Stage 5: DACL Relaxation

TreeSetNamedSecurityInfo() grants Everyone: GENERIC_ALL on both the CloudFiles key and the Policies\System key (via the symlink). This ensures any process can write to these keys, even low-integrity ones.

Stage 6: DisableLockWorkstation

Setting DisableLockWorkstation = 1 in the hijacked Policies\System key prevents the lock screen, ensuring the attacker maintains interactive access. A monitoring loop watches for the desktop to become available.

Stage 7: Weaponization — SYSTEM Shell

NtMapViewOfSection() maps the SYSTEM-created section into the attacker’s process with read-write access. Payload data (DLL path, COM object reference, or function pointer table) is written to the section. When a SYSTEM service reads the section data, it trusts it implicitly — because it was “created by ctfmon.”


Why Windows 10 Is Not Affected

Windows 10’s ctfmon uses a different section creation path. The CTF.AsmListCache.FMPWinlogon{SID} naming convention and the specific restart behavior triggered by CfAbortOperation are Windows 11+ features. On Windows 10, Stage 3 simply times out because ctfmon never creates the section at the expected path.


The Root Cause

Two missing validations:

  1. ctfmon.exe doesn’t validate symlinks before NtCreateSection — the Object Manager follows attacker-controlled redirects
  2. Cloud Files policy engine follows registry symlinks without validation — enabling cross-key policy hijacking

The fix: ctfmon should verify the target path is not a symbolic link before creating section objects. The Cloud Files engine should not follow REG_OPTION_CREATE_LINK registry entries.


Detection

The PoC repo includes Sigma rules:

RuleDetects
GreenPlasma Registry SymlinkCloudFiles\BlockedApps\SymbolicLinkValue modification
GreenPlasma Policy HijackDisableLockWorkstation = 1 in HKCU Policies\System
GreenPlasma Object SymlinkCTF.AsmListCache symlink in Object Manager namespace

Sysmon key events:

  • Event ID 12: Registry create with REG_OPTION_CREATE_LINK on CloudFiles\BlockedApps
  • Event ID 13: DisableLockWorkstation = 1 value set
  • Event ID 4656: NtCreateSymbolicLinkObject handle request

IOCs

  • NtCreateSymbolicLinkObject targeting CTF.AsmListCache paths
  • TreeSetNamedSecurityInfo granting Everyone: GENERIC_ALL on CloudFiles/Policies keys
  • Volatile CloudFiles\BlockedApps key with REG_OPTION_CREATE_LINK
  • CfAbortOperation calls from non-Cloud Files processes
  • Section handles at \BaseNamedObjects\CTFMON_DEAD opened by standard user processes

Mitigation (Before Patch)

  1. Deploy Sigma rules from the repo’s detection/ directory
  2. Monitor registry operations for REG_OPTION_CREATE_LINK on CloudFiles paths
  3. Audit CfAbortOperation calls from unexpected processes
  4. Restrict NtCreateSymbolicLinkObject via process allowlisting (SeCreateSymbolicLinkPrivilege)
  5. Consider disabling cldapi.dll in restricted environments

Build & Test

:: Build the exploit (PoC)
cl /EHsc /DUNICODE /D_UNICODE /std:c++17 /Fe:GreenPlasma.exe PoC.cpp /link ntdll.lib advapi32.lib user32.lib shell32.lib

:: Build the payload DLL (for section hijack weaponization)
cl /EHsc /DUNICODE /D_UNICODE /LD /Fe:greenplasma_payload.dll payload.cpp /link advapi32.lib shell32.lib

:: Build the payload EXE (standalone testing only)
cl /EHsc /DUNICODE /D_UNICODE /DSTANDALONE_EXE /Fe:greenplasma_payload.exe payload.cpp /link advapi32.lib shell32.lib

Important: The payload EXE requires SYSTEM privileges. Running it as a standard user will simply report all techniques failed. The PoC must run as a true standard user (not admin) in an interactive session.

Expected behavior on patched systems: Stage 3 times out because ctfmon validates symlinks before section creation.


References


Tracked in [[SB2026051378 - GreenPlasma (CTFMON EoP)]] • See [[CVE Database]] for full vulnerability tracking