Kerberoasting und AD-Credential-Angriffe: Erkennung und Abwehr

Kerberoasting ist eine der häufigsten Techniken, die Verteidiger gegen Active Directory (AD) beobachten, und wird von den verantwortlichen Teams dennoch oft missverstanden. Dieser Artikel nimmt konsequent eine defensive Perspektive ein: Wir erklären, was die Technik ist, wie das zugrunde liegende Kerberos-Protokoll funktioniert, warum bestimmte Konten angreifbar werden und — vor allem — wie Blue Teams sie erkennen, mindern und dagegen härten. Das Ziel ist Verstehen, um zu verteidigen. Sie finden hier keine operativen Angriffsanleitungen, sondern die Telemetrie, Kontrollen und Checklisten, die ein Detection Engineer oder AD-Administrator braucht, um die Kosten des Angriffs zu erhöhen und das Zeitfenster zu verkleinern, in dem er gelingen kann.

Was Kerberoasting ist

Kerberoasting ist eine Technik zum Zugriff auf Anmeldedaten, die eine legitime Kerberos-Funktion missbraucht: Jeder authentifizierte Domänenbenutzer kann ein Serviceticket für ein Dienstkonto anfordern, das einen Service Principal Name (SPN) registriert hat. Ein Teil dieses Tickets ist mit einem Schlüssel verschlüsselt, der aus dem Passwort des Dienstkontos abgeleitet wird. Da die Anfrage selbst normales Protokollverhalten ist, erzeugt sie wenig Lärm, und weil das anschließende Knacken des Passworts offline erfolgt, sieht der Domänencontroller (DC) die Rateversuche nie. Das Risiko konzentriert sich daher auf schwache Dienstkonto-Passwörter und veraltete Verschlüsselung. Aus Sicht eines Verteidigers versteht man die Technik am besten als Missverhältnis zwischen einer alten Komfortfunktion und moderner Passwort-Knack-Hardware. Sie ist in MITRE ATT&CK als T1558.003 klassifiziert und gehört zur Taktik Credential Access.

Wie die Kerberos-Authentifizierung funktioniert

Um die Technik abzuwehren, brauchen Sie ein funktionierendes mentales Modell von Kerberos. Bei der Anmeldung erhält ein Benutzer ein Ticket-Granting Ticket (TGT) vom Key Distribution Center (KDC), das auf dem Domänencontroller läuft. Möchte dieser Benutzer später auf einen Dienst zugreifen — einen SQL Server, einen Web-Anwendungspool, eine Dateifreigabe — legt er das TGT vor und fordert ein Ticket-Granting-Service-Ticket (TGS) für den spezifischen SPN an. Das KDC gibt ein TGS zurück, dessen Dienstteil mit dem Langzeitschlüssel des Kontos verschlüsselt ist, dem der SPN gehört. Legitim leitet der Client das Ticket an den Zieldienst weiter, der es zur Prüfung entschlüsselt. Die Designannahme lautet, dass nur der Dienst (der sein eigenes Passwort kennt) den verschlüsselten Teil lesen kann. Diese Annahme bricht, wenn das Kontopasswort schwach genug ist, um offline wiederhergestellt zu werden, denn jeder, der das Ticket erhält, kann versuchen, den Schlüssel abzuleiten. Dieser Ablauf sagt Ihnen genau, wo Sie Ihre Telemetrie platzieren: am KDC, bei Ticket-Anfrage-Ereignissen.

Wie der Angriff auf hoher Ebene abläuft

Auf hoher Ebene hat die Technik drei konzeptionelle Phasen, die ein Verteidiger erkennen sollte. Erstens die Enumeration: das Identifizieren, welche Konten SPNs registriert haben, da nur diese angreifbar sind. Zweitens die Ticketanforderung: das Beschaffen von TGS-Tickets für diese SPNs über gewöhnliche, authentifizierte Protokollaufrufe, die wie normaler Dienstzugriff aussehen. Drittens die Offline-Wiederherstellung: den verschlüsselten Teil vollständig vom Netzwerk zu entfernen und das Passwort auf eigener Hardware zu rekonstruieren, ohne weiteren Kontakt zu Ihrer Domäne. Die entscheidende Erkenntnis für das Blue Team ist, dass nur die ersten beiden Phasen für Sie sichtbar sind — die dritte geschieht außerhalb des Netzwerks. Deshalb zählt Prävention (starke Passwörter, moderne Verschlüsselung, verwaltete Konten) ebenso wie Erkennung: Hat ein Ticket mit schwachem Passwort die Umgebung verlassen, kann kein Alarm es zurückholen.

Angriffsfläche und Exposition

