Kerberoasting erkennen: Event 4769, RC4 und das Muster im Kerberos-Log

Kerberoasting erkennen ist für die meisten Blue Teams die erste Erkennung, die sie gezielt bauen, und das aus gutem Grund: Die Technik braucht keine Schwachstelle, keine Schadsoftware und keine erhöhten Rechte, nur ein beliebiges Domänenkonto, und sie führt bei schwachen Dienstkonten-Passwörtern innerhalb von Stunden zu Administratorrechten. Dieser Beitrag ist der erste der Serie „Angriff erkennen“ und folgt dem festen Aufbau: was der Angreifer tut, welche Logquellen es zeigen, die konkreten Ereignisse, eine Sigma-Regel, der Test und die Fehlalarme.

Was der Angreifer tut

Kerberos erlaubt jedem authentifizierten Benutzer, ein Diensticket für jeden Dienst mit registriertem Service Principal Name anzufordern; das ist keine Lücke, sondern das Protokolldesign. Das Ticket ist mit dem Passwort-Hash des Dienstkontos verschlüsselt. Wie der Ticket-Fluss aus TGT und TGS funktioniert, steht unter Kerberos verstehen. Wer das Ticket hat, kann es offline mit Wörterbuch und Regeln angreifen, ohne dass der Domain Controller davon etwas mitbekommt, und bei RC4-Verschlüsselung geht das um Größenordnungen schneller als bei AES. Der Ablauf in drei Schritten: Der Angreifer fragt per LDAP alle Konten mit einem servicePrincipalName ab, fordert für jedes ein Diensticket an und knackt die Tickets offline mit Hashcat. Werkzeuge wie Rubeus oder das GetUserSPNs-Skript aus Impacket erledigen die ersten beiden Schritte in Sekunden. In MITRE ATT&CK ist die Technik als T1558.003 unter Credential Access geführt; die Detection Strategy dazu nennt genau die Ereignisse, um die es im nächsten Abschnitt geht.

Welche Logquellen die Technik zeigen

Voraussetzung für 4769 ist die Überwachungsrichtlinie „Kerberos-Dienstticketvorgänge überwachen“ auf den Domain Controllern; sie gehört zu Microsofts Empfehlungen und ist in der Referenz zu den Event-IDs beschrieben. Auf einem Domain Controller mit vielen Benutzern erzeugt 4769 tausende Ereignisse pro Stunde, fast alle legitim; die Erkennung lebt von der Filterung auf den Verschlüsselungstyp und der Zählung pro Konto.

Das Muster im Log

Drei Merkmale unterscheiden Kerberoasting von normalem Kerberos-Verkehr. Erstens der Verschlüsselungstyp: Angreifer fordern gezielt RC4 an, weil es schneller zu knacken ist, und in 4769 steht dann 0x17 statt 0x12 für AES-256. Zweitens die Streuung: Ein normaler Benutzer fordert Tickets für die Dienste an, die er benutzt, also einige wenige; ein Angreifer fordert Tickets für alle Dienstkonten an, oft zehn, zwanzig oder mehr innerhalb von Sekunden. Drittens das Ziel: Angreifer interessieren sich für Benutzerkonten mit SPN, nicht für Computerkonten, deren Passwörter zufällig und lang sind; Dienstnamen, die auf ein Dollarzeichen enden, und krbtgt fallen deshalb aus der Betrachtung. Wer nach 4769 mit 0x17 filtert, Computerkonten ausnimmt und pro anforderndem Konto in einem Zeitfenster von fünf Minuten die verschiedenen Dienstnamen zählt, sieht Kerberoasting als Zeile mit einer Zahl, die sonst nie vorkommt.

Die Sigma-Regel

Die Basisregel filtert die Ereignisse, die Korrelationsregel zählt; beide in einer Datei nach der Sigma-Spezifikation, wie im Beitrag zu Sigma-Regeln beschrieben:

title: Kerberos TGS Request With RC4 For User Account
name: tgs_rc4_user
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'
    Status: '0x0'
  filter_computer_accounts:
    ServiceName|endswith: '$'
  filter_krbtgt:
    ServiceName: 'krbtgt'
  condition: selection and not 1 of filter_*
---
title: Possible Kerberoasting - Many Service Tickets With RC4
id: 7d3e1a9b-2c4f-4b8d-a6e5-9f0c1d2e3a4b
status: test
description: Ein Konto fordert in kurzer Zeit RC4-Diensttickets fuer
  mehrere verschiedene Dienstkonten an.
