RC4 verschwindet endgültig aus Kerberos. Was bricht und wie Sie bis Juli 2026 migrieren

Einleitung

Rund zwanzig Jahre lang haben Windows-Domänencontroller RC4-HMAC klammheimlich als Fallback-Verschlüsselung für Kerberos-Tickets akzeptiert. Eine gute Idee war das nie, aber es hielt alte Appliances und vergessene Service-Accounts am Laufen, also blieb es. Damit ist dieses Jahr Schluss. Microsoft hat einen gestaffelten Rollout an CVE-2026-20833 gekoppelt und am Ende dieser Zeitleiste steht ein Update im Juli 2026, das den Rückweg abschneidet. Danach ist RC4 aus dem KDC-Pfad verschwunden, sofern du nicht pro Konto eine ausdrückliche Ausnahme definiert hast.

Wer Active Directory betreibt, hat es hier mit einem Risiko für Authentifizierungsausfälle samt fester Deadline zu tun, nicht mit einer Aufräumaufgabe, die sich beliebig verschieben lässt. Im Folgenden geht es darum, was sich tatsächlich ändert, was typischerweise bricht, wie du es mit vorhandenen Bordmitteln aufspürst und welcher Migrationsweg dich aus dem Schlamassel heraushält.

Die Schwachstelle hinter der Änderung

CVE-2026-20833 wurde am 13. Januar 2026 veröffentlicht und ist als Verwendung eines unsicheren oder fehlerhaften kryptografischen Algorithmus in Windows Kerberos eingestuft. Kurz gesagt: Ein authentifizierter Angreifer kann beim KDC Service, Tickets in einem schwachen Verschlüsselungstyp anfordern und anschließend das Passwort des Service-Accounts offline knacken. Das ist Kerberoasting und RC4 macht es einfach. RC4-Schlüssel leiten sich unter Windows aus dem NTLM-Hash ab, ohne Salt und ohne Iteration. Ein abgegriffenes RC4-Service-Ticket lässt sich daher in Hashcat werfen und deutlich schneller per Brute Force knacken als ein AES-verschlüsseltes.

Der Angriff braucht keine Adminrechte. Ein Fuß in der Tür auf irgendeinem domänengebundenen Client genügt, um Tickets für jeden SPN der Domäne anzufordern und das Knacken passiert offline, wo deine Eventlogs es nie zu sehen bekommen. Die Service-Accounts sind die Beute, weil sie meist zu hoch privilegiert und selten rotiert sind. Genau diese Angriffsfläche schließt Microsoft, indem AES zum angenommenen Standard wird.

Ganz offen gesagt: Für genau diese CVE gibt es keinen breit veröffentlichten Proof-of-Concept und Tracker melden bislang nur begrenzte Hinweise auf aktive Ausnutzung. Das senkt die Dringlichkeit nicht. Ziel der Änderung ist es, eine ganze Klasse billiger Offline-Angriffe über die gesamte Installationsbasis hinweg zu beseitigen und die Deadline gilt unabhängig davon, ob dich gerade jemand angreift.

Die drei Phasen und was jede davon konkret bewirkt

Microsoft hat das als Kalender-Rollout gestaffelt, damit du genug Vorlauf hast, um deine RC4-Abhängigkeiten zu finden, bevor etwas bricht.

13. Januar 2026 (Audit). Das Update ist rein diagnostisch. Es ergänzt neun neue KDCSVC-Events (IDs 201 bis 209) im System-Log der Domänencontroller, reichert die bestehenden Security-Events 4768 und 4769 um Details zum Verschlüsselungstyp an und führt einen temporären Registry-Wert namens RC4DefaultDisablementPhase ein. Blockiert wird noch nichts. Ab Werk steht der Wert auf Phase 1, also nur Warn-Events. Was gern übersehen wird: Das Januar-Update behebt die CVE nicht von allein. Um sie wirklich zu entschärfen, aktivierst du das Enforcement entweder manuell (Registry-Wert auf 2), sobald deine Logs sauber sind, oder du wartest, bis die späteren Updates es für dich erledigen.

14. April 2026 (Standard kippt auf AES). Dieses Update setzt den Standardwert von DefaultDomainSupportedEncTypes (DDSET) auf 0x18, also AES-SHA1 only, für jedes Konto ohne explizit gesetztes Attribut msDS-SupportedEncryptionTypes. In der Praxis hört der KDC auf, stillschweigend auf RC4 zurückzufallen. Alles, was weiterhin von RC4 abhängt und nicht behoben wurde, beginnt hier zu scheitern. Ein manuelles Rollback in den Audit-Modus ist zu diesem Zeitpunkt noch möglich, falls etwas schiefgeht, aber Microsoft versteht das als temporären Notausgang, nicht als Dauerzustand.

