[English]NTLM-Relaying ist eine beliebte Angriffsmethode, die von Bedrohungsakteuren zur Kompromittierung der Identität verwendet wird. Microsoft möchte dem einen Riegel vorschieben und hat damit begonnen, Schutzmaßnahmen in Windows auszurollen, die einen besseren Schutz vor Standard-NTLM-Relay-Angriffen bieten sollen.
NTLM-Relay-Angriffe
NTLM-Relaying ist eine beliebte Angriffsmethode, um eine Identität zu kompromittieren bzw. zu stehlen. Für den NTLM-Relay-Angriff wird das Opfer dazu gebracht, sich an einem beliebigen Endpunkt zu authentifizieren. Die Anmeldeinformationen werden dann an die Angreifer weitergeleitet.
Durch die Weiterleitung der Anmeldeinformationen an einen anfälligen Endpunkt können sich Angreifer authentifizieren und Aktionen im Namen des Opfers durchführen. Dies verschafft Angreifern eine Ausgangsbasis für die weitere Kompromittierung einer Domäne.
Microsoft erschwert NTLM-Relay-Angriffe
Um die Ausnutzung von Schwachstellen wie Relaying-Angriffe zu stoppen, ist es erforderlich, die anfälligen Dienste standardmäßig ganzheitlich anzugehen. Hier kommen EPA oder andere Kanalbindungsmechanismen ins Spiel. Diese stellen sicher, dass sich Clients nur bei dem für sie vorgesehenen Server authentifizieren können.
Microsoft hat den Artikel Mitigating NTLM Relay Attacks by Default veröffentlicht und beschreibt, was man in Produkten tut, um Systeme vor NTLM Relay-Angriffen zu schützten.
Im Februar 2024 wurde ein Update für Exchange Server veröffentlicht, das mit Extended Protection for Authentication einen erweiterten Schutz für die Authentifizierung (EPA) für neue und bestehende Installationen von Exchange 2019 aktiviert. Damit reagierte Microsoft auf die Schwachstelle CVE-2024-21410.
Mit Windows Server 2025 steht eine ähnliche Sicherheitsverbesserung für Azure Directory Certificate Services (AD CS) bereit. Auch dort ist EPA standardmäßig aktiviert. Darüber hinaus ist in der gleichen Version von Windows Server 2025 für LDAP nun standardmäßig die Kanalbindung aktiviert. Durch diese Sicherheitsverbesserungen wird das Risiko von NTLM-Relaying-Angriffen standardmäßig für drei On-Premises-Dienste gemindert: Exchange Server, Active Directory Certificate Services (AD CS) und LDAP. Details lassen sich im Artikel Mitigating NTLM Relay Attacks by Default nachlesen. Bei heise gibt es diesen Beitrag mit einigen weiteren Informationen.
Das sind noch die letzten Zuckungen, um NTLM zu härten.
NTLMv1 ist standardmäßig schon in Win 11 24H2 und Server 2025 deaktiviert und NTLM (v1, v2) allgemein wurde von Microsoft als deprecated klassifiziert und wird in einer der folgenden Windows- und Serverversionen komplett rausgekickt, d.h. nicht mehr unterstützt.
Da sind jetzt die Softwareentwickler von Drittanbietern gefragt, NTLM auch aus den eigenen Produkten rauszuwerfen.
Auch Microsoft selbst ist gefordert, aber auch Admins und so weiter. Kerberos, so schön es auch ist, wird nämlich mit NTLM als Fallback „umgangen“, wenn es nicht funktioniert. Das passiert zum Beispiel wenn man Zielserver nur als Hostname statt FQDN angibt, oder statt FQDN die IP-Adrresse. Was man eigentlich immer abschalten kann, ist zumindestens NTLMv1, NTLMv2 wird schon schwieriger. Wir sind mittlerweile so weit, dass wir per GPO auf allen Windows-Systemen zumindestens NTLMv1 und v2 komplett ausgehend abschalten konnten, bei einigen Servern und allen DCs eingehend leider noch nicht, weil es immer noch Alt-Applikationen und diverse Appliances (insbesondere wenn sie Linux-basiert sind, komisch…) , aber auch Firewalls, Switches, Storages mit AD-Auth gibt, die kein Kerberos können und teilweise sogar nur NTLMv1 nutzen obwohl die neuesten Updates drauf sind. Wenn ich in unserem SIEM nach NTLM-Auths filtere, kommt mir immer noch das kalte Grauen. Das bekommt man nur langsam weg, ständig den Herstellern auf den Nerv gehen, und irgendwann passiert was… Jetzt, wo MS das abgekünigt hat, vielleicht etwas schneller. Siehe auch den jüngsten NTLM-Artikel auf gruppenrichtlinien.de.
Ich habe hier in der Firma NTLM schon vor ca. 2 Jahren rausgekickt.
Zuerst das NTLM-Logging angeschaltet und dann regelmäßig in die Logs geschaut. Nachdem 3 Monate nacheinander keinerlei NTLM-Verkehr mehr feststellbar war, hab ich NTLM komplett deaktiviert.
Seit dem läuft hier nur noch Kerberos.
Bezüglich logging ist wichtig zu wissen dass es bei ntlm V1 und V2 bei Anonymous Verbindungen keinen erkennbaren Unterschied gibt und somit im Log ntlm(V1) steht. Anonymous im Log somit für den Fall ignorieren.
Wenn es mit den ganzen Spezial und Legacy Anwendungen nur nicht so umständlich wäre NTLM ganz rauszuschmeißen. Hatte es Mal getestet, abet da gingen einige Anmeldungen nicht mehr. Und nicht in allen Anwendungen kann man überhaupt Kerberos aktivieren…
Immerhin v1 konnte ich deaktivieren…
wichtig ist dass der FQDN bevorzugt verwendet wird und ganz besonders wichtig dass das Zielkonto (Computer oder Service Benutzer) den passenden eindeutigen SPN im AD haben. Ja, AD Integration ist nötig.
Betrifft diese Härtung bzw. die dafür ausgerollten Updates (Dezember Turnus seit 10.12.2024 bzw. KBNummern irgendwo bekannt?),
auch das zuvor hier besprochene Thema was von ACROS Security 0patch aufgedeckt wurde?
https://www.borncity.com/blog/2024/12/06/windows-0patch-fuer-0-day-url-file-ntlm-hash-disclosure-schwachstelle/