[English]Ich ziehe mal ein Sicherheitsthema rund um Windows 11 24H2 raus, was mich bereits ca. eine Woche beschäftigt. Sicherheitsforscher von Zero Solarium haben eine Möglichkeit gefunden, die Windows-Datei WerFaultSecure.exe zu missbrauchen, um einerseits LSASS-Passwörter aus dem Cache zu stehlen. Andererseits lassen sich Sicherheitsanwendungen über WerFaultSecure.exe und ein entsprechendes Tool einfrieren. Allerdings erkennt der Microsoft Defender diesen Versuch zum Einfrieren. Und der LSASS-Dump erfordert das Kopieren einer Windows 8.1 Datei auf das Windows 11-System.
EDR-Freeze mittels WerFaultSecure.exe
Erste Informationen zu einem Problem in Windows sind mir zum 21. September 2025 über nachfolgenden Tweet untergekommen.
Zero Solarium beschreibt im Artikel EDR-Freeze: A Tool That Puts EDRs And Antivirus Into A Coma State, wie man mit Windows-Bordmitteln Sicherheitssoftware (Endpoint Detection and Response, EDR, Antivirensoftware) im Betriebssystem aushebeln kann. Dazu ließe sich die Datei WerFaultSecure.exe der Windows Error Reporting-Funktion missbrauchen.
WerFaultSecure missbraucht
Auf den Sachverhalt stießen die Sicherheitsforscher von Zero Solarium bei der Entwicklung eines Tools zum Dumpen des LSA-Prozesses WSASS. Dort erhielt der Sicherheitsforscher einige Informationen über das Programm WerFaultSecure.exe.
"WerFaultSecure unterstützt die Ausführung mit PPL-Schutz auf WinTCB-Ebene", schreibt der Autor des Zero Solarium-Artikels. Das Kürzel PPL steht für Protected Process Light, eine in Windows 8.1 eingeführte Sicherheitsfunktion, um wichtige Systemprozesse vor Manipulationen oder Beendigung zu schützen. Der Mechanismus soll sensible Dienste wie Antivirenlösungen und EDR-Systeme vor unbefugten Eingriffen.
WinTCB sind eine Klasse von besonders geschützten Prozessen mit besonderen Privilegien (einige Erklärungen finden sich hier und hier). Wenn WerFaultSecure.exe also auf WinTCB-Level läuft und einen PPL-Schutz unterstützt, kann man mit dem Tool allerhand Unsinn in Windows anstellen.
Analyse der Situation durch Sicherheitsforscher
Die Leute bei Zero Solarium haben also festgestellt, dass die Funktion MiniDumpWriteDump sehr schnell ausgeführt wird, so dass Benutzer möglicherweise gar mitbekommen, dass der Zielprozess während des Schreiben des Minidumps angehalten wurde. Es stand also die Frage im Raum, wie man diesen Mechanismus ausweiten könne.
Wenn ein normaler Prozess einen neuen Prozess mit PPL-Schutz ausführen kann, lässt sich während des CreateProcess der untergeordnete PPL-Prozess mit dem Flag CREATE_SUSPENDED zwangsweise anhalten.
Die dauerhaft einzufrierenden Prozesse sind häufig EDR- und Antivirenprozesse, die aber in der Regel durch PPL (Protected Process Light) geschützt sind. Es gilt also den PPL-Schutz zu umgehen, um mit diesen Prozessen interagieren zu können.
Mit den Parametern zum Ausführen von WerFaultSecure, rückportiert aus einem früheren Projekt, lässt die Funktion MiniDumpWriteDump mit jedem gewünschten Prozess aktivieren. Und in Kombination mit dem Tool CreateProcessAsPPL lässt sich WerFaultSecure nutzen, um den PPL-Schutz zu umgehen. Wer die Funktion OpenProcess mit PROCESS_SUSPEND_RESUME-Berechtigung für PPL-Prozesse aufrufen kann, hat die Möglichkeit, diesen Prozess auch anzuhalten.
Das EDR-Freeze
Basierend auf den Erkenntnissen aus dem obigen Artikel hat ein Sicherheitsforscher EDR-Freeze geschrieben und auf GitHub veröffentlicht. Dieses Tool nutze die Software-Sicherheitslücke von WerFaultSecure aus, um die Prozesse von EDRs und Antimalware-Programmen anzuhalten, ohne die BYOVD-Angriffsmethode (Bring Your Own Vulnerable Driver) verwenden zu müssen.
EDR-Freeze hält Schutzsoftware an
EDR-Freeze arbeitet im Benutzermodus, sodass Sie keine zusätzlichen Treiber installieren müssen. Es kann auf der neuesten Version von Windows ausgeführt werden. Das Tool hält alle Antimalware-/EDR-Prozesse für einen Zeitraum von 1–3 Sekunden vorübergehend an. Wird das Tool per Script aufgerufen, könnte es die Sicherheitsprozesse auch über lange Zeiträume einfrieren.
Die Tests während der Entwicklung wurden mit der aktuellen voll gepatchten Version von Windows 11 24H2 durchgeführt. In diesem Tweet bestätigt eine weitere Partei, dass der Ansatz funktioniert.
Schutz vor diesem Angriff
Steven Lim – den ich in obigem Tweet zitiert habe, hat ein Tool DefenderXDR KQL entwickelt, um solche Angriffe durch Zuordnung der WerFaultSecure PID zu Kern-MDE-Prozessen zu erfassen.
Sicherheitsforscher Florian Roth weist in obigem Tweet darauf hin, dass erste Beispiele bei VirusTotal hochgeladen wurden. Allerdings ist die "Hütte wohl nicht am brennen". Ich hatte die Tage bereits einen Tweet gesehen, dass es bei Windows 11 Enterprise nicht funktioniere, da dort "Sicherheitsfunktionen" den Angriff verhinderten (finde diese Quelle aktuell aber nicht mehr).
Die Kollegen von Bleeping Computer hatten bei Microsoft nachgefragt und geben hier die Antwort eines Microsoft-Sprechers wieder: "Kunden, die Microsoft Defender verwenden, sind von diesem Tool nicht betroffen, und jeder Versuch wird vor der Ausführung erkannt und blockiert. Wir evaluieren und sichern Windows weiterhin gegen diese und andere potenzielle Angriffstechniken.".
Hacker nutzen WerFaultSecure für LSASS-Passwort-Dump
Dann hatte ich noch den nachfolgenden Tweet gesehen – und ein Leser hat mich ebenfalls darauf hingewiesen (danke dafür).
Cyber Security News beschreibt in diesem Artikel, wie Angreifer veraltete Versionen des Windows-Fehlerberichtsprogramm WerFaultSecure.exe missbrauchen können, um den Speicherbereich des Local Security Authority Subsystem Service (LSASS.EXE) zu extrahieren. Mit diesen Dumps lassen sich zwischengespeicherte Anmeldedaten (aus dem Cache) von vollständig gepatchten Windows 11 24H2-Systemen sammeln. Auch dieser Artikel bezieht sich auf den oben von Zero Solarium skizzierten Ansatz, WerFaultSecure.exe zu missbrauchen.
Angreifer benötigen einen unverschlüsselten Speicher-Dump
Nachdem Angreifer sich zunächst Zugang zu einem System verschafft haben, versuchen sie häufig, den LSASS-Speicher zu dumpen. Denn dort finden sich Anmeldedaten, mit denen Angreifer ggf. ihre Berechtigungen erweitern und sich lateral im Netzwerk bewegen können.
Normalerweise wird ein LSASS-Speicherdump verschlüsselt gespeichert. Daher greifen die Hacker zu einem Trick: In Windows 8.1 gab es eine Schwachstelle, durch die WerFaultSecure.exe dazu gebracht werden konnte, Crash-Dumps zu schreiben, ohne das die im Betriebssystem integrierten Verschlüsselungsroutinen angewendet wurden. In Konsequenz werden unverschlüsselte Dump-Dateien auf der Festplatte gespeichert, aus denen man die Passwörter extrahieren kann.
Windows 11 WerFaultSecure.exe unterjubeln
Sicherheitsforscher von Zero Solatium haben nun einfach eine WerFaultSecure.exe von Windows 8.1 genommen und diese auf einen Windows 11 24H2-Rechner kopiert. Ich habe es nicht getestet – aber die Windows 8.1-Kopie von WerFaultSecure.exe ist von Microsoft signiert und kann wohl aus beliebigen Ordnern gestartet werden (im Beispiel aus C:\Tmp\). Anschließend konnten die Sicherheitsforscher ein eigenes Tool dazu bringen, über WerFaultSecure.exe unter dem Schutz der PPL-Erweiterung den LSASS-Speicher als Raw-Dump auf die Festplatte zu schreiben.
Zero Salarium berichtet hier, dass die Exploit-Sequenz die Ausführung von WerFaultSecure.exe mit undokumentierten Schaltern erfordert. Diese Optionen wurden durch Reverse Engineering entdeckt:
- /h zum Aufrufen des sicheren versteckten Absturzmodus,
- /pid [pid] zum Ansprechen des LSASS-Prozesses,
- /tid [tid] zum Festlegen seines Haupt-Threads und
- /file [handle] zum Festlegen eines unverschlüsselten Ausgabe-Handles.
Das Ganze wurde in einem Tool kombiniert, das den LSASS-Cache als unverschlüsselten Dump in eine Datei schreibt und diese als PNG-Grafikdatei verschleiert. Nach dem Ausführen des Tools kann man die Datei proc.png aus Ordner, in dem WSASS.exe liegt, kopieren.
Ändert man die ersten 4 Bytes auf die Werte {0x4D, 0x44, 0x4D, 0x50} (MDMP) zurück, hat man eine normale Minidump-Datei. Dann lassen sich Tools wie Mimikatz verwenden, um diesen Minidump nach Anmeldeinformationen zu durchsuchen.
Der Blog-Leser, der mich ebenfalls auf das Thema hinwies, warf die Frage auf, ob man in Applocker, SRP oder Software-Deployment explizit angeben kann, dass die Datei WerFaultSecure.exe nur aus den Windows-Verzeichnissen aufgerufen werden darf. Dann wäre der obige Ansatz nur mit administrativen Berechtigungen zum Kopieren der Datei erforderlich. Frage daher an die Spezialisten: Wäre dieser Ansatz gangbar und falls ja, wie?
MVP: 2013 – 2016
Zitat:
" ob man in Applocker, SRP oder Software-Deployment explizit angeben kann, dass die Datei WerFaultSecure.exe nur aus den Windows-Verzeichnissen aufgerufen werden darf. "
—
Man kann die Dateihashes der Windows 8.1-Datei WerFaultSecure.exe im Applocker sperren.
Dann kann sie aus keinem Ordner mehr gestartet werden.
Man müsste allerdings sämtliche betroffene 8.1-Versionen dieser Datei sperren, also mit allen Patch-Leveln, in denen diese Datei vorhanden sein könnte, denn die könnte durch jedes Update für Windows 8.1 verändert worden sein.
Temp-Ordner und alle sonstigen Ordner, in denen ein Benutzer Schreibrechte hat, sollte man im Applocker auch sperren.
Falls der Angreifer aber Adminrechte hat, dann ist das zwecklos.
Alternativ könnte man im Applocker statt des Dateihashes auch per "Herausgeber" sperren.
Bei "Dateiversion" ersetzt man die "10.0.0.0" (von Windows 10 und 11) durch "6.3.0.0" für Windows 8.1 und "6.2.0.0" für Windows 8.0.
learn. microsoft. com/en-us/windows/win32/sysinfo/operating-system-version
Fehler:
Sperren per Herausgeber mit Dateiversioen "6.3.0.0" oder "6.2.0.0" funktioniert nicht, weil die aktuellen Versionen dann ebenfalls gesperrt werden, weil rechts daneben die Einstellung "und höher" steht.
Statt dessen stellt man als Dateiversion besser 9.9.9.9 ein und rechts danaben stellt man auf "und niedriger" um.
Dann wird alles vor Windows 10 gesperrt, also auch Windows 8.1.Alle Versionen ab einschließlich 10.0.0.0 bleiben erlaubt.
Vielleicht wäre es sogar besser bei "Dateiname" nicht "Werfault.exe" einzugeben, sondern ein * (Wildcard), falls der Hacker diese Datei einfach umbenennt.
* (Wildcard) funktioniert solange es keine ausführbaren Dateien mit dem gleichen Herausgeberzertifikat und einer Version kleiner der Versionsnummer in der Regel gibt. Es bleibt daher ein Restrisiko für Nebenwirkungen. Wenn Microsoft alle .exe sauber innerhalb der Basisversion versioniert hat, könnte es klappen.
** NACHTRAG **
Mit Wildcard kann z.B. das Notepad oder der Rechner nicht mehr gestartet werden. Damit das wieder ging, mussten erstmal alle Regeln wieder gelöscht werden. Wildcard als Lösung fällt somit weg.
Auf Windows 10 IoT Enterprise LTSC 2021 kann ich Rechner (calc.exe) und Notepad.exe starten, obwohl ich * (Wildcard) als Dateiname und Version kleiner als 9.9.9.9 eingetragen habe.
Bei beiden exe beginnt die Dateiversion mit 10.0.
Dann hat Microsoft bei deinem Windows 11 die Versionsnummern nicht korrekt eingetragen.
Das ist dann ein weiterer Grund, Windows 11 nicht zu benutzen, wenn da noch nichtmal die Dateiversionen zum OS passen.
Nun funktioniert es auch hier mit Windows 11. War mein Fehler. Bei den App-Paketregeln fehlten die Default-Allow-Regeln. Da bei den ausführbaren Dateien mit dem Herausgeber gesperrt wurde, hat dies offenbar auch Auswirkungen auf die App-Pakete wie notepad.exe und calc.exe.
Um die Wirkung der Wildcard-Herausgeber-Regel abzuschwächen, kann man direkt auf der Regel die Ordner %PROGRAMFILES% und %WINDOWS% als Ausnahmen erfassen. Dann wird alles vom Herausgeber kleiner der Versionsnummer in der Regel ausserhalb des Windows-Kernsystems geblockt im Kern selber aber nicht. Wenn das System so eingerichtet ist, dass nur Admin in %PROGRAMFILES% und %WINDOWS% schreiben können, bringt man auch nicht einfach so eine Windows 8.1.-Programmdatei unter einem Tarnnamen da rein.
Mit AppLocker eine Herausgeber-Regel für WerFaultSecure.exe erstellen und dort die Dateiversion auf „10.0.0.0" "und niedriger" einstellen.
Achtung:
Falls noch keine Default-Allow-Regeln bestehen, diese bei der entsprechenden Abfrage erstellen lassen, damit sich alles andere weiterhin aus den Ordner Programme und Windows ausführen lässt!
Test:
WerFaultSecure.exe von einem Windows Server 2012 R2 mit Dateiversion 6.3.9600.nnnn an beliebige Stellen im System kopiert – die Ausführung wird zuverlässig blockiert und die originale Version von Windows 11 in C:\Windows\System32 wird nicht blockiert.
Bei uns dürfen User keine Programme aus von ihnen beschreibbaren Ordnern ausführen (auch die ganzen Ausnahmen in %windir% sind gesperrt) und es gibt keine generelle Microsoft-Freigabe aufgrund der Dateisignur. Von daher glaube ich, dass ich mich recht entspannt zurück lehnen kann, eine von daheim mitgebrachte WerFaultSecure.exe wird wohl nur mit schon Adminrechten ausführbar sein, dann ist es aber eh schon zu spät. Und der Nerd muss die Datei erstmal aufs System bringen, USB-Sticks sind gesperrt, der Proxy passt auf wie ein Wachhund und per Mail gehts auch nur sehr wohlüberlegt.
Servus,
ich habe mir nur einige Informationen zu den PPLs durchgelesen.
Soweit wie ich dies verstehe, ist aber gerade hier die Möglichkeit von Microsoft geschaffen worden, diese Anwendungen mit Service-Berechtigungen – mit Umgehung der UAC – starten zu können.
Hier wurden die Windows-Updates, etc. als Beispiel erwähnt, welche auch ohne Admin-Berechtigungen vom User gestartet und installiert werden können.
Desweitere hat diese Datei natürlich ein Zertifikat von Microsoft.
Wie weit nun der Defender oder andere Endpoint-Security Produkte solche "Systemdateien" von Microsoft auch blockieren kann / blockiert oder diese explizit als Ausnahme dort geführt werden (in den letzten 10 Jahren gab es ja öfters AV-Pattern, welche das gesamte OS lahmgelegt hat)… entzieht sich meiner Kenntnis, wäre für mich aber eine sinnvolle Mitigation, um solche Probleme (Systemdateien werden durch Pattern-Update als malicious erkannt) zu verhindern.
Leider findet man bisher kaum Kommentare dazu in den bisherigen Berichten, noch Hinweise der AV-Hersteller dazu.