Goodbye Arc4! Don't miss the door!

IQ Story 5. Februar 2026

Texte weitestgehend KI-frei
Bilder durch KI erzeugt
kann Spuren von Nüssen enthalten

Goodbye Arc4!

Microsoft hat am 13.01.2026 mit KB5073381 begonnen das Grab für die RC4-Verschlüsselung bei Kerberos auszuheben: es verschwindet nun auch (endlich) aus dem Kerberos V5-Protokoll.

RC4 kam 1987 auf die Welt und ist ein Kind von Ron Rivest (daher RC = „Rons Code“). RC4 hat noch drei Geschwister: einen älteres Geschwisterteil, RC2, und zwei jüngere Geschwister RC5 und RC6.

RC1 – nie veröffentlicht (intern, früh)
RC2 – veröffentlicht (Blockcipher)
RC3 – nie veröffentlicht
RC4 – veröffentlicht (Streamcipher)
RC5 – veröffentlicht
RC6 – veröffentlicht (AES-Finalist)

RC4, 1987

Wo ist RC3? Genau da wo auch RC1 ist!

Vielleicht nicht unbedingt im Keller, angekettet (weil der Kopf so komisch aussieht), sondern weil diese „RC“s nie veröffentlicht wurden.

RC2 und RC4, 1987

Es könnte natürlich aus sein, dass RC1 und RC3 von den illuminierten Echsenmenschen benutzt werden um mit den sphärischen Lichtwesen in der Innenerde zu kommunizieren, wer weiß das schon.

Existiert nicht. Hah!

RC4 / Arc4 / Arcfour?

RC4 wurde von RSA Security als Marke entwickelt, tauchte aber 1994, anonym in einer Mailingliste, veröffentlicht im Quelltext auf. Dieser „stream cipher*“ fand, zumindest der Wikipedia nach, in der Opensource-Community regen Zuspruch. Damit es mit der Marke „RC4“ keine rechtlichen Kalamitäten gab, wurde das Opensource-Kind ARC4 (alleged RC4 / alleged = angeblich) oder auch Arcfour genannt.

*(im Deutschen: „Stromverschlüsselung“! Als ob man Strom verschlüsseln könnte! Wobei: ganz früher, kurz nach dem Krieg , als man im Hotels noch richtige Schlüssel für die Zimmer ausgehändigt bekam, wurde ich gelegentlich vom Zimmerschloss beim Entriegeln mit einer statischen Entladung begrüßt. Vielleicht ist das ja der Schlüsselstrom.).

Die „Hochzeit“ Kerberos bei Microsoft Active Directory wurde durch Kerberoasting

bereits massiv gestört, Angriffsszenarien war leicht umzusetzen und werden leicht umgesetzt.

RC4 ist ein digitaler Kosmopilit und tanzt(e) auf vielen, vielen Hochzeiten:

TLS / SSL (RIP 2015)
Kerberos bei Microsoft Active Directory (living dead – burial scheduled for 06/2026)
NTLM, intern zur Challenge-Response-Berechnung (living dead – burial scheduled in short future)
WEP (WLAN)
WPA-TKIP
Microsoft Office
PDF-Verschlüsselung (Revision 2–4)
ZIP bei Classic ZIP Encryption
und noch diverse andere Hochzeiten (Java, SOAP / REST über TLS, CDNs, DRM, IoT)

Nun ist es soweit: die letzten Tage von RC4 bei Kerberos sind angezählt!

Zeit es los zu werden!

Los werden? Sagt wer? Funktioniert doch noch! Nix da!

Mir doch egal, das bleibt!
Was ist denn so schlimm, wenn das bleibt?
War früher doch auch kein Problem!

Es muss gehen, denn Kerberoasting bleibt trivial

RC4-HMAC (etype 23) ist der Hauptgrund, warum Kerberoasting so effektiv ist.

Service-Tickets werden mit einem RC4-Key aus dem NT-Hash des Service-Accounts verschlüsselt
Offline-Bruteforce möglich
Keine Rate-Limits
Kein Online-Kontakt mit DC nötig

Es muss gehen, denn SKELETON KEYS greifen in der Regel auf RC4 zurück.

Eine erfolgreiche Authentisierung von einem beliebigem Security Principal über das richtige, das falsche oder ein leeres Kennwort darf nicht toleriert werden.

Es muss gehen, denn es gibt so Kein Forward Secrecy

Kompromittierter Hash = alle Tickets kompromittiert
Auch rückwirkend (Offline-Analyse alter Tickets)