references:
  - https://attack.mitre.org/techniques/T1558/003/
author: Blue Team
date: 2026-09-13
tags:
  - attack.credential_access
  - attack.t1558.003
correlation:
  type: value_count
  rules:
    - tgs_rc4_user
  group-by:
    - TargetUserName
    - IpAddress
  timespan: 5m
  condition:
    field: ServiceName
    gte: 5
falsepositives:
  - Anwendungen und Dienstkonten, die auf RC4 angewiesen sind
  - Schwachstellenscanner mit Kerberos-Pruefungen
level: high

Die Schwelle von fünf verschiedenen Diensten in fünf Minuten ist ein Startwert; in einer Umgebung mit wenigen Dienstkonten kann sie auf drei sinken, in einer mit hunderten auf zehn steigen. Wichtiger als die Zahl ist der Status 0x0: Nur erfolgreiche Anforderungen zählen, fehlgeschlagene sind ein anderes Muster. Für Umgebungen, deren SIEM keine Korrelationsregeln übersetzt, wird die Basisregel als Suche gespeichert und die Zählung in der Regel-Engine des SIEM abgebildet. Zusätzlich lohnt eine zweite, einfachere Regel ohne Zählung: jedes 4769 mit 0x17 für ein Dienstkonto, das auf der Liste der Konten mit erzwungenem AES steht, ist für sich allein verdächtig.

Der Test

Atomic Red Team führt für T1558.003 mehrere Tests, darunter die Anforderung von Diensttickets per PowerShell und per Rubeus. Im Homelab mit dem absichtlich angelegten Dienstkonto aus dem Bauplan reicht ein Aufruf als normaler Benutzer auf dem Client, und innerhalb einer Minute muss auf dem Domain Controller 4769 mit 0x17 für das Dienstkonto stehen, im kerberos.log des Sensors dieselbe Anforderung mit dem Cipher rc4-hmac, und im SIEM der Alarm der Korrelationsregel, sobald die Schwelle erreicht ist. Wer den Test mit nur einem Dienstkonto fährt, sieht die Basisregel treffen, aber nicht die Korrelation; für den vollständigen Test legt man vorher fünf Dienstkonten mit SPN an. Der Test wird mit Datum und Ergebnis im Navigator eingetragen, und die Regel gilt erst danach als vorhanden.

Fehlalarme und Tuning

• Alte Anwendungen mit RC4. Dienste, die AES nicht unterstützen, erzeugen dauerhaft 4769 mit 0x17, aber für denselben Dienst und von denselben Clients. Sie erreichen die Schwelle der verschiedenen Dienste nicht; wenn doch, kommen sie mit Begründung auf die Ausnahmeliste, und die Umstellung auf AES wird zur Maßnahme.
• Schwachstellenscanner. Scanner mit Kerberos-Prüfungen sehen exakt wie Kerberoasting aus. Ihre Quelladressen und Konten werden ausgenommen, und der Scan-Zeitplan steht im Ticket des Tuning-Eintrags.
• Monitoring und Inventarwerkzeuge. Systeme, die Dienste über viele Server abfragen, fordern viele Tickets an, aber mit AES. Wer sie in der Regel sieht, hat ein Konto, dem RC4 erlaubt ist, und sollte das ändern statt die Regel.
• Die Gegenmaßnahme, die die Regel entlastet. Dienstkonten mit langen, zufälligen Passwörtern, am besten als gruppenverwaltete Dienstkonten, und die Kontooption, nur AES zu unterstützen. Danach ist jedes verbleibende 4769 mit 0x17 für ein Benutzerkonto ein Treffer, und die Technik wird für den Angreifer wertlos, weil es nichts mehr zu knacken gibt.

Fazit

Kerberoasting ist die Technik, an der sich zeigt, ob ein SIEM die Domain Controller wirklich sieht: ein Ereignis, ein Feld, eine Zählung, und der Angreifer, der mit einem gestohlenen Benutzerkonto still nach Administratorrechten sucht, wird zur Zeile mit einer Zahl, die sonst nie vorkommt. Wer die Regel baut, sie mit fünf Dienstkonten im Lab testet und nebenbei die Dienstkonten auf AES und lange Passwörter umstellt, hat eine der häufigsten Techniken auf dem Weg zum Domain-Admin abgedeckt und die Technik zugleich entwertet. Das Blue Team, das hier anfängt, fängt an der richtigen Stelle an.