Die IT-Welt steht vor einem bedeutenden Wendepunkt: Das Authentifizierungsprotokoll NTLM (NT LAN Manager), das seit Jahrzehnten das Rückgrat der Windows-Netzwerke bildet, wird nun endgültig in den Ruhestand geschickt. Was lange Zeit als notwendiges Übel für die Abwärtskompatibilität galt, wird heute von Experten wie Google Mandiant als eines der größten Sicherheitsrisiken moderner Infrastrukturen eingestuft.

Sie nutzen in Ihrem Unternehmen wahrscheinlich noch immer Anwendungen oder Drucker, die auf NTLM angewiesen sind. Doch die aktuelle Bedrohungslage lässt keinen Spielraum mehr für Nostalgie. Microsoft hat den Prozess zur Deaktivierung eingeleitet, und Google Mandiant liefert mit neuesten Erkenntnissen zu Rainbow Tables den letzten Beweis: NTLM ist nicht mehr sicher. In diesem Artikel erfahren Sie, warum der „Todesstoß“ für NTLM überfällig ist und wie Sie den Übergang zu moderneren Protokollen wie Kerberos meistern.

Warum NTLM heute ein massives Sicherheitsrisiko darstellt

Obwohl NTLM über die Jahre in verschiedenen Versionen (NTLMv1, NTLMv2) aktualisiert wurde, sind die grundlegenden Schwächen im Design geblieben. In einer Zeit, in der Ransomware-Angriffe und staatlich geförderte Spionage an der Tagesordnung sind, ist ein Protokoll, das auf veralteten Hashing-Verfahren basiert, eine offene Tür für Angreifer.

Die Gefahr durch NTLMv1 und Rainbow Tables

Google Mandiant hat kürzlich verdeutlicht, dass insbesondere NTLMv1 durch die Verwendung von Rainbow Tables (vorberechnete Tabellen von Hashes) innerhalb von Sekunden geknackt werden kann. Angreifer müssen lediglich den Netzwerkverkehr abfangen, um an die Passwörter der Benutzer zu gelangen. Da NTLMv1 keine moderne Kryptografie nutzt, ist es gegen Brute-Force-Angriffe nahezu schutzlos.

Pass-the-Hash und Relay-Angriffe

Eines der bekanntesten Konzepte im Bereich der Windows-Exploits ist der Pass-the-Hash-Angriff. Da NTLM den Hash des Passworts direkt für die Authentifizierung nutzt, muss ein Angreifer das Klartext-Passwort gar nicht kennen. Es reicht aus, den Hash aus dem Arbeitsspeicher eines kompromittierten Systems zu extrahieren, um sich als legitimer Benutzer im Netzwerk zu bewegen.

Die Rolle von Google Mandiant beim „Todesstoß“

Die Sicherheitsforscher von Google Mandiant haben eine klare Botschaft an die IT-Welt gesendet: Wer NTLM weiterhin einsetzt, handelt grob fahrlässig. Durch die Analyse von realen Angriffsszenarien konnten sie zeigen, dass NTLM oft der erste Dominostein ist, der bei einem Einbruch fällt.

• Veraltete Infrastruktur: Viele Unternehmen schleppen NTLM nur deshalb mit, weil sie Angst vor Funktionsstörungen bei Legacy-Systemen haben.
• Sichtbarkeit: Mandiant betont, dass viele Administratoren gar nicht wissen, an welchen Stellen in ihrem Netzwerk NTLM noch aktiv genutzt wird.
• Automatisierte Angriffe: Tools wie „Responder“ können NTLM-Anfragen im lokalen Netzwerk provozieren und abfangen, was ohne zusätzliche Absicherung (wie SMB-Signing) fatal endet.

Der Microsoft-Fahrplan: Von der Abkündigung zur Deaktivierung

Microsoft hat offiziell angekündigt, dass NTLM in künftigen Versionen von Windows und Windows Server standardmäßig deaktiviert wird. Dieser Schritt ist Teil einer breiteren Initiative zur Härtung des Betriebssystems („Secure Future Initiative“).

NTLM Management Tools

