NTLM-Authentifizierung

2. Der Ablauf der NTLM-Authentifizierung

Das NTLMv2-Protokoll verwendet einen NT-Hash in einem Challenge/Response-Austausch zwischen dem Server und dem Client. Der Ablauf der NTLM-Authentifizierung ist wie folgt:

1. NEGOTIATE: Der Client-Rechner sendet eine Anfrage mit dem Benutzernamen und weiteren Konfigurationsinformationen an einen Server.
2. CHALLENGE: Der Server generiert eine Zufallszahl und sendet diese zum Client-Rechner
3. AUTHENTICATE: Der Client-Rechner verschlüsselt die Zufallszahl mit dem DES-Algorithmus und dem NT-Hash des Passworts als Schlüssel, um zu beweisen, dass er das Passwort kennt.
4. Der Server überprüft die Identität des Benutzers, indem er sicherstellt, dass die Challenge tatsächlich mit dem richtigen Benutzer/Passwort erstellt wurde. Dazu verwendet er entweder den hinterlegten NT-Hash aus seiner eigenen SAM-Datenbank oder er leitet das Challenge/Response-Paar zur Validierung an den Domain Controller weiter.

3. Wie kann die NTLM-Authentifizierung angegriffen werden?

NTLM sendet zwar keine Kennwörter über das Netzwerk die abgefangen werden könnten, aber NTLMv1 ist nach heutigen Maßstäben ein sehr schwaches Authentifizierungsprotokoll. Und obwohl v2 sicherer ist als v1, ist es immer noch deutlich entfernt vom Nachfolgeprotokoll Kerberos.

Pass the Hash

Bei der NTLM-Authentifizierung ist der Hash des Kennwortes ein entscheidendes Element der Authentifizierung. Sollte also ein Angreifer den Benutzernamen und den Kennwort-Hash herausfinden, dann kann er direkt mit der NTLM-Authentifizierung Verfahren starten. Die Kenntnis des eigentlichen Kennwortes ist dabei nicht notwendig.

Diese Technik ist bekannt unter der Bezeichnung Pass the Hash und ist seit mehr als 20 Jahren bekannt.

Für einen Angreifer stellt sich die Frage wie Benutzernamen und Passwort-Hash erbeutet werden können. Benutzernamen gibt es aus Sicht des Angreifers recht einfach, beispielsweise unverschlüsselt im Netzwerkverkehr. Auch Passwort-Hashes sind recht leicht zu bekommen. Auf Endbenutzer-Systemen finden sich die Passwort-Hashes in der Datei

C:\Windows\System32\config\SAM

Die SAM-Datei kann von jedem Benutzer mit administrativen Rechten gelesen werden.

Ebenso werden die Password-Hashes auch im Speicher zwischengespeichert. Von dort können sich mit Tools wie Mimikatz extrahiert werden.

Auf der Serverseite werden Passwort-Hashes bei Domänencontrollern in der Datei

C:\Windows\ntds\ntds.dit

gespeichert. Dort sind die Hashes anfällig für DC-Sync-Angriffe. Sie verleiten einen Domänen Controller (DC) dazu die eigenen Passwort-Hashes mit jemand zu synchronisieren, der sich als ein anderer DC ausgibt.

Es gibt aber noch andere Möglichkeiten, an Hashes zu gelangen. Insbesondere wenn man direkten Zugriff auf das Netzwerk hat, können Tools wie Responder recht wirkungsvoll genutzt werden um solches Hashes zu bekommen..

Kennwort-Hashes werden außerdem für die Dauer der Sitzung im Speicher einer RDP-Verbindung (Remote Desktop Protocol) gesichert. Wenn ein Benutzer also die Verbindung trennt, ohne sich abzumelden, bleibt der Passwort-Hash im Speicher noch einige Zeit erhalten.

Zu den empfohlenen Gegenmaßnahmen gehören:

Brute-Force-Angriffe

Die NTLM-Authentifizierung ist auch anfällig für Brute-Force-Angriffe, da der Hash-Algorithmus, den das Protokoll verwendet ohne einen sogenannten Salt verwendet wird. Ein Salt fügt eine zufällige Zeichenkette zu einem Passwort hinzu, bevor dieses ge-hasht wird. Selbst wenn zwei Benutzer das gleiche Passwort wählen, unterscheiden sich dennoch die Passwort-Hashes.

Mit vorberechneten Hashes von Standardpasswörtern und einer Rainbow Table lassen sich praktikable Brute-Force-Angriffe durchführen, falls die Kennwortkomplexität und -länge nicht ausreichend gewählt wurde (Tipp: >15 Zeichen).

Keine Unterstützung für Mehrfaktor-Authentifizierung

Das NTLM-Authentifizierungsprotokoll unterstützt keine Multifaktor-Authentifizierung (MFA), so dass es genügt einen Kennwort-Hash abzugreifen. Einen zweiten Faktor wie eine Authenticator-App, einen Hardware-OTP-Token oder eine SMS wird grundsätzlich nicht verwendet.

NTLM-Relay-Angriff

Die NTLM-Authentifizierung ist auch anfällig für NTLM-Relay-Angriffe.

Der Client des Benutzers hat grundsätzlich keine Möglichkeit, die Identität des Servers zu überprüfen. Daher können sich Angreifer zwischen Client und Server hängen und sich als Man-in-the-middle betätigen.

Momentan wird sie auch bei Penetrationstests häufig mit überprüft, da in den letzten Jahren Schwachstellen entdeckt wurde, die diesen Angriffsvektor wieder praktikable machten.

Weitere Schwachstellen

