In den letzten Monaten fanden Security Researcher viele Schwachstellen in Microsoft Produkten, die es im schlimmsten Fall ermöglichen die Rechte von einem nicht-authentisierten Zugriff zum Domain Administrator zu eskalieren. Dazu gehören ProxyLogon (CVE-2021-26855, CVE-2021-27065) und ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) von Orange Tsai, PetitPotam (VDB-179650) von topotam, sowie unterschiedliche Schwachstellen in unsicher konfigurierten Active Directory Certificate Services (ADCS) von Will Schroeder und Lee Christensen. Ein gemeinsamer Nenner ist die Verwendung respektive der Missbrauch des Authentisierungsprotokolls New Technology LAN Manager (NTLM).

Angreifer versuchen eine NLTM-Authentisierung eines Benutzers oder Maschine zu erzwingen, um diese für ihre Zwecke zu missbrauchen. Diese Technik wird als Coerced Authentication oder Forced Authentication bezeichnet. Der Missbrauch kann über direkte Anfragen oder indirekt über Machine-in-the-Middle-Angriffe (MitM) sowie ARP oder Multicast Poisoning bewerkstelligt werden. Das Tool Responder von Laurent Gaffie ist für die letztere Angriffstechnik ein beliebtes und zuverlässiges Werkzeug für Angreifer. Angreifer können die erzwungene NTLM-Authentisierung nutzen, um Zugangsdaten aus Challenge-Response-Hashes zu errechnen, oder diese an ein anderes System weiterzuleiten. Eine Übersicht über NTLM-Relay-Angriffe zeigt das Mindmap von Charlie Bromberg und diese werden unter der Seite NTLM-Relay-Angriffe dokumentiert.

NTLM stellt ein Sicherheitsrisiko in einer IT-Infrastruktur dar und sollte deaktiviert werden.

Einführung

Das Protokoll NTLM ist eine Challenge-Response-Authentisierung und verwendet dazu verschiedene Protokolle. Der Begriff NTLM sollte nicht mit der Hashfunktion von Windows verwechselt werden. Windows speichert den Hash von Passwörtern lokal in der SAM Datenbank und auf Domain Controllern in der Datei ntds.dit und verwendet die Hashfunktion NTHash, welche den Algorithmus MD4(UTF-16-LE(password)) nutzt. Der NTHash wird fälschlicherweise oft als NTLM bezeichnet.

NTLM setzt die folgenden Protokolle ein:

• LAN Manager Version 1 (LM)
• LAN Manager Version 2 (LMv2)
• NT LAN Manager Version 1 (NTLMv1 oder Net-NTLMv1)
• NT LAN Manager Version 2 (NTLMv2 oder Net-NTLMv2)
• NT LAN Manager 2 – Sitzungssicherheit

Die Funktionsweise der Protokolle werden im Artikel The NTLM Authentication Protocol and Security Support Provider ausführlich erklärt. NTLMv2 wird ab Windows NT 4.0 SP4 unterstützt. Seit Windows 2000 wird in einer Active-Directory-Infrastruktur das Protokoll Kerberos als primäre und bevorzugte Authentisierungsmethode eingesetzt. Aus Kompatibilitätsgründen ist NTLM jedoch in Windows 10 und Windows Server 2019 standardmässig aktiv. NTLM wird dann zur Authentisierung genutzt, wenn keine AD-Infrastruktur vorhanden ist, eine Authentisierung mit Systemen ausserhalb der Domäne stattfindet, Systeme über die IP-Adresse anstelle von Hostnamen oder DNS adressiert werden oder kein Domain Controller mittels Kerberos erreichbar ist.

NTLM deaktivieren

Die Abwärtskompatibilität und der Fallback-Einsatz erschwert es NTLM zu deaktivieren. Es kann daher zu Ausfällen kommen, wenn NTLM ohne jegliche Vorabklärung auf allen Systemen deaktiviert wird. Der “Microsoft Veteran” und Principal Program Manager im Bereich Windows Server Engineering Ned Pyle schrieb bereits 2009 im TechNet-Artikel NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7, dass das Blocken von NTLM nicht einfach sei und dazu eine Analyse und längere Vorbereitung notwendig ist.

Audit von NTLM

Es gibt drei Gruppenrichtlinien unter dem Pfad Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options, und die empfohlene Einstellung um eine Analyse durchzuführen lautet:

Die Richtlinie Audit NTLM authentication in this domain sollte nur auf Domain Controllern angewandt werden, die beiden Andern können auf allen Systemen appliziert werden. Die NTLM-Audit-Ereignisse werden in dem Event Log Applications And Services Logs\Microsoft\Windows\NTLM\Operational protokolliert.

Auswertung

Alle Ereignisse werden idealerweise in einer zentralen Log-/Monitoring-Infrastruktur gesammelt und ausgewertet. Bei Splunk kann beispielsweise die SplunkForwarder-Konfiguration in inputs.conf um den folgenden Eintrag erweitert werden:

