Hintergrund und Einordnung
GreenPlasma ist ein am 12. Mai 2026 veröffentlichter Proof-of-Concept des Forschers Nightmare-Eclipse (GitHub: Nightmare-Eclipse/GreenPlasma). Der PoC demonstriert eine Privilege Escalation unter Windows 11, Windows Server 2022 und Windows Server 2026 durch die Kombination zweier Techniken: einer Object-Manager-Symlink-Platzierung auf einem CTF-Session-Objekt und einer anschließenden Registry-Link-Abuse über die CloudFiles-Richtlinienstruktur.
Nightmare-Eclipse hat den PoC ausdrücklich als CTF-Challenge veröffentlicht – der Code enthält nicht die vollständige Angriffskette. Der Forscher schreibt: „I stripped off the necessary code for a full SYSTEM shell. This is a huge challenge for CTF lovers out there.“ Die vorliegende Analyse beschreibt ausschließlich, was im veröffentlichten Quellcode und in kontrollierten Labortests beobachtbar ist.
GreenPlasma ist Teil einer Serie ungepatchter Windows-Schwachstellen desselben Forschers (BlueHammer, RedSun, UnDefend, YellowKey). Microsoft hat zum Zeitpunkt dieser Analyse keinen Patch veröffentlicht. Externe Berichte vom 12./13. Mai 2026 (Born City, Het Mehta) ordnen GreenPlasma einheitlich als „CTFMON Arbitrary Section Creation Elevation of Privileges“ ein – benannt nach dem Windows Text Services Framework (CTF), dessen Session-Objekte als Angriffsfläche dienen.
Die konzeptionellen Wurzeln liegen in der CTF-Protokoll-Forschung von James Forshaw (Google Project Zero, 2019), der dokumentierte, dass das CTF-Protokoll keine Absenderauthentifizierung enthält und verschiedene Privilege-Escalation-Pfade ermöglicht. GreenPlasma nutzt dieselbe Angriffsfläche, verwendet jedoch einen anderen Exploit-Primitiv (Section-Interception statt ALPC-Protokollmanipulation) – dazu mehr in Abschnitt 4.
CTF-Subsystem und Winlogon-Desktop
ctfmon.exe koordiniert das Text Services Framework (TSF) – IMEs, Spracherkennung, Barrierefreiheitsdienste – und läuft in einer Standard-Windows-Desktop-Sitzung im Sicherheitskontext des angemeldeten Benutzers, nicht als SYSTEM. Diese Unterscheidung ist für das Verständnis des Angriffs entscheidend.
Der Winlogon-Desktop (Anmeldebildschirm, UAC-Prompt, Sperrbildschirm) betreibt eine eigene CTF-Server-Instanz im SYSTEM-Kontext. Prozesse wie consent.exe und LogonUI.exe laufen auf diesem Desktop als SYSTEM; gemäß Forshaws CTF-Forschung (2019) sind Winlogon-Desktop-Prozesse mit der CTF-Infrastruktur verknüpft. GreenPlasma erzwingt einen Wechsel auf den Winlogon-Desktop (via conhost.exe runas), um genau diesen SYSTEM-Kontext zu erreichen. Der PoC-Quellcode macht das explizit: er schlägt mit der Meldung „Either ctfmon is running as SYSTEM or an instance of the PoC is already running“ fehl, wenn die Voraussetzungen nicht erfüllt sind.
Das Zielobjekt ist ein benanntes Section-Objekt im Windows Object Manager:
\Sessions\<N>\BaseNamedObjects\CTF.AsmListCache.FMPWinlogon<N>
Dieses Objekt wird beim Wechsel auf den Winlogon-Desktop von einer Winlogon-Desktop-Kontext-Komponente angelegt. Wenn vorab ein Symlink an dieser Position platziert wurde, deuten die Lab-Beobachtungen darauf hin, dass die Section über diesen Symlink auf das angegebene Ziel umgeleitet wird – dies entspricht dem öffentlich beschriebenen Konzept von Arbitrary Section Creation.
Angriffsmechanismus Schritt für Schritt
Der folgende Ablauf ist direkt aus dem veröffentlichten Quellcode (GreenPlasma.cpp) abgeleitet. Alle genannten API-Aufrufe sind im Code nachweisbar.
Angriffskette (aus Quellcode abgeleitet)
- 1
Session-Check
ProcessIdToSessionId() prüft, ob der Angreifer in Session ≥ 1 läuft. Session 0 (Dienst-Kontext) wird explizit abgelehnt ("Seriously...?"). Voraussetzung: interaktive Desktop-Sitzung.
- 2
Object-Manager-Symlink platzieren
NtCreateSymbolicLinkObject() legt einen Symlink unter \Sessions\<N>\BaseNamedObjects\CTF.AsmListCache.FMPWinlogon<N> an. Schlägt dieser Schritt fehl (Namenskonflikt), ist ctfmon bereits aktiv – der Angriff kann erst nach einem ctfmon-Neustart erneut versucht werden.
- 3
Winlogon-Desktop aktivieren
ShellExecuteEx() startet C:\Windows\System32\conhost.exe mit dem Verb "runas". Dies erzwingt einen UAC-Prompt auf dem Winlogon-Desktop. Nach Lab-Beobachtung legt dort eine SYSTEM-Kontext-Komponente das CTF.AsmListCache-Section-Objekt an; die beobachteten Artefakte deuten darauf hin, dass die Section dabei über den vorplatzierten Symlink umgeleitet wird.
- 4
Section-Handle abgreifen
NtOpenSection() wird in einer Polling-Schleife aufgerufen, bis ein Handle auf das Section-Objekt am Symlink-Ziel erhalten wird – ein Indikator für eine erfolgreiche Interception des SYSTEM-seitig erstellten Objekts.
- 5
SetPolicyVal() – Registry-Manipulation
CfAbortOperation() (cldapi.dll, CloudFilter API) wird aufgerufen, um laufende Cloud-Filter-Callbacks zu unterbrechen. Danach: TreeSetNamedSecurityInfo() setzt die DACL von HKCU\...\CloudFiles auf Everyone:GENERIC_ALL. BlockedApps-Key wird gelöscht und als volatiles REG_LINK (undokumentierter Windows-Registry-Symlink-Typ) neu erstellt, das auf ...\Policies\System zeigt. TreeSetNamedSecurityInfo() setzt auch die DACL von Policies\System auf Everyone:GENERIC_ALL. DisableLockWorkstation=1 wird geschrieben.
- 6
Desktop-Wechsel
OpenInputDesktop() wird gepollt; sobald der Desktop wechselt, ruft der PoC LockWorkStation() auf. Im veröffentlichten gestrippten Code endet die Kette hier – der Handle wird ausgegeben und nach Tastendruck werden Symlink und Registry bereinigt.
Die Schritte 1–4 (Section-Interception) und der Registry-Manipulationsblock (Schritt 5) sind im veröffentlichten Code vollständig. Was fehlt, ist die Nutzung des Section-Handles für tatsächliche Codeausführung als SYSTEM. Dieser Teil wurde bewusst entfernt. Der PoC demonstriert die Voraussetzungen und Indikatoren, nicht die vollständige Ausnutzung.
Abgrenzung: Forshaw 2019 vs. GreenPlasma
Beide Angriffe nutzen das CTF-Subsystem – ihre Exploit-Primitive sind jedoch grundlegend verschieden. Diese Unterscheidung ist für eine korrekte Einordnung und eine zielgerichtete Erkennung entscheidend.
| Merkmal | Forshaw 2019 (ctftool) | GreenPlasma 2026 |
|---|---|---|
| Exploit-Primitiv | ALPC-Protokollmanipulation (MSG_CALLSTUB, Pointer-Marshaling) | Object-Manager-Symlink + Registry-Link-Abuse |
| ALPC-Port genutzt? | Ja – msctf.server<Desktop><Session> | Der veröffentlichte PoC enthält keine direkten ALPC-Aufrufe |
| Zielobjekt | CTF-ALPC-Port (Nachrichteninjektion) | CTF.AsmListCache.FMPWinlogon<N> (Section-Interception) |
| ctfmon.exe Rolle | Direkte Manipulation über ALPC | Indirekt – Winlogon-Desktop-Kontext-Prozess (SYSTEM) ist Ziel |
| Registry-Manipulation | Nicht Teil des Angriffs | Kernbestandteil (CloudFiles DACL, BlockedApps REG_LINK) |
| Betroffene Windows-Versionen | Windows 10 1903 (EDB-ID 47258, gepatcht) | Windows 11, Server 2022, Server 2026 (ungepatcht, Stand Mai 2026) |
Sowohl Forshaw (2019) als auch GreenPlasma verwenden LockWorkStation() bzw. einen erzwungenen Winlogon-Desktop-Wechsel als Auslöser, um SYSTEM-Kontext-Prozesse zu aktivieren. Dieser Schritt ist erkennungstechnisch relevant: eine ungewöhnliche Aktivierung des Winlogon-Desktops aus einem nicht-privilegierten Prozesskontext heraus ist ein potentielles Indiz.
Empirische Laborbeobachtungen
Die folgenden Beobachtungen stammen aus einer kontrollierten Testumgebung (Windows 11, Sysmon 15, interaktive Desktop-Sitzung). Alle Einträge beziehen sich direkt auf beobachtbare Artefakte des veröffentlichten PoC-Codes.
| Beobachtung | Ergebnis | Bedeutung |
|---|---|---|
| NtCreateSymbolicLinkObject auf CTF.AsmListCache | OK (Session ≥ 1, ctfmon noch nicht gestartet) | Race-Condition gewonnen – Symlink platziert |
| NtCreateSymbolicLinkObject auf CTF.AsmListCache | Fehler (Name Collision) | Race verloren – ctfmon läuft bereits; Neustart nötig |
| NtOpenSection – Polling-Schleife | Handle nach UAC-Prompt erhalten | Artefakte deuten darauf hin, dass ein SYSTEM-Kontext-Prozess die Section über den Symlink erstellt hat |
| cldapi.dll Ladevorgang | Bestätigt (CfAbortOperation-Aufruf) | CloudFilter-API als Voraussetzung für Registry-Manipulation |
| HKCU\...\CloudFiles\BlockedApps als REG_LINK | Bestätigt (volatile Registry-Symlink) | In bisherigen Tests stärkstes GreenPlasma-spezifisches IOC |
| SymbolicLinkValue → ...\Policies\System | Bestätigt | Umleitung auf Policies\System-Key |
| DisableLockWorkstation = 1 | Bestätigt (SetPolicyVal Phase) | Teil der Angriffskette; allein sehr hohe False-Positive-Rate |
| wmiprvse.exe ProcessAccess (0x1400) | mehrfach (Baseline) | WMI-Lesezugriff – kein Angriffssignal; GrantedAccess=0x1400 ausschließen |
Der PoC setzt DisableLockWorkstation=1 explizit in SetPolicyVal(). Dieser Wert wird jedoch auch von Kiosk-Software, GPO-Rollouts, IT-Management-Tools und anderen legitimen Anwendungen gesetzt. Als Standalone-IOC ist er zu laut für den Produktiveinsatz. Wertvoll ist er ausschließlich in Kombination mit den Registry-Link-IOCs (BlockedApps REG_LINK + SymbolicLinkValue).
Gegenmaßnahmen und ihre Einschränkungen
Da GreenPlasma eine laufende interaktive Sitzung und den Winlogon-Desktop-Wechsel voraussetzt, gibt es keine einzelne Maßnahme, die den Angriff vollständig ohne Nebenwirkungen blockiert.
IFEO – ctfmon.exe-Start blockieren
Debugger-Eintrag in HKLM\...\Image File Execution Options\ctfmon.exe verhindert den Start – in unserem Labor bestätigt. Seiteneffekt: IME, Spracherkennung, On-Screen-Keyboard und Barrierefreiheitsdienste sind dauerhaft deaktiviert. Für Systeme mit nicht-lateinischen Zeichensätzen oder Barrierefreiheitsanforderungen nicht geeignet.
MsCtfMonitor-Dienst deaktivieren
MsCtfMonitor ist ein Watchdog-Dienst, der ctfmon.exe neustartet. Das alleinige Deaktivieren hat in unserem Labor keinen Effekt gezeigt, solange Winlogon aktiv ist. Keine wirksame Gegenmaßnahme für sich allein.
GPO: Drittanbieter-TSF einschränken
Über Gruppenrichtlinien können Text-Service-Provider von Drittanbietern eingeschränkt werden. Reduziert gemäß Windows-TSF-Dokumentation die Angriffsfläche; eine vollständige Laborvalidierung steht aus. Seiteneffekt: Spezialisierte IMEs und Eingabehilfen können deaktiviert werden.
Fokus auf Erkennung
Da keine präventive Maßnahme ohne Nebenwirkungen auskommt, empfehlen wir einen erkennungs-zentrierten Ansatz: Die Registry-basierten IOCs (BlockedApps REG_LINK, SymbolicLinkValue) zeigten in bisherigen Tests ein günstiges Signal-Rausch-Verhältnis und sind ohne Systemeinschränkungen einsetzbar.
Erkennungsregeln für Sysmon und Wazuh
Die Erkennungsregeln sind nach Spezifität in zwei Kategorien gegliedert: GreenPlasma-spezifische IOCs (aus dem veröffentlichten Quellcode direkt abgeleitet) und Klassen-IOCs für den breiteren CTF-Angriffspfad (Forshaw-Technik und Varianten).
| Sysmon Event | EventID | Wazuh | Level | Beschreibung |
|---|---|---|---|---|
| RegistryEvent (BlockedApps CREATE) | 12 | 100100 | 15 | GreenPlasma-spezifisch: HKCU\...\CloudFiles\BlockedApps erstellt (volatiler REG_LINK) |
| RegistryEvent (SymbolicLinkValue SET) | 13 | 100101 | 14 | GreenPlasma-spezifisch: SymbolicLinkValue unter CloudFiles\BlockedApps gesetzt |
| RegistryEvent (BlockedApps DELETE) | 12 | 100102 | 12 | GreenPlasma-spezifisch: BlockedApps-Key gelöscht (Cleanup-Phase) |
| ImageLoad cldapi.dll | 7 | 100103 | 10 | GreenPlasma-spezifisch: CfAbortOperation-Aufruf – ungewöhnlicher cldapi.dll-Ladevorgang |
| RegistryEvent (DisableLockWorkstation) | 13 | 100104 | 8 | Kombinations-IOC: allein zu laut; nur in Verbindung mit 100100/100101 verwertbar |
| ProcessCreate (ctfmon-Kind) | 1 | 100110 | 12 | CTFMON-Anomalie: Kindprozess von ctfmon.exe – in bisherigen Standard-Baselines nicht beobachtet; organisationsspezifisch zu validieren |
| ProcessAccess ctfmon (Zugriffsrechte) | 10 | 100109 | 12 | CTFMON-Anomalie: Handle mit prozessmanipulationsrelevanten Zugriffsrechten (PROCESS_VM_WRITE / PROCESS_CREATE_THREAD) auf ctfmon.exe |
| CreateRemoteThread in ctfmon | 8 | 100108 | 12 | CTFMON-Injection-Heuristik: CreateRemoteThread in ctfmon.exe – nicht GreenPlasma-spezifisch; relevant für verwandte Prozessmanipulationsszenarien |
<!-- PRIMÄRES IOC: BlockedApps als volatiler REG_LINK erstellt -->
<RuleGroup name="" groupRelation="or">
<RegistryEvent onmatch="include">
<Rule name="GP_BlockedApps_create" groupRelation="and">
<TargetObject condition="contains">CloudFiles\BlockedApps</TargetObject>
<EventType condition="is">CreateKey</EventType>
</Rule>
</RegistryEvent>
</RuleGroup>
<!-- SEKUNDÄRES IOC: SymbolicLinkValue unter CloudFiles\BlockedApps gesetzt -->
<!-- Sysmon EID 13: Wertname erscheint im TargetObject-Feld (Vollpfad), nicht im Details-Feld -->
<RuleGroup name="" groupRelation="or">
<RegistryEvent onmatch="include">
<Rule name="GP_SymbolicLinkValue" groupRelation="and">
<TargetObject condition="contains">CloudFiles\BlockedApps</TargetObject>
<TargetObject condition="contains">SymbolicLinkValue</TargetObject>
</Rule>
</RegistryEvent>
</RuleGroup>
<!-- cldapi.dll-Last durch unübliche Prozesse (CfAbortOperation-Aufruf) -->
<RuleGroup name="" groupRelation="or">
<ImageLoad onmatch="include">
<Rule name="GP_cldapi_unusual" groupRelation="and">
<ImageLoaded condition="end with">cldapi.dll</ImageLoaded>
<Image condition="does not contain">OneDrive</Image>
<Image condition="does not contain">svchost</Image>
<Image condition="does not contain">FileCoAuth</Image>
</Rule>
</ImageLoad>
</RuleGroup>
<!-- Rauschunterdrückung: WMI-Lesezugriff und AV aus ProcessAccess-Monitoring ausschließen -->
<!-- Für ctfmon.exe-Überwachung: separate ProcessAccess-Include-Regel erforderlich (s. Deployment-Hinweise) -->
<RuleGroup name="" groupRelation="or">
<ProcessAccess onmatch="exclude">
<Rule name="FP_wmi_readonly" groupRelation="and">
<SourceImage condition="end with">wmiprvse.exe</SourceImage>
<GrantedAccess condition="is">0x1400</GrantedAccess>
</Rule>
<SourceImage condition="end with">MsMpEng.exe</SourceImage>
</ProcessAccess>
</RuleGroup><!-- 100100: BlockedApps-Key als REG_LINK erstellt (Level 15 = Kritisch) --> <rule id="100100" level="15"> <if_group>windows</if_group> <field name="win.system.eventID">^12$</field> <field name="win.system.providerName">Microsoft-Windows-Sysmon</field> <field name="win.eventdata.targetObject" type="pcre2">(?i)CloudFiles\\BlockedApps$</field> <field name="win.eventdata.eventType">CreateKey</field> <description>GreenPlasma: CloudFiles\BlockedApps als volatiler Registry-Link erstellt</description> <mitre><id>T1112</id><id>T1548</id></mitre> </rule> <!-- 100101: SymbolicLinkValue unter CloudFilesBlockedApps gesetzt (Level 14) --> <!-- Sysmon EID 13: Wertname im targetObject-Feld (Vollpfad inkl. Wertname) --> <rule id="100101" level="14"> <if_group>windows</if_group> <field name="win.system.eventID">^13$</field> <field name="win.system.providerName">Microsoft-Windows-Sysmon</field> <field name="win.eventdata.targetObject" type="pcre2">(?i)CloudFiles\\BlockedApps.*SymbolicLinkValue</field> <description>GreenPlasma: Registry-Symlink (SymbolicLinkValue) unter CloudFiles\BlockedApps gesetzt</description> <mitre><id>T1112</id></mitre> </rule> <!-- 100105: Korrelation BlockedApps-Create + SymbolicLinkValue (300s) --> <rule id="100105" level="15" timeframe="300"> <if_matched_sid>100100</if_matched_sid> <same_field>win.system.computer</same_field> <field name="win.system.eventID">^13$</field> <field name="win.eventdata.targetObject" type="pcre2">(?i)CloudFiles\\BlockedApps.*SymbolicLinkValue</field> <description>GreenPlasma: BlockedApps REG_LINK gefolgt von SymbolicLinkValue-Set – vollständige Registry-Kette</description> </rule> <!-- 100109: ProcessAccess mit Injektions-Bits auf ctfmon.exe; wmiprvse (0x1400) ausgeschlossen --> <rule id="100109" level="12"> <if_group>windows</if_group> <field name="win.system.eventID">^10$</field> <field name="win.system.providerName">Microsoft-Windows-Sysmon</field> <field name="win.eventdata.targetImage" type="pcre2">(?i)\\ctfmon\.exe$</field> <field name="win.eventdata.grantedAccess" type="pcre2" negate="yes">^0x(1400|1000|0400|1410)$</field> <description>CTF-Klasse: Injektions-relevanter Handle auf ctfmon.exe</description> <mitre><id>T1055</id></mitre> </rule> <!-- 100110: ctfmon.exe Kindprozess (CTFMON-Anomalie, Level 12) – generische Heuristik, organisationsspezifisch validieren --> <rule id="100110" level="12"> <if_group>windows</if_group> <field name="win.system.eventID">^1$</field> <field name="win.system.providerName">Microsoft-Windows-Sysmon</field> <field name="win.eventdata.parentImage" type="pcre2">(?i)\\ctfmon\.exe$</field> <description>CTF-Klasse: ctfmon.exe spawnt Kindprozess (in Standard-Baselines nicht beobachtet)</description> <mitre><id>T1055</id></mitre> </rule>
- Sysmon: Schemaversion 4.90+, separate RuleGroup für Include und Exclude je Ereignistyp
- Wazuh: Regeln 100100–100110 in
custom_rules.xml, Agent neu starten - Erkennungsregeln erfordern eine interaktive Desktop-Sitzung (Session ≥ 1) – ctfmon.exe läuft nicht in Service-Kontexten (Session 0)
- ProcessAccess-Überwachung (100109) erfordert eine separate ProcessAccess-Include-Regel für ctfmon.exe in der Sysmon-Konfiguration; das dargestellte Exclude-Regelwerk allein reicht nicht
- Vor Produktiveinsatz: Baseline für cldapi.dll-Ladezeiten erstellen; OneDrive/FileCoAuth sind legitime Loader
- DisableLockWorkstation (100104) nur als Korrelationssignal nutzen, nicht als Standalone-Alert
- Sysmon Event ID 8 (CreateRemoteThread / Regel 100108) ist in vielen Produktivumgebungen aus Performance-Gründen deaktiviert – als optionale Ergänzung betrachten
Fazit
GreenPlasma demonstriert, wie ein scheinbar peripherer Windows-Mechanismus – das CTF Session-Objekt im Object Manager – als Pivot für eine Privilege Escalation dienen kann. Der eigentliche Exploit-Primitiv ist nicht die ALPC-Protokollmanipulation (Forshaw 2019), sondern eine Object-Manager-Symlink-Platzierung vor dem Winlogon-Desktop-Wechsel, kombiniert mit einer Registry-Link-Abuse über die CloudFiles-Richtlinienstruktur.
Wichtig für die Einordnung: ctfmon.exe selbst läuft als normaler Benutzer. Die SYSTEM-Rechte entstehen durch die Interaktion mit Winlogon-Desktop-Kontext-Prozessen, die beim UAC-Prompt aktiviert werden. Der veröffentlichte PoC ist bewusst unvollständig – die tatsächliche Codeausführung als SYSTEM ist nicht enthalten.
Erkennungsseitig zeigen die Registry-basierten IOCs (BlockedApps REG_LINK, SymbolicLinkValue) den besten Signal-Rausch-Abstand: Sie zeigten in bisherigen Lab- und Standardumgebungstests ein sehr günstiges Signal-Rausch-Verhältnis und sollten vor dem Produktiveinsatz gegen die jeweilige Umgebung validiert werden. Die vorgestellten Sysmon- und Wazuh-Regeln wurden im Labor iterativ auf offensichtliche Falsch-Positive geprüft und können als Ausgangspunkt für eigene Detection-Engineering-Pipelines dienen.