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.

Der Patch Tuesday von Microsoft für August 2025 enthält Sicherheitsupdates für 107 Schwachstellen, darunter eine öffentlich bekannt gegebene Zero-Day-Sicherheitslücke in Windows Kerberos.

Dieser Patch Tuesday behebt außerdem dreizehn „kritische” Sicherheitslücken, darunter neun Schwachstellen, die die Ausführung von Remote-Code ermöglichen, drei Schwachstellen, die zur Offenlegung von Informationen führen, und eine Schwachstelle, die eine Erhöhung der Berechtigungen ermöglicht.

Die Anzahl der Fehler in jeder Schwachstellenkategorie ist unten aufgeführt:

• 44 Sicherheitslücken mit Rechteausweitung
• 35 Sicherheitslücken mit Remote-Codeausführung
• 18 Sicherheitslücken mit Offenlegung von Informationen
• 4 Sicherheitslücken mit Denial-of-Service
• 9 Sicherheitslücken mit Spoofing

Microsoft-Sicherheitslücken

Dieser Patch Tuesday umfasst 107 von Microsoft behobene Sicherheitslücken und übertrifft damit die Gesamtzahl des letzten Monats, wobei 13 als kritisch eingestuft wurden. Allerdings ist nur eine Zero-Day-Sicherheitslücke mit Proof-of-Concept enthalten. Nachfolgend finden Sie die Details zu den wichtigsten kritischen Updates.

CVE-2025-53779 – Windows Kerberos – Sicherheitslücke zur Erhöhung von Berechtigungen

CVE-2025-53779, die einzige Zero-Day-Sicherheitslücke in diesem Patch Tuesday, ist eine kritische Schwachstelle im Windows Kerberos-Authentifizierungssystem. Sie betrifft eine relative Pfadüberquerungsschwachstelle (CWE-23) aufgrund einer unsachgemäßen Validierung von Pfadeingaben im Zusammenhang mit domänenverwalteten Dienstkonten (dMSAs). Dieses Problem tritt bei der Verarbeitung bestimmter Attribute von dMSAs durch Windows Kerberos auf, insbesondere beim Attribut „msds-ManagedAccountPrecededByLink“. Durch Manipulation dieser Pfade kann ein Angreifer mit hohen Berechtigungen Verzeichnisstrukturen durchlaufen und sich als Benutzer mit höheren Berechtigungen als vorgesehen ausgeben. Diese Sicherheitslücke untergräbt das vertrauenswürdige Delegierungsmodell, das Kerberos für die Verwaltung von Dienstkonten in Active Directory-Umgebungen verwendet.

Betroffene Systeme:

• Windows Server mit Active Directory-Domänendiensten
• Domänencontroller, die die Kerberos-Authentifizierung verwalten
• Umgebungen, die dMSAs verwenden
• Alle unterstützten Versionen von Windows Server mit aktiviertem Kerberos

Angriffseigenschaften:

• Angriffsvektor: Netzwerk (AV:N)
• Komplexität des Angriffs: Gering (AC:L)
• Erforderliche Berechtigungen: Hoch (PR:H)
• Benutzerinteraktion: Keine (UI:N)

CVSS-Übersicht:

• Basisbewertung: 7,2 (Hoch)
• Zeitliche Bewertung: 6,7 (Mittel)
• Auswirkungen: Vollständige Kompromittierung der Vertraulichkeit, Integrität und Verfügbarkeit des Systems
• Öffentlich bekannt gegeben: Ja
• In freier Wildbahn ausgenutzt: Nein (zum Zeitpunkt der Offenlegung)
• Proof of Concept: Ja, funktionsfähiger Exploit-Code existiert
• Bewertung der Ausnutzbarkeit: „Ausnutzung unwahrscheinlich” (laut Microsoft)

Voraussetzungen für die Ausnutzung:

• Hohe Berechtigungen innerhalb der Domänenumgebung
• Zugriff zum Ändern bestimmter dMSA-Attribute:
• msds-groupMSAMembership (zur Verwendung der dMSA)
• msds-ManagedAccountPrecededByLink (zur Angabe des Benutzers, als den sich die dMSA ausgeben kann)
• Durch Ausnutzen der Path-Traversal-Sicherheitslücke kann der Angreifer diese Attribute manipulieren und so unzulässige Delegierungsbeziehungen erstellen, die ihm Folgendes ermöglichen:
• Sich als privilegierte Konten ausgeben
• Berechtigungen auf Domänenadministrator-Ebene eskalieren
• Möglicherweise vollständige Kontrolle über die Active Directory-Domäne erlangen

Ausnutzungsszenarien:

Erster Zugriff: Ein Angreifer, der ein privilegiertes Konto kompromittiert hat (z. B. durch Phishing oder Diebstahl von Anmeldedaten), kann diese Schwachstelle nutzen, um von einem eingeschränkten Administratorkonto auf die vollständige Domänenkontrolle zu gelangen.

Seitliche Bewegung: Techniken wie Kerberoasting oder Silver-Ticket-Angriffe in Kombination mit dieser Schwachstelle ermöglichen es Angreifern, während der Eskalation von Berechtigungen dauerhaften Zugriff aufrechtzuerhalten.

Umgehung von Sicherheitskontrollen: Durch den Erwerb von Domänenadministratorrechten können Angreifer die Sicherheitsüberwachung deaktivieren, Gruppenrichtlinienobjekte ändern und Auditprotokolle manipulieren.

Angriffe auf die Lieferkette: In Umgebungen mit mehreren Gesamtstrukturen oder in Unternehmen mit Partnerverbindungen könnten Angreifer diese Schwachstelle nutzen, um von einer kompromittierten Domäne auf andere zu wechseln.

Gefährdete Umgebungen:

• Große Unternehmensumgebungen mit komplexen Active Directory-Konfigurationen
• Unternehmen, die dMSAs intensiv für die Verwaltung von Dienstkonten nutzen
• Hochwertige Ziele wie Behörden, Finanzinstitute und Organisationen im Gesundheitswesen
• Umgebungen mit umfangreichen Delegierungsmodellen für Verwaltungsaufgaben

Obwohl Microsoft die Schwachstelle als „wenig wahrscheinlich auszunutzen“ eingestuft hat, stellt sie aufgrund des Vorhandenseins eines funktionsfähigen Exploit-Codes und ihrer Auswirkungen auf zentrale Authentifizierungsmechanismen ein erhebliches Risiko dar. Die Anforderung hoher Berechtigungen mag als Schutzmaßnahme erscheinen, aber viele Unternehmen verfügen über Konten mit diesen Berechtigungen. Sobald ein solches Konto kompromittiert ist, ist der Weg zur vollständigen Kompromittierung der Domäne viel kürzer.

Unternehmen sollten diese Schwachstelle mit Dringlichkeit behandeln, da sie in ausgeklügelten Angriffsketten auf hochwertige Umgebungen genutzt werden kann.

Sicherheitsupdates für Exchange Server im August 2025

Microsoft hat Sicherheitsupdates (SUs) für Sicherheitslücken veröffentlicht, die in folgenden Produkten gefunden wurden:

• Exchange Server Subscription Edition (SE)
• Exchange Server 2019
• Exchange Server 2016

SUs sind für die folgenden spezifischen Versionen von Exchange Server verfügbar:

• Exchange SE RTM
• Exchange Server 2019 CU14 und CU15
• Exchange Server 2016 CU23

Die SUs vom August 2025 beheben Sicherheitslücken, die Microsoft von Sicherheitspartnern verantwortungsbewusst gemeldet und durch interne Prozesse von Microsoft entdeckt wurden. Obwohl uns keine aktiven Exploits bekannt sind, empfehlen wir, diese Updates sofort zu installieren, um Ihre Umgebung zu schützen.

Diese Sicherheitslücken betreffen Exchange Server. Exchange Online-Kunden sind bereits vor den durch diese SUs behobenen Sicherheitslücken geschützt und müssen keine weiteren Maßnahmen ergreifen, außer die Exchange-Server oder Exchange-Verwaltungstools-Workstations in ihrer Umgebung zu aktualisieren.

Weitere Informationen zu bestimmten CVEs finden Sie im Sicherheitsupdate-Leitfaden (filtern Sie unter „Produktfamilie” nach „Server-Software”).

Exchange Server AMSI-Body-Scanning standardmäßig aktiviert

Ab dem Exchange Server-Sicherheitsupdate (SU) für November 2024 wurde die AMSI-Integration um neue Funktionen zum Scannen des „HTTP-Nachrichtentextes” erweitert. Diese Funktion wird standardmäßig für alle Protokolle aktiviert, beginnend mit der Installation des Exchange Server-Sicherheitsupdates vom August 2025.

Wenn Sie nach der Installation des SU vom August 2025 eine verminderte Leistung feststellen, finden Sie in der Dokumentation zur Exchange Server AMSI-Integration Anweisungen zum Deaktivieren der AMSI-Body-Scan-Funktion.

Sicherheitsupdates vom Patch Tuesday im August 2025

Nachfolgend finden Sie eine vollständige Liste der behobenen Sicherheitslücken in den Updates vom Patch Tuesday im Juli 2025.

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.