Ein öffentlich verfügbarer Windows-Exploit kann einem lokalen Standardbenutzer SYSTEM-Rechte verschaffen. Das Sicherheitsteam Howler Cell von Cyderes hat den unter dem Namen SignDrop veröffentlichten Proof of Concept reproduziert. Die Angriffskette nutzt ausgerechnet eine Schutzfunktion des Common Log File System: Beim Anlegen einer Authentifizierungsdatei können privilegierte Prozesse eine Datei erzeugen, die einem unprivilegierten Benutzer Schreibzugriff erlaubt.
Das Repository wurde am 10. November 2026 unter dem Handle MSNightmare veröffentlicht. Für die Risikobewertung ist die lokale Voraussetzung entscheidend: SignDrop ist kein belegter Weg, einen Windows-Rechner unmittelbar aus dem Internet zu übernehmen. Wer bereits Code mit eingeschränkten Benutzerrechten ausführen kann, erhält damit jedoch einen möglichen nächsten Schritt zur weitreichenden Kontrolle über das System.
Die Schutzdatei übernimmt die falschen Zugriffsrechte
Das Common Log File System, kurz CLFS, ist eine Windows-Komponente für Protokolldaten. Sein Kernel-Treiber clfs.sys verarbeitet Logdateien und war wiederholt von Schwachstellen zur Rechteausweitung betroffen. Microsoft führte deshalb eine Authentifizierung der Logdateien mit HMAC-basierten Prüfwerten ein. Die hier betroffene Härtung wurde am 28. Oktober 2025 im offiziellen Release-Kanal ausgerollt.
SignDrop setzt an der zugehörigen Datei mit der Endung .cnpf an. Öffnet ein Prozess eine CLFS-Logdatei, kann der Treiber diese Authentifizierungsdatei im Sicherheitskontext des aufrufenden Prozesses anlegen. Dabei übernimmt er aber die Discretionary Access Control List der ursprünglichen Datei – also jene Berechtigungen, die festlegen, wer darauf zugreifen darf.
Das wird gefährlich, wenn ein Standardbenutzer zunächst eine Logdatei vorbereitet und später ein privilegierter Prozess diese öffnet. Die neu erzeugte Datei gehört dann SYSTEM, bleibt aufgrund der übernommenen Zugriffsrechte aber für den Standardbenutzer beschreibbar. Laut der technischen Beschreibung prüft CLFS die Berechtigungen beim ursprünglichen Zugriff korrekt. Die Sicherheitsgrenze bricht erst beim späteren Öffnen durch den höher privilegierten Prozess. Der Forscher beschreibt damit einen Logikfehler in der Härtung, keinen Speicherkorruptionsfehler. (MSNightmare/SignDrop – Proof-of-Concept-Repository und technische Beschreibung (GitHub))
Defender wird Teil der Angriffskette
Im veröffentlichten PoC übernimmt Windows Defender die Rolle des privilegierten Öffners. Über eine Funktion zur Aktualisierung der Antimalware-Engine und manipulierte symbolische Verknüpfungen im Windows-Objektmanager wird die Engine dazu gebracht, den vorbereiteten CLFS-Container zu öffnen. Fehlt die .cnpf-Datei, entsteht sie erneut – nun mit den Rechten des Antimalware-Prozesses.
Die von Cyderes untersuchte Kette lenkt diese Dateierstellung auf eine DLL im Verzeichnisbaum von Program Files um. Anschließend kommt DLL-Sideloading zum Einsatz: Ein Prozess lädt die dort platzierte Bibliothek und führt deren Code aus. Bei der Reproduktion erhielt das Team eine Konsole mit SYSTEM-Rechten auf dem interaktiven Desktop. Damit liegt neben der Veröffentlichung des Forschers eine dokumentierte praktische Reproduktion vor.
Für die Erkennung ist ein weiteres Detail wichtig: Die platzierte DLL wird nach der Ausführung mittels transaktierter Löschung wieder entfernt. Laut Cyderes lässt sich die Schreibspur deshalb nur über die zum Ausführungszeitpunkt erfasste Datei-, Image-Load- und Prozess-Telemetrie forensisch nachweisen. Eine spätere Suche nach der DLL allein reicht für diese Kette nicht aus. (Cyderes Howler Cell: SignDrop Zero-Day Turns Windows CLFS Defense Into Privilege Escalation)
Der Forscher behauptet darüber hinaus, die Technik könne die Selbstschutzmechanismen beliebiger Antimalware-Engines umgehen, weil die Dateierstellung aus Sicht ihrer Kernel-Treiber vom eigenen legitimen Prozess ausgehe. Diese Verallgemeinerung ist nicht durch veröffentlichte Tests mit Drittanbieter-Produkten belegt. Die konkret dokumentierte Angriffskette verwendet Defender.
Welche Systeme betroffen sein können
Nach der PoC-Dokumentation ist der Registry-Wert HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication\Mode maßgeblich. Als betroffen werden die Werte 0 für Enforcement und 1 für Learning genannt. Die Werte 2 und 3 gelten dort als nicht betroffen. Der Modus ist damit ein Anhaltspunkt für die Bestandsaufnahme, aber keine vollständige Aussage über sämtliche Windows-Versionen.
Der Forscher nennt Tests auf Windows 11 26H2, Windows 11 26H2 Experimental und Windows Server 2025 Experimental. Für ältere Versionen fehlen entsprechende Tests. Auch seine Schätzung, rund 80 Prozent der Windows-Installationen seien verwundbar, ist nicht mit veröffentlichten Daten unterlegt; Cyderes bewertet sie ausdrücklich mit geringer Konfidenz.
Hinzu kommt ein zeitlicher Faktor: Die CLFS-Authentifizierung sieht eine Adoptionsphase von 90 Tagen ab dem ersten Start mit der jeweiligen CLFS-Version vor. Danach wechselt der Treiber beim nächsten Start automatisch in den Enforcement-Modus. Für Administratoren ist daher der tatsächlich gesetzte Wert aussagekräftiger als eine Annahme darüber, in welchem Zustand sich ein Rechner seit der Installation befindet.
Schutz abschalten würde ein anderes Risiko öffnen
Die CLFS-Authentifizierung zur Abwehr von SignDrop zu deaktivieren, empfiehlt der Forscher ausdrücklich nicht. Dadurch würden ältere Angriffsmöglichkeiten über Speicherkorruptionsfehler in CLFS wieder geöffnet. Die als nicht betroffen beschriebenen Registry-Modi sind deshalb nicht als pauschale Handlungsempfehlung zu verstehen.
Microsoft erklärte gegenüber SecurityWeek, das Unternehmen untersuche die Schwachstelle aktiv. Microsoft Defender erkenne und blockiere Ausnutzungsversuche; Hinweise auf Angriffe in freier Wildbahn lägen dem Unternehmen zu diesem Zeitpunkt nicht vor. Das ist eine Herstellerangabe zum Schutzstatus, kein Nachweis für eine Behebung der zugrunde liegenden Schwachstelle.
Cyderes verzeichnete am 11. November noch keinen CVE-Eintrag und keinen Patch. Ob bis zum Ende des durch die vorliegenden Quellen abgedeckten Zeitraums am 13. November ein Update oder eine CVE-Zuweisung folgte, bleibt offen. Für Betriebsteams stehen damit zunächst die Bestandsaufnahme der CLFS-Konfiguration, die Prüfung verfügbarer Microsoft-Sicherheitsinformationen und die Auswertung vorhandener Telemetrie im Vordergrund. Bei Verdachtsfällen ist besonders relevant, ob Dateioperationen, DLL-Ladevorgänge und nachfolgende Prozesse zeitlich zusammenpassen – auch wenn die abgelegte DLL inzwischen verschwunden ist.
📂
Kategorie
Sicherheit
Datenlecks, Schwachstellen, Überwachung und Datenschutz – was du wissen solltest, bevor es zu spät ist.
