Kerberoasting – Domäne proaktiv auf RC4 durchsuchen

Im dritten Teil dieser Reihe möchte ich die Vorkehrungen treffen, um in weiterer Folge RC4 weitestgehend einzuschränken und somit die Angriffsfläche für Kerberoasting einzugrenzen. Wie bereits im letzten Teil angesprochen, gibt es einige sinnvolle Sicherheitsvorkehrungen, die du als Administrator in deiner Active Directory Domäne treffen solltest:

• Überall dort, wo Service Accounts verwendet werden, sollte auf gMSA umgestellt werden.
• Sollte eine Umstellung auf gMSA nicht möglich sein, sollte das Kennwort des Service Accounts entsprechend stark gewählt werden.
• Service Accounts sowie gMSA sollten nach dem Least-Privilege-Konzept angelegt werden. Es werden nur jene Berechtigungen vergeben, die für die jeweilige Aufgabe absolut notwendig sind. Ein generelles Verteilen von administrativen Berechtigungen mag zwar verlockend sein, bietet aber ein riesiges Einfallstor.

Logging & Auditing

Allgemein

In diesem Post möchte ich auf das Thema Logging und Auditing eingehen. Jeder Zugriff innerhalb der Domäne wird am Domain Controller geloggt. Diese Logs können wir analysieren um somit bereits im Vorfeld herausfinden, welche Accounts sich wie an der Domäne authentifizieren. Diese Vorgehensweise bildet den ersten Schritt in Richtung Absicherung gegen Kerberoasting.

Solltest du mehrere Domain Controller betreiben, kann das Durchsuchen von Logs sehr schnell umständlich werden. Daher empfehle ich grundsätzlich die Verwendung eines SIEM oder zumindest das zentrale Abspeichern der Security Events eines jeden DCs.

Logging aktivieren

In neuen Domänen ist das Kerberos Logging standardmäßig aktiviert. Solltet ihr jedoch die unten genannten Events nicht finden, prüft, ob das „Account Logon“ für Success und Failed Zugriffe auch wirklich aktiviert ist.

Auf einem Domain Controller könnt ihr dafür folgenden Befehl ausführen:

auditpol /get /category:"Account Logon"

Das Logging von Kerberos kannst du auch via GPO aktivieren:

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

Relevante Events

Kerberoasting bezieht sich, wie im ersten Teil bereits angesprochen, auf das Kerberos-Protokoll. Solltest du nicht wissen, wie Kerberos funktioniert, empfehle ich dir unbedingt vorher den ersten Teil zu lesen.

Daher sind für uns natürlich die Kerberos-Authentifizierungslogs ausschlaggebend. Dabei sind folgende Events für uns besonders interessant:

Für Kerberoasting ist vor allem Event 4769 entscheidend – allerdings nicht nur wegen der reinen Anzahl an Anfragen, sondern wegen des Felds „Ticket Encryption Type“. Genau dieses Feld ermöglicht es uns im nächsten Schritt, gezielt nach RC4-verschlüsselten TGS-Anfragen zu suchen. Dabei werden folgende Werte unterstützt:

Eine vollständige Liste aller Encryption Types findest du in den Microsoft Docs.

Ein Hinweis vorab: 4769 wird bei jedem Ressourcenzugriff geloggt. Auf einer produktiven Domäne kommt hier schnell ein enormes Log-Volumen zusammen. Bevor du also blind alle Events auswertest, solltest du gezielt nach Encryption Type filtern bzw. bekannte, unkritische Dienstkonten von vornherein ausschließen.

Deep-Dive Event 4769

Kerberoasting nutzt TGS-Tickets von Service Accounts aus. Sobald der Domain Controller ein TGS-Ticket ausstellt, wird das Event 4769 generiert. Deshalb wollen wir darauf unser Hauptaugenmerk legen. Schauen wir uns daher an, welche Informationen in diesem Event stecken:

Die für uns wichtigsten Werte sind:

ServiceSupportedEncryptionTypes und ClientAdvertizedEncryptionTypes wurden mit dem Januar 2025 CU ab Windows Server 2016 eingeführt. Solltest du diese Information also nicht in deinen Events sehen, ist ein Update deiner Infrastruktur notwendig.

Eine vollständige Auflistung findest du auch wie gewohnt in den Microsoft Docs.

Welcher Encryption Typ gewinnt?

Mit welcher Verschlüsselungsmethode das TGS-Ticket ausgestellt wird, hängt dabei maßgeblich von den zwei Parteien ab:

• Domain Controller (DCSupportedEncryptionTypes)
• Service Account (ServiceSupportedEncryptionTypes)

Bis April 2026 hat Microsoft standardmäßig RC4 als Verschlüsselung verwendet, wenn weder der Service, noch Domain Controller AES enforced haben (siehe Decrypting the Selection of Supported Kerberos Encryption Types). Dieses Verhalten hat sich aber durch den CVE-2026-20833 geändert.

