Kategorie
Active Directory & Identity
Thema
RC4-Abschaltung in Kerberos
Zielgruppe
IT-Administratoren & AD-Verantwortliche
Lesezeit
ca. 10 Minuten

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

1

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.

2

Phase 2, Enforcement-Phase: April 2026 (aktuell aktiv, kritischste Phase)

Mit dem April-2026-Update tritt die Durchsetzungsphase in Kraft:

  • Der Standardwert für DefaultDomainSupportedEncTypes wird auf 0x18 (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
3

Phase 3, Finale Durchsetzung: Juli 2026 (bevorstehend)

Mit dem Juli-2026-Update wird der Audit-Modus vollständig entfernt:

  • Der Registry-Key RC4DefaultDisablementPhase wird 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

1

Angreifer erhält initialen Zugang zu einem Client im Netzwerk.

2

Über einen kompromittierten Domain-Account werden Kerberos-Service-Tickets für alle SPNs angefordert.

3

Die RC4-verschlüsselten Tickets werden offline mit Tools wie Hashcat geknackt.

4

Klartextpasswörter von Service-Accounts mit erhöhten Rechten werden extrahiert.

5

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.

„Kerberoasting ist kein exotischer Angriff mehr, sondern der erste Handgriff in nahezu jedem Active-Directory-Assessment mit RC4 im Spiel.“
Mint Secure GmbH

 

Was Administratoren jetzt tun müssen

1

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).

2

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?

3

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.

4

krbtgt-Account-Passwort zurücksetzen

Den krbtgt-Account einmalig rotieren, um AES-Schlüssel zu generieren. Dies sollte kontrolliert und dokumentiert erfolgen.

5

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.

6

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.