
Die Ankündigung von Microsoft, RC4 als Verschlüsselungsalgorithmus in der Kerberos-Authentifizierung schrittweise abzuschalten, ist die nächste große Sicherheitsänderung in Windows-Umgebungen, direkt nach der NTLM-Abschaltung.
Für IT-Administratoren bedeutet das konkrete Handlungsbedarfe, laufende Fristen und potenzielle Ausfälle, wenn jetzt nicht gehandelt wird.
Was ist RC4, und warum wird es abgeschafft?
RC4 (Rivest Cipher 4) ist ein Stromverschlüsselungsalgorithmus, der seit den frühen Windows-Versionen in der Kerberos-Authentifizierung verwendet wird. Er blieb vor allem aus Kompatibilitätsgründen erhalten: Ältere Geräte, Legacy-Anwendungen und Service-Accounts, die nie auf stärkere Verschlüsselung migriert wurden, stützten sich jahrelang stillschweigend darauf.
Kerberos ist das primäre Authentifizierungsprotokoll in Active-Directory-Umgebungen. Wenn sich ein Benutzer oder Dienst anmeldet, stellt ein Domain Controller (Key Distribution Center, KDC) ein verschlüsseltes Ticket aus, das die Identität des Anfragenden gegenüber anderen Diensten beweist.
Das Problem: RC4 gilt heute als kryptografisch gebrochen. Seine Schwächen ermöglichen konkrete Angriffe:
-
Kerberoasting: Angreifer fordern Service-Tickets an, die mit RC4 verschlüsselt sind, und knacken die Passwörter der zugehörigen Service-Accounts offline, ohne direkten Zugriff auf das System.
-
Pass-the-Hash / Credential Theft: Gestohlene Hashes reichen aus, um sich zu authentifizieren.
-
Lateral Movement: Kompromittierte Service-Accounts mit zu vielen Rechten ermöglichen die vollständige Domain-Kompromittierung.
RC4 ist damit ein zentraler Angriffsvektor moderner Ransomware-Kampagnen, die auf Active-Directory-Umgebungen abzielen.
Die offizielle Microsoft-Zeitleiste
Phase 1, Audit-Phase: Januar 2026 (abgeschlossen / aktiv)
Mit dem Windows Cumulative Update vom 13. Januar 2026 hat Microsoft die Audit-Phase gestartet. RC4 wird noch nicht blockiert, aber neue Event-IDs werden in den Eventlogs der Domain Controller eingeführt: 201, 202, 206, 207, 4768, 4769.
Ticket Encryption Type 0x17 in den Security-Events zeigt RC4-Nutzung an. Microsoft stellt zwei neue PowerShell-Skripte auf GitHub bereit: List-AccountKeys.ps1 und Get-KerbEncryptionUsage.ps1.
Wer in dieser Phase bereits Audit-Events sieht, hat RC4-abhängige Systeme und wird in Phase 2 Ausfälle erleben.
Phase 2, Enforcement-Phase: April 2026 (aktuell aktiv, kritischste Phase)
Mit dem April-2026-Update tritt die Durchsetzungsphase in Kraft:
- Der Standardwert für
DefaultDomainSupportedEncTypeswird auf0x18 (AES-SHA1 only)gesetzt - RC4 wird für alle Accounts ohne explizite Konfiguration nicht mehr ausgehandelt
- Service-Accounts ohne gesetztes
msDS-SupportedEncryptionTypes-Attribut erhalten nur noch AES-verschlüsselte Tickets - Ein Rollback in den Audit-Modus ist noch möglich, wird aber als rein temporäre Maßnahme eingestuft
Phase 3, Finale Durchsetzung: Juli 2026 (bevorstehend)
Mit dem Juli-2026-Update wird der Audit-Modus vollständig entfernt:
- Der Registry-Key
RC4DefaultDisablementPhasewird nicht mehr ausgelesen - RC4 ist vollständig aus dem Kerberos-KDC-Pfad entfernt
- Nur noch Accounts mit explizit gesetztem
msDS-SupportedEncryptionTypes-Wert können RC4 nutzen (stark abgeraten) - Kein Rollback mehr möglich
Konkrete Auswirkungen
Service-Accounts
Service-Accounts, deren Passwort seit Einführung von AES-SHA1 (Windows Server 2008) nie zurückgesetzt wurde, verfügen unter Umständen nur über RC4-Schlüssel. Typischerweise betroffen:
-
SQL Server-Dienstkonten
-
IIS-Anwendungspools
-
Scheduled-Task-Konten
-
Backup-Dienste
NAS-Systeme und Dateifreigaben
Netzwerkspeicher-Geräte, die per Kerberos in Active Directory eingebunden sind, fallen ohne explizite AES-Konfiguration aus. Besonders betroffen sind Synology (ältere Firmware), QNAP, NetApp sowie FSLogix-Profile-Shares bei Azure Virtual Desktop und RDS.
Drucker und Multifunktionsgeräte
Geräte, die Kerberos für Scan-to-Folder oder SMB-Authentifizierung nutzen, können nach der Enforcement-Phase keine Tickets mehr erhalten. Betroffen sind unter anderem ältere Geräte von HP, Canon, Kyocera und Ricoh.
Linux-Systeme mit Samba
Ältere Samba-Konfigurationen nutzen RC4 als Fallback. Ohne Aktualisierung der Einstellungen in der smb.conf oder krb5.conf schlägt die Authentifizierung fehl.
Active Directory: krbtgt-Account
Oft übersehen: Wenn der krbtgt-Account seit dem Upgrade auf Windows Server 2008 nie geändert wurde, verfügt er möglicherweise nicht über AES-Schlüssel, das kann zu flächendeckenden Authentifizierungsfehlern führen.
Das Sicherheitsrisiko: Typische Angriffskette
Angreifer erhält initialen Zugang zu einem Client im Netzwerk.
Über einen kompromittierten Domain-Account werden Kerberos-Service-Tickets für alle SPNs angefordert.
Die RC4-verschlüsselten Tickets werden offline mit Tools wie Hashcat geknackt.
Klartextpasswörter von Service-Accounts mit erhöhten Rechten werden extrahiert.
Lateral Movement und Privilege Escalation bis hin zur vollständigen Domain-Kompromittierung.
Diese Angriffsmethode erfordert kein Administratorrecht und hinterlässt zunächst kaum Spuren im Eventlog.
Mint Secure GmbH
Was Administratoren jetzt tun müssen
Kerberos-Auditing aktivieren
Auf allen Domain Controllern ab Windows Server 2019/2022/2025:
Audit Kerberos Authentication Service -> Aktivieren
Audit Kerberos Service Ticket Operations -> Aktivieren
Zusätzlich: PowerShell-Skripte von Microsoft auf GitHub nutzen (List-AccountKeys.ps1, Get-KerbEncryptionUsage.ps1).
RC4-abhängige Accounts und Systeme identifizieren
Über die neuen Event-IDs und Skripte gezielt prüfen: Welche Service-Accounts haben kein AES-Schlüsselmaterial? Welche Computer-Accounts und NAS-Geräte sind betroffen?
msDS-SupportedEncryptionTypes setzen
Für alle betroffenen Service-Accounts das Attribut explizit auf AES setzen und anschließend das Passwort zurücksetzen, erst dann werden neue Kerberos-Schlüssel generiert.
krbtgt-Account-Passwort zurücksetzen
Den krbtgt-Account einmalig rotieren, um AES-Schlüssel zu generieren. Dies sollte kontrolliert und dokumentiert erfolgen.
Enforcement im Audit-Modus testen
Vor der automatischen Aktivierung den Registry-Key RC4DefaultDisablementPhase = 2 testweise auf nicht-produktiven Domain Controllern setzen und Ausfälle identifizieren.
Security Audit und Pentesting durchführen
Erst durch einen gezielten Audit wird sichtbar, welche Angriffspfade in der aktuellen Konfiguration bereits ausnutzbar sind und wo RC4 still im Hintergrund genutzt wird.
Wie Mint Secure euch dabei unterstützt
Als spezialisierter IT-Security-Dienstleister unterstützt Mint Secure Unternehmen bei der sicheren Migration und Absicherung ihrer Active-Directory-Infrastruktur.
RC4 & Kerberos-Audit
Wir analysieren, welche Accounts, Systeme und Dienste noch RC4 nutzen und ob der krbtgt-Account AES-Schlüsselmaterial besitzt.
AD Security Audit
Wir prüfen Delegierungen, Trust-Beziehungen, Kerberos-Konfiguration, Privilegien und Anomalien in der Verschlüsselungskonfiguration.
AD Penetration Testing
Wir simulieren Kerberoasting, AS-REP Roasting, Pass-the-Hash und Lateral Movement, um Angriffspfade zu identifizieren.
Legacy-System-Analyse
Wir prüfen Drucker, NAS-Systeme, Embedded Devices und Anwendungen auf RC4-Abhängigkeiten und entwickeln Migrationsstrategien.
Unsicher, ob eure Umgebung betroffen ist? Wir werten eure Domain-Controller-Logs gemeinsam mit euch aus. Jetzt Kontakt aufnehmen.
Fazit
Die Abschaltung von RC4 in Kerberos ist keine theoretische Empfehlung, sondern eine laufende, erzwungene Änderung mit konkreten Deadlines.
Die Audit-Phase hat im Januar 2026 begonnen, die Enforcement-Phase ist im April 2026 aktiv, und ab Juli 2026 gibt es keinen Weg zurück. Unternehmen, die jetzt handeln, vermeiden ungeplante Ausfälle in der Authentifizierungsinfrastruktur, schließen einen der meistgenutzten Angriffsvektoren in Active-Directory-Umgebungen und reduzieren das Risiko einer vollständigen Domain-Kompromittierung durch Kerberoasting erheblich.
Jetzt ist der richtige Zeitpunkt zu handeln, bevor Microsoft die Entscheidung abnimmt. Sprecht uns an.