Microsoft schreitet ein: CVE-2026-20833

Microsoft selbst hat mittlerweile erkannt, dass es sich hierbei um ein bekanntes Problem (CVE-2026-20833) handelt und hat eigenständige Vorkehrungen getroffen. Seit dem April 2026 CU wird das oben beschrieben Angriffsmuster auf aktuellen Domain Controllern standardmäßig blockiert. Da dies den Rahmen dieses Artikels wieder einmal sprengen würde, habe ich diesen Part in einen eigenen Post ausgelagert (Coming Soon). Wichtig für uns ist dabei erstmal nur, dass Domain Controller jetzt nur noch Tickets mit AES-Verschlüsselung ausstellen. Eine Ausnahme wird nur gemacht, wenn der Service Account das entsprechende Attribut msDS-SupportedEncryptionTypes gesetzt hat.

Dazu gibt es auch einen interessanten Blogeintrag im Microsoft Security Forum.

Logs analysieren

Um die Logs praktikabel zu analysieren, ist ein zentrales Log-Repository, gerade bei mehreren Domain Controllern, unabdingbar. In meinem Fall greife ich auf ANEXIA Cloudlog zurück. Die Queries sollten aber in anderen Anwendungen relativ ähnlich sein.

Da jeder Kerberos Zugriff Logeinträge generiert, haben wir in größeren Domänen gerne tausende Einträge in wenigen Minuten. Damit wir nur jene Einträge finden, die für uns relevant sind, müssen wir auf Filter zurückgreifen. Schauen wir daher einmal, nach welchen Informationen ich filtern möchte:

• Sobald ein TGS-Ticket ausgestellt wurde (event_id == 4769)
• Alle Tickets, die bereits via AES verschlüsselt wurden, sind für mich nicht relevant (TicketEncryptionType != 0x12)
• Ich möchte nur Einträge, bei denen erfolgreich ein Kerberos Ticket ausgestellt wurde (Status == 0x0)

Somit ergibt das für mich folgende Query:

event_id:4769 AND !event_data.TicketEncryptionType: (0x11 OR 0x12) AND event_data.Status: 0x0

Und schon finde ich ausschließlich jene Services, die ein TGS-Ticket ohne AES-Verschlüsselung ausgestellt bekommen haben:

Der limitierende Faktor ist in diesem Fall der Service Account selbst. Das erkennt man am Attribut ServiceSupportedEncryptionTypes = „0x6 (DES, RC4)“. Das bedeutet, dass das dazugehörige AD-Objekt explizit das Attribut msDS-SupportedEncryptionTypes auf 0x6 gesetzt hat. Eine schnelle Kontrolle im Active Directory selbst bestätigt diesen Verdacht:

Anpassung im AD

Dadurch, dass Microsoft mittlerweile für TGS-Tickets ohnehin AES-Verschlüsselung erfordert (aktueller Patchstand der DCs vorausgesetzt), wird RC4 nur noch für Service Accounts akzeptiert, bei denen explizit der Wert msDS-SupportedEncryptionTypes gesetzt wurde. Wir können also zusätzlich das Active Directory nach AD-Objekten filtern, die dieser Anforderung nicht entsprechen.

Mit folgenden PowerShell Cmdlets findet man alle User/Computer, welche eine statische Verschlüsselungsmethode konfiguriert haben, die nicht zumindest AES128/AES256 enthält:

Get-ADUser -Properties msDS-SupportedEncryptionTypes -Filter * | Where-Object {
    $_.Enabled -and
    $_."msDS-SupportedEncryptionTypes" -ne $null -and
    $_."msDS-SupportedEncryptionTypes" -ne 0 -and
    ($_."msDS-SupportedEncryptionTypes" -band 0x18) -eq 0
}

Get-ADComputer -Properties msDS-SupportedEncryptionTypes -Filter * | Where-Object {
    $_.Enabled -and
    $_."msDS-SupportedEncryptionTypes" -ne $null -and
    $_."msDS-SupportedEncryptionTypes" -ne 0 -and
    ($_."msDS-SupportedEncryptionTypes" -band 0x18) -eq 0
}

Eine Anpassung muss anschließend pro Konto erfolgen – vorausgesetzt, es wurde vorab geprüft, ob AES tatsächlich unterstützt wird.

Fazit

Durch das Update von Microsoft und der Anpassung der Standardverschlüsselung für TGS-Tickets auf AES wird Administratoren einiges an Arbeit abgenommen. Außerdem werden Domänen, die eher stiefmütterlich behandelt werden, direkt von Microsoft größtenteils gegen Kerberoasting geschützt. Wir Administratoren müssen nur noch manuell gesetzte Encryption Types bei Service Accounts hinterfragen und ggf. anpassen.

Ich möchte noch erwähnen, dass hiermit nur TGS-Tickets abgesichert werden. TGTs können weiterhin mit RC4-Verschlüsselung ausgestellt werden – das ist jedoch Thema eines kommenden Posts.