Silverfort entdeckt eine Active Directory Die Gruppenrichtlinie zum Deaktivieren von NTLMv1 kann durch eine einfache Fehlkonfiguration leicht umgangen werden, wodurch NTLMv1-Authentifizierungen bestehen bleiben.
TL; DR
- News: SilverfortDas Forschungsteam von hat einen neuen Weg für Angreifer entdeckt, - NTLMv1 bei Angriffen, trotz der Bemühungen, es zu deaktivieren. Durch eine Fehlkonfiguration in On-Premise-Anwendungen können Angreifer die Gruppenrichtlinie zum Stoppen von NTLMv1 Authentifizierungen.
- Warum es darauf ankommt: 64% der Active Directory Benutzerkonten authentifizieren sich regelmäßig mit NTLM, obwohl es bekannte Schwächen hat und von Microsoft abgelehnt wird. Viele Organisationen versuchten, das NTLMv1-Problem mit einem Active Directory Gruppenrichtlinie. Wir haben jedoch festgestellt, dass diese Richtlinie fehlerhaft ist und NLTMv1-Authentifizierungen bestehen lässt, was ein falsches Sicherheitsgefühl erzeugt und Organisationen angreifbar macht. Angreifer wissen, dass NTLMv1 ein schwaches Beglaubigung Protokoll und suchen Sie aktiv danach, um sich seitwärts zu bewegen oder Privilegien zu erhöhen.
- Wer ist betroffen: Jede Organisation, die Anwendungen von Drittanbietern oder selbst entwickelte Anwendungen vor Ort verwendet und die nicht ausschließlich Windows-Rechner verwendet. Wenn sich beispielsweise ein Mac-Computer mit einer Bankanwendung verbindet, könnte dies gefährdet sein.
- Auswirkungen auf Organisationen: Ein Angreifer, der in einem Netzwerk sitzt, kann den NTLMv1-Verkehr sehen und die Anmeldeinformationen der Benutzer offline knacken, was zu einer seitlichen Bewegung führt und PrivilegeskalationUnser POC emuliert eine Anwendung, die die Umzäunung umgeht, und bestätigt, dass diese Fehlkonfiguration einem Angreifer einen Vorteil verschafft.
- Ergebnis der Offenlegung: Während das Microsoft Security Response Center (MSRC) die NTLMv1 Obwohl die Umgehung keine Sicherheitslücke darstellt, haben sie proaktive Maßnahmen zur Verbesserung der Sicherheit ergriffen und die vollständige Entfernung von NTLMv1 innerhalb von zwei Monaten nach unserer Offenlegung angekündigt, beginnend mit Windows 11 Version 24H2 und Windows Server 2025.
Wir haben vor Kurzem ein Webinar veranstaltet, in dem ich die Teilnehmer detaillierter durch die Forschungsergebnisse führte und ihnen zeigte, wie man NTLMv1-Authentifizierungen ohne Patch abschwächen kann. Sie können dieses Webinar hier auf Abruf ansehen.
Zusammenfassung und Schadensbegrenzung
Trotz seiner historischen Bedeutung stellt NTLM ein erhebliches Sicherheitsrisiko dar. Seine veralteten kryptografischen Methoden, gut dokumentierten Schwächen und das Fehlen moderner Sicherheitsfunktionen (wie MFA und Server-Identitätsüberprüfung) machen es zu einem attraktiven Ziel für Angreifer. NTLMv1-Hashes können abgefangen und verwendet werden für Beglaubigung Relay-Angriffe oder sogar Wörterbuchangriffe, die Angreifern unbefugten Zugriff auf sensible Systeme ermöglichen. In den letzten Monaten wurden neue NTLM-Schwachstellen bekannt, einschließlich eines Zero-Day. In jüngerer Zeit, CyberSky entdeckt eine NTLM-Schwachstelle, die von russischen Bedrohungsakteuren als Teil einer Angriffskette ausgenutzt wird, die die Open-Source- Spark RAT Malware.
Viele Organisationen nutzen proaktiv den Gruppenrichtlinienmechanismus von Microsoft, um NTLMv1 stoppen, in der Annahme, dass dies sie vor unsicheren NTLMv1-Authentifizierungen schützt. Unsere Untersuchungen zeigen jedoch, dass On-Premise-Anwendungen so konfiguriert werden können, dass NTLMv1 aktiviert wird, wodurch die höchste Authentifizierungsstufe des Group Policy LAN Managers in Active Directory. Organisationen denken, sie tun das Richtige, indem sie diese Gruppenrichtlinie festlegen, aber sie wird trotzdem von der falsch konfigurierten Anwendung umgangen. Solange Anwendungen nicht für die Authentifizierung mit NTLMv1 konfiguriert werden können, wird das Problem bestehen bleiben.
At Silverforthaben wir in unserem Kundenstamm viele Versuche zur Authentifizierung über NTLMv1 beobachtet. Wir arbeiten eng mit unseren Kunden zusammen, um die Nutzung von NTLMv1 abzubilden und zu erkennen und risikobasierte Zäune anwenden um das Risiko einer Kompromittierung zu verringern. Ohne einen Patch für NLTMv1 sollten Unternehmen, die in der Vergangenheit NTLMv1 verwendet haben, Folgendes beachten:
- Aktivieren Sie Überwachungsprotokolle für alle NTLM-Authentifizierungen in der Domäne.
- Ordnen Sie alle Anwendungen zu, die in erster Linie oder als Fallback NTLM-Authentifizierungen verwenden.
- Erkennen Sie anfällige Anwendungen, die Clients auffordern, NTLMv1-Nachrichten zu verwenden.
- Zäunen Sie alle NTLM mit einer modernen Authentifizierungsmethode ein.
Technischer Deep Dive: NTLMv1-Bypass in Active Directory
NTLM (NT LAN Manager) ist ein alter, aber weit verbreiteter Authentifizierungsmechanismus, der häufig in Windows-basierten Umgebungen verwendet wird. Er wurde Anfang der 1990er Jahre von Microsoft entwickelt und war einst der Standard für die Authentifizierung von Benutzern in einem Netzwerk, insbesondere bei Microsofts Active Directory. Obwohl sie weitgehend durch sicherere Protokolle wie KerberosNTLM ist aufgrund von Abwärtskompatibilitätsanforderungen weiterhin in Legacy-Systemen vorhanden. Im Laufe der Jahre wurden Maßnahmen ergriffen, um die Verwendung neuerer, sichererer Authentifizierungsformen zu fördern, z. B. die Blockierung des alten NTLMv1 in der gesamten Domäne. Im Dezember 2024 kündigte Microsoft die Abschaffung der aktiven NTLM-Entwicklung. Trotz dieser Änderungen bleiben Fragen offen. Schaffen diese Maßnahmen eine sicherere Umgebung? Kommen wir einer vollständigen Entfernung von NTLMv1 wirklich näher? Lassen Sie uns in die technischen Details eintauchen.
NTLM 101
NTLM ist ein Authentifizierungsmechanismus, der zur Überprüfung der Identität eines Benutzers in Windows-basierten Systemen verwendet wird. NTLM besteht aus drei Nachrichten: Negotiate, Challenge und Authenticate. Der Prozess beginnt damit, dass der Client eine Negotiate-Nachricht an den Server sendet, in der er seine Absicht angibt, NTLM zur Authentifizierung zu verwenden, und Informationen zu unterstützten Authentifizierungsoptionen bereitstellt. Der Server antwortet dann mit einer Challenge-Nachricht, die eine Zufallszahl (die Challenge) enthält, die der Client anhand seiner Anmeldeinformationen hashen muss. Der Client sendet dann die gehashte Antwort in der Authenticate-Nachricht an den Server zurück, die auch den Benutzernamen, die Domäne und die Sitzungsinformationen des Clients enthält. Der Server validiert die Antwort und gewährt bei Erfolg Zugriff auf die angeforderte Ressource.
NTLM wird häufig als zugrunde liegender Authentifizierungsmechanismus in Protokollen höherer Ebene wie SMB (Server Message Block) oder HTTP verwendet. Obwohl NTLM ein eigenständiges Authentifizierungsprotokoll ist, wird es oft als „Mechanismus“ bezeichnet, da es häufig als Teil anderer Protokolle oder Systeme implementiert wird, um Authentifizierung bereitzustellen.
Abbildung 1: Einfache NTLM-Authentifizierung
NTLMv1 im Vergleich zu NTLMv2
NTLMv1 wurde erstmals 1993 eingeführt. Das Sicherheitsbewusstsein war zu dieser Zeit gering und NTLM wurde entsprechend entwickelt. Die Verschlüsselung, der erste Sicherheitsmechanismus, steckte noch in den Kinderschuhen und es wurde nur DES unterstützt. Der zweite Mechanismus, die Challenge, bestand nur aus einer 8-Byte-Server-Challenge. Diese Anzahl zufälliger Bytes war leichter zu erraten, wenn es darum ging, die Verschlüsselung zu knacken und die Anmeldeinformationen des Benutzers herauszufinden. Der letzte Mechanismus, der in der ersten Version von NTLM fehlte, war die Angabe der Quelle und des Ziels der NTLM-Authentifizierung. Dies führte sehr schnell zu der berüchtigten Angriffsmethode NTLM Relay, die den Gegner zwischen Client und Server positionierte. Wenn eine NTLMv1-Nachricht abgefangen wurde, konnte sie verwendet werden, um den Gegner gegenüber der Anwendung erneut zu authentifizieren und sie sogar mit einem anderen Protokoll wiederzuverwenden. Beispielsweise durch die Umstellung der NTLM-Authentifizierung über SMB auf NTLM über LDAP.
Die zweite Version von NTLM – NTLMv2 – führte Abhilfemaßnahmen für viele der oben beschriebenen Sicherheitslücken ein. Die erste war die Verbesserung der Verschlüsselungsmethode durch die Verwendung von RC4, wodurch die Chiffre gestärkt und ihre Brute-Force-Angriffe erschwert wurden. Die zweite war die Hinzufügung der Client Challenge, die der Berechnung der Chiffre eine weitere Entropiequelle hinzufügte. Die letzte und größte Änderung an NTLM war AV_PAIRS. Dadurch wurden der NTLM-Authentifizierungsnachricht zusätzliche Felder hinzugefügt, wie Quellclient, Zielserver, Domäne und sogar SPN, die einige der Felder sind, die für jede Authentifizierung einen eindeutigen Sitzungsschlüssel erstellen. Dieser Schutz erschwerte die Durchführung von Relay-Angriffen.
Netlogon zur Evaluierung von NTLM
Das letzte Puzzleteil ist, dass der Anwendungsserver in Active Directory kann die NTLM-Nachricht nicht selbst auswerten, da die Anmeldeinformationen des Benutzers nicht gespeichert sind. Stattdessen verwendet Microsoft die RPC-Netlogon-Schnittstelle, um die NTLM-Nachricht remote auszuwerten. Der Server muss die NTLM-Nachricht zusammen mit den NTLM-Herausforderungen an die Funktion NetrLogonSamLogonEx anhängen. Wenn der Domänencontroller die Nachricht mithilfe der gespeicherten Anmeldeinformationen des Benutzers erfolgreich neu erstellt, gibt er eine Erfolgsmeldung zurück und folgt dem Privilege Access Certificate (PAC) des Benutzers, um eine Autorisierung und einen passenden Sitzungsschlüssel durchzuführen. Wenn die Auswertung fehlschlägt, wird der entsprechende Fehler ausgegeben.
Abbildung 2: NTLM-Authentifizierung in Active Directory
NTLMv1-Offenlegung
Der Gruppenrichtlinienmechanismus ist die Lösung von Microsoft, um NTLMv1 im gesamten Netzwerk zu deaktivieren. Der Registrierungsschlüssel LMCompatibilityLevel verhindert, dass die Domänencontroller NTLMv1-Nachrichten auswerten, und gibt bei der Authentifizierung mit NTLMv0 einen falschen Kennwortfehler (000006xC1A) zurück. Dies sollte NTLMv1 vollständig eliminieren und alle Anwendungsserver dazu zwingen, NTLMv2 bereitzustellen. Eliminiert dies NTLMv1? Werfen wir einen Blick darauf.
Abbildung 3: NTLMv1 mit aktiviertem GP ablehnen
NTLMv1-Umgehung
MS-NRPC ist die Spezifikation der Netlogon-Remoteschnittstelle, die alle ihre Strukturen und Funktionen beschreibt. NetrLogonSamLogon und seine Varianten (NetrLogonSamLogonEx und NetrLogonSamLogonWithFlags) überwachen die sichere Übermittlung der NTLM-Nachricht vom Server an den Domänencontroller zur Auswertung. Die Funktionsstruktur erfordert die Übermittlung von Identitätsinformationen zusammen mit der NTLM-Nachricht. Wie in Abschnitt 2.2.1.4.15 definiert, enthält NETLOGON_LOGON_IDENTITY_INFO viele Felder wie Domänenname, Benutzername, Arbeitsstation und andere. Ein interessantes Feld ist ParameterControl. Wenn wir uns seine Flags ansehen, können wir sehen, dass im O-Wert steht: „NTLMv1-Authentifizierung (MS-NLMP) zulassen, wenn nur NTLMv2 (NTLM) zulässig ist.“
Abbildung 4: Ein Screenshot der ParameterControl-Flag-Seite 65 der MS-NRPC-Dokumentation.
Ich habe mich gefragt, ob Microsoft Anwendungen wirklich erlaubt, NTLMv1 zu verwenden, wenn es deaktiviert ist. Nachdem ich die Datenstruktur erstellt und eine bösartige Anwendung simuliert hatte, stellte ich fest, dass dieses Flag die Gruppenrichtlinie umgeht, die die Verwendung der NTLMv1-Authentifizierung im gesamten Netzwerk verhindert.
Abbildung 5: Umgehen Sie die NTLMv1-Gruppenrichtlinie.
Welche Auswirkungen hat dies auf die Eliminierung von NTLMv1?
Anwendungen, die Clients auffordern, NTLMv1 zu generieren, können dies weiterhin tun, auch wenn die Gruppenrichtlinie aktiviert ist. Es ist wichtig zu beachten, dass Windows-Clients mit LMCompatibilityLevel 3 und höher auf Anfrage kein NTLMv1 generieren. Nicht-Windows-Clients sind jedoch nicht geschützt. Wenn eine Anwendung eine NTLMv1-Nachricht von einem Nicht-Windows-Client anfordert, kann der Domänencontroller die Authentifizierung genehmigen und einen Sitzungsschlüssel generieren. Wir verwenden in unseren Kundennetzwerken Anwendungen, die versuchen, NTLMv1 zu verwenden, auch wenn die entsprechende Gruppenrichtlinie aktiviert ist. Aufgrund dieser Umgehung können Sie nicht feststellen, ob eine anfällige Anwendung vollständig entschärft ist. Während viele Organisationen versuchen, die gesamte NTLMv1-Verwendung aufzudecken, sind sie sich möglicherweise nicht einmal bewusst, dass einige Anwendungen immer noch NTLMv1 verwenden.
Was muss ich tun, um das Risiko vollständig zu mindern?
- Aktivieren Sie Überwachungsprotokolle für alle NTLM-Authentifizierungen in der Domäne.
- Ordnen Sie alle Anwendungen zu, die in erster Linie oder als Fallback NTLM-Authentifizierungen verwenden.
- Erkennen Sie anfällige Anwendungen, die Clients zur Verwendung von NTLMv1-Nachrichten auffordern.
- Zäunen Sie alle NTLM mit einer modernen Authentifizierungsmethode ein.
Silverfort's Unified Identitätssicherheit Die Plattform erkennt und schützt alle NTLM-Authentifizierungen. Unsere ITDR Das Modul kann NTLMv1-Anwendungen erkennen und eine moderne, risikobasierte Abgrenzung aller anfälligen Anwendungen durchführen.
Offenlegungsprozess
Obwohl MSRC angab, dass die NTLMv1-Umgehung nicht als Schwachstelle eingestuft wurde, ergriff das Unternehmen proaktiv Maßnahmen und kündigte die vollständige Entfernung von NTLMv1 ab Windows 11 Version 24H2 und Windows Server 2025 an. Das Problem wurde am 30. September 2024 gemeldet und die Reaktion des Unternehmens stimmte mit der offiziellen Ankündigung der Entfernung im November 2024 überein. Indem Microsoft Altrisiken angeht und veraltete Protokolle ausmustert, zeigt das Unternehmen ein starkes Engagement für die Verbesserung der Sicherheit mit einem zukunftsorientierten Ansatz. Dieser Schritt unterstreicht die Bedeutung der Absicherung von Systemen mit modernen, sicheren Alternativen wie SSO oder Kerberos und zeigt, wie verantwortungsvolle Berichterstattung zu sinnvollen Verbesserungen beitragen kann.
Möchten Sie mehr erfahren? Sehen Sie sich unser On-Demand-Webinar an
Wenn Sie tiefer in die Details dieser Forschung eintauchen möchten, Schauen Sie sich dieses On-Demand-Webinar an, wo ich erläutert habe, wie NTLMv1-Authentifizierungen ohne Patch abgeschwächt werden können.