In Windows 11 und Windows Server 2025 soll der Credential Guard das Abfließen von Anmeldedaten verhindern. Sicherheitsforscher haben nun gezeigt, dass sich der Credential Guard in Windows austricksen lässt und weiterhin Anmeldedaten preisgeben kann. Angreifer können NTLMv1-Anmeldeinformationen abrufen. Microsoft teilte den Sicherheitsforschern nach der Meldung mit, dass man das nicht fixen werde.
Hintergrund: Credential Dumping
Credential Dumping ist eine Technik, mit der Angreifer versuchen, Anmeldedaten (Credentials) zu extrahieren, um sich Zugang zu Konten und Anmeldedaten eines Systems, in der Regel in Form eines Hash-Werts oder eines Klartext-Passworts, zu verschaffen. Anmeldedaten können aus dem Cache, dem Speicher oder Strukturen des Betriebssystems extrahiert werden.
Diese Anmeldedaten (Credentials) lassen sich dann für laterale Bewegungen im Netzwerk und den Zugriff auf abgesicherte Systeme und die dort gespeicherten Informationen verwenden. Credential Dumping ist nach wie vor eine der effektivsten Techniken, die sowohl von Angreifern als auch von Red-Teamern eingesetzt wird, um nach einer Exploitation in Windows-Umgebungen lateral vorzugehen.
Windows Credential Guard verspricht Schutz
Ein Hauptziel solcher Angriffe ist der LSASS-Prozess, der NTLM- und Kerberos-Anmeldedaten speichert. Aufgrund des Ausmaßes dieser Bedrohung hat Microsoft 2015 mit Windows 10 den Credential Guard eingeführt, um Anmeldedaten und Geheimnisse durch Isolierung mit Virtualization-Based Security zu schützen. Bei der Funktion des Credential Guard handelt es sich um eine virtualisierungsbasierte Isolationstechnologie für LSASS (Local Security Authority Subsystem Service), die Angreifer daran hindert, Anmeldedaten zu stehlen, die für Pass-the-Hash-Angriffe verwendet werden könnten.
Der Credential Guard verhindert, dass Angreifer die in LSASS gespeicherten Anmeldedaten auslesen können, indem LSASS in einem virtualisierten Container ausgeführt wird, auf den selbst Benutzer mit SYSTEM-Rechten keinen Zugriff haben. Das System erstellt dann einen Proxy-Prozess namens LSAIso (LSA Isolated) für die Kommunikation mit dem virtualisierten LSASS-Prozess. Ab Windows 10 Version 20H1 ist Credential Guard nur in der Enterprise-Edition des Betriebssystems verfügbar.
Windows Credential Guard versagt
Leider scheint dies nicht immer zu funktionieren. Ich bin über nachfolgenden Tweet auf den Beitrag Catching Credential Guard Off Guard vom 23. Oktober 2025 gestoßen.
Die Botschaft des Tweets lautet, dass Sicherheitsforscher von SpecterOps bei Analysen zeigen konnten, dass Credential Guard weiterhin unter Windows Anmeldedaten preisgeben kann. Angreifer können durch Missbrauch des Remote Credential Guard NTLMv1-Challenge-Antworten anfordern und NT-Hashes wiederherstellen. Die Sicherheitsforscher haben das Szenario detailliert in ihrem Beitrag beschrieben.
Diese Angriffsart ist selbst auf vollständig gepatchten Windows 11-Systemen mit VBS und PPL (also dem sichersten aller Windows-Versionen) sowie unter Windows Server 2025 möglich. Nachdem das Problem an Microsoft im August 2025 gemeldet wurde, konnte das Unternehmen dies im September 2025 reproduzieren. Gegenüber den Sicherheitsforderungen hat Microsoft bestätigt, dass der Angriff funktioniert. Allerding hat Microsoft zum 24. September 2024 die Meldung des Problem mit "wird nicht behoben" gekennzeichnet und den Fall abgeschlossen. Die Forscher haben dann ein Proof of Concept (PoC) namens DumpGuard veröffentlicht.
MVP: 2013 – 2016
Auch eine mögliche Fragestellung hier: Backdoors müssen erhalten werden?
Typische Antwort eines Foristen, der sein Lebtag keine unternehmerische Verantwortung trug, nie zu Kosten-Nutzen-Abwägungen gewzungen war und auf seine alten Tage plötzlich überall das Gras wachsen hört.
Vielleicht fixt MS das nicht mehr, weil NTLMv1 ohnehin nicht mehr verwendet werden sollte.
Also behebbar, in dem man NTLMv1 ausschaltet?
So wird es in dem Artikel von specterops.io und dem Github Repository beschrieben. Obwohl ein hehres Ziel, ist das Abschalten trotz aller Sicherheitsbedenken eben nicht immer möglich. Geschäftsanforderungen wie das Vorhalten alter Finanzanwendungen aufgrund HGB ohne Support für andere Anuthentifizierungsprotokolle oder IT-Führungen ohne Interesse an dem Thema schränken die Handlungsfähigkeit für den Admin mitunter stark ein und kneifen ihn sozusagen in den Allerwertesten. Man hat dann die Wahl zwischen Anschiss wegen eigenmächtigem Handeln oder Anschiss wegen Sicherheitsvorfall.
Das Vertrauen auf einen Hersteller, der Sicherheitslücken dann nicht mehr behebt, weil damit ja nur die abgekündigten Funktionen geschützt würden, ist damit natürlich "leicht" untergraben (nicht, dass es dieses Vertrauen noch gegeben hätte…).
Mal schauen, wann diese Sicherheitslücke andere Authentifizierungsprotokolle bedroht.
Betr. "Geschäftsanforderungen wie das Vorhalten alter Finanzanwendungen aufgrund HGB ohne Support für andere Anuthentifizierungsprotokolle oder IT-Führungen ohne Interesse an dem Thema …":
S. auch Kommentar (1). Wer meint, solche Finanzanwendungen noch fahren zu dürfen, um sich Migrationen auf zeitgemässe Implementationen sparen zu können, gehört eigentlich hinter Schloss und Riegel. Ich meine nicht den Adminstrator, sondern Eigentümer und Geschäftsführer.
_
(1) https://borncity.com/blog/2025/10/24/oracle-e-business-suite-0-day-schwachstelle-cve-2025-61882/#comment-234201
Drum geht es gar nicht.
Sondern um die gesetzlichen Aufbewahrungsfristen von steuerrelevanten Daten.
Das Backup solcher Daten darf nicht löschbar oder änderbar sein.
Soft-und Hardware, um dieses Backup und die darin enthaltenen Daten noch lesbar zu machen, müssen bis zum Ende der Aufbewahrungsfrist ebenfalls aufbewahrt werden.
Und wenn man jetzt eine entsprechende Software durch eine andere Software ablöst, dann sind bei der Datenmigration aber nicht die steuerrelevanten Daten im Originalformat vorhanden.
Ergo muß man die alte Software aufbewahren.
Das ist nur vielen Leuten in Firmen nicht bewusst.
Und wer Elster Online nutzt, muss dann hoffen, dass sein Login noch geht, wenn man an die Erklärung ranwill…
Gänseblümchen, ich habe es so verstanden, dass es auch mit deaktiviertem NTLM leckt.
Laut dem Tweet und der Diskussion die sich hier drunter befindet, eher nicht, da es kein Problem von NTLMv1 ist, sondern vom Credential Guard selbst:
So, be clear, if you set LmCompatibilityLevel to 5 (which should reject any NTLMv1 calls) this might not mitigate it? Yet, Microsoft is not going to fix this?
-> I think because the vector is Credential Guard itself, and not any NTLM calls. You're just asking CG to drop hashes in a specific format, it just complies with an insecure format.
und
NTLMv1 should be just disabled. Plain and simple. Microsoft is screaming about that since ages.
->It is disabled, but this technique works despite that
bin jetzt aber ehrlich gesagt auch verunsichert.
NTLMv1 deaktivieren ist eine der wichtigsten AD Härtungen.
Der Nachfolger NTLMv2 ist mit Windows NT 4.0 SP4 eingeführt worden.
Das wird der Grund sein, dass MS das nicht mehr interessiert.
Und Kerberos wurde mit Windows 2000 eingeführt.
Es sollte also gar keine Sachen mehr geben, die NTLM, egal ob v1 oder v2, verwenden.
erkläre das Mal deiner lokalen PC Instanz, wie sie das machen soll ohne AD. ;-)
Kerberos gab es schon lange, bevor es so etwas wie ein AD gab!
Kerberos gibt es allgemein verfügbar seit Ende der 1980er Jahre.
Und seit dem gibts das auch in der Unix-Welt.
Erst mit Windows 2000 wurde das AD eingeführt.
NT4 hat noch kein AD.
Und ab Windows 2000 unterstützen auch Windows Clients Kerberos.
> Es sollte also gar keine Sachen mehr geben, die NTLM, egal ob v1 oder v2, verwenden.
Du hast mich nicht verstanden.
Die LSA (Local System Authority), die deine LOKALEN Konten authentifiziert, wenn du zB über C$ mit dem .\Administrator zugreifst, kann kein Kerberos anbieten.
Das LOKALE Konto nutzt, auch auf einen Client der im AD ist, weiterhin NTLMv2
DAS sind die Sachen, die NTLM verwenden und weiterhin nutzen. Es gibt keine Alternative.
Da du mit LAPS arbeiten solltest, kannst du NTLM nur für Domänenkonten verweigern, aber nicht komplett, wenn LAPS genutzt wird.
Netzwerksicherheit: Beschränken von NTLM: Eingehender NTLM-Datenverkehr
– "Alle zulassen"
—> "Alle Domänenkonten verweigern"
– "Alle Konten verweigern"
Selbst NTLMv2 sollte man nach Möglichkeit nicht mehr verwenden. Und ein nicht gehärtetes Kerberos (z.B. noch mit RC4) ist für einen Pentester auch ein Fest.
NTLM gabz abschalten, also auch NTLMv2!
Microsoft hat schon lange dazu Tutorials veröffentlicht.
Zuerst schaltet man das Logging von NTLM ein und dann schaut man regelmäßig in die Ereingnisanzeige und sucht nach entsprechenden Einträgen.
Findet man keine, wird NTLM nicht verwendet und man kann es problemlos komplett deaktivieren.
Das ist hier schon vor weit über 1 Jahr passiert.
Und findet man Einträge, sieht man, wer oder was noch NTLM verwendet und kann dann schauen, ob sich das nicht auf Kerberos umstellen lässt.
Wäre schön wenn das so einfach in jeder Umgebung ginge.
So wie ich es verstanden habe, leakt es auch, wenn NTLM komplett deaktiviert ist.
NTLMv1 kann weg. Wenn eine Uralt Anwendung anch 10J mal benötigtwird, übergangsweise wieder aktivieren.
Wer heute noch NTLMv1 verwendet dem kann eh nicht geholfen werden.
Ausnahmsweise kann ich MS hier etwas nachvollziehen, warum sie keine Energie in veraltete und unsichere Methoden reinstecken wollen, die unabhängig davon schon ewig nicht mehr eingesetzt werden sollten.
Ich erinnere mich in meiner Firma vor vielen vielen Jahren wo WS2003 Support-Ende war und der zuständige Systemverantwortliche eines WS2003-Servers tatsächlich wortwörtlich sagte: "Warum soll ich den Ablösen? Der läuft doch noch gut… "
Falscher Beruf in der IT ?! Und ja, wens interessiert: Er hatte natürlich zwangsweise einen neuen Windows-Server mit aktuellem OS bekommen und arbeitet damit sowie sonst auch "zufriedenstellend".
ROFLMAO, welche Welt…. Und heute wird täglich über Schwachstellen und Datenabfluss berichtet… Naja…
Der erwähnte Leak ist auch möglich, wenn NTLMv1 oder NTLMv2 ausgeschaltet sind. Das ist ja der Clou daran.
der credential guard war immer schon relativ sinnfrei, da er nur die Daten der LSA schützt, wohingegen alle anderen Kombinationen des Anmeldetresors in Klartext auszulesen sind.
einer der Gründe, warum LAPS zum Schutz effektiver ist. die lokale Instanz ist nicht mehr zu retten, wenn ich an die lokalen Daten komme