Kerberos RC4 Deaktivierung in 2026

Worum geht es?

Microsoft entfernt ab 2026 schrittweise den veralteten Verschlüsselungsalgorithmus RC4‑HMAC aus der Kerberos‑Authentifizierung in Active Directory. RC4 gilt seit Jahren als unsicher und ermöglicht unter anderem effektive Kerberoasting‑Angriffe. Daher ist dies bereits auch schon länger Bestandteil unserer Security‑Optimierungen.

Wenn alle Vorbereitungen bereits getroffen sind und RC4 nicht mehr benötigt wird, gibt es keinen Grund, auf das Enforcement seitens Microsoft zu warten – also RC4 sofort deaktivieren!

Weitere Informationen findet man auch unter der Bezeichnung CVE-2026-20833 oder in folgenden Quellen:

• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20833
• https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/what-changed-in-rc4-with-the-january-2026-windows-update-and-why-it-is-important/4504732
• https://support.microsoft.com/en-us/topic/how-to-manage-kerberos-kdc-usage-of-rc4-for-service-account-ticket-issuance-changes-related-to-cve-2026-20833-1ebcda33-720a-4da8-93c1-b0496e1910dc

Was ist, wenn ich nichts mache?

Dann ist damit zu rechnen, dass es zu Ausfällen und Einschränkungen von Systemen/Funktionen kommen kann. Typische Fälle könnten dabei folgende sein:

• Service Accounts mit alten Passwörtern
• Veraltete Windows Versionen (z. B. 2000, XP, Windows Server 2003)
• NetApp CIFS Shares (wo AES noch nicht aktiviert wurde)
• NAS, Appliances, Firewall, Linux Systeme ohne AES Unterstützung
• Nicht kompatible Applikationen
• Keytab Anbindungen

In einzelnen Fällen insbesondere Windows OS wird es zu einem Fallback auf NTLM kommen.
Dies ist aber keine Lösung, sondern die noch schlechtere Option, NTLM = alt und unsicher.

Was passiert wann?

Durch die Installation der jeweiligen Security Updates ändert sich folgendes.

Wie ist die Vorgehensweise?

⚠️ Die folgenden Schritte sollten vor den April 2026 Sicherheitsupdates abgeschlossen sein!

1. Installation Updates auf den DC’s
   • Für Events 201-209: mindestens Januar 2026 erforderlich
   • Für Security Events 4768, 4769: mindestens Januar 2025 erforderlich
2. Aktivierung Auditing auf den DC’s
   • Um die entsprechenden Events zu erhalten, ist Auditing auf den Domain-Controllern zu aktivieren. Dies ist recht einfach via Gruppenrichtlinie möglich.

     Gruppenrichtlinien-Editor – Deutsch:

     Computerkonfiguration → Richtlinien → Windows-Einstellungen → Sicherheitseinstellungen → Erweiterte Überwachungsrichtlinie → KontoanmeldungKerberos-

     Authentifizierungsdienst überwachen → Erfolgreich & FehlgeschlagenTicketvorgänge des Kerberos-Diensts überwachen → Erfolgreich & FehlgeschlagenGruppenrichtlinien-Editor – Englisch:

     Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Account Logon

     Audit Kerberos Authentication Service → Success & Failure

     Audit Kerberos Service Ticket Operations → Success & Failure

   • An dieser Stelle noch der Tipp, auch die entsprechenden Event Logs auf dem DC zu vergrößern.
3. Auswertung Events auf den DC’s und Behebung von Problemen

• • Siehe Tabelle „Neue Events und deren Bedeutung“ für mögliche Ansatzpunkte → Die Vorgehensweise mit den neuen Events ist nun deutlich einfacher und klarer!
  • Alternativ ist dies aber auch über die „alten“ Security Events 4768, 4769 (Filter nach TicketEncryptionType=0x17 und TicketEncryptionType=0x18 ) möglich.

Für diese Variante hier ein RC4 TicketEncryptionType XML Filter, welcher einfach im Security Eventlog genutzt werden kann:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[
        System[
          Provider[@Name='Microsoft-Windows-Security-Auditing']
          and (EventID=4768 or EventID=4769)
        ]
        and
        EventData[
             Data[@Name='TicketEncryptionType']='0x17'
          or Data[@Name='TicketEncryptionType']='0x18'
        ]
      ]
    </Select>
  </Query>
</QueryList>

Optional, aber sinnvoll: Auswertung via Powershell oder mit einer zentralen Logging Lösung!

Neue Events und deren Bedeutung

Event Log: System / Event Source: Kdcsvc

Es ist darauf zu achten, dass die „neuen“ Events nur in den genau beschriebenen Konstellationen auftreten. Wenn man also versucht, zur Verifikation absichtlich via SupportedEncryptionTypes ein RC4 Event zu generieren, ist dies nicht unbedingt erfolgreich – da die Events nur auftreten, wenn das Attribut „leer“ ist oder eins der beiden Attribute (SupportedEncryptionTypes, DefaultDomainSupportedEncTypes) auf „AES“ steht.

Noch nicht alle zusammengetragenen Informationen in der Tabelle konnte ich bestätigen. Weitere Details sind auch unter How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 – Microsoft Support zu finden.

Weitere Optimierung der Sicherheit

• Prüfung, ob fälschlicherweise Accounts RC4 via msds-SupportedEncryptionTypes aktiviert haben, obwohl diese auch AES könnten!
  • 0x24 = AES128 / AES 256 → also eine bereits „sichere“ Konfiguration
  • 0x28 = AES128 / AES 256 / RC4 → Prüfung, ob RC4 hier wirklich benötigt wird
• Wenn die Umgebung bereits ausschließlich Kerberos AES spricht, dann kann dies jetzt via Gruppenrichtlinien (GPO) global durchgesetzt werden.

Ergänzende Informationen

Der temporäre Registry Wert „RC4DefaultDisablementPhase“

Der Registry Wert steuert die Bereitstellung der Kerberos Änderungen. Dieser Wert ist nur temporär und wird in Phase 3 bereits ignoriert.

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters

Wert: RC4DefaultDisablementPhase

• 0: kein Audit / keine Änderung
• 1: Events mit Warnungen werden generiert (Standard in Phase 1)
• 2: Kerberos geht davon aus, dass RC4 nicht aktiviert ist (Standard in Phase 2)

Wie funktioniert Kerberoasting?

Beim Kerberoasting werden Kerberos‑Service‑Tickets extrahiert und anschließend offline geknackt.

• Ein Angreifer fordert Service Tickets (TGS) für gültige SPNs an.
  Das entspricht dem normalen Verhalten von Kerberos in Domänen – hierfür sind keine besonderen Rechte erforderlich.
• Die Tickets können über Tools oder PowerShell‑Skripte extrahiert werden.
  (Solche Tools werden von Sicherheitslösungen inzwischen häufiger erkannt.)
• Die extrahierten Tickets lassen sich als Datei mitnehmen und anschließend offline per Brute‑Force‑ oder Wörterbuch‑Angriff knacken.
  Insbesondere bei RC4 ist das Knacken vergleichsweise einfach, da der Algorithmus kryptografisch schwach ist.
• Als Ergebnis erhält der Angreifer das Passwort des Service Accounts.