[WinEvent Log://Microsoft-Windows-NTLM/Operational]
checkpointInterval = 5
current_only = 0
disabled = 0
start_from = oldest

Das Ziel ist es zu identifizieren, welche Systeme NTLM zur Authentisierung nutzen. NTLM wird in verschiedenen Protokollen wie HTTP oder SMB eingesetzt. Mit dem folgenden Splunk Query kann eine Liste von IP-Adressen von Zielservern generiert werden:

source="winEvent Log*" "LogName=Microsoft-Windows-NTLM/Operational"
| rex field=_raw "(?i)target\sserver:\s(?<IP>.*)" 
| dedup IP
| table IP

Diese Liste dient als Startpunkt für die Analyse, welche Systeme und Applikationen NTLM einsetzen. Dazu werden die Logdaten von Clients und Server korreliert. In Ereignissen mit der Event ID 8003 werden auf Server die durchgeführte Authentisierung protokolliert, daraus kann der Benutzer, Domain und die Workstation ausgelesen werden. Gleichzeitig wird auf dem Client unter der Event ID 8001 die ausgehende Verbindung aufgezeichnet. Daraus kann im Falle von Applikationen, die nicht über das SMB-Protokoll kommunizieren, das Zielsystem (Target server) und der Prozess (Name of client process) ausgelesen werden.

Im folgende Beispiel greift der Benutzer jdoe auf eine Webapplikation mit aktivierter Windows Authentication per IP-Adresse zu:

Message=NTLM client blocked audit: Audit outgoing NTLM authentication traffic that would be blocked.
Target server: HTTP/192.168.1.112
Supplied user: jdoe
Supplied domain: TEST
PID of client process: 5780
Name of client process: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
LUID of client process: 0xBE4B5
User identity of client process: jdoe
Domain name of user identity of client process: TEST

Der Client client01 baut eine Verbindung über die URL https://192.168.1.112 zum Webserver web01 auf. Für den Zugriff ist eine Authentisierung notwendig und da die IP-Adresse verwendet wird, einigen sich Webserver und Browser auf das Protokoll NTLM. Der Benutzer gibt seine Domain-Zugangsdaten ein, der Webserver nimmt diese entgegen und validiert die Zugangsdaten mit der Hilfe eines Domain Controllers. Anhand der Analyse der Logs ist bekannt, dass auf dem Client eine ausgehende NTLM-Verbindung zu 192.168.1.112 aufgebaut wird (Event ID 8001), auf dem Webserver die NTLM-Verbindung eingeht (Event ID 8002) und dieser die Prüfung der Zugangsdaten an einen DC weiterleitet (Event ID 8004).

Die Auditphase sollte über mehrere Monate fortgeführt werden. Innerhalb dieser Phase können bereits Logdaten analysiert und mögliche Fehlkonfigurationen behoben werden. Ein Beispiel für eine Fehlkonfiguration ist, dass der Zugriff über eine IP-Adresse anstelle des NetBIOS-Servernamen oder des vollqualifizierten Domänennamens (Fully qualified domain name, kurz FQDN) konfiguriert wurde.

Wenn die Anwendung oder der Dienst nur NTLM unterstützt, muss dies als Ausnahme erfasst werden. Das Ziel ist es jedoch so wenig Ausnahmen wie möglich zu haben.

Zum Abschluss der Auditphase sollte eine Ausnahmeliste vorliegen, die alle Systeme enthält, die eingehende NTLM-Verbindungen erhalten und von welchen Systemen der Zugriff möglich sein muss. Die Vollständigkeit der Liste ist essentiell für den Betrieb der Infrastruktur. Sobald NTLM blockiert wird, und ein System befindet sich nicht auf der Liste, wird diese Anwendung nicht mehr funktionieren.

Blocken von NTLM

Wenn NTLM geblockt wird, ist es auf einem System nicht vollständig deaktiviert, da der lokale Anmeldungsprozess weiterhin NTLM verwendet. Auch wenn NTLM blockiert wird, bleibt die Anmeldung mit einem lokalen Konto möglich.

Es gibt drei Gruppenrichtlinien für das Blocken von NTLM unter dem Pfad Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options, und die Einstellungen um NTLM vollständig zu blockieren lauten:

Die Einstellungen Incoming NTLM traffic und Outgoing NTLM traffic to remote servers können auf allen Systemen konfiguriert werden. Die Einstellung NTLM authentication in this domain ist für Domain Controller relevant.

Falls Ausnahmen für die Blockierung notwendig sind, stehen die Einstellungen unter dem Pfad Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options zur Verfügung:

• Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication
• Network security: Restrict NTLM: Add server exceptions in this domain

Mit der Einstellung Add remote server exceptions for NTLM authentication wird definiert, auf welche Systeme ein Client sich weiterhin über NTLM authentisieren kann. Als gültige Werte werden der NetBIOS-Servername, FQDN und IP-Adressen akzeptiert. Die Liste der Systeme, die weiterhin NTLM-Anfragen entgegen nehmen und sich innerhalb der Domäne befinden, muss in die Einstellung Add server exceptions in this domain aufgenommen werden. Diese Einstellung wird auf Domain Controllern gepflegt.

Anwendungsbeispiel

In einer Umgebung soll NTLM geblockt werden. Grundsätzlich können ein- und ausgehende NTLM-Verbindungen auf allen Systemen einer Domäne blockiert werden. Auf den Domain Controllern wird die Verwendung von NTLM innerhalb der Domäne zusätzlich deaktiviert. Ebenso wird auf den Domain Controllern eine Ausnahmeliste gepflegt. Zusätzlich müssen ausgehende NTLM-Verbindungen als Ausnahme auf den betroffenen Systemen deklariert werden. Diese Liste sollte auf die Bedürfnisse aufgeteilt und nicht als Ganzes verteilt werden.

Als Ausnahme wurde eine Webapplikation definiert, die einen IIS-Webserver mit Windows Authentication einsetzt. Die Angaben der involvierten Systeme sind in der folgenden Tabelle aufgelistet. Der DC dc01 steht exemplarisch für alle Domain Controller in der Domäne.

Die Einschränkung Outgoing NTLM traffic to remote servers betrifft in diesem Beispiel nur client01, da dort die ausgehende NTLM-Verbindung zu web01 geblockt wird (Event ID 4001). Daher wird die IP-Adresse von web01 in die Liste der Einstellung Add remote server exceptions for NTLM authentication aufgenommen. Idealerweise wird die Ausnahmeliste nur Clients zugewiesen, die den Zugriff auf die Webapplikation benötigen.

Da die Einstellung Incoming NTLM traffic auf den Wert Deny all accounts gesetzt wurde, wird die NTLM-Verbindung von client01 zu web01 auf dem Webserver geblockt (Event ID 4002). Gemäss der Dokumentation von Microsoft kann für Incoming NTLM traffic die Ausnahmenliste von Add server exceptions in this domain verwendet werden. Diese Ausnahme hatte in der Testumgebung jedoch nicht funktioniert, sodass die Einstellung Incoming NTLM traffic auf web01 auf den Wert Allow all konfiguriert werden musste.

Um NTLM innerhalb der Domain zu deaktivieren, wird die Einstellung NTLM authentication in this domain auf den Wert Deny all gesetzt. In diesem Beispiel wird daher die NTLM-Authentisierungsanfrage des Webservers auf dem DC geblockt (Event ID 4004). Daher wird web01 in die Liste der Einstellung Add server exceptions in this domain aufgenommen. In der Testumgebung musste der NetBIOS-Servername eingetragen werden, wenn der FQDN verwendet wurde, hatte die Ausnahme nicht geklappt.

Die Konfiguration für die Systeme inklusive den Ausnahmen sieht wie folgt aus:

Fazit

Das Authentisierungsprotokoll NTLM ist veraltet und unsicher und wurde durch Kerberos abgelöst. Seither wird NTLM aus Kompatibilitätsgründen weiter unterstützt und ist auch in der aktuellen Version von Windows noch aktiv. NTLM wird zudem für viele Angriffe missbraucht und erleichtert Angreifern eine Active-Directory-Infrastruktur zu kompromittieren.

Die Aufgabe NTLM zu blockieren muss in mehreren Schritten durchgeführt werden. Zuerst muss festgestellt werden, welche Systeme und Dienste NTLM noch nutzen. Dazu sollten die Audit-Einstellungen aktiviert und die Logs über Monate ausgewertet werden mit dem Ziel fehlerhafte Konfigurationen zu finden und die NTLM-Nutzung reduzieren zu können. Danach müssen die Ausnahmen definiert und die Konfiguration spezifiziert werden. Danach kann NTLM innerhalb der Domäne geblockt werden.

Die Hürde NTLM zu blockieren ist hoch, es ist keine einfache Aufgabe dies umzusetzen und das Risiko von Ausfällen besteht. Aber angesichts der vielen Angriffe und Schwachstellen in NTLM ist der Sicherheitsgewinn so gross, dass es sich lohnt das Projekt anzugehen. Es ist Zeit sich von NTLM zu verabschieden. Lebewohl.

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• http://davenport.sourceforge.net/ntlm.html
• https://attack.mitre.org/techniques/T1187/
• https://blog.orange.tw/2021/08/proxylogon-a-new-attack-surface-on-ms-exchange-part-1.html
• https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic
• https://g-laurent.blogspot.com/
• https://github.com/lgandx/Responder
• https://github.com/topotam/PetitPotam
• https://specterops.io/assets/resources/Certified_Pre-Owned.pdf
• https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/ntlm-blocking-and-you-application-analysis-and-auditing/ba-p/397191
• https://twitter.com/NerdPyle
• https://twitter.com/_nwodtuhs
• https://twitter.com/harmj0y
• https://twitter.com/orange_8361
• https://twitter.com/tifkin_
• https://twitter.com/topotam77
• https://vuldb.com/de/?id.170592
• https://vuldb.com/de/?id.170595
• https://vuldb.com/de/?id.174834
• https://vuldb.com/de/?id.178577
• https://vuldb.com/de/?id.178612
• https://vuldb.com/de/?id.179650
• https://www.thehacker.recipes/ad-ds/movement/ntlm/relay