Es muss gehen, denn es ist nicht mehr Stand der Technik

Da gibt es rechtlich ganz fix die Unterhose in den Schritt, denn es ist juristisch relevant:

Art. 32 DSGVO
BSI-Grundschutz
ISO 27001
KRITIS / NIS2

Es muss gehen, denn die Haftung nach Sicherheitsvorfall ist brisant

Nach einem Incident wird gefragt: „Warum wurde ein bekanntermaßen gebrochener Algorithmus weiter betrieben?“

Es muss gehen, denn bei Audits & Versicherungen gibt es sonst Probleme

Cyber-Versicherungen und Audits prüfen heute explizit:

LM?
NTLMv1?
NTLMv2?
RC4?
Kerberos AES enforced?
Kerberos Armoring / FAST?

Es muss gehen, denn es gibt eine Dokumentierte Herstellerwarnung

Microsoft kündigt die Abschaltung offiziell an
Damit ist RC4:
- nicht mehr „best practice“
- sondern bewusst ignoriertes Risiko

Advanced Encryption Standard (AES)

Die werte Dame auf dem obigen Bild tanzt es richtig vor: Advanced Encryption Standard – AES.

AES gibt es in der Microsoft-Implementierung von Kerberos V5 seit dem Jahr 2008 mit Server 2008 und Windows Vista. Seit 18 Jahren wird in der Regel bei den Kerberos Ticket, basierend auf den Betriebsystemen von Microsoft, die Kryptografie ausgehandelt. Das ist im Übrigen auch der Grund, warum der Kerberos-Client immer eine Authentisierung ohne PA-Data durchführt (steht auch in der RFC 4120 so drin). Kann der DC AES256 und der Client AES256 wird mit AES256 verschlüsselt (Ticket und Session).

Also: seit 18 Jahren machen wir doch eh AES-Verschlüsselung bei Kerberos, oder?

Ja, schon, aber:

RC4 ist nicht deaktiviert und daher immer noch nutzbar
Gibt es Konstellationen in denen trotz technischer Unterstützung von AES nur RC4 verwendet wird
Gibt es Konstellationen in denen aufgrund der Datenqualität im AD technisch nur RC4 möglich ist.

Schade.

Und nun?

Abschalten aber richtig!

Bevor man das RC4-Protokoll bei Kerberos V5 abschaltet sollten ein paar Punkte beachtet werden:

Welche Computer- und Userkonten mit SPNs weisen keinen AES-Hash auf?
Welche Computer- und Userkonten davon (siehe 1) können davon nicht auf AES erweitert werden (weil der Service das nicht zulässt)?
Welche Computer- und Userkonten mit SPNs (siehe 1) können auf AES erweitert werden, jedoch kann / darf / soll das Kennwort nicht geändert werden?
Welche keytabs wurden nur mit RC4 erzeugt?

Die wichtigsten technischen Tools:

(Windows) PowerShell
DSInternals
Eventlog (Log Security) auf Domain Controllern
dsa.msc (Active Directory Users and Computers)
adsiedit.msc (Active Directory Services Interface Editor)

Ok, wie starte ich am besten?

Die gute Nachricht vorweg: alle Rechner mit Windows Vista, Server 2008 oder neuer und einem Kennwort von 2011* oder neuer sind unproblematisch.

*Sofern die Domäne schon im 2008 Domain Functional Level oder höher ist.

Warum? Ab dem Domain Functional Level 2008 (oder höher) werden nur noch DCs mit Server 2008 (oder neuer) betrieben und Rechner wie Vista und/oder Server 2008 hinterlegen im AD zu ihrem NT-Hash auch die AES-Hashes.

Aber: wie prüfe ich das?

Windows Eventlog „Security“ auf Domain Controllern

Es wird das Eventlog Security auf den Domain Controllern nach den Events 4768 (TGT-Request) und 4769 (TGS-Request) untersucht. Ticket Encryption Type und Session Encryption Types mit (0x12 = AES256-CTS-HMAC-SHA1-96 und 0x11 = AES128-CTS-HMAC-SHA1-96) sind ok. Alles andere nicht!

Wenn hier etwas aus der 0x12er und 0x11er Reihe tanzt ist das vermutlich der betagten Herrn RC4 (0x17 = RC4-HMAC-NT). Der ältere Herr bewegt sich mit der tanzenden Masse, so dass ein Blick durch den XPath-Filter lohnt. ProTipp: auf jedem DC schauen!