Juli 2026 (kein Zurück mehr). Das Juli-Update entfernt den Registry-Key RC4DefaultDisablementPhase vollständig und schafft den Audit-Modus ab. Enforcement ist dann der einzige Zustand. RC4 ist aus dem KDC-Pfad verschwunden, außer bei Konten, für die du msDS-SupportedEncryptionTypes ausdrücklich auf RC4 gesetzt hast. Danach gibt es kein Rollback mehr. Wer die Migrationsarbeit bis dahin nicht erledigt hat, findet seine verbliebenen RC4-Abhängigkeiten auf die harte Tour.

Wenn du dir nur ein Datum merkst, dann den Juli. Im April zeigte sich der meiste Schaden; im Juli verlierst du die Möglichkeit, ihn rückgängig zu machen.

Was typischerweise bricht

Das Fehlerbild ist fast immer dasselbe: Ein Principal, der nur über RC4-Schlüsselmaterial verfügt, oder ein Client, der nur RC4 anbietet, spricht mit einem DC, der kein RC4-Ticket mehr ausstellt. Die üblichen Verdächtigen:

Service-Accounts, deren Passwörter älter als AES sind. AES-SHA1-Schlüssel entstehen bei einer Passwortänderung. Ein Service-Account, der unter Windows Server 2008 oder früher angelegt und seitdem nie zurückgesetzt wurde, besitzt unter Umständen nur RC4-Schlüssel. SQL-Server-Dienstkonten, IIS-Anwendungspool-Identitäten, Konten für geplante Tasks und Backup-Dienstkonten sind typische Kandidaten, weil sich niemand an ihre Passwörter herantraut.
NAS und Dateifreigaben. Per Kerberos in AD eingebundener Netzwerkspeicher fällt ohne AES-Konfiguration aus. Ältere Synology-Firmware, QNAP und NetApp tauchen hier auf, ebenso FSLogix-Profil-Shares hinter Azure Virtual Desktop und RDS.
Drucker und Multifunktionsgeräte. Scan-to-Folder und SMB-Authentifizierung älterer Geräte von HP, Canon, Kyocera und Ricoh setzen oft noch auf RC4. Firmware-Updates erhalten diese Geräte selten in einem vernünftigen Rhythmus.
Linux und Samba. Ältere Samba-Konfigurationen fallen auf RC4 zurück. Wenn krb5.conf oder smb.conf nur RC4 festlegt oder zulässt, schlägt die Authentifizierung fehl, sobald die DCs es nicht mehr anbieten.
Der krbtgt-Account selbst. Das ist der Fall, der aus einem lokalen Ausfall einen domänenweiten macht. Wurde krbtgt unter Server 2008 angelegt und nie rotiert, fehlen ihm möglicherweise die AES-Schlüssel. Geh das sorgfältig und überlegt an, denn ein Fehler hat hier einen eigenen Wirkungsradius.

RC4-Abhängigkeiten finden

Erst erkennen, dann ändern. Aktiviere auf deinen Domänencontrollern die beiden Kerberos-Audit-Unterkategorien:

Audit Kerberos Authentication Service       -> Success/Failure
Audit Kerberos Service Ticket Operations    -> Success/Failure

Das Januar-Update reichert die Events 4768 (TGT-Anforderung) und 4769 (Service-Ticket-Anforderung) um fünf nützliche Felder an: msDS-SupportedEncryptionTypes, Available Keys, Advertised Etypes, Ticket Encryption Type und Session Encryption Type. Die relevanten Werte für den Verschlüsselungstyp:

0x17 = RC4-HMAC (das, wonach du suchst)
0x11 = AES128-SHA1
0x12 = AES256-SHA1

Bei einem 4769 spiegelt der Ticket-Verschlüsselungstyp den Schlüssel des Service-Accounts wider. Ein 4769 mit 0x17 bedeutet also, dass dieser Dienst ein RC4-Ticket ausgegeben hat und roastbar ist. Auf KDC-Seite sagen dir die neuen KDCSVC-Warnungen, was das Enforcement tun wird: 201 und 202 markieren Konten, die brechen werden und sie werden im Enforcement zu den blockierenden Fehlern 203 und 204 (206/207 und ihre blockierenden Gegenstücke 208/209 decken die Fälle ab, in denen AES-only konfiguriert ist). Event 205 ist der Sonderfall: Es feuert, wenn du DDSET ausdrücklich so konfiguriert hast, dass etwas Unsicheres erlaubt ist und es wird nie zu einem Fehler, weil Microsoft die ausdrückliche Entscheidung des Admins respektiert. Es erinnert dich nur daran, dass du sie getroffen hast.

