Autor: Salman Dolatpanah Gortlar
Stand: Oktober 2026
NTLM gehört zu den langlebigsten Authentifizierungsmechanismen in Windows-Umgebungen. Gleichzeitig ist es seit Jahren ein attraktives Ziel für Angreifer, weil bestimmte Angriffswege nicht das Klartext-Passwort benötigen. Stattdessen kann unter bestimmten Voraussetzungen bereits ein gestohlener NT Hash ausreichen, um sich gegenüber einem entfernten Dienst als Benutzer auszugeben. Dieses Prinzip ist als Pass-the-Hash bekannt.
Microsoft hat NTLM inzwischen offiziell als veraltet eingestuft. In Windows Server 2025 ist NTLMv1 entfernt, NTLMv2 funktioniert weiterhin, befindet sich aber nicht mehr in aktiver Feature-Entwicklung und soll langfristig ebenfalls verschwinden. Für Active-Directory-Umgebungen ist Kerberos die bevorzugte Authentifizierung.
Was ist NTLM?
NTLM ist eine Familie von Challenge-Response-Protokollen für Windows-Authentifizierung. Vereinfacht gesagt wird das Passwort nicht direkt über das Netzwerk übertragen. Stattdessen nutzt das Protokoll kryptografisch abgeleitete Werte, um auf eine Challenge zu antworten.
Historisch war das ein Fortschritt gegenüber noch älteren Verfahren. Moderne Unternehmensnetze haben jedoch andere Anforderungen: gegenseitige Authentifizierung, stärkere Kryptografie, Delegation, Service Principal Names und Schutz gegen Relay- oder Credential-Theft-Szenarien. In Active Directory erfüllt Kerberos diese Anforderungen deutlich besser.
Was ist ein NT Hash?
Windows speichert für bestimmte Authentifizierungsszenarien einen kryptografischen Hash des Kennworts. Dieser NT Hash ist kein Klartext-Passwort. Das Problem: In einigen NTLM-basierten Szenarien kann der Hash selbst als wertvolles Authentifizierungsgeheimnis dienen.
Das erklärt, warum der Satz „Das Passwort wurde doch nicht gestohlen“ in einer Incident-Analyse zu kurz greift. Ein Angreifer kann versuchen, Credential-Material aus einem kompromittierten System zu extrahieren und anschließend für weitere Authentifizierungsversuche zu verwenden.
Pass-the-Hash: Authentifizieren ohne das Passwort zu kennen
Bei einem Pass-the-Hash-Angriff versucht ein Angreifer, einen gestohlenen Hash für eine NTLM-Authentifizierung zu verwenden, ohne das ursprüngliche Passwort zurückzurechnen. Microsoft beschreibt diese Angriffsklasse ausdrücklich in seiner Dokumentation zu Credential Guard und Protected Users.
Für Verteidiger ist entscheidend: Pass-the-Hash ist keine Passwort-Cracking-Technik. Der Angreifer muss das Klartext-Passwort nicht zwingend kennen. Genau deshalb ist der Schutz von Credential-Material im Speicher so wichtig.
Warum administrative Konten besonders gefährlich sind
Wenn ein hochprivilegiertes Konto auf einem kompromittierten Endpunkt verwendet wird, können dort besonders wertvolle Anmeldeinformationen oder Tokens entstehen. Ein lokaler Administrator, Domain Admin oder Service Account hat einen deutlich höheren „Wert“ für einen Angreifer als ein normales Benutzerkonto.
Das ist ein Grundprinzip von Tiering- und Privileged-Access-Konzepten: Hochprivilegierte Konten sollten nicht auf normalen Clients für Browsing, E-Mail oder tägliche Büroarbeit verwendet werden.
NTLM deaktivieren bedeutet nicht automatisch, dass keine Hashes mehr gestohlen werden können
Dieser Punkt wird häufig missverstanden. Die Deaktivierung von NTLM verhindert nicht automatisch die Entstehung oder den Diebstahl jedes Credential-Hashes. Sie reduziert jedoch die Möglichkeit, gestohlene NTLM-bezogene Credentials in NTLM-Authentifizierungsszenarien zu verwenden.
Deshalb sollte die Migration weg von NTLM immer mit weiteren Schutzmaßnahmen kombiniert werden: Credential Guard, Privileged Access, LSA-Schutz, moderne MFA-Verfahren, Kerberos-Härtung und möglichst wenige langlebige Secrets.
Microsofts Richtung: Kerberos und Negotiate statt NTLM
Microsoft empfiehlt Anwendungen, NTLM-Aufrufe durch Negotiate zu ersetzen. Negotiate versucht bevorzugt Kerberos und kann in Übergangsszenarien auf NTLM zurückfallen. Damit lässt sich eine Migration schrittweise durchführen, ohne jede Altanwendung an einem einzigen Stichtag abzuschalten.
Windows Server 2025 markiert dabei einen wichtigen Punkt: NTLMv1 ist entfernt, NTLMv2 ist deprecated. Unternehmen sollten diese Zeit nutzen, um Abhängigkeiten systematisch zu finden, statt auf eine zukünftige harte Entfernung zu warten.
Warum „einfach NTLM per GPO blockieren“ riskant sein kann
In vielen gewachsenen Umgebungen existieren versteckte NTLM-Abhängigkeiten. Typische Beispiele sind ältere Web-Anwendungen, SQL-Verbindungen, Reporting-Systeme, Geräte, NAS-Systeme, Scanner, Services mit IP-basierter Verbindung oder Anwendungen mit falsch konfigurierten SPNs.
Eine produktive Abschaltung ohne Voranalyse kann deshalb Ausfälle verursachen. Der bessere Weg ist:
- NTLM-Auditing aktivieren,
- Quellen und Zielsysteme identifizieren,
- Abhängigkeiten nach Kritikalität klassifizieren,
- Kerberos-fähige Alternativen testen,
- SPNs, DNS und Service Accounts korrigieren,
- zunächst kontrollierte Testfenster durchführen,
- danach schrittweise blockieren.
Welche Rolle spielt Kerberos?
Kerberos verwendet Tickets statt eines Challenge-Response-Verfahrens wie NTLM. In einer Active-Directory-Domäne kann der Client zunächst ein Ticket Granting Ticket erhalten und anschließend Service Tickets für konkrete Dienste anfordern. Dadurch können Dienste eindeutig über SPNs adressiert werden.
Kerberos bietet wichtige Vorteile, darunter gegenseitige Authentifizierung und ein Design, das besser zu modernen Domänenumgebungen passt. Es ist jedoch kein Selbstläufer: Falsche DNS-Auflösung, fehlende oder doppelte SPNs und ungeeignete Service Accounts können dazu führen, dass Anwendungen auf NTLM zurückfallen.
Credential Guard als zusätzliche Schutzschicht
Microsoft Defender Credential Guard nutzt Virtualization-based Security, um bestimmte Secrets wie NTLM-Hashes und Kerberos-TGTs von normalen Betriebssystemprozessen zu isolieren. Microsoft nennt ausdrücklich Pass-the-Hash und Pass-the-Ticket als Angriffsklassen, gegen die Credential Guard zusätzlichen Schutz bietet.
Das ist besonders wichtig: Der sicherste Weg ist nicht nur, ein altes Protokoll zu deaktivieren, sondern auch die Credentials selbst besser zu schützen.
Weitere sinnvolle Maßnahmen
- Protected Users für besonders sensible Konten prüfen,
- lokale Administratorpasswörter mit Windows LAPS verwalten,
- Service Accounts auf gMSA migrieren, wo möglich,
- SMB Signing und weitere Protokollhärtung prüfen,
- Extended Protection for Authentication bei geeigneten Webdiensten einsetzen,
- privilegierte Logons auf administrativ verwaltete Systeme beschränken,
- Passkeys oder phishing-resistente MFA für Cloud- und Hybrididentitäten verwenden.
Wie sieht eine saubere NTLM-Migration aus?
Eine professionelle Migration beginnt nicht mit der Abschaltung, sondern mit Messbarkeit. Unternehmen sollten zuerst wissen, welche Systeme tatsächlich noch NTLM verwenden. Danach wird jede Abhängigkeit einzeln bewertet: Kann die Anwendung Kerberos? Wird ein FQDN statt einer IP verwendet? Existiert der SPN? Läuft der Dienst unter dem richtigen Konto? Funktioniert die Authentifizierung auch nach einem Neustart?
Erst wenn diese Fragen beantwortet sind, sollte das Blocking stufenweise verschärft werden. Gute Rollback-Pläne und gespeicherte Logs gehören zu jedem Testfenster.
Fazit: NTLM ist heute vor allem technische Schuld
NTLM ist 2026 weniger ein Feature, das Unternehmen aktiv einsetzen möchten, sondern häufig eine Altlast, die unbemerkt weiterläuft. Genau diese Altlast kann Angreifern zusätzliche Möglichkeiten geben, gestohlene Credentials zu verwerten.
Die nachhaltige Strategie lautet deshalb: NTLM-Abhängigkeiten sichtbar machen, Kerberos korrekt implementieren, Credentials mit Credential Guard und Privileged-Access-Konzepten schützen und NTLM kontrolliert zurückbauen.
Quellen und weiterführende Informationen
Microsoft Learn: NTLM overview in Windows Server
Microsoft Learn: Deprecated features in Windows Server 2025
Microsoft Learn: Credential Guard overview
Microsoft Learn: Protected Accounts and Pass-the-Hash