Die exponierte Fläche ist die Menge der Konten mit SPNs. In den meisten Umgebungen umfasst das Dienstkonten für Datenbanken (MSSQLSvc), Webserver, individuelle Geschäftsanwendungen und diverse Herstellerprodukte, die historisch einen Domänenbenutzer zum Ausführen benötigten. Zwei Kategorien verdienen besondere Prüfung. Die erste sind privilegierte Dienstkonten — jedes SPN-tragende Konto, das zugleich Mitglied von Domänen-Admins, Enterprise-Admins oder anderen hochprivilegierten Gruppen ist. Sie sind die wertvollsten Expositionen, weil die Wiederherstellung ihres Passworts sofortiges Privileg bringt. Die zweite sind veraltete Konten: vor Jahren mit einem menschlich gewählten Passwort erstellte Dienstkonten, das nie rotiert wurde. Diese Fläche zu inventarisieren ist ein Verteidigungsprojekt für sich. Sie sollten jederzeit beantworten können, wie viele SPN-Konten existieren, welche privilegiert sind, welche veraltete Verschlüsselung nutzen und wann jedes Passwort zuletzt geändert wurde. Können Sie das nicht, ist diese Lücke Ihr erster Befund.

Erkennung: Logs, Event-IDs und Telemetrie

Die Erkennung konzentriert sich auf Kerberos-Serviceticket-Ereignisse auf den Domänencontrollern. Das Schlüsselsignal ist Event ID 4769 ("Ein Kerberos-Serviceticket wurde angefordert"). Für sich genommen ist dieses Ereignis extrem häufig und harmlos, daher ist naives Alarmieren nutzlos; die Kunst liegt in der Anreicherung. Priorisieren Sie 4769-Ereignisse, bei denen der Ticket Encryption Type 0x17 (RC4-HMAC) statt 0x12 (AES256) ist, denn ein Downgrade auf RC4 bei einem Konto, das AES unterstützen sollte, ist ein starker Indikator. Korrelieren Sie über Volumen und Vielfalt: Ein einzelner Principal, der in kurzer Zeit Tickets für ungewöhnlich viele verschiedene SPNs anfordert, ist weit verdächtiger als die reine Ereigniszahl. Beobachten Sie Event ID 4768 (TGT angefordert) für den initialen Authentifizierungskontext und paaren Sie 4769 mit anforderndem Konto, Quellhost und Tageszeit-Baseline. Moderne EDR- und Identity-Threat-Detection-Plattformen (etwa Microsoft Defender for Identity) liefern eigene Kerberoasting-Analysen; betreiben Sie eine, stimmen Sie deren Alarme ab und validieren Sie sie. Erwägen Sie schließlich ein Honeypot-Dienstkonto: einen SPN-Köder mit langem Zufallspasswort ohne legitime Nutzung, sodass jede 4769-Anfrage dafür einen hochwertigen Alarm auslöst.

Minderung und Härtung

Bei der Prävention gewinnen Sie. Die wirksamste Kontrolle ist, menschlich gewählte Dienstkonto-Passwörter zu eliminieren: Migrieren Sie zu Group Managed Service Accounts (gMSA) oder delegierten Managed Service Accounts, deren Passwörter über 120 Zeichen lange Zufallswerte sind, die AD automatisch rotiert und die kein Mensch kennt. Ein gMSA-Passwort ist offline praktisch nicht wiederherstellbar, wodurch das Konto vollständig aus dem Risiko fällt. Wo ein gMSA noch nicht möglich ist, erzwingen Sie lange, zufällige Passwörter (25+ Zeichen) für jedes SPN-Konto, da die Passwortlänge der direkte Hebel gegen Offline-Cracking ist. Deaktivieren Sie RC4 und verlangen Sie AES-Verschlüsselung für Kerberos, sowohl auf Domänenrichtlinien-Ebene als auch pro Konto-Attribut (msDS-SupportedEncryptionTypes), nachdem Sie zuvor auf Altlast-Abhängigkeiten getestet haben. Wenden Sie Tiering an: Kein Dienstkonto sollte zugleich SPN-tragend und Mitglied einer hochprivilegierten Gruppe sein — trennen Sie die Rollen. Erzwingen Sie einen Rotationsplan für verbleibende manuelle Konten und entfernen Sie SPNs von Konten, die sie nicht mehr brauchen.

Verwandte AD-Credential-Angriffe

Kerberoasting steht selten allein; es gehört zu einer Familie von AD-Credential-Techniken, die ein Verteidiger gemeinsam behandeln sollte. AS-REP Roasting (T1558.004) zielt auf Konten mit deaktivierter Kerberos-Vorauthentifizierung und liefert knackbares Material, ohne dass ein gültiges Domänenkonto nötig ist — prüfen Sie also das Flag DONT_REQ_PREAUTH und entfernen Sie es überall dort, wo es nicht zwingend erforderlich ist. Pass-the-Ticket und Pass-the-Hash verwenden gestohlene Authentifikatoren wieder, statt sie zu knacken, weshalb Credential-Hygiene-Kontrollen wie Credential Guard, LSASS-Schutz und die Einschränkung, wo privilegierte Konten sich anmelden, wichtig sind. Golden- und Silver-Ticket-Fälschungen missbrauchen die KRBTGT- bzw. Dienstkonto-Schlüssel, was ein weiterer Grund ist, KRBTGT regelmäßig zu rotieren und Dienstkonto-Geheimnisse zu schützen. Diese als zusammenhängende Fläche zu sehen hilft, jene Kontrollen zu priorisieren — starke Geheimnisse, moderne Verschlüsselung, Tiering und Privileged-Access-Management — die mehrere zugleich reduzieren.

