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.

Die Uhr tickt für veraltete Verschlüsselungsprotokolle in Microsoft-Umgebungen. Mit der Ankündigung der endgültigen Kerberos RC4 Abschaltung im Sommer 2026 setzt Microsoft einen entscheidenden Schritt in Richtung einer sichereren Identitätsinfrastruktur. Für IT-Administratoren und Sicherheitsverantwortliche bedeutet dies jedoch: Handeln Sie jetzt.

Das Kerberos RC4-Protokoll (Rivest Cipher 4) ist ein Relikt aus den 90er Jahren. In einer modernen Bedrohungslandschaft stellt es ein signifikantes Sicherheitsrisiko dar, da es anfällig für diverse Angriffsvektoren ist, die es Angreifern ermöglichen könnten, Identitäten zu kompromittieren und sich seitlich durch Ihr Netzwerk zu bewegen.

In diesem umfassenden Leitfaden analysieren wir die Hintergründe der Abschaltung, basierend auf den neuesten Informationen von Microsoft. Wir führen Sie Schritt für Schritt durch den Prozess der Identifizierung von RC4 in Ihrem Netzwerk, zeigen Ihnen, wie Sie die moderne Alternative AES implementieren und welche Voraussetzungen Sie zwingend erfüllen müssen, um einen Systemausfall im Jahr 2026 zu verhindern. Warten Sie nicht bis zur letzten Minute – die Migration erfordert Zeit, Analyse und Sorgfalt.

Warum die Kerberos RC4 Abschaltung notwendig ist

Die Sicherheitsrisiken von RC4

RC4 ist eine Stromchiffre, die für ihre Einfachheit und Geschwindigkeit bekannt war. Doch kryptografische Forschungen haben über die Jahre massive Schwachstellen aufgedeckt. In der Welt von Kerberos bedeutet die Nutzung von RC4, dass die Tickets (TGTs und Service Tickets), die für die Authentifizierung im Netzwerk genutzt werden, mit einem schwachen Algorithmus verschlüsselt sind.

Angreifer können diese Schwäche durch Methoden wie „Kerberoasting“ ausnutzen. Wenn ein Angreifer ein RC4-verschlüsseltes Ticket abfängt, kann er dieses offline extrem schnell knacken („Brute Force“), um an das Passwort des Dienstkontos oder des Benutzers zu gelangen. Microsoft betont in seiner Ankündigung vom Dezember 2025, dass die Entfernung von RC4 nicht mehr optional, sondern essenziell für die Integrität des Active Directory ist.

Der Zeitplan: Sommer 2026

Laut offiziellen Quellen von Microsoft wird die Unterstützung für RC4 in Kerberos-Authentifizierungen mit den Updates im Sommer 2026 standardmäßig deaktiviert und die Nutzung technisch unterbunden. Das bedeutet, dass Systeme, die bis dahin nicht auf AES umgestellt wurden, keine Authentifizierung mehr durchführen können. Dies betrifft:

• Anmeldungen von Benutzern an Computern.
• Zugriffe auf Dateiserver und Drucker.
• Authentifizierungen von Webservern und Datenbanken.
• Legacy-Applikationen, die fest auf RC4 kodiert sind.

Zwingende Voraussetzungen für die AES-Migration

Bevor Sie technische Maßnahmen ergreifen, müssen Sie sicherstellen, dass Ihre Infrastruktur bereit für den Wechsel von Kerberos RC4 zu AES (Advanced Encryption Standard) ist. AES ist der heutige Goldstandard für Kerberos-Verschlüsselung in Windows.

1. Domain Functional Level (DFL)

Ihre Domänen- und Gesamtstrukturfunktionsebene sollte mindestens auf Windows Server 2008 R2 liegen, idealerweise jedoch auf Windows Server 2016 oder höher. Während AES technisch bereits ab Server 2008 (Vista) unterstützt wird, bieten neuere Funktionsebenen bessere Verwaltungsoptionen und Sicherheitspatches.

2. Client- und Server-Betriebssysteme

Alle beteiligten Geräte müssen AES unterstützen.

• Unterstützt: Windows Vista / Server 2008 und neuer (inklusive Windows 10, 11, Server 2019, 2022, 2025).
• Nicht unterstützt: Windows XP, Server 2003 (Diese Systeme sollten sich ohnehin nicht mehr in einem produktiven Netzwerk befinden).

3. Updates und Patches

Stellen Sie sicher, dass alle Domain Controller (DCs) und Clients vollständig gepatcht sind. Microsoft hat in den letzten Jahren mehrere Updates veröffentlicht, die die Logik der Verschlüsselungsaushandlung verbessert haben.

4. Kennwort-Resets (Kritisch)

Ein häufig übersehener Punkt: Der krbtgt-Account (das Konto, das die Kerberos Tickets signiert) muss AES-Schlüssel besitzen. Wenn Ihre Domäne vor langer Zeit erstellt wurde und das Passwort des krbtgt-Kontos nie geändert wurde, fehlen möglicherweise die AES-Schlüssel im Active Directory.

