RC4-Verschlüsselung in Active Directory abschalten — Warum jetzt Handlungsbedarf besteht

RC4 in Kerberos — ein Relikt aus einer anderen Ära

Die Stromchiffre RC4 wurde 1987 entworfen und war über Jahrzehnte der Standard-Verschlüsselungsalgorithmus in Microsoft-Netzwerken. In Kerberos-Umgebungen verschlüsselt RC4-HMAC sowohl die Ticket Granting Tickets (TGTs) als auch die Service Tickets, die für den Zugriff auf Netzwerkressourcen benötigt werden. Das Problem: RC4 ist kryptografisch gebrochen. Der Algorithmus weist statistische Schwächen im Keystream auf, die sich seit den Fluhrer-Mantin-Shamir-Angriffen von 2001 systematisch ausnutzen lassen.

In der Praxis bedeutet das konkret: Ein mit RC4-HMAC verschlüsseltes Kerberos-Service-Ticket lässt sich mit modernen GPUs in Stunden bis Tagen offline knacken — bei schwachen Passwörtern sogar in Minuten. Mit AES-256 steigt der Aufwand um mehrere Größenordnungen. Trotzdem lief RC4 in vielen Active-Directory-Umgebungen jahrelang als Standardverschlüsselung weiter, weil niemand explizit AES konfiguriert hat.

Damit ist jetzt Schluss. Mit dem Sicherheitsupdate vom Januar 2026 hat Microsoft den Anfang vom Ende eingeleitet — und mit der April-2026-Aktualisierung wird die Durchsetzung aktiv.

CVE-2026-20833: Was Microsoft konkret ändert

Die Schwachstelle CVE-2026-20833 klassifiziert die Verwendung von RC4 in Kerberos offiziell als Information-Disclosure-Schwachstelle. Microsoft reagiert mit einer dreistufigen Abschaltung, die IT-Administratoren ein Zeitfenster zur Migration gibt — aber kein unbegrenztes.

Die drei Phasen im Überblick

Die entscheidende Änderung in Phase 2 betrifft alle Konten, deren msDS-SupportedEncryptionTypes-Attribut nicht explizit gesetzt ist. Bisher hat das Key Distribution Center (KDC) in diesem Fall RC4 als Fallback akzeptiert. Ab April 2026 geht das KDC standardmäßig davon aus, dass solche Konten AES unterstützen — und stellt keine RC4-Tickets mehr aus.

Das trifft in der Praxis vor allem Service Accounts, die vor Windows Server 2008 erstellt und seitdem nie ein Passwort-Reset erhalten haben. Diese Konten besitzen schlicht keine AES-Schlüssel, weil AES-Schlüssel erst beim Setzen eines neuen Passworts generiert werden.

Warum RC4 in Kerberos ein Sicherheitsrisiko ist

Die Kombination aus RC4-Verschlüsselung und Kerberoasting gehört zu den effektivsten Angriffspfaden in Active-Directory-Umgebungen. Der Angriff funktioniert so: Ein authentifizierter Domänenbenutzer — selbst ohne privilegierte Rechte — fordert Service Tickets für Konten mit Service Principal Names (SPNs) an. Diese Tickets sind mit dem Passwort-Hash des zugehörigen Service Accounts verschlüsselt. Der Angreifer extrahiert die Tickets und knackt sie offline mit Tools wie Hashcat.

Wenn das Service Ticket mit RC4-HMAC verschlüsselt ist, sinkt die Rechenzeit für den Offline-Crack drastisch. Hashcat erreicht auf einer einzelnen modernen GPU mehrere Milliarden RC4-HMAC-Hashes pro Sekunde. Bei AES-256 liegt die Rate um den Faktor 100–1000 niedriger. Für einen Service Account mit einem zehnstelligen alphanumerischen Passwort bedeutet das den Unterschied zwischen einem Tag und mehreren Jahrhunderten Rechenzeit.

Besonders kritisch: Viele Angreifertools wie Rubeus fordern gezielt RC4-verschlüsselte Tickets an, auch wenn der Account AES unterstützt. Solange RC4 als Option verfügbar ist, bleibt diese Angriffsfläche offen.

Betroffene Konten identifizieren: Die Audit-Phase nutzen

Seit Januar 2026 protokollieren alle unterstützten Windows-Domain-Controller neue Audit-Events im System-Eventlog. Diese Events zeigen exakt, welche Konten von der RC4-Abschaltung betroffen wären.

