Kerberoasting erkennen und verhindern: Servicekonten in Active Directory absichern

Ein Administrator prüft morgens die SIEM-Meldungen und entdeckt innerhalb weniger Minuten zahlreiche Kerberos-Service-Tickets für Datenbank-, Backup- und Webservicekonten. Die Anfragen stammen von einem gewöhnlichen Domänenkonto, das eigentlich keinen administrativen Auftrag hat. Genau dieses Muster kann auf Kerberoasting hindeuten: Angreifer fordern Tickets für Service Principal Names, kurz SPNs, an und versuchen anschließend, die darin enthaltenen verschlüsselten Daten offline gegen Kennwortlisten und leistungsfähige Hardware zu prüfen.

Kerberoasting ist kein Angriff, der eine spektakuläre Sicherheitslücke im Active Directory ausnutzt. Er missbraucht reguläre Kerberos-Funktionen und trifft deshalb besonders häufig Umgebungen, in denen alte Servicekonten, schwache Kennwörter oder zu weitreichende Berechtigungen bestehen. In hybriden Windows-Umgebungen kommen zusätzliche Risiken hinzu, etwa wenn lokale Dienste, Azure-Workloads und automatisierte Prozesse auf dieselben schlecht gepflegten Domänenkonten zugreifen.

Entscheidend ist daher nicht nur, Kerberoasting im SIEM zu erkennen. Du musst zuerst verstehen, welche Servicekonten überhaupt angreifbar sind, welchen geschäftlichen Zweck sie erfüllen und welche Rechte sie besitzen.

Infografik zu Kerberoasting erkennen und verhindern: Servicekonten in Active Directory absichern (KI-generiert).

Was bei Kerberoasting technisch passiert

Kerberos verwendet Tickets, damit sich Benutzer und Dienste in einer Active-Directory-Domäne gegenseitig authentifizieren können. Benötigt ein Benutzer Zugriff auf einen Dienst, etwa eine SQL-Instanz oder einen Webserver, fordert sein Client beim Domain Controller ein Service-Ticket an. Dieses Ticket wird mit dem Geheimnis des Dienstkontos geschützt, dem der SPN zugeordnet ist.

Ein Angreifer mit einem normalen Domänenkonto kann grundsätzlich ebenfalls Service-Tickets für viele SPNs anfordern. Anschließend extrahiert er den relevanten Ticketanteil und versucht offline, das Kennwort des zugehörigen Servicekontos zu ermitteln. Dafür muss er nicht fortlaufend mit dem Domain Controller kommunizieren. Genau das macht die Methode gefährlich: Nach der Ticket-Anfrage verlagert sich der eigentliche Kennwortangriff außerhalb deiner Infrastruktur.

Besonders riskant sind Servicekonten mit diesen Eigenschaften:

• Das Konto besitzt einen oder mehrere SPNs.
• Das Kennwort ist kurz, wiederverwendet oder seit Jahren unverändert.
• Das Konto verwendet ältere oder weniger robuste Verschlüsselungsverfahren.
• Das Konto ist Mitglied privilegierter Gruppen.
• Das Konto darf sich interaktiv anmelden oder auf vielen Servern Dienste ausführen.
• Das Konto wird für mehrere fachlich unabhängige Anwendungen verwendet.

Auch mit moderneren Verschlüsselungsverfahren bleibt ein schwaches Servicekonto ein Risiko. Der wichtigste Schutz ist deshalb ein langes, zufälliges und automatisiert verwaltetes Kennwort sowie die konsequente Begrenzung der Kontorechte.

Riskante SPNs und Servicekonten systematisch finden

Beginne nicht mit einzelnen Verdachtsfällen, sondern mit einer belastbaren Inventarisierung. Viele Unternehmen wissen zwar, dass sie Servicekonten haben, kennen aber weder alle SPNs noch die tatsächlichen Abhängigkeiten. Gerade nach Migrationen, Fusionen oder der Ablösung alter Anwendungen bleiben oft Konten zurück, die weiter berechtigt und technisch erreichbar sind.

Prüfe für jedes Konto mit SPN mindestens die folgenden Punkte:

Prüffrage	Warum sie wichtig ist
Welcher Dienst benötigt den SPN?	Verwaiste SPNs schaffen unnötige Angriffsfläche.
Wer ist fachlich und technisch verantwortlich?	Ohne Verantwortliche bleiben Kennwortwechsel und Berechtigungsprüfungen liegen.
Läuft der Dienst noch?	Nicht mehr benötigte Konten und SPNs solltest du entfernen oder deaktivieren.
Welche Gruppenmitgliedschaften bestehen?	Privilegierte Rollen machen ein kompromittiertes Konto besonders wertvoll.
Wo darf sich das Konto anmelden?	Interaktive Anmeldung und breite Serverrechte erhöhen die Folgen eines Kennwortdiebstahls.
Welches Verschlüsselungsverfahren wird verwendet?	Ältere Einstellungen können die Offline-Angriffe erleichtern.
Wann wurde das Kennwort zuletzt geändert?	Lange unveränderte Kennwörter sind ein deutliches Warnsignal.