Um den Übergang zu erleichtern, bietet Microsoft neue Werkzeuge an, mit denen Administratoren die NTLM-Nutzung auditieren können. Ziel ist es, die Abhängigkeiten zu identifizieren, bevor die harte Abschaltung erfolgt.

Kerberos als der rechtmäßige Nachfolger

Der empfohlene Pfad führt weg von NTLM hin zu Kerberos. Kerberos bietet eine ticketbasierte Authentifizierung, die deutlich robuster gegen Replay-Angriffe ist und moderne Verschlüsselungsstandards wie AES-256 unterstützt.

Schritt-für-Schritt-Analyse: So identifizieren Sie NTLM-Abhängigkeiten

Bevor Sie den Schalter umlegen, müssen Sie verstehen, wo NTLM in Ihrer Umgebung noch „lebt“. Eine voreilige Deaktivierung kann geschäftskritische Prozesse lahmlegen.

1. Event-Logs aktivieren: Nutzen Sie die Gruppenrichtlinien, um das „Audit NTLM“ zu aktivieren. Dies schreibt Ereignisse in das Windows-Ereignisprotokoll, sobald eine NTLM-Authentifizierung stattfindet.
2. Analyse der Quellsysteme: Identifizieren Sie, welche Server und Clients NTLM-Anfragen senden. Oft sind es alte Scanner, Multifunktionsdrucker oder Linux-Systeme mit veralteten Samba-Konfigurationen.
3. Applikations-Checks: Prüfen Sie hausinterne Software. Entwickler haben in der Vergangenheit oft auf die einfache NTLM-Schnittstelle zurückgegriffen, anstatt eine saubere Kerberos-Implementierung umzusetzen.

Die technischen Hürden beim Umstieg auf Kerberos

Kerberos ist sicherer, aber auch komplexer in der Handhabung. Während NTLM oft „einfach funktioniert“, erfordert Kerberos eine präzise Konfiguration von Service Principal Names (SPNs) und eine korrekte DNS-Auflösung.

Herausforderung: Service Principal Names (SPN)

Ein häufiger Grund, warum Kerberos-Authentifizierungen fehlschlagen und das System auf NTLM zurückfällt, sind fehlende oder doppelte SPNs. Sie müssen sicherstellen, dass jeder Dienst im Active Directory eindeutig identifizierbar ist.

Herausforderung: Zeit-Synchronisation

Kerberos-Tickets haben eine begrenzte Gültigkeit. Wenn die Uhrzeit zwischen Client, Server und Domain Controller um mehr als fünf Minuten abweicht, schlägt die Authentifizierung fehl. Eine robuste NTP-Konfiguration ist daher Pflicht.

Best Practices für eine sichere Übergangsphase

Solange Sie NTLM nicht vollständig deaktivieren können, sollten Sie es so sicher wie möglich konfigurieren.

• NTLMv1 verbieten: Stellen Sie sicher, dass per Gruppenrichtlinie mindestens „Nur NTLMv2-Antworten senden“ konfiguriert ist.
• SMB-Signing erzwingen: Verhindern Sie Relay-Angriffe, indem Sie die digitale Signatur für SMB-Pakete zwingend vorschreiben.
• EPA (Extended Protection for Authentication): Aktivieren Sie EPA für Dienste wie IIS oder SQL, um eine Bindung zwischen der TLS-Sitzung und der Authentifizierung herzustellen.

Fazit: Handeln Sie jetzt, bevor es zu spät ist

Das Ende von NTLM ist keine theoretische Diskussion mehr – es ist eine technische Notwendigkeit. Die Analysen von Google Mandiant und die klaren Schritte von Microsoft lassen keinen Zweifel daran, dass NTLM ein Relikt der Vergangenheit ist, das in einem modernen Sicherheitskonzept keinen Platz mehr hat.

Beginnen Sie noch heute mit dem Audit Ihrer Umgebung. Identifizieren Sie Legacy-Systeme und planen Sie den Umstieg auf Kerberos. Jedes System, das Sie von NTLM befreien, ist ein potenzieller Angriffspunkt weniger in Ihrem Netzwerk.