Häufige Fallstricke

Mehrere wiederkehrende Fehler untergraben ansonsten gute Programme. Der erste ist das Alarmieren auf rohes 4769-Volumen: Ohne Anreicherung um Verschlüsselungstyp und Vielfalt begräbt der Lärm das Signal und die Regel wird binnen einer Woche deaktiviert. Der zweite ist die Annahme, AES sei erzwungen, während eine einzige Altanwendung stillschweigend RC4 für das ganze Konto erzwingt — prüfen Sie den ausgehandelten Verschlüsselungstyp stets in echten Ereignissen, nicht nur in der Richtlinie. Der dritte ist das belassene privilegierte Dienstkonto, weil "die App es braucht" — genau diese Exposition macht aus einem geringfügigen Befund einen Pfad zur Domänenkompromittierung. Der vierte ist, eine gMSA-Migration als abgeschlossen zu betrachten, während einige hartnäckige Altdienste noch unter manuellen Konten laufen; dort konzentriert sich das Risiko. Der fünfte ist das Deaktivieren der Vorauthentifizierung zur Fehlersuche und das Vergessen, sie wieder zu aktivieren, was AS-REP Roasting öffnet. Führen Sie jeden Punkt als stehende Hygieneaufgabe.

Checkliste für Verteidiger

Nutzen Sie diese Checkliste als wiederkehrende Überprüfung. Inventar: Pflegen Sie eine Live-Liste aller SPN-Konten und kennzeichnen Sie privilegierte und Altverschlüsselungs-Konten. Verschlüsselung: Verlangen Sie AES und deaktivieren Sie RC4, wo Abhängigkeiten es erlauben, geprüft an echten 4769-Ereignissen. Verwaltete Konten: Migrieren Sie Dienstkonten zu gMSA/dMSA; setzen Sie ein Zieldatum zum Ausmustern verbleibender manueller Konten. Passwörter: Erzwingen Sie für jedes manuelle Konto 25+ Zeichen lange Zufallsgeheimnisse und einen Rotationsplan. Tiering: Stellen Sie sicher, dass kein SPN-Konto hochprivilegierte Gruppenmitgliedschaft hält. Erkennung: Betreiben Sie angereicherte 4769-Analysen (Verschlüsselungstyp + SPN-Vielfalt + Baseline) und validieren Sie sie in einem kontrollierten Test. Honeypot: Richten Sie ein Köder-SPN-Konto mit hochwertigem Alarm ein. Angrenzende Flags: Prüfen und entfernen Sie unnötiges DONT_REQ_PREAUTH und bestätigen Sie geplante KRBTGT-Rotation. Reaktion: Dokumentieren Sie das Playbook für eine bestätigte Erkennung — Geheimnis rotieren, nach Weiterverwendung jagen, privilegierte Exposition prüfen.

Häufig gestellte Fragen

Lässt sich Kerberoasting vollständig verhindern oder nur erkennen? Es lässt sich als praktische Bedrohung wirksam verhindern. Die Migration von SPN-Konten zu gMSA/dMSA oder das Erzwingen sehr langer Zufallspasswörter mit reiner AES-Verschlüsselung macht die Offline-Wiederherstellung praktisch unmöglich. Erkennung bleibt als Verteidigung in der Tiefe und zum Aufspüren fehlkonfigurierter Ausnahmen wertvoll, doch starke Geheimnisse beseitigen das eigentliche Risiko.

Warum ist Event ID 4769 so laut, und wie mache ich es nützlich? Jeder normale Dienstzugriff erzeugt ein 4769, daher sind rohe Zahlen bedeutungslos. Nützlich wird es durch Anreicherung: Filtern Sie RC4-Anfragen (0x17) auf AES-fähigen Konten, korrelieren Sie einen einzelnen Anforderer, der schnell viele verschiedene SPNs trifft, bilden Sie eine Baseline pro Konto und reservieren Sie hochwertige Alarme für Honeypot-SPNs, die kein legitimer Prozess je anfordern sollte.

Fazit

Kerberoasting hält sich nicht, weil es raffiniert ist, sondern weil so viele Umgebungen weiterhin schwache Dienstkonto-Passwörter und veraltete RC4-Verschlüsselung tragen. Für Verteidiger ist der Weg klar und dauerhaft: Inventarisieren Sie Ihre SPN-Konten, überführen Sie sie in verwaltete Konten, erzwingen Sie AES, trennen Sie Privileg von Dienstidentität und bauen Sie angereicherte Erkennung auf Kerberos-Ticket-Ereignissen mit einem Honeypot als Stolperdraht. Behandeln Sie es zusammen mit seinen Verwandten — AS-REP Roasting, Ticketfälschung und Credential-Wiederverwendung — als eine zusammenhängende Identitätssicherheitsfläche. Tun Sie das, und Sie verwandeln einen verlässlichen Angreiferliebling in eine Technik, die laut ist, wenn versucht, und wertlos, wenn erfolgreich. Verstehen Sie es, und Sie können sich verteidigen.