Achte besonders auf Konten, deren Namen nach administrativen Diensten, Datenbanken, Backup-Lösungen, Deployment-Werkzeugen oder Middleware aussehen. Ein Konto für einen SQL-Dienst kann beispielsweise hochkritisch sein, wenn es zusätzlich lokale Administratorrechte auf mehreren Servern besitzt oder in einer privilegierten AD-Gruppe Mitglied ist.

SPNs sollten eindeutig sein. Doppelte oder falsch zugeordnete SPNs verursachen nicht nur Authentifizierungsprobleme, sondern erschweren auch die Analyse im Incident-Fall. Dokumentiere daher pro SPN den Dienstnamen, Server, Port, das zugehörige Konto, den Eigentümer und die erforderlichen Berechtigungen.

Die technische Bestandsaufnahme ist auch ein sinnvoller Anlass, Berechtigungen zu hinterfragen. Wie du Schwachstellen nach Ausnutzbarkeit und Auswirkung einordnest, erläutern wir in Schwachstellen bewerten und priorisieren. Für Kerberoasting gilt dabei: Ein altes Konto mit starkem Kennwort ist nicht automatisch harmlos, wenn es weitreichende Zugriffsrechte besitzt.

gMSA als Standard für geeignete Dienste einsetzen

Group Managed Service Accounts, kurz gMSA, sind für viele Windows-basierte Dienste die beste Alternative zu klassischen Benutzerkonten als Servicekonto. Das Active Directory verwaltet bei gMSA das Kennwort automatisch. Der Dienst oder Server erhält das aktuelle Kennwort kontrolliert über die Domäne, ohne dass Administratoren es manuell vergeben, in Skripten hinterlegen oder zwischen Teams weiterreichen müssen.

gMSA reduzieren damit einen der Hauptgründe für Kerberoasting-Erfolge: langlebige, menschlich gewählte und selten geänderte Kennwörter. Sie sind besonders sinnvoll für Dienste, die auf mehreren autorisierten Servern laufen, etwa hochverfügbare Anwendungen oder geplante Aufgaben in einer Servergruppe.

Vor der Umstellung solltest du diese Punkte prüfen:

• Unterstützt die Anwendung gMSA und die eingesetzte Windows-Version?
• Welche Hosts dürfen das gMSA verwenden?
• Sind SPNs korrekt dem gMSA zugeordnet?
• Sind Dateifreigaben, Datenbanken, Zertifikate und externe Systeme auf die neue Identität vorbereitet?
• Gibt es geplante Aufgaben, Skripte oder Monitoring-Systeme, die noch fest mit dem alten Konto arbeiten?
• Wurde ein Rückfallplan getestet, falls der Dienst nach der Umstellung nicht startet?

Nicht jede Altanwendung kann sofort mit gMSA arbeiten. Für solche Fälle brauchst du ein reguläres Servicekonto mit einem langen, zufällig erzeugten Kennwort, das ausschließlich für diesen Dienst verwendet wird. Lege das Kennwort nicht in Dokumentationen, Skripten, Konfigurationsdateien oder Passworttresoren mit zu breitem Zugriff ab. Plane einen kontrollierten Wechselprozess und teste ihn, bevor das Kennwort produktiv geändert wird.

Wichtig: gMSA ersetzen nicht das Least-Privilege-Prinzip. Ein automatisch verwaltetes Konto mit weitreichenden Domain- oder Serverrechten bleibt ein hohes Risiko. Entferne daher unnötige Gruppenmitgliedschaften, begrenze lokale Anmelderechte und trenne Dienste mit unterschiedlichen Schutzbedarfen auf separate Identitäten.

Verdächtige Ticket-Anfragen in Logs erkennen

Der zentrale Windows-Sicherheitsindikator für Kerberoasting ist häufig das Ereignis 4769 auf Domain Controllern. Es dokumentiert eine Anfrage für ein Kerberos-Service-Ticket. Einzelne Ereignisse sind vollkommen normal, denn Kerberos ist Grundlage vieler regulärer Zugriffe. Aussagekräftig wird die Erkennung erst durch Kontext und Korrelation.

Ein verdächtiges Muster kann vorliegen, wenn ein Benutzerkonto in kurzer Zeit Tickets für viele unterschiedliche SPNs anfordert, insbesondere für Dienste, die es im normalen Arbeitsablauf nicht benötigt. Auch Ticket-Anfragen außerhalb üblicher Zeiten oder von ungewöhnlichen Quellgeräten verdienen eine Prüfung.

Achte in deinem SIEM insbesondere auf:

• Eine hohe Anzahl unterschiedlicher Service Names von einem Benutzer oder Client in kurzer Zeit.
• Anfragen für privilegierte oder besonders sensible Servicekonten.
• Ticket-Anfragen von Konten, die sonst kaum Kerberos-Aktivität zeigen.
• Auffällige Ticket Encryption Types, insbesondere wenn ältere Verschlüsselung wie RC4 in deiner Umgebung nicht mehr erwartet wird.
• Ungewöhnliche Kombinationen aus Quellhost, Benutzerkonto und angefragtem Dienst.
• Neue SPNs oder Änderungen an bestehenden SPN-Zuordnungen.
• Parallel auftretende Hinweise auf Kontoübernahme, etwa neue Anmeldeorte, fehlgeschlagene Anmeldungen oder Änderungen von Gruppenmitgliedschaften.

Ein SIEM-Use-Case sollte deshalb nicht schlicht „mehr als zehn Ereignisse 4769“ melden. Das erzeugt schnell Fehlalarme. Besser ist eine Baseline je Kontoart: Welche Service-Tickets fordert ein Arbeitsplatzkonto gewöhnlich an? Welche Tickets sind für Administratoren, Serverkonten oder Automatisierungskonten erwartbar? Ergänze die Erkennung um Ausnahmen für bekannte Batch-Prozesse, überprüfe diese Ausnahmen aber regelmäßig.

Für belastbare Analysen brauchst du außerdem passende Audit-Richtlinien, zentralisierte Logs und ausreichend Aufbewahrungszeit. Grundlagen zu sinnvollen Logquellen, Korrelation und Alarmierung findest du in unserem Beitrag Angriffe früh erkennen: Logging und Monitoring.

So reagierst du auf einen Kerberoasting-Verdacht

Wenn dein SIEM auffällige Ticket-Anfragen meldet, behandle den Fall nicht automatisch als bestätigten Angriff. Kläre zuerst, ob ein neuer Rollout, ein Inventarisierungstool, ein Backup-Lauf oder eine administrative Tätigkeit das Verhalten erklärt. Dokumentiere diese Prüfung nachvollziehbar.

Bleibt der Verdacht bestehen, solltest du zügig handeln:

• Sichere die relevanten Domain-Controller-, Endpoint- und SIEM-Logs.
• Ermittle Benutzerkonto, Quellgerät, angefragte SPNs, Zielkonten und Zeitraum.
• Prüfe, ob sich das Quellkonto oder Gerät ungewöhnlich verhalten hat.
• Bewerte die Berechtigungen der betroffenen Servicekonten.
• Ändere Kennwörter verdächtiger klassischer Servicekonten kontrolliert und prüfe die Dienstabhängigkeiten.
• Entferne nicht benötigte SPNs sowie überflüssige Gruppenmitgliedschaften.
• Untersuche das Quellgerät auf weitere Hinweise, etwa Credential-Dumping, Remote-Ausführung oder verdächtige Skripte.
• Prüfe, ob das betroffene Konto für andere Systeme wiederverwendet wurde.

Ein Kennwortwechsel allein beendet den Vorfall nicht zwingend. Wurde ein Servicekonto bereits erfolgreich kompromittiert, können Angreifer seine Berechtigungen genutzt, Persistenz eingerichtet oder weitere Konten missbraucht haben. Die strukturierte Vorgehensweise für Analyse, Eindämmung und Wiederherstellung beschreiben wir in Incident Response: was tun im Ernstfall.

Kerberoasting dauerhaft erschweren

Eine wirksame Absicherung entsteht aus Identitätsmanagement, Härtung und Überwachung. Prüfe SPNs und Servicekonten mindestens in festen Intervallen sowie nach größeren Infrastrukturänderungen. Integriere die Prüfung in Change-Prozesse, damit neue Anwendungen nicht wieder mit dauerhaftem Standardkennwort und übermäßigen Rechten produktiv gehen.

Nutze Penetrationstests, um nicht nur technische Fehlkonfigurationen, sondern auch realistische Angriffspfade zu prüfen. Ein professioneller Test zeigt beispielsweise, ob ein niedrig privilegiertes Konto Tickets für kritische Dienste abrufen kann und welche Folgen ein erfolgreich kompromittiertes Servicekonto hätte. Wie ein solcher Test strukturiert abläuft, erklären wir in Ein Penetrationstest Schritt für Schritt.

Wichtig ist außerdem die rechtliche und organisatorische Kontrolle: Ticket-Abfragen, Hash-Extraktion und Kennwortprüfungen gehören ausschließlich in klar beauftragte Tests mit definiertem Umfang. Die Grenzen und Voraussetzungen erläutern wir in Die rechtlichen Grenzen: testen nur mit Auftrag.

Passende Seminare und Termine zu Active Directory, Windows-Sicherheit und Penetrationstests findest du bei uns auf cmt.de.