• Maßnahme: Setzen Sie das Kennwort des krbtgt-Kontos zweimal zurück (um sicherzustellen, dass die Replikation greift und alte Tickets ungültig werden – beachten Sie hierbei die Wartezeit zwischen den Resets).

Anleitung: Prüfung auf Kerberos RC4 Nutzung

Bevor Sie etwas abschalten, müssen Sie wissen, wo es genutzt wird („Audit Phase“). Blindes Abschalten führt fast garantiert zu Ausfällen.

Die wichtigste Informationsquelle ist das Sicherheitsprotokoll (Security Event Log) auf Ihren Domain Controllern.

Nutzung von Event ID 4769

Das Ereignis 4769 („A Kerberos service ticket was requested“) ist Ihr wichtigster Indikator.

So gehen Sie vor:

1. Öffnen Sie die Ereignisanzeige auf einem Domain Controller.
2. Navigieren Sie zu Windows-Protokolle -> Sicherheit.
3. Erstellen Sie eine Benutzerdefinierte Ansicht oder filtern Sie das aktuelle Protokoll.
4. Filtern Sie nach der Event-ID 4769.
5. Suchen Sie im Detailbereich des Events nach dem Feld Ticket Encryption Type (Ticket-Verschlüsselungstyp).

Die Hex-Codes verstehen:

• 0x17 (oder 23 dezimal): RC4-HMAC (Das ist das Protokoll, das wir eliminieren wollen).
• 0x12 (oder 18 dezimal): AES256-CTS-HMAC-SHA1-96 (Das ist das Ziel).
• 0x11 (oder 17 dezimal): AES128-CTS-HMAC-SHA1-96.

Analyse-Strategie: Wenn Sie Einträge mit 0x17 finden, notieren Sie sich:

• Account Name: Welches Benutzer- oder Computerkonto hat das Ticket angefordert?
• Service Name: Für welchen Dienst wurde das Ticket ausgestellt?
• Client Address: Von welcher IP-Adresse kam die Anfrage?

Hinweis: Ignorieren Sie Tickets, die mit einem Dollarzeichen enden und Computerkonten gehören, wenn diese nur vereinzelt auftreten, fokussieren Sie sich primär auf Dienstkonten (Service Accounts) und Benutzer.

Anleitung: Die Alternative AES einrichten und nutzen

AES (Advanced Encryption Standard) ist der Ersatz für Kerberos RC4. Es ist sicherer, schneller auf moderner Hardware und Standard in aktuellen Windows-Versionen. Die Einrichtung erfolgt primär über das Attribut msDS-SupportedEncryptionTypes im Active Directory.

Schritt 1: Konfiguration der Verschlüsselungstypen pro Objekt

Active Directory muss wissen, dass ein Konto AES unterstützt. Dies wird über ein Bitmask-Attribut gesteuert.

1. Öffnen Sie Active Directory-Benutzer und -Computer (stellen Sie sicher, dass „Erweiterte Features“ im Menü „Ansicht“ aktiviert ist).
2. Öffnen Sie die Eigenschaften eines Benutzers oder Dienstkontos.
3. Wechseln Sie zum Reiter Attribut-Editor.
4. Suchen Sie das Attribut msDS-SupportedEncryptionTypes.

Die Werte: Wenn der Wert 0 oder <nicht gesetzt> ist, verhält sich das System oft so, als wäre RC4 der Standard (abhängig vom Betriebssystem und DFL). Um AES zu erzwingen, müssen Sie die Werte berechnen:

• RC4 = 4
• AES 128 = 8
• AES 256 = 16

Um AES 128 und AES 256 zu unterstützen (empfohlen), addieren Sie 8 + 16 = 24. Tragen Sie den Wert 24 (oder 28, wenn Sie RC4 vorübergehend noch zulassen wollen) in das Attribut ein.

Alternative über die GUI: Im Reiter Konto finden Sie unter „Kontooptionen“ die Checkbox:

• „Dieses Konto unterstützt Kerberos-AES-128-Bit-Verschlüsselung“
• „Dieses Konto unterstützt Kerberos-AES-256-Bit-Verschlüsselung“

Das Setzen dieser Haken aktualisiert automatisch das Attribut msDS-SupportedEncryptionTypes.

Schritt 2: Gruppenrichtlinien (GPO) für die Domäne

Sie müssen sicherstellen, dass Ihre Server und Clients auch bereit sind, AES zu sprechen.

1. Öffnen Sie die Gruppenrichtlinienverwaltung.
2. Bearbeiten Sie die Default Domain Policy (oder eine dedizierte Sicherheitsrichtlinie).
3. Navigieren Sie zu: Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Sicherheitsoptionen
4. Suchen Sie die Richtlinie: Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren.
5. Aktivieren Sie diese Richtlinie und wählen Sie:
   • AES256_HMAC_SHA1 (Priorität)
   • AES128_HMAC_SHA1
   • Deaktivieren Sie RC4_HMAC_MD5.

