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.
| # | Name | Date | Target | Patched? |
|---|---|---|---|---|
| 1 | BlueHammer | Apr 3, 2026 | Windows Defender LPE | ✅ CVE-2026-33825 |
| 2 | RedSun | Apr 17, 2026 | Defender Admin EoP | ✅ Patched |
| 3 | UnDefend | Apr 2026 | Defender DoS | ❌ |
| 4 | YellowKey | May 12, 2026 | BitLocker bypass | ❌ |
| 5 | GreenPlasma | May 12, 2026 | CTFMON 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:
Stage 1: Object Manager Symlink
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.
Stage 4: Registry Symlink Hijack
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:
- ctfmon.exe doesn’t validate symlinks before
NtCreateSection— the Object Manager follows attacker-controlled redirects - 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:
| Rule | Detects |
|---|---|
| GreenPlasma Registry Symlink | CloudFiles\BlockedApps\SymbolicLinkValue modification |
| GreenPlasma Policy Hijack | DisableLockWorkstation = 1 in HKCU Policies\System |
| GreenPlasma Object Symlink | CTF.AsmListCache symlink in Object Manager namespace |
Sysmon key events:
- Event ID 12: Registry create with
REG_OPTION_CREATE_LINKonCloudFiles\BlockedApps - Event ID 13:
DisableLockWorkstation = 1value set - Event ID 4656:
NtCreateSymbolicLinkObjecthandle request
IOCs
NtCreateSymbolicLinkObjecttargetingCTF.AsmListCachepathsTreeSetNamedSecurityInfograntingEveryone: GENERIC_ALLon CloudFiles/Policies keys- Volatile
CloudFiles\BlockedAppskey withREG_OPTION_CREATE_LINK CfAbortOperationcalls from non-Cloud Files processes- Section handles at
\BaseNamedObjects\CTFMON_DEADopened by standard user processes
Mitigation (Before Patch)
- Deploy Sigma rules from the repo’s
detection/directory - Monitor registry operations for
REG_OPTION_CREATE_LINKon CloudFiles paths - Audit
CfAbortOperationcalls from unexpected processes - Restrict
NtCreateSymbolicLinkObjectvia process allowlisting (SeCreateSymbolicLinkPrivilege) - 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
- GreenPlasma GitHub (original)
- SB2026051378 — Cybersecurity Help
- Born’s IT Blog (DE)
- The Register — English coverage
- Chaotic Eclipse’s PGP-signed disclosure
- taviso/ctftool — Related CTF exploration research
- ANALYSIS.md — Stage-by-stage technical breakdown
Tracked in [[SB2026051378 - GreenPlasma (CTFMON EoP)]] • See [[CVE Database]] for full vulnerability tracking