Ihre Handlungsaufforderung (CTA): Prüfen Sie Ihre Active Directory Gruppenrichtlinien! Haben Sie das NTLM-Auditing bereits aktiviert? Erstellen Sie noch diese Woche einen Bericht über die verbleibende NTLM-Nutzung in Ihrem Unternehmen und setzen Sie sich eine Deadline für die Deaktivierung von NTLMv1. Sicherheit ist kein Zustand, sondern ein fortlaufender Prozess.

Microsoft gibt bekannt, dass die Sicherheitsupdates vom April 2025 auf einigen Windows Server 2025-Domänencontrollern Authentifizierungsprobleme verursachen.

Die Liste der betroffenen Plattformen umfasst Windows Server 2016, Windows Server 2019, Windows Server 2022 und die neueste Version, Windows Server 2025.

Wie das Unternehmen jedoch weiter erklärte, ist es unwahrscheinlich, dass Privatanwender von diesem bekannten Problem betroffen sind, da Domänencontroller in der Regel für die Authentifizierung in Unternehmen und Organisationen verwendet werden.

„Nach der Installation des monatlichen Windows-Sicherheitsupdates vom 8. April 2025 (KB5055523) oder später können bei Active Directory-Domänencontrollern (DC) Probleme bei der Verarbeitung von Kerberos-Anmeldungen oder -Delegierungen auftreten, die zertifikatsbasierte Anmeldeinformationen verwenden, die auf der Schlüsselvertrauensstellung über das Active Directory-Feld „msds-KeyCredentialLink“ basieren“, erklärte Microsoft in einem Windows-Release-Health-Update.

„Dies kann zu Authentifizierungsproblemen in Windows Hello for Business (WHfB)-Schlüsselvertrauensumgebungen oder Umgebungen führen, in denen die Geräte-Public-Key-Authentifizierung (auch als Machine PKINIT bekannt) bereitgestellt wurde.“

Diese Probleme können auch Software betreffen, die für die Authentifizierung auf diese beiden Funktionen angewiesen ist, darunter unter anderem Single-Sign-On-Lösungen (SSO) von Drittanbietern, Identitätsmanagementsysteme und Smartcard-Authentifizierungsprodukte.

Zu den betroffenen Authentifizierungsprotokollen gehören Kerberos Public Key Cryptography for Initial Authentication (Kerberos PKINIT) und Certificate-based Service-for-User Delegation (S4U) über Kerberos Resource-Based Constrained Delegation (RBKCD oder A2DF Delegation) oder Kerberos Constrained Delegation (KCD oder A2D2 Delegation).

Authentifizierungsprobleme im Zusammenhang mit den Sicherheitspatches CVE-2025-26647

Laut Microsoft stehen diese Probleme im Zusammenhang mit Sicherheitsmaßnahmen , die eine schwerwiegende Sicherheitslücke mit der Kennung CVE-2025-26647 beheben sollen. Diese Sicherheitslücke kann es authentifizierten Angreifern ermöglichen, durch Ausnutzen einer Schwachstelle bei der Eingabevalidierung in Windows Kerberos, das [NTLM ersetzt hat](https://answers. microsoft.com/en-us/msoffice/forum/all/ntlm-vs-kerberos/d8b139bf-6b5a-4a53-9a00-bb75d4e219eb) als neues Standardauthentifizierungsprotokoll für domänenverbundene Geräte auf allen seit Windows 2000 veröffentlichten Windows-Versionen ersetzt wurde.

„Ein Angreifer, der diese Sicherheitslücke erfolgreich ausnutzt, könnte vom Key Distribution Center viel mehr Rechte für das Zertifikat erhalten als beabsichtigt„, erklärt Redmond.

“Ein authentifizierter Angreifer könnte diese Sicherheitslücke ausnutzen, indem er von einer Zertifizierungsstelle (CA) ein Zertifikat mit dem Wert des Ziel-Subject Key Identifier (SKI) erhält. Der Angreifer könnte dann dieses Zertifikat verwenden, um vom Key Distribution Center (KDC) ein Ticket Granting Ticket (TGT) für den Zielbenutzer zu erhalten.“

Als Workaround wird betroffenen Kunden empfohlen, den Registrierungswert „AllowNtAuthPolicyBypass“ in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc von „2“ auf „1“ zu ändern, wie in diesem Support-Dokument beschrieben.