Die zwei PowerShell-Skripte (und woher du sie bekommst)

Microsoft liefert zwei quelloffene Helfer im GitHub-Repository microsoft/Kerberos-Crypto (github.com/microsoft/Kerberos-Crypto, unter /scriptsoder hier ist der direkte Link: KLICK). Sie sind standardmäßig nirgends installiert, du lädst sie also selbst herunter:

List-AccountKeys.ps1 parst 4768/4769 aus dem Security-Log und listet auf, welche Schlüsseltypen ein Konto tatsächlich hat. Ein Konto, das als {RC4} ohne AES-Einträge zurückkommt, bricht beim Enforcement garantiert.
Get-KerbEncryptionUsage.ps1 fasst zusammen, welche Verschlüsselungstypen im Einsatz sind, mit einem Filter, um RC4 zu isolieren.

Führe sie in einer erhöhten PowerShell-Sitzung auf einem DC aus oder remote gegen einen:

# Konten, die in den letzten 14 Tagen RC4-Schlüssel genutzt haben
.\List-AccountKeys.ps1 -Since (Get-Date).AddDays(-14) -ContainsKeyType RC4

# Alles, was noch RC4 aushandelt, zusammengefasst
.\Get-KerbEncryptionUsage.ps1

Für eine einmalige Bestandsaufnahme auf einem einzelnen DC reichen die Skripte. Für alles Laufende oder alles über mehr als ein, zwei Domänencontroller hinweg schieb die Events nach Sentinel und werte sie dort aus.

Deckt Defender for Identity das nicht schon ab?

Teilweise und es lohnt sich, genau zu sein, welche Frage MDI beantwortet, denn es ist nicht dieselbe wie „Wer nutzt gerade RC4?".

MDI hat ein Identity-Posture-Assessment namens Stop weak cipher usage, ausgespielt über den Secure Score. Es markiert Identitäten, die so konfiguriert sind, dass sie schwache Cipher (DES, 3DES, RC4) zulassen und die Liste der betroffenen Entitäten lässt sich exportieren. Das liefert eine Bestandsaufnahme auf Konfigurationsebene, ohne ein einziges Eventlog anzufassen: welche Konten überhaupt RC4 erlauben. MDI führt außerdem ein zugehöriges krbtgt-Assessment, das ein altes krbtgt-Passwort meldet, was gut zur ohnehin nötigen krbtgt-Rotation passt.

Was MDI dir nicht gibt, ist das Nutzungssignal pro Ticket. Der Kerberos-Ticket-Verschlüsselungstyp jeder Anforderung steckt in 4768/4769 und die Identity-Tabellen von MDI (IdentityLogonEvents, IdentityDirectoryEvents, IdentityQueryEvents) stellen ihn nicht als abfragbare Spalte bereit. Die neuen KDCSVC-Events 201–209 sind Windows-System-Log-Events und ebenfalls nicht in MDI. MDI sagt dir also, welche Konten schwach konfiguriert sind; es sagt dir nicht, welcher Dienst um 02:14 Uhr letzte Nacht ein RC4-Ticket bekommen hat oder was der April-Standardwechsel gleich blockieren wird.

Die praktische Aufteilung:

MDI-Posture (Stop weak cipher usage, krbtgt-Assessment) = die Konfigurationsliste, laufend gepflegt, gut für die Management-Sicht.
Sentinel SecurityEvent 4768/4769 = tatsächliche RC4-Nutzung, die Liste, die echten Schaden vorhersagt und die Kerberoasting-Erkennung speist.
KDCSVC 201–209 (System-Log) = was das Enforcement warnt versus blockiert, pro DC.

Nutze alle drei. Sie beantworten verschiedene Teile derselben Frage.

RC4 mit KQL jagen

Sobald die Security- und System-Logs der DCs in Sentinel fließen (4768/4769 und die KDCSVC-System-Events über eine AMA Data Collection Rule sammeln), wird die Bestandsaufnahme zur Abfrage statt zur Skriptübung. Ein paar, die sich lohnen.