Bei NTLM werden alle Kleinbuchstaben in einer Kennwortfolge vor der Erstellung des Hashwerts in Großbuchstaben umgewandelt, was die mögliche Komplexität einschränkt. Als Folge dauert es bei bekanntem Hash-Wert 2,5 Stunden, um ein Passwort mit 8 Zeichen herauszufinden (Stand 2019, Workstation mit 8xGPU und HashCat).

Auch verwendet NTLMv1 eine 16-Byte-Zufallszahl für die Challenge, die in der Praxis doch nicht so sehr zufällig ist.

In NTLMv2 hingegen ist es eine Challenge variabler Länge, was deutlich stärker ist. Auch fügt der Verschlüsselungsschritt bei NTLMv2 einen Zeitstempel hinzu.

Sowohl NTLMv1 als auch NTLMv2 nutzen die als veraltete Hash-Funktion MD4. Aus kryptographischer Sicht ist diese zwar gebrochen, dennoch ist sie in dem speziellen Anwendungsfall bei NTLM für die Praxis weiterhin als recht stabil anzusehen.

4. Warum wird die NTLM-Authentifizierung noch verwendet?

Microsoft hat NTLM bereits in Windows 2000 durch Kerberos als Standard-Authentifizierungsprotokoll ersetzt.

Dennoch wird die NTLM-Authentifizierung weiterhin von Windows aus Gründen der Abwärtskompatibilität unterstützt. Es gibt noch eine Reihe von alter Software, die NTLMv2 oder sogar NTLMv1 verwendet.

Viele der betroffenen Anwendungen wurden Ende der 1990er und in den frühen 2000er Jahren entwickelt. Oftmals sind die Anwendungen nicht mehr vom Hersteller unterstützt oder wurden als Spezialanwendung direkt für ein Unternehmen programmiert.

5. Unterschied zwischen dem Nachfolger Kerberos und NTLM

Einer der wichtigsten Unterschiede zwischen NTLM und Kerberos besteht in einem geänderten Authentifizierungsvorgang.

Der Authentifizierungsprozess selbst läuft nicht mehr als zweistufiges Challenge/Response ab, sondern ist dreistufig ausgelegt.

Ebenso hat Kerberos andere kryptographische Eigenschaften als NTLM. Die Hashfunktion die NTLM für erstellung des Passwort-Hashes nutzt wurde durch eine Verschlüsselungsfunktion ersetzt.

Zusammenfassend lässt sich sagen, dass Kerberos das deutlich sicherere Protokoll ist. Aber auch Kerberos ist nicht ganz frei von Sicherheitsproblemen.

6. Vorgehen zum Abschalten von NTLM

Als Strategie empfehle ich ein gestuftes Vorgehen.

1. Audit: Zuerst ist die Frage zu klären welche Anwendungen das NTLM-Protokoll noch benötigen. Eine Überprüfung per Gruppenrichtlinie Network security: Restrict NTLM: Audit NTLM authentication in this domain lässt sich leicht aktivieren ohne den Betrieb zu stören. Zusätzliche Tools können auch die Version des Protokolls mit in Erfahrung bringen.
2. Härtung Clients: Mit diesen Informationen kann geprüft werden, ob die fraglichen Anwendungen so konfiguriert werden können, dass ausschließlich ein stärkeres Protokoll (NTLMv2 oder optimalerweise Kerberos) verwendet wird. Updates sollten dabei geprüft und entsprechend priorisiert werden.
3. Härtung Server: Falls möglich sollten NTLMv1 und NTLMv2 vollständig per Gruppenrichtlinie deaktiviert werden. Die Einrichtung einer Ausnahmeliste ist möglich, falls sich Anwendungen nicht updaten lassen und NTLM weiterhin benötig werden sollte.

7. Kann man NTLM noch sicher verwenden?

Die Nutzung von NTLM sollte im Netzwerk minimiert oder vollständig deaktiviert werden. Unternehmen, die aus Kompatibilitätsgründen weiterhin NTLM zwingend einsetzen müssen, sollten die folgenden Punkte beachten.

1. SMB-Signierung: . Um Angreifer daran zu hindern, einfachere NTLM-Relay-Angriffe zu starten, sollten die SMB-Signierung auf allen Computern im Netzwerk aktiviert sein.
2. Blockieren von NTLMv1: Da NTLMv1 ist vollständig unsicher. Es sollte über die entsprechende Gruppenrichtlinie vollständig blockiert werden.
3. LDAP/S-Signierung: . Um NTLM-Relay in LDAP zu verhindern, muss die LDAP-Signierung und die LDAPS-Kanalbindung auf Domänencontrollern aktiviert werden.
4. Enhanced Protection for Authentication (EPA): . Um NTLM-Relay auf Webservern zu verhindern, sollten alle Webserver (OWA, ADFS) so konfiguriert werden, dass sie nur Anfragen mit EPA akzeptieren.

Grundsätzlich sind die folgenden weiteren Maßnahmen auch sehr empfehlenswert. Sie führen zu einer Härtung der gesamten IT-Landschaft.

• Laufendes und regelmäßiges Patchen aller IT-Systeme
• Defender Windows Credential Guard aktivieren
• Begrenzen der Konten mit Administratorrechten
• Keine Verwendung des Remote Desktop Protocol (RDP) zur Verwaltung von Clients
• Remote Management nur von gehärteten Jump-Hosts aus
• Falls nötig: Nutzung von Microsoft Local Administrator Password Solutions (LAPS)
• Einschränken von Client-zu-Client Kommunikation, beispielsweise mit einer Firewall um Lateral Movement zu erschweren