Im Laufe der Geschichte von Active Directory haben Angreifer immer wieder neue Wege gefunden, Schwachstellen im Kerberos-Authentifizierungsprotokoll aufzudecken. Um die mit „Kerberoasting“ verbundenen Risiken zu verringern, wird Microsoft die RC4-Verschlüsselung ab April 2026 auslaufen lassen. Falls Sie die Anwendungen in Ihrer Umgebung, die von dieser Änderung betroffen sein könnten, noch nicht ausfindig gemacht haben, ist es an der Zeit, diese Aufgabe ganz oben auf Ihre To-do-Liste zu setzen. Dieser Beitrag erläutert den Prozess – und verweist Sie auf Ressourcen, die Ihnen dabei helfen können.
Warum stellt Microsoft die RC4-Verschlüsselung ein?
Taktiken, Techniken und Vorgehensweisen (TTPs), die Kerberos ausnutzen, lassen sich in drei Kategorien einteilen:
- Roasting-Angriffe, wie beispielsweise AS-REQ Roasting und Kerberoasting
- Missbrauch von Delegierungen, einschließlich uneingeschränkter Kerberos-Delegierung und ressourcenbasierter eingeschränkter Delegierung
- Missbrauch von Tickets, darunter Golden Ticket, Silver Ticket, Diamond Ticket, Sapphire Ticket, Bronze Bit, Pass-the-Ticket und so weiter
Kerberoasting hat sich zu einer der gängigsten dieser Angriffstechniken entwickelt. In den letzten Jahren hat Microsoft Abwehrmaßnahmen gegen Kerberoasting-Angriffe eingeführt, und es sind zahlreiche Artikel zum Thema Kerberoasting und zu dessen Abwehr erschienen. Wir werden in diesem Beitrag nicht näher auf die technischen Details des Angriffs eingehen, doch aus allgemeiner Sicht funktioniert er wie folgt:
- Ein Angreifer fordert ein Dienstticket für einen gültigen Dienstprinzipalnamen (SPN) an.
- Das Kerberos Key Distribution Center (KDC) stellt das Service-Ticket unter Verwendung der RC4-Verschlüsselung aus – einem Algorithmus, der schwächer ist als AES-SHA1 (und daher leichter zu knacken ist).
- Der Angreifer speichert dieses Ticket offline und nutzt einen Brute-Force-Angriff, um das Passwort für das Konto zu ermitteln.
- Der Angreifer nutzt das kompromittierte Konto für die laterale Bewegung und die Ausweitung von Berechtigungen.
Da RC4 häufig im Rahmen von Kerberoasting-Angriffen ausgenutzt wird, hat Microsoft angekündigt, diese Verschlüsselungsmethode auslaufen zu lassen: Die Überprüfung beginnt im Januar 2026, die Durchsetzung mit manueller Rücknahme im April 2026 und die vollständige Durchsetzung im Juli 2026.
Viele Unternehmen nutzen jedoch nach wie vor interne oder von Drittanbietern stammende Anwendungen, die sicherere Verschlüsselungsstandards wie AES-128 und AES-256 nicht unterstützen. Falls Ihr Unternehmen zu dieser Gruppe gehört, müssen Sie diese Anwendungskonten ausfindig machen und für jedes einzelne die AES-Verschlüsselung konfigurieren.
Welche Anwendungen verwenden RC4?
Woher wissen Sie also, welche Anwendungen RC4 als Kerberos-Verschlüsselungsart verwenden?
Sie müssen den Kerberos-Authentifizierungsdienst und die Kerberos-Dienstticketvorgänge überwachen, um die Ereignis-IDs 4768 (Ereignisse des Authentifizierungsdienstes) und 4769 (Dienstticketvorgänge) im Sicherheitsereignisprotokoll zu erfassen. (Microsoft hat mit den Patches vom Januar 2026 zusätzliche Ereignis-IDs 201–209, auch bekannt als KDC-Hardening, in das Systemereignisprotokoll aufgenommen, um die Bemühungen zur Abschaffung von RC4 weiter zu unterstützen. Die Ereignisse 4768 und 4769 können jedoch als die „führenden“ Ereignisse betrachtet werden, weshalb sich dieser Beitrag auf die Verfolgung dieser beiden Ereignisse konzentriert.)
Lassen Sie uns diese Ereignisse näher betrachten.
Ereignis-ID 4768
Abbildung 1 zeigt ein Beispiel für die Ausgabe der Ereignis-ID 4768.
Es wurde ein Kerberos-Authentifizierungsticket (TGT) angefordert.
Kontoinformationen:
Kontoname: jdoe
Angegebener Realm-Name: CHILD
Benutzer-ID: S-1-5-21-1873250772-3107742394-1596888999-1114
Von MSDS unterstützte Verschlüsselungstypen: 0x27 (DES, RC4, AES-Sk)
Verfügbare Schlüssel: AES-SHA1, RC4
Dienstinformationen:
Dienstname: krbtgt
Dienst-ID: S-1-5-21-1873250772-3107742394-1596888999-502
MSDS-unterstützte Verschlüsselungstypen: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Verfügbare Schlüssel: AES-SHA1, RC4
Informationen zum Domänencontroller:
MSDS-unterstützte Verschlüsselungstypen: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Verfügbare Schlüssel: AES-SHA1, RC4
Netzwerkinformationen:
Client-Adresse: ::ffff:10.1.1.250
Client-Port: 53904
Angegebene E-Typen:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC-NT
DES-CBC-MD5
Zusätzliche Informationen:
Ticket-Optionen: 0x40810010
Ergebniscode: 0x0
Ticket-Verschlüsselungstyp: 0x12
Sitzungsverschlüsselungstyp: 0x12
Vorabauthentifizierungstyp: 2
Verschlüsselungstyp für Vorabauthentifizierung: 0x12
--Der Rest wurde der Kürze halber gekürzt.--
Abbildung 1. Beispielausgabe der Ereignis-ID 4768
Dieses Beispiel enthält mehrere relevante Informationen.
Kontoinformationen
- Kontoname. Die Identität, die das Ticket Granting Ticket (TGT) anfordert
- Angegebener Realm-Name. Die Domäne, in der sich die Identität befindet
- Benutzer-ID. Der Anzeigename (oder SID) der Identität
- MSDS-unterstützte Verschlüsselungsarten. Die Verschlüsselungsarten, die das Konto verwenden kann
Serviceinformationen
- Dienstname. Der angeforderte Dienstprinzipal (in diesem Fall krbtgt)
- Dienst-ID. Der Anzeigename (oder SID) des angeforderten Dienstprinzipals
- MSDS-unterstützte Verschlüsselungsarten. Die Verschlüsselungsarten, die das Dienstkonto verwenden kann
Informationen zum Domänencontroller (DC)
- MSDS-unterstützte Verschlüsselungsarten. Die vom DC unterstützten Verschlüsselungsarten
Zusätzliche Informationen
- Ticket-Optionen: 0x40810010 (weiterleitbar, verlängerbar, kanonisieren, verlängerbar-ok), wie in Abbildung 2 dargestellt.
- Ticket-Verschlüsselungstyp: 0x12 (AES256), wie in Abbildung 3 dargestellt .
- Typ der Sitzungsverschlüsselung: 0x12 (AES256), wie in Abbildung 3 dargestellt .
- Vorauthentifizierungs-Verschlüsselungstyp: 0x12 (AES256), wie in Abbildung 4 dargestellt.
Ereignis-ID 4769
Abbildung 5 zeigt ein Beispiel für die Ausgabe der Ereignis-ID 4769.
A Kerberos service ticket was requested.
Account Information:
Account Name: jdoe@CHILD.CONTOSO.COM
Account Domain: CHILD.CONTOSO.COM
Logon GUID: {5f752786-c7b3-fb33-0ce8-a54adeea22c3}
MSDS-SupportedEncryptionTypes: N/A
Available Keys: N/A
Service Information:
Service Name: CHILDMEMBER$
Service ID: S-1-5-21-1873250772-3107742394-1596888999-1105
MSDS-SupportedEncryptionTypes: 0x1C (RC4, AES128-SHA96, AES256-SHA96)
Available Keys: AES-SHA1, RC4
Domain Controller Information:
MSDS-SupportedEncryptionTypes: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Available Keys: AES-SHA1, RC4
Network Information:
Client Address: ::ffff:10.1.1.250
Client Port: 53905
Advertized Etypes:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC-NT
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0x12
Session Encryption Type: 0x12
Failure Code: 0x0
Transited Services: -
--Remainder snipped brevity--
Abbildung 5. Beispielausgabe für die Ereignis-ID 4769
Dieses Beispiel enthält mehrere relevante Informationen.
Serviceinformationen
- Dienstname. Die SPN der Dienstticket-Anforderung (in diesem Fall für host/childmember.child.contoso.com), wie in Abbildung 6 dargestellt.
sname-string: 2 Einträge
SNameString: host
SNameString: childmember.child.contoso.com
Abbildung 6. Ausschnitt aus einem Wireshark-Trace, der den SPN der Service-Ticket-Anfrage zeigt
- Dienst-ID. Der Anzeigename (oder SID) des Sicherheitsprinzips, das den SPN registriert hat
- MSDS-unterstützte Verschlüsselungsarten. Die Verschlüsselungsarten, die das Dienstkonto verwenden kann
Informationen zu DC
- MSDS-unterstützte Verschlüsselungsarten. Die Verschlüsselungsarten, die der DC unterstützt
Zusätzliche Informationen
- Ticketoptionen. 0x40810000
- Ticket-Verschlüsselungstyp: 0x12 (AES256)
- Art der Sitzungsverschlüsselung: 0x12 (AES256)
Wenn RC4 zur Verschlüsselung verwendet wird, weichen die Ergebnisse geringfügig von denen in den vorherigen Beispielen ab. Abbildung 7 zeigt die Ausgabe der Ereignis-ID 4769 für einen Client-Computer, der ausschließlich die RC4-Verschlüsselung verwendet.
A Kerberos service ticket was requested.
Account Information:
Account Name: jdoe@CHILD.CONTOSO.COM
Account Domain: CHILD.CONTOSO.COM
Logon GUID: {df8a66a8-8c1d-061e-b216-f935b45eb88a}
MSDS-SupportedEncryptionTypes: N/A
Available Keys: N/A
Service Information:
Service Name: CHILDMEMBER$
Service ID: CHILD\CHILDMEMBER$
MSDS-SupportedEncryptionTypes: 0x4 (RC4)
Available Keys: AES-SHA1, RC4
Domain Controller Information:
MSDS-SupportedEncryptionTypes: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Available Keys: AES-SHA1, RC4
Network Information:
Client Address: ::ffff:10.1.1.250
Client Port: 51299
Advertized Etypes:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC-NT
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0x17
Session Encryption Type: 0x17
Failure Code: 0x0
Transited Services: -
--Remainder snipped for brevity--
Abbildung 7. Ausgabe für die Ereignis-ID 4769 auf einem Client-Computer, der ausschließlich RC4 verwendet
Die fettgedruckten Stellen zeigen die wesentlichen Unterschiede zwischen diesem Fall und den vorherigen Beispielen. Lassen Sie uns diese näher betrachten.
Serviceinformationen
- Dienstname: CHILDMEMBER$ (wie im vorherigen Beispiel)
- Dienst-ID. Der Anzeigename (oder SID) des angeforderten Dienstprinzipals
- Von MSDS unterstützte Verschlüsselungsarten. 0x4 (RC4)
Zusätzliche Informationen
- Ticketoptionen. 0x40810000 (wie im vorherigen Beispiel)
- Ticket-Verschlüsselungstyp: 0x17 (RC4-HMAC)
- Typ der Sitzungsverschlüsselung: 0x17 (RC4-HMAC)
So überprüfen Sie Ihre Umgebung auf Anwendungen, die RC4 verwenden
Wie das vorangegangene RC4-Beispiel zeigt, müssen Sie zur Erkennung von RC4-Verschlüsselung in Ihrer Umgebung die Ereignisprotokolle (vorzugsweise SIEM-Protokolle) durchsuchen, um Authentifizierungsdienstanfragen (AS-REQ) und -antworten (AS-REP) sowie Ticket Granting Service-Anfragen (TGS-REQ) und -antworten (TGS-REP) mit den Ticket- und Sitzungsverschlüsselungstypen 0x17 zu finden.
Um Ihnen dabei zu helfen, haben wir Beispielabfragen sowohl für Microsoft Sentinel als auch für Splunk erstellt. Sie können diese Beispiele als Vorlagen verwenden, um Ihre eigene Umgebung zu überprüfen.
Je nachdem, wie Sie die Ereignisweiterleitung für Sentinel konfiguriert haben, müssen Sie entweder „DeviceEvents“ oder „WindowsEvent“ abfragen. Wenn Sie beispielsweise die Windows-Ereignisweiterleitung verwenden, um Ereignisprotokolle zu erfassen und an Sentinel weiterzuleiten, müssen Sie „WindowsEvent“ abfragen und nur nach Instanzen der Ereignis-IDs 4768 und 4769 suchen, bei denen entweder der „Ticket-Verschlüsselungstyp“ oder der „Sitzungsverschlüsselungstyp“ mit 0x17 übereinstimmt.
Mit der folgenden Abfrage können Sie Sentinel durchsuchen. Diese Abfrage wurde um weitere Datenspalten erweitert.
WindowsEvent
| where EventID in ('4768', '4769')
| where TimeGenerated between (ago(60d) .. now())
| extend EventDataJson = parse_json(EventData)
| extend TargetUserName = EventDataJson.TargetUserName
| extend TargetDomainName = EventDataJson.TargetDomainName
| extend IpAddress = EventDataJson.IpAddress
| extend ServiceAvailableKeys = EventDataJson.ServiceAvailableKeys
| extend ServiceName = EventDataJson.ServiceName
| extend SessionKeyEncryption = EventDataJson.SessionKeyEncryptionType
| extend TicketEncryption = EventDataJson.TicketEncryptionType
| extend TicketOptions = EventDataJson.TicketOptions
| where SessionKeyEncryption == '0x17' or
TicketEncryption == '0x17'
| project TimeGenerated, EventID, TargetUserName, TargetDomainName, IpAddress, ServiceName, TicketEncryption, SessionKeyEncryption, TicketOptions, ServiceAvailableKeys, EventDataJson
Hier finden Sie eine kurze Übersicht über die Anfrage:
WindowsEvent
Wie die Abfrage in dieser Implementierung von Sentinel gespeichert wird (in Ihrer Umgebung könnte es sich, wie zuvor beschrieben, um DeviceEvents handeln)
| where EventID in ('4768', '4769')
Suche nach den Ereignis-IDs 4768 und 4769
| where TimeGenerated between (ago(60d) .. now())
Reicht 60 Tage zurück (Sie können einen beliebigen Wert festlegen)
| extend EventDataJson = parse_json(EventData)
Formatiert die Spalte „EventData“ im JSON-Format und wertet das JSON aus, damit es in der restlichen Abfrage verwendet werden kann
| extend TargetUserName = EventDataJson.TargetUserName
Gibt die Identität an, die das Ticket anfordert
| extend TargetDomainName = EventDataJson.TargetDomainName
Gibt die Domäne an, in der sich die anfragende Identität befindet
| extend IpAddress = EventDataJson.IpAddress
Zeigt die IP-Adresse des Clients an, sofern diese im Ereignis angegeben ist
| extend ServiceAvailableKeys = EventDataJson.ServiceAvailableKeys
Zeigt die für den Dienst verfügbaren Verschlüsselungsschlüssel an
| extend ServiceName = EventDataJson.ServiceName
Gibt den SPN an, für den die Ticketanforderung bestimmt ist
| extend SessionKeyEncryption = EventDataJson.SessionKeyEncryptionType
Gibt die Verschlüsselungsart des Sitzungsschlüssels an, den der Client (Anforderer) für die Interaktion mit dem Ticketinhaber verwendet
| extend TicketEncryption = EventDataJson.TicketEncryptionType
Gibt die Verschlüsselungsart des TGT oder des Service-Tickets an
| extend TicketOptions = EventDataJson.TicketOptions
Enthält zusätzliche Informationen zu den Ticketoptionen der Anfrage, die bei der Identifizierung von Ticketoptionen wie Weiterleitungstickets, Delegationstickets, weitergeleiteten Tickets, Proxy-Tickets usw. hilfreich sein können
| where SessionKeyEncryption == '0x17' or
TicketEncryption == '0x17'
Sucht entweder nach einer Verschlüsselung des Sitzungsschlüssels oder nach einer Ticketverschlüsselung vom Typ RC4-HMAC (0x17)
| project TimeGenerated, EventID, TargetUserName, TargetDomainName, IpAddress, ServiceName, TicketEncryption, SessionKeyEncryption, TicketOptions, ServiceAvailableKeys, EventDataJson
Gibt die Felder an, die in der Ergebnisanzeige angezeigt werden sollen
Abbildung 8 zeigt ein Beispiel für die Ergebnisse dieser Abfrage.
Bei Splunk würde dieselbe Abfrage wie folgt aussehen:
index="wineventlog" LogName="Security" EventCode IN ("4768", "4769") earliest=-60d@d latest=now
| search Session_Encryption_Type="0x17" or Ticket_Encryption_Type="0x17"
| Tabelle _time EventCode Account_Name Account_Domain Client_Address service_name Ticket_Encryption_Type Session_Encryption_Type Ticket_Options, _raw
Bevor Sie diese Abfragen in Ihrer Umgebung verwenden, stellen Sie sicher, dass die Protokollierung von Dienstanfragen aktiviert ist. Ohne diese Aktivierung generieren die Domänencontroller die entsprechenden Ereignisse nicht (Ereignis-IDs 4768 und 4769 sowie die Ereignis-IDs 201–209, die sich auf die KDC-Absicherung beziehen).
Die beste Möglichkeit, die Überwachung von Diensttickets zu aktivieren, besteht darin, entweder eine vorhandene Gruppenrichtlinie zu aktualisieren oder eine neue hinzuzufügen, die der Organisationseinheit (OU) Ihres Domänencontrollers zugewiesen ist. Dies müssen Sie für jede Domäne in Ihrer AD-Gesamtstruktur tun. Der Pfad zu den entsprechenden Einstellungen lautet: „Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Erweiterte Konfiguration der Überwachungsrichtlinien > Überwachungsrichtlinien > Kontoanmeldung“. Aktivieren Sie die Unterkategorien „Kerberos-Authentifizierungsdienst überwachen“ und „Kerberos-Service-Ticket-Vorgänge überwachen“ sowohl für „Erfolgreich“ als auch für „Fehlgeschlagen“ ( Abbildung 9).
Falls Sie in Ihren Domänen noch nie eine erweiterte Überwachungsrichtlinie konfiguriert haben, stellen Sie sicher, dass Sie unter „Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen“ auch die Einstellung „Überwachung: Einstellungen der Unterkategorie ‚Überwachungsrichtlinie erzwingen‘ (Windows Vista oder höher) überschreiben“ aktivieren. Diese Richtlinie wird in der Regel in derselben Gruppenrichtlinie festgelegt wie die Überwachung von Diensttickets.
Hinweis: Wenn in den Sicherheitsereignisprotokollen Ihrer Domänencontroller keine 4769-Service-Ticket-Ereignisse angezeigt werden, werden auch keine KDC-Sicherheitswarnungen (201–209) im Systemprotokoll angezeigt.
Tipp zur Validierung: Stellen Sie vorübergehend sicher, dass ein Gerät ausschließlich RC4 unterstützt, und fordern Sie ein Service-Ticket von einem Konto an, bei dem das Feld „msDS-SupportedEncryptionTypes“ keine Werte enthält. Wenn die Überwachung ordnungsgemäß konfiguriert ist, sollten die entsprechenden Warnungen angezeigt werden. Weitere Informationen finden Sie im Microsoft Learn-Artikel„Erkennen und Beheben der RC4-Verwendung in Kerberos“.
Sobald Sie wissen, dass Ihre Kerberos-Protokollierung funktioniert, beginnt die eigentliche Arbeit: die Analyse der empfangenen Ereignisse und die Behebung der Probleme bei den betroffenen Konten oder Systemen.
Die größte Schwierigkeit bei der Entfernung von RC4 ergibt sich aus alten Dienstkonten, deren Passwörter seit vielen Jahren nicht mehr geändert wurden. Da RC4 in Active Directory an den NT-Hash gebunden ist, verfügt jedes Konto, dessen Passwort nach der Einführung von AES (d. h. nach der Veröffentlichung von Windows Server 2008 und Windows Vista) nie zurückgesetzt wurde, möglicherweise weiterhin nur über RC4-kompatible Schlüssel.
Sie können dieses Problem nur beheben, indem Sie das Kennwort des Dienstkontos zweimal zurücksetzen, wodurch Active Directory gezwungen wird, die erforderlichen AES-Schlüssel zu generieren. Allerdings müssen Sie auch wissen, wo dieses Dienstkonto in Ihrer Umgebung verwendet wird, beispielsweise zum Starten des entsprechenden Dienstes auf einem bestimmten Mitgliedsserver oder zum Ausführen einer geplanten Aufgabe.
Sollten Sie neben den Ereignissen 4768 oder 4769 Warnungen zur KDC-Sicherheitshärtung (Ereignisse 201–209 im Systemprotokoll) sehen, bietet dieser LinkedIn-Beitrag von Jerry Devore von Microsoft einen hervorragenden Überblick darüber, wie Sie die betroffenen Konten und Systeme beheben können, wobei msds-SET = msDS-SupportedEncryptionTypes (Tabelle 1) gilt.
| Veranstaltungspaar | Was das bedeutet | Hauptursache | Schnelle Lösung |
|---|---|---|---|
| 201/203 | RC4-only-Client + leeres msds-SET | Älteres Gerät oder Keytab | Aktivieren Sie AES auf dem Client ODER setzen Sie msds-SET auf 28 |
| 202/204 | Dem Konto fehlt der AES-Schlüssel + leeres msds-SET | Altes Passwort | Passwort für das Konto zurücksetzen (zweimal) |
| 205 | Verwendete Standard-Domänen- und unterstützte Verschlüsselungstypen | Registry-Überschreibung vorhanden | Entfernen Sie die Überschreibung, sofern möglich |
| 206/208 | RC4-only-Client + AES-only-msds-SET | Inkompatibilität des Clients | Fügen Sie RC4 zu msds-SET hinzu (Wert 28) |
| 207/209 | Dem Konto fehlt der AES-Schlüssel + AES msds-SET | Passwort wurde nicht zurückgesetzt | Passwort für das Konto zurücksetzen (zweimal) |
Das Fazit für IT-Administratoren
- Überprüfen Sie jetzt, ob noch Konten und Geräte mit RC4 verbunden sind.
- Passen Sie die Dienstkonten vor der vollständigen Durchsetzung oder der Abkündigung von RC4 an AES-fähige Konfigurationen an.
- Altsysteme, die AES nicht unterstützen, sind zu entfernen oder anzupassen.
- Nutzen Sie Ereignisprotokolle proaktiv, um problematische Geräte zu erkennen, bevor sie ausfallen – was nach der Installation der Updates vom Juli 2026 der Fall sein wird.
Benötigen Sie weitere Hilfe?
Die Abkündigung von RC4 ist ein wichtiger Schritt im Kampf gegen Kerberoasting, erfordert jedoch rasches Handeln. Sollten Sie Fragen zu diesen Abfragen haben oder Unterstützung bei der Umstellung Ihrer Anwendungskonten benötigen, stehen wir Ihnen gerne zur Verfügung.