Wichtig: Diese Richtlinie steuert, welche Verschlüsselungstypen der Client dem KDC (Key Distribution Center) anbietet.

Anleitung: Wie Kerberos RC4 abgeschaltet wird

Nachdem Sie auditiert haben und sichergestellt haben, dass alle Konten AES unterstützen (insbesondere Service Accounts!), können Sie an die Abschaltung gehen. Dies sollte schrittweise geschehen.

Phase 1: Soft-Disable über Registry (Testing)

Sie können auf einzelnen Servern testen, wie diese reagieren, wenn RC4 nicht mehr verfügbar ist. Microsoft dokumentiert hierfür Registry-Keys unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters.

Erstellen oder ändern Sie den DWORD-Wert SupportedEncryptionTypes. Setzen Sie diesen auf 0x7ffffff8 (dies entfernt RC4, welches Bit 2 ist). Dies zwingt den Client/Server dazu, nur noch AES (oder neuere Verfahren) zu nutzen.

Phase 2: Domänenweite Abschaltung

Die effektivste Methode ist die oben genannte Gruppenrichtlinie (Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren).

Wenn Sie in dieser GPO den Haken bei „RC4_HMAC_MD5“ entfernen und die Richtlinie auf alle Domain Controller und Clients anwenden, wird Kerberos RC4 effektiv in der Domäne deaktiviert.

Phase 3: Active Directory Härtung

Stellen Sie sicher, dass keine Konten mehr existieren, die explizit auf RC4 konfiguriert sind. Prüfen Sie via PowerShell, ob Benutzerkonten das Attribut Use DES encryption types (sehr alt) oder spezifische Legacy-Settings haben.

Ein PowerShell-Snippet zur Suche nach Konten ohne explizite AES-Freigabe (vereinfacht):

Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object { $_."msDS-SupportedEncryptionTypes" -eq $null -or $_."msDS-SupportedEncryptionTypes" -band 4 }

Hinweis: Dieser Befehl dient der Analyse und zeigt Konten, die potentiell noch RC4 nutzen oder es nicht explizit ausgeschlossen haben.

Häufige Probleme und Fallstricke

Bei der Migration von Kerberos RC4 auf AES treten erfahrungsgemäß folgende Probleme auf:

1. Legacy Storage-Systeme und Drucker

Ältere NAS-Systeme (Network Attached Storage) oder Multifunktionsdrucker, die „Scan-to-Folder“ nutzen, haben oft veraltete Firmware, die nur RC4 unterstützt.

• Lösung: Firmware-Update durchführen. Wenn dies nicht möglich ist, muss das Gerät isoliert oder ersetzt werden. Es gibt keine sichere Koexistenz nach 2026.

2. Vertrauensstellungen (Forest Trusts)

Wenn Sie Vertrauensstellungen zu anderen Active Directory Forests haben, müssen diese ebenfalls AES unterstützen.

• Prüfung: Öffnen Sie Active Directory-Domänen und -Vertrauensstellungen, Eigenschaften des Trusts -> Reiter „Sicherheit“. Stellen Sie sicher, dass „Der andere Domänen unterstützt Kerberos AES-Verschlüsselung“ aktiviert ist.

3. Java-Applikationen

Ältere Java-Versionen haben standardmäßig starke Verschlüsselung (wie AES 256) deaktiviert (wegen alter US-Exportbeschränkungen).

• Lösung: Installieren Sie die „Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files“ oder aktualisieren Sie auf eine moderne Java-Version.

Fazit: Agieren statt Reagieren

Die Kerberos RC4 Abschaltung im Jahr 2026 ist kein Vorschlag von Microsoft, sondern ein notwendiger Schnitt, um die Sicherheit der Windows-Welt zu gewährleisten. Wer bis zum Sommer 2026 wartet, riskiert massive Betriebsstörungen.

Die Migration auf AES ist nicht nur eine Compliance-Aufgabe, sondern ein direktes Upgrade Ihrer Sicherheitsarchitektur gegen moderne Angriffe wie Kerberoasting.

Handlungsempfehlung:

1. Beginnen Sie heute mit dem Audit Ihrer Event Logs (Event ID 4769).
2. Identifizieren Sie Legacy-Systeme und planen Sie deren Austausch.
3. Aktivieren Sie AES auf allen Service Accounts.
4. Testen Sie die Deaktivierung von RC4 in Testumgebungen vor dem Stichtag.

Schützen Sie Ihre Identitäten. Die Zeit von RC4 ist abgelaufen.

Haftungsausschluss: Die in diesem Artikel beschriebenen Eingriffe in die Systemkonfiguration erfolgen auf eigene Gefahr. Erstellen Sie vor Änderungen immer Backups und testen Sie Einstellungen in einer isolierten Umgebung. Beachten Sie die offiziellen Dokumentationen von Microsoft.