NTLM – New Technology LAN Manager & die Angriffsmöglichkeiten

Hintergrundwissen. Was ist NTLM?

Die Abkürzung NTLM steht für New Technology LAN Manager, dabei handelt es sich um ein von Microsoft entwickeltes und bereitgestelltes Authentifizierungsverfahren anhand eines Challenge-Response-Mechanismus.

Die erste NTLM Version, welche im Jahr 1993 erstmals veröffentlicht wurde, ist mittlerweile als NTLMv1 bekannt. Diese Version sollte nicht mehr verwendet werden. Bereits fünf Jahre später, also 1998, veröffentlicht Microsoft die heute üblicherweise verwendete Version NTLMv2.

Du bist Gehackt, was ist zu tun?

Wenn Du Opfer eines erfolgreichen Hackerangriffs wurdest,
ließ Dir unseren Beitrag durch.

Zum Artikel

Unterschiede zwischen NTLMv1 und NTLMv2

Der Client fügt einen Zeitstempel bei der Übermittlung des Benutzernamens an den Server hinzu.
Die verwendete Länge der „Challenge“ ist variable und damit schwerer zu cracken.
Der schwache DES Algorithmus wurde durch den HMAC_MD5 Algorithmus im Rahmen des Challenge-Response Protokolls abgelöst. (Nicht zu verwechseln mit der Erstellung des nt-hashes mittels md4). Wobei auch der „neuere“ MD5 Algorithmus nicht mehr zum Stand der Technik gehört und keine Anwendung mehr finden sollte, da er anfällig gegen Angriffe ist.

NTLMv2 ist in Netzwerken noch häufig verbreitet, insbesondere da ältere Dienste und Protokolle nicht deaktiviert werden, kommt dieses zum Einsatz. Falls die Netzwerkinfrastruktur und die verwendeten Systeme es zulassen, sollte dies durch neuere Protokolle wie z.B Kerberos ersetzt werden!

Unterschied zwischen NT-Hash, NTLM und NetNTLMv1/v2

Im Kontext des Themas NTLM gibt es immer wieder Verwirrung in der Unterscheidung der Begrifflichkeiten.

NT-Hash: Der NT-Hash (Windows NT), ist gemeinsam mit dem LM-Hash (LAN Manager), in der SAM-Datenbank (Security Accounts Manager) zu finden. Gegen diesen können Angriffe zum Cracken der Hashe laufen oder er kann für pass-the-hash Angriffen verwendet werden.

NTLM: Von Microsoft bereitgestelltes Authentifizierungsprotokoll. Dies wurde mittlerweile durch Kerberos abgelöst. NTLM existiert in zwei Versionen, der älteren NTLMv1 auch bekannt als Net-NTLMv1 und der Version NTLMv2 bzw. Net-NTLMv2. Wobei auch die neuere Version nicht mehr als Stand der Technik angesehen werden kann und dort, wo möglich durch Nachfolgelösungen z.B. Kerberos ersetzt werden sollte.

Wie funktioniert NTLMv2?

NTLMv2 verwendet ein Challenge-Response-Verfahren, um den anfragenden Netzteilnehmer zu authentifizieren. Dazu findet folgende Kommunikation zwischen Client und Server statt:

Der Client sendet einen Benutzernamen an den Host.
Als Antwort darauf sendet der Server eine Zufallszahl (Challenge).
Daraus errechnet der Client, in Verbindung mit dem NT-Hash, einen Hashwert und sendet diesen zurück (Response).
Da dem Server der NT-Hash des Benutzers bekannt ist, berechnet dieser ebenfalls diesen Hashwert zum Abgleich.
- Wenn beide Werte übereinstimmen, konnte die Authentizität des Clients bestätigt werden (Confirmation).
- Weichen die beiden Hashwerte voneinander ab, wird die Anfrage abgelehnt (Denial).

Angriff: Angriffsmöglichkeiten mittels Man-in-the-Middle

Sollte es einem Angreifer gelingen, einen NTLMv2 Hash zu erhalten, kann er versuchen diesen zu cracken und das Passwort zu erhalten oder sich zwischen die Kommunikation von Client und Server „schalten“ und Informationen zu (veränderten) Anfragen abzufangen. Wie dies möglich ist, haben wir in den Beiträgen LLMNR, NetBIOS oder auch IPv6 beschrieben.

Zur Veranschaulichung der Angriffsmöglichkeiten wurde eine Laborumgebung aufgebaut, darin befinden sich:

Windows Server 2016 als Domain Controller
Windows 10 als Client
Kali Linux als Angreifer, mit den Tools
- responder
- mitm6
- ntlmrelayx (impacket)

Zur Durchführung der nachfolgend beschriebenen Szenarien, muss das Netzwerk so konfiguriert sein, dass IPv6 aktiv ist und keine automatische Filterung von Paketen erfolgt (in virtuellen Umgebungen muss dies ggf. aktiv eingestellt werden).