RC4-Service-Tickets und TGTs, letzte 14 Tage. Der Basis-Hunt:

WindowsEvent
| where TimeGenerated > ago(14d)
| where EventID in (4768, 4769)
| where Channel == "Security"
| extend Etype   = tostring(EventData.TicketEncryptionType),
         Account = tostring(EventData.TargetUserName),
         Service = tostring(EventData.ServiceName),
         Client  = tostring(EventData.IpAddress)
| where Etype == "0x17" // RC4-HMAC
| summarize Requests = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen  = max(TimeGenerated)
    by Account, Service, Etype, Computer
| sort by Requests desc

RC4-only-Service-Accounts. Das ist die Abfrage, die tatsächlich vorhersagt, wer bricht, denn ein Konto, das manchmal AES nutzt, übersteht den Standardwechsel. Du willst die Konten, die es nie tun:

let lookback = 30d;
WindowsEvent
| where TimeGenerated > ago(lookback)
| where EventID == 4769 and Channel == "Security"
| extend Service = tostring(EventData.ServiceName),
         Etype   = tostring(EventData.TicketEncryptionType)
| where Service !endswith "$"
| summarize Etypes = make_set(Etype), Requests = count() by Service
| extend UsesRC4 = set_has_element(Etypes, "0x17"),
         UsesAES = set_has_element(Etypes, "0x11") or set_has_element(Etypes, "0x12")
| where UsesRC4 and not(UsesAES)
| sort by Requests desc

Was das Enforcement blockiert versus warnt. Die KDCSVC-Events direkt zu lesen zeigt dir, wie viel Schmerz April und Juli verursachen werden, bevor sie ihn verursachen:

WindowsEvent
| where TimeGenerated > ago(7d)
| where Channel == "System"
| where Provider has "Kdcsvc" or Provider has "Key-Distribution-Center"
| where EventID between (201 .. 209)
| extend Severity = case(
    EventID in (203, 204, 208, 209), "BLOCKED (enforcement)",
    EventID == 205, "Insecure DDSET configured",
    "WARNING (pre-enforcement)")
| summarize Count = count() by EventID, Severity, Computer
| sort by Severity asc, Count desc

Schlag die Brücke zur eigentlichen Bedrohung. Die Abschaltung existiert wegen Kerberoasting, also lohnt es sich, dieselben Daten auf das Verhalten zu richten. Eine Identität, die in einem engen Zeitfenster einen Stapel unterschiedlicher RC4-Service-Tickets zieht, sieht nach Roasting-Vorbereitung aus:

WindowsEvent
| where TimeGenerated > ago(7d)
| where EventID == 4769 and Channel == "Security"
| extend Etype     = tostring(EventData.TicketEncryptionType),
         Service   = tostring(EventData.ServiceName),
         Requestor = tostring(EventData.TargetUserName),
         IpAddress = tostring(EventData.IpAddress)
| where Etype == "0x17"
| where Service !endswith "$"
| summarize DistinctSPNs = dcount(Service),
            SPNs = make_set(Service, 40)
    by Requestor, IpAddress, bin(TimeGenerated, 1h)
| where DistinctSPNs >= 10
| sort by DistinctSPNs desc

Reichere um Identitätskontext an. Eine flache Liste von RC4-Konten ist weniger wert als dieselbe Liste, sortiert danach, wie sehr eine Kompromittierung wehtäte. Wenn du UEBA-/Identity-Daten hast, reichere an:

let rc4 = WindowsEvent
    | where TimeGenerated > ago(14d)
    | where EventID == 4769 and Channel == "Security"
    | extend Etype   = tostring(EventData.TicketEncryptionType),
             Account = tostring(EventData.TargetUserName)
    | where Etype == "0x17"
    | distinct AccountName = tolower(Account);
IdentityInfo
| where TimeGenerated > ago(14d)
| where tolower(AccountName) in (rc4)
| summarize arg_max(TimeGenerated, AccountDisplayName, IsAccountEnabled, AssignedRoles, Tags)
    by AccountName

Zwei praktische Hinweise. Erstens ist 4769 eines der volumenstärksten Events, die ein DC erzeugt. Filtere daher schon in der DCR (sammle nur, was du brauchst) und stütze das laufende Monitoring auf die volumenarmen KDCSVC-Events; heb die schweren 4769-Abfragen für den Inventur-Durchlauf auf. Zweitens sind das pro Workspace laufende Abfragen, wenn du sie über mehrere Tenants fährst: fächere sie mit union workspace(...) auf oder nutze das Äquivalent im mandantenübergreifenden Advanced Hunting von Defender XDR, statt zwischen Portalen zu springen.