Update vom 11.02.2026: Lieber Sascha, danke für den Hinweis mit 0x17 (0x18 wäre der etype rc4-hmac-exp)!

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

DSInternals

Mit dem PowerShell-Modul „DSInternals“ von Michael Grafnetter lassen sich Computer- und Benutzerobjekte wunderbar über die RPC-Schnittstelle der Domain Controller inkl. der Hashes betrachten. Das Modul lässt sich am besten mit „Install-Module -Name DSInternals“ über NuGet installieren.

NuGet ist meistens der Package-Provider, den PowerShell benutzt, um Pakete aus NuGet-Repositories zu beziehen; vor allem als Transport / Backend für Dinge wie PowerShellGet. NuGet, ja? Nicht Nugget! Wir sind hier nicht bei den „goldenen Bögen“!

DSInternals gestattet es, sofern die erweiterten Berechtigungen „Replicate Directory Changes und Replicate Directory Change (All)“ gewährt wurden, das Betrachten der Hashes aus dem AD bei Benutzer- und Computerkonten.

Wenn der Block „KerberosNew“ leer ist fehlen diesem Konto die AES-Hashes und es können keine AES-Verschlüsselten TGTs / TGSs ausgestellt werden. Bei einem „normalen“ User ohne SPN ist das (fast) egal. Das Betrifft Benuzter- und Computerkonten, welche SPNs aufweisen. Ohne SPN wird im Bereich Kerberos (mit oder ohne RC4) hier nichts passieren.

Get-ADReplAccount -SamAccountName administrator -Domain CH -Server ch-vdc01