Neue KDC-Hardening-Events

Die Events 201, 202, 205, 206 und 207 erscheinen seit Phase 1 (Januar 2026). Die Events 203, 204, 208 und 209 kommen ab Phase 2 (April 2026) hinzu.

Klassische Erkennung über Security-Eventlog

Zusätzlich zu den neuen Events bleiben die bewährten Security-Event-IDs 4768 und 4769 relevant. Event 4768 protokolliert TGT-Anfragen, Event 4769 Service-Ticket-Anfragen. In beiden Events zeigt der Wert 0x17 im Feld „Ticket Encryption Type" oder „Session Encryption Type" die Verwendung von RC4-HMAC an.

Microsoft stellt zwei PowerShell-Skripte über das GitHub-Repository Kerberos-Crypto bereit, die die Auswertung vereinfachen. Das Skript Get-KerbEncryptionUsage.ps1 filtert gezielt nach RC4-Nutzung:

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4

Wer ein SIEM wie Microsoft Sentinel einsetzt, kann RC4-Nutzung mit einer KQL-Abfrage erfassen:

WindowsEvent
| where EventID in ('4768', '4769')
| extend SessionKeyEncryption = EventDataJson.SessionKeyEncryptionType
| extend TicketEncryption = EventDataJson.TicketEncryptionType
| where SessionKeyEncryption == '0x17' or TicketEncryption == '0x17'

Von RC4 zu AES migrieren: Schritt für Schritt

Die Migration erfordert Sorgfalt, aber keine Wunder. Der kritische Punkt: Konten brauchen AES-Schlüssel, und diese werden erst bei einem Passwort-Reset generiert. Die folgenden Schritte decken die häufigsten Szenarien ab.

Schritt 1: Bestandsaufnahme

Alle Konten identifizieren, deren msDS-SupportedEncryptionTypes-Attribut nicht gesetzt oder auf einen Wert ohne AES-Bit konfiguriert ist. Per PowerShell:

Get-ADObject -Filter {
  (ObjectClass -eq 'user' -or ObjectClass -eq 'computer') -and
  (msDS-SupportedEncryptionTypes -notlike '*')
} -Properties msDS-SupportedEncryptionTypes, servicePrincipalName |
Where-Object { $_.servicePrincipalName } |
Select-Object Name, ObjectClass, msDS-SupportedEncryptionTypes

Schritt 2: Service-Account-Passwörter zurücksetzen

Für Konten, die vor der AES-Unterstützung (Windows Server 2008) erstellt wurden, müssen die Passwörter zurückgesetzt werden — idealerweise zweimal, um sowohl den aktuellen als auch den vorherigen Schlüssel zu erneuern. Erst durch den Passwort-Reset werden die AES-128- und AES-256-Schlüssel im AD generiert.

Wo immer möglich, sollten klassische Service Accounts durch Managed Service Accounts ersetzt werden. Group Managed Service Accounts (gMSA) verwenden automatisch generierte 120-Zeichen-Passwörter, die alle 30 Tage rotiert werden — Kerberoasting wird damit praktisch unmöglich. Wer bereits Windows Server 2025 einsetzt, sollte Delegated Managed Service Accounts (dMSA) in Betracht ziehen: Deren Credentials sind maschinengebunden und werden ausschließlich auf dem Domain Controller gespeichert, sodass sie sich weder extrahieren noch offline knacken lassen. dMSAs können bestehende Service Accounts ohne Unterbrechung ablösen und verwenden standardmäßig AES-256.

Schritt 3: Encryption Types explizit konfigurieren

Nach dem Passwort-Reset sollte das Attribut msDS-SupportedEncryptionTypes auf den Wert 24 (dezimal) gesetzt werden, was AES-128 und AES-256 entspricht. Wenn Abwärtskompatibilität zu Legacy-Systemen nötig ist, kann temporär der Wert 28 verwendet werden (RC4 + AES-128 + AES-256).

Per Gruppenrichtlinie lässt sich die Kerberos-Verschlüsselung domänenweit steuern:

Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Configure encryption types allowed for Kerberos

Dort nur AES128_HMAC_SHA1 und AES256_HMAC_SHA1 aktivieren — RC4_HMAC_MD5 deaktiviert lassen.

Schritt 4: Legacy-Systeme identifizieren und migrieren

Geräte und Anwendungen, die kein AES unterstützen, sind nach Phase 3 (Juli 2026) nicht mehr in der Lage, sich per Kerberos zu authentifizieren. Das betrifft insbesondere Systeme, die auf Windows Server 2003 oder älter basieren — einem Betriebssystem, das seit über einem Jahrzehnt keinen Support mehr erhält. Auch Drittanbieter-Appliances (NAS-Systeme, Netzwerkdrucker, Legacy-ERP-Systeme) können betroffen sein.

Schritt 5: Monitoring nach der Umstellung

Nach der AES-Migration sollte das Monitoring bestehen bleiben. Authentifizierungsfehler zeigen sich als Event ID 4769 mit Fehlercode 0xE (KDC_ERR_ETYPE_NOTSUPP). SMB-Zugriffe scheitern mit Netzwerkfehlern, WMI-Remote-Sessions mit dem Error-Code 0x80090342. In beiden Fällen fehlen dem Zielkonto die AES-Schlüssel — ein Passwort-Reset löst das Problem.

Was passiert, wenn Unternehmen nicht reagieren?

Die Konsequenzen sind nicht theoretisch, sondern unmittelbar spürbar. Ab Phase 2 (April 2026) schlägt die Authentifizierung fehl, wenn ein Service Account keine AES-Schlüssel besitzt und das msDS-SupportedEncryptionTypes-Attribut nicht gesetzt ist. Das kann bedeuten: Dateifreigaben sind nicht mehr erreichbar, Dienste starten nicht, Remote-Management per PowerShell schlägt fehl, und Anwendungen, die auf Kerberos-Authentifizierung angewiesen sind, verlieren den Zugriff auf Backend-Systeme.

In einer typischen mittelständischen AD-Umgebung mit mehreren hundert Service Accounts können solche Ausfälle kaskadieren — besonders wenn die betroffenen Konten nie inventarisiert wurden. Wir finden in Assessments regelmäßig Service Accounts, die seit der Domäneneinrichtung vor zehn oder mehr Jahren unverändert laufen und deren Abhängigkeiten niemand mehr vollständig kennt.

Checkliste: RC4-Migration auf einen Blick

Die folgende Tabelle fasst die wesentlichen Aufgaben zusammen, die IT-Administratoren bis zur vollständigen Durchsetzung im Juli 2026 abarbeiten sollten.

Über die Compliance hinaus: RC4-Abschaltung als Sicherheitsgewinn

Die Migration von RC4 auf AES ist nicht nur eine technische Pflichtübung, die Microsoft erzwingt. Sie ist eine der wirksamsten Einzelmaßnahmen zur Härtung einer Active-Directory-Umgebung. Mit der konsequenten AES-Durchsetzung wird Kerberoasting um Größenordnungen schwieriger. Die Kombination mit Managed Service Accounts — gMSAs oder dMSAs in Windows-Server-2025-Umgebungen — und einem sauberen Tiering-Modell eliminiert einen der häufigsten Angriffspfade zum Domain Admin.

Gleichzeitig ist die RC4-Migration ein guter Anlass, die gesamte Kerberos-Konfiguration zu überprüfen. Weitere sinnvolle Maßnahmen im gleichen Zug: das krbtgt-Passwort rotieren (in vielen Umgebungen seit der Domäneneinrichtung unverändert), NTLM so weit wie möglich einschränken und Konten ohne Kerberos-Vorauthentifizierung identifizieren — Stichwort AS-REP Roasting. Wer die RC4-Abschaltung als isolierte Pflichtübung behandelt, verschenkt das Potenzial für eine umfassende Härtung der Identitätsinfrastruktur.

Unternehmen, die die Audit-Phase seit Januar 2026 genutzt haben, kennen ihre RC4-Abhängigkeiten bereits und können die Enforcement-Phase ohne Betriebsunterbrechungen überstehen. Für alle anderen wird die Zeit knapp: Bis zur vollständigen Durchsetzung im Juli 2026 bleiben nur noch wenige Monate.

Ein umfassendes AD Security Assessment zeigt Ihnen nicht nur RC4-Abhängigkeiten, sondern alle Angriffspfade in Ihrer Active-Directory-Umgebung — von Kerberoasting über Pass-the-Hash bis zu unsicheren Delegierungen. Sprechen Sie mit uns über ein Identity & Access Hardening für Ihre Umgebung.