Die Migration

Arbeite risikobasiert. Aktiviere kein Enforcement, bevor Discovery und Remediation wirklich abgeschlossen sind.

Inventarisieren und priorisieren. Zentralisiere 4768/4769 und die KDCSVC-Events, lass die Helfer-Skripte oder die obigen KQL-Abfragen laufen und sortiere nach Exposition. Privilegierte Service-Accounts mit SPNs zuerst. Produktive Drittanbieter-Appliances als Nächstes. Labor- und Ausmusterungsgeräte zuletzt.
Service-Accounts in Ordnung bringen. Setze für jedes betroffene Konto msDS-SupportedEncryptionTypes ausdrücklich auf AES (0x18) und setze anschließend das Passwort zurück. Erst das Zurücksetzen erzeugt die AES128-SHA96- und AES256-SHA96-Schlüssel; die Attributänderung allein bewirkt nichts, solange sich das Passwort nicht ändert. Prüfe mit List-AccountKeys.ps1, dass nun AES-Schlüsselmaterial vorhanden ist. Plane ein Wartungsfenster ein, weil der Dienst das neue Passwort übernehmen muss.
krbtgt vorsichtig rotieren. Setze krbtgt zurück, damit er AES-Schlüssel hält. Die unterstützte Empfehlung lautet, zweimal zurückzusetzen, mit mindestens zehn Stunden Abstand, damit du nicht alle ausstehenden Tickets ungültig machst und einen selbst verschuldeten Ausfall auslöst. Nutze die dokumentierte Reset-Prozedur von Microsoft, führe sie in einem Änderungsfenster durch und dokumentiere sie.
Die Appliances angehen. Bei NAS, Druckern und Linux-Hosts ist die richtige Lösung ein Firmware- oder Konfigurations-Update, das AES aktiviert. Wo der Hersteller keinen Weg bietet, musst du entscheiden, dazu unten mehr.
Enforcement testen, bevor es dir aufgezwungen wird. Setze RC4DefaultDisablementPhase = 2 auf einem nicht-produktiven DC (oder einer Test-OU voller DCs), um das April-Verhalten zu simulieren und beobachte die obigen Abfragen auf neue Fehler. So findest du die Abhängigkeit, die du übersehen hast.
Erst breit erzwingen, wenn die Logs sauber sind und die Stakeholder zugestimmt haben.

Wenn du wirklich nicht von RC4 wegkommst

Manchmal hat eine Legacy-Appliance keine AES-fähige Firmware und kein Budget für Ersatz vor der Deadline. Microsoft lässt eine Tür offen, aber es ist eine Notlösung und du solltest sie auch so behandeln. Setze msDS-SupportedEncryptionTypes für genau dieses Konto auf 0x24, also RC4 mit AES-Sitzungsschlüsseln, beschränkt auf diesen einen Principal. Die domänenweite Alternative, DDSET auf jedem KDC auf 0x24 zu setzen, lässt deine gesamte Domäne genau dem Angriff ausgesetzt, den diese Änderung verhindern soll. Meide sie, sofern du nicht wirklich keine andere Option hast.

Wenn du eine RC4-Ausnahme behältst, umgib sie mit kompensierenden Maßnahmen. Setz das Konto und den Dienst in ein segmentiertes VLAN, gib ihm ein langes, zufälliges Passwort und rotiere es in kurzen Abständen, überwache seine Ticket-Aktivität und setz ein festes Datum für die Migration, damit die Ausnahme nicht klammheimlich dauerhaft wird. Eine RC4-Ausnahme ohne Abbauplan ist nur aufgeschobenes Risiko mit Aktenzeichen.

Womit du diese Woche anfängst

Patche deine Domänencontroller mit dem Januar-2026-Update oder neuer, falls noch nicht geschehen, schalte das Kerberos-Auditing ein und erstelle eine saubere Bestandsaufnahme, welche Konten und Geräte noch RC4 berühren. Zieh die MDI-Weak-Cipher-Posture für die Konfigurationssicht und lass die RC4-only-Service-Accounts-Abfrage für die Nutzungssicht laufen; wo sich beide Listen überschneiden, liegt deine vordringliche Arbeit. Alles danach ist Abarbeiten gegen eine Deadline, die du nicht kontrollierst und die Deadline ist der Juli.

Quellen

Zurück zum Blog

Planen Sie Ihren Weg zur Sicherheit mit uns.