DistinguishedName: CN=Administrator,CN=Users,DC=CLOUD-HYBRID,DC=DE
[...]
    KerberosNew:
      Credentials:
        AES256_CTS_HMAC_SHA1_96
          Key: 6be3f442c9ef38b2f88c9510fc14a97e188338e4b6008b69224cf9e04535d2d6
          Iterations: 4096
        AES128_CTS_HMAC_SHA1_96
          Key: 4a42bcf9ac0d13f95e6b70cdf0a4fc08
          Iterations: 4096
        DES_CBC_MD5
          Key: 985d76ea76aeb062
          Iterations: 4096
      OldCredentials:
        AES256_CTS_HMAC_SHA1_96
          Key: 47d600a1bf1471bb6e105da580d4e4454e6e47f26ffb5e12cb0397a8d20364bf
          Iterations: 4096
        AES128_CTS_HMAC_SHA1_96
          Key: 5bb9fb4fcee73182bacfb02491a9b009
          Iterations: 4096
        DES_CBC_MD5
          Key: c8452fb023ea1a16
          Iterations: 4096
      OlderCredentials:
        AES256_CTS_HMAC_SHA1_96
          Key: fe6d990288b2f3b323b921798441604bf702bb53eadd75b2a965bab87a683eed
          Iterations: 4096
        AES128_CTS_HMAC_SHA1_96
          Key: 8bbcf061cfb4331d06035ef4fa366ff6
          Iterations: 4096 [...

Indikation und Diagnose

Das Eventlog bietet mir eine Indikation an, die genaue Diagnose muss ich über DSInternals stellen. Wenn keine AES-Hashes im AD hinterlegt sind können keine TGT und TGS mit AES ausgestellt werden, logisch.

PS C:\> (Get-ADReplAccount -SamAccountName svcdataapp19 -Domain CH -Server ch-vdc01).Supplementalcredentials.KerberosNew
PS C:\> (Get-ADReplAccount -SamAccountName krbtgt -Domain CH -Server ch-vdc01).Supplementalcredentials.KerberosNew

Credentials:
  AES256_CTS_HMAC_SHA1_96
    Key: f728266fff86c49b0ca26e26d1a6e3982689a1fcd65d97d431e14d61a1b4b5da
    Iterations: 4096
  AES128_CTS_HMAC_SHA1_96
    Key: 2d13a56b437eabd347376e796a2eb29a
    Iterations: 4096
  DES_CBC_MD5
    Key: 1a082f193751322c
    Iterations: 4096
OldCredentials:
OlderCredentials:
ServiceCredentials:
Salt: CLOUD-HYBRID.DEkrbtgt
DefaultIterationCount: 4096
Flags: 0

Ist die Abfrage $null, muss ich was tun.

$user = Get-ADUser -Filter { serviceprincipalname -like "*" }
$user.ForEach{ 
                $return = (Get-ADReplAccount -SamAccountName $_.SamAccountName -Domain CH -Server CH-VDC01).Supplementalcredentials.KerberosNew
                if ($null -eq $return) {
                Write-Output "Issue with $($_.SamAccountName)" }
             }

ProTipp: der NetBIOS-Name der Domäne und der Name des DC müssen an die eigene Umgebung angepasst werden.
ProPlusTipp: es reicht sich den Kram bei einem DC anzuschauen, vorzugsweise dem PDC-E

msDS-SupportedEncryptionTypes und DefaultDomainSupportedEncTypes

Wichtig bevor man die Verschlüsselung bei Kerberos V5 auf AES erweitert: es müssen AES-Hashes bei dem Benutzer- oder Computerkonto vorhanden sein. Fehlen die Hashes, müssen diese durch erneutes setzen des Kennwortes erzeugt werden.

Beim Benutzerobjekt in der Regel durch „Reset Password“, dann wird auch die Historie nicht geprüft, bei Computerkonten durch „Test-ComputerSecureChannel -Repair“.

Jetzt wäre die Gelegenheit sich den Artikel „Spaß mit Kerberos V5 (mal wieder)“ wegen der DefaultDomainSupportedEncTypes durchzulesen, denn wir müssen das Attribut msDS-SupportedEncryptionTypes bei den betroffenen Konten auf 24 (dezimal) setzen. <not set>, 0, 4 oder 28 wird zu 24 (bitte auch an Vertrauensstellungen und an das krbtgt-Konto denken). Das erweitert die Kryptografie um die AES-Verschlüsselung, RC4 wird noch nicht abgeschaltet.

Ja, in 28 ist die 24 drin, ich weiß. Ich will aber die 4 da raus bekommen. Das Ziel ist es ja RC4 los zu werden und nicht „nur“ um AES zu erweitern.

Spätestens jetzt müssen ggf. erstellte Keytab-Dateien erneuert werden. Ich kann aus eigner Erfahrung sagen: holt die ensprechenden Personen aus den Fachabteilungen rechtzeitig ins Boot und testet vorher ausgiebig!

Computerkonten unter Microsoft Windows stellen sich in dem Attribut über die GPO (siehe unten) selber um; da muss man sich nicht groß kümmern. Dienstkonten und Computerkonten, die nicht unter Microsoft Windows betrieben werden, müssen per Hand umgestellt werden.

RC4 per GPO abschalten

Per Gruppenrichtlinie muss jetzt, vorsichtig bei den Clients beginnend, das RC4-Protokoll bei Kerberos abgeschaltet werden. Die empfohlene Einstellunge gem. Microsoft Baseline und CIS-Benchmark ist AES128, AES256 und Future encyption types.

Zu finden ist das unter „Computer Configuration“ ⇒ Policies ⇒ „Windows Settings“ ⇒ „Security Settings“ ⇒ „Local Policies“ ⇒ „Security Options“ ⇒ „Network security: Configure encryption types allowed for Kerberos“.

Die Zauberformel

Mit wenigen Clients anfangen. RC4 abschalten und die Logs auf den DCs hierzu beobachen, ebenso auf Rückmeldungen der Anwender achten.
Den Kreis der RC4-less-Clients erweitern bis alle Clients ohne RC4 bei Kerberos auskommen.
Mit wenigen Server weiter machen. RC4 abschalten, die Logs auf den DCs hierzu beobachen, ebenso auf Rückmeldungen der Systembetreuer und Anwender achten.
Den Kreis der RC4-less-Server erweitern bis alle Server ohne RC4 bei Kerberos auskommen.
Mit wenigen Domain Controllern weiter machen, am besten, sofern vorhanden, in einer AD-Site. RC4 abschalten und die Logs auf den DCs hierzu beobachen.
Den Kreis der RC4-less-Domain Controller erweitern bis alle Domain Controller ohne RC4 bei Kerberos auskommen.

Das ist mir zu heiß!

Die Uhr tickt, die Zeit läuft: es muss RC4 auch bei Kerberos V5 endlich abgeschaltet werden (siehe oben).

Wenn das nun zu unbequem und / oder zu risikoreich anmutet: wir bieten in diesem Bereich seit 2019 Unterstützung, Beratung und Schulungen an.

Eine kurze E-Mail an info@iqunit.com oder ein Anruf unter +49 731 1848699-0 sind keine große Hürde.

Goodbye Arc4! Don’t miss the door!