Zusätzlich zeigte sich, dass in dieser Labor-Umgebung auf dem Domain-Controller die Active Directory-Zertifikatsdienste zum Nachstellen für den Relay auf LDAPS installiert und eingerichtet werden müssen.

NTLM-Relay zu SMB

Im ersten Angriff-Szenario erfolgt ein Relay der NTLM Authentifizierung zu SMB. Dazu nutzen wir das Windows Verhalten bei der Namensauflösung. Wenn im Client nach einer Freigabe gesucht wird, welche der bekannte DNS nicht auflösen kann, erfolgt die Abfrage mittels alternativer (Vorgänger-)Protokolle, z.B. LLMNR.

Diese Abfrage kann vom Angreifer abgefangen werden, der sich als entsprechender Server ausgibt und die Anfrage verändert weiterreicht. Denn ein NTLM-Hash beinhaltet keinerlei Angaben zu Ziel oder Absender. In unserem Fall erfolgt eine Abfrage der Sicherheitskontenverwaltung (SAM – Security Account Manager) zur Ausgabe aller lokal auf dem System abgelegten Passwort-Hashs der vorhandenen Benutzer:

Vor dem Start des responders sind in der Konfiguration die Optionen SMB und http zu deaktivieren. Der Responder lauscht auf dem Interface eth0.

Ntlmrelayx soll eine Weiterleitung an die IP 192.168.5.5 vornehmen, in diesem Falle der lokale Windows 10 Client. Der Dump der SAM-Daten ist Standardverhalten des Tools für SMB.

Die Ausgabe zeigt die entsprechenden LM- bzw. NT-Passwort Hashs der Nutzer, darunter z.B. Administrator und myUser. Diese Hashes können nun zu Offline-Angriffen auf die Passwörter mittels Brute-Force genutzt oder zur Authentifizierung in Windows-Domänen genutzt werden.

NTLM-Relay zu LDAP

Im nächsten Beispiel erfolgt eine Weiterleitung mittels IPv6 an LDAP. Dadurch kann durch einen unautorisierten Benutzer ohne Berechtigungen im AD eine Abfrage von Domäneninformationen erfolgen. Der Angriff erfolgt mittels mitm6 und ntlmrelayx.

Anschließend genügt es, wenn ein User auf dem Windows10-Client den Browser öffnet. Denn im Standardverhalten sucht dieser zuerst nach bereitgestellten Proxykonfigurationen, welche der Angreifer mittels mitm6 abfängt. Das Standardverhalten von ntlmrelayx bei einer Weiterleitung zu ldap ist die Abfrage von Domäneninformationen, welche im lokalen Verzeichnis abgelegt werden.

NTLM-Relay zu LDAPS

Zuletzt wird die Anfrage mittels LDAPS weitergeleitet. Der Versuchsaufbau ist dabei der gleiche wie im letzten Szenario, allerdings soll ntlmrelayx nun eine Verbindung zu LDAPS herstellen und dabei einen PC anlegen. Diesen könnten wir anschließend für weitere Angriffe verwenden.

Verhinderung: Möglichkeiten zur Verhinderung von Angriffen mittels NTLM-Relay

Die beste Vorgehensweise zur Verhinderung der genannten Angriffe ist die entsprechend, sichere Konfiguration des Netzwerks bzw. der beteiligten Komponenten. Einige Möglichkeiten, welche auch vor den beschriebenen Angriffen schützen, wurden bereits in unseren bisherigen Beiträgen vorgestellt, dazu zählen etwa „IPv6 – Man in the Middle“ oder „LLMNR Poisoning“. Darüber hinaus verhindern die folgenden Maßnahmen die Möglichkeit, die oben gezeigten Angriffe erfolgreich auszuführen.

Wie funktioniert Paket-Signierung?

Bei der Paket-Signierung wird jedes versendetes Paket mit einer Signatur versehen, diese ermöglicht es Client und Server festzustellen, dass dieses nicht verändert wurde. Es schützt jedoch nicht davor, dass Pakete mitgelesen werden können. Signierung darf hier nicht mit Verschlüsselung verwechselt werden.

Bei SMBv2 wird beispielsweise unter Berücksichtigung der gesamten Nachricht ein entsprechender Hash mittels HMAC-SHA256 berechnet.

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/a3e9ea1e-53c8-4cff-94bd-d98fb20417c0

Beispiel: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb/8b80e60b-7514-442b-baf4-eb785d0b0e2c

SMB Signierung

Die SMB-Signierung dient als Authentizitäts- und Integritäts-Merkmal für SMB-Pakete, die beim Ressourcenzugriff innerhalb des Active Directories genutzt werden. Client und Server signieren dabei die SMB-Pakete bei der Kommunikation, so dass verhindert werden kann, dass SMB-Pakete verändert oder weitergeleitet werden. (Details unter https://www.prosec-networks.com/blog/smb-server-message-block-protokoll/)

Eine entsprechende Signierung wird dabei erst ab Version SMBv2 empfohlen, da die Paketgröße bei SMBv1 so gering ist, dass es hier zu Performanceproblemen kommen kann. Weiterhin ist bei der Konfiguration darauf zu achten, dass die Signierung erzwungen (required) wird und diese nicht nur erwünscht bzw. ermöglicht (enabled) wird.

Die SMB Signierung kann durch GPOs an Servern und Clients konfiguriert werden. Wie immer wird auch an dieser Stelle geraten, dies in entsprechenden Teststellungen vor der Umsetzung zu prüfen!

Empfohlene Einstellungen:

Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) Aktiviert

Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) Deaktiviert

Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) Aktiviert

Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt) Deaktiviert

LDAP Signing

Analog zur Signierung mittels SMB, kann eine Signierung auch für LDAP eingestellt werden. LDAP-Signing versieht die LDAP-Verbindung mit einer digitalen Signatur.

Die Einstellung erfolgt ebenfalls mittels GPO auf dem Domänencontroller für Server und Client:

LDAP-Signaturanforderung für den Server (GPO):

Computer -> Richtlinien -> Windows Einstellungen -> Sicherheitseinstellungen -> lokale Richtlinien -> Sicherheitsoptionen -> “Domänencontroller: Serversignaturanforderungen für LDAP-Server“ aktivieren

LDAP-Signaturanforderung für den Clients, mittels DC Gruppenrichtlinie (GPO):

Computer -> Richtlinien -> Windows Einstellungen -> Sicherheitseinstellungen -> lokale Richtlinien -> Sicherheitsoptionen -> “ Netzwerksicherheit: LDAP-Clientsignierungsanforderungen –“ Aktivieren

LDAP Channel Binding

Ein fehlendes Channelbinding erlaubt es Authentifizierungen an LDAPS weiterzuleiten.

Beim Channelbinding wird ein Hash des Zertifikats (des Servers gebildet) und an das normale Paket angehangen. Der Server führt denselben Schritt durch und überprüft dann den Hash seines Zertifikats mit dem Hashwert der dem LDAPS Paket angehangen wurde.

Im März 2020 veröffentlichte Microsoft entsprechende Updates, um Channelbinding zu nutzen.

Hinweis: In der oben genannten Test-Umgebung müssen die Updates entsprechend installiert werden, da Channelbinding ansonsten nicht verfügbar ist.

– An Domain Controllern kann das Channel Binding über die Aktivierung der Gruppenrichtlinie „Domänencontroller: Anforderungen an das LDAP-Serverkanal-Bindungstoken“ konfiguriert werden. Diese befindet sich in der Gruppenrichtlinienverwaltung unter dem Pfad Computer > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen

– Die Richtlinie muss auf die Option „Immer“ konfiguriert werden und die Richtlinie muss aktiviert werden.

Hinweis: Ob LDAP Signing und Channelbinding aktiv sind, kann einfach mittels LdapRelayScan https://github.com/zyn3rgy/LdapRelayScan.git überprüft werden. Zur Überprüfung von LDAP Signing muss ein valider Domänen Nutzer verwendet werden.

Erkennung: Wie können Angriffe im Netzwerk erkannt werden

Der direkte Angriff kann nur schwer erkannt werden, da die Nutzung der beschriebenen Protokolle zum Standardverhalten im Netzwerk gehört. Eine Möglichkeit der Erkennung ist die Überwachung der Geräte im Netzwerk auf den dem Angriff zugrundeliegenden Protokolle (z.B.) LLMNR. Antworten auf diese Anfragen kommen in der Regel nicht von den im Netz vorhandenen Systemen, Details dazu unter: https://www.prosec-networks.com/blog/llmnr-poisoning/

Ebenso kann diese Erkennung in der Firewall konfiguriert werden. Die Antworten, die der Angreifer in oben vorgestellten Szenarien sendet, sollten nur von bekannten und autorisierten System erfolgen (LLMNR, wpad). Erfolgt im Netzwerk eine Antwort einer dazu nicht definierten IP, so kann der Angreifer dadurch ermittelt werden.

React: Auf erkannte Angriffe reagieren

Wird durch die im letzten Abschnitt beschriebenen Methoden ein Angriff erkannt, so sollten sie möglichst viele Informationen zu diesem erlangen. Anschließend sollte das entsprechende Gerät gesperrt werden.

Zusätzlich sollten alle vorhandenen Protokolle nach Aktivitäten dieser IP durchsucht werden. Dazu zählen neben den Logs der Firewalls und Netzwerkgeräte, insbesondere die Ereignisprotokolle der Domänencontroller.