Kerberoasting Erkennung Praevention: Wie sich knackbar erscheinende Dienstkonten finden und schützen lassen

Kerberoasting Erkennung Praevention beginnt mit einer einfachen Tatsache: Jeder authentifizierte Active-Directory-Principal mit einem gültigen TGT kann Service-Tickets für SPNs anfordern, und einige dieser Tickets lassen sich noch immer offline knacken, wenn das Ziel-Dienstkonto schwach genug ist. Die Schwierigkeit liegt nicht darin, den Namen des Angriffs zu kennen. Die Schwierigkeit liegt darin, nachzuweisen, welche SPN-gebundenen Konten in Ihrer Domäne realistisch ausnutzbar bleiben, welche Telemetrie tatsächlich nützlich ist und welche Remediation-Schritte das Risiko messbar senken, ohne die Produktion zu stören.

Was ist Kerberoasting?

Kerberoasting ist der Missbrauch der Kerberos-Ausstellung von Service-Tickets, um Ticketmaterial zu erhalten, das anschließend offline gegen das Geheimnis eines Dienstkontos geknackt werden kann. MITRE führt dieses Verhalten unter T1558.003 Kerberoasting.

In Active Directory verwendet Kerberos Service Principal Names (SPNs), um eine Service-Instanz mit dem Konto zu verknüpfen, das diesen Dienst ausführt. Microsoft dokumentiert SPNs als den Bezeichner, mit dem Kerberos den Ziel-Principal eines Dienstes ermittelt. Wenn ein Client ein Kerberos-Service-Ticket für diesen SPN anfordert, wird das Ticket für das Dienstkonto erzeugt, dem der SPN gehört.

Das bedeutet nicht, dass jedes Konto mit einem SPN gleich gefährlich ist. Die reale Exponierung hängt von vier Punkten ab:

• Ob das Konto auf einem manuell verwalteten Benutzerkennwort basiert oder auf einer besser verwalteten Dienstidentität
• Ob das Geheimnis des Kontos alt, vorhersagbar oder nie rotiert wurde
• Welche Kerberos-Verschlüsselungstypen bei der Ticketausstellung tatsächlich verwendet werden
• Welche Zugriffe das Konto eröffnet, falls seine Anmeldeinformationen am Ende wiederhergestellt werden

Deshalb ist Kerberoasting nicht nur ein Kerberos-Problem. Es ist zugleich ein Problem der Dienstkonto-Hygiene, der Verschlüsselungspolitik und oft auch der Privilegien-Governance.

Warum Kerberoasting in Active Directory weiter relevant ist

Kerberoasting ist weiterhin relevant, weil viele Domänen noch immer einen langen Bestand an Legacy-Dienstkonten mit sich tragen:

• benutzergebundene Dienstkonten, die vor Jahren angelegt wurden;
• Konten mit PasswordNeverExpires;
• Konten, deren Kennwort einmal gesetzt und dann vergessen wurde;
• Konten, die aus Kompatibilitätsgründen noch auf RC4 angewiesen sind;
• Konten, die im Lauf der Zeit lokalen Admin, Backup-, SQL-, Orchestrierungs- oder delegierte Rechte angehäuft haben.

Diese Kombination macht die Technik praktisch nutzbar. Der Kerberos-Anforderungspfad ist legitim. Das Offline-Knacken passiert außerhalb der Domäne. Der Blast Radius hängt davon ab, was das Dienstkonto anschließend tun darf.

Das erklärt auch, warum AD-Passwortsicherheit und veraltete und überprivilegierte Konten in AD hier so wichtig sind. Ein Service-Ticket ist nicht das eigentliche Ziel. Das Ziel ist die Wiederherstellung eines Geheimnisses, das einen größeren Privilegienpfad öffnet.

Voraussetzungen für eine reale Kerberoasting-Exponierung

Ein Kerberoasting-Finding verdient dann hohe Priorität, wenn die meisten der folgenden Punkte zutreffen:

• Das Konto besitzt einen oder mehrere SPNs
• Das Konto basiert auf einem manuell verwalteten Kennwort statt auf einer verwalteten Dienstidentität
• Das Kennwort ist alt, wird selten rotiert oder ist von der Ablaufregel ausgenommen
• RC4 wird noch genutzt oder akzeptiert, obwohl stärkere Verschlüsselungstypen bereits vorhanden sein sollten
• Das Konto besitzt realen Wert für laterale Bewegung oder Privilegieneskalation
• Die Umgebung überprüft weder SPN-Inventar noch Ownership der Dienstkonten regelmäßig

Microsofts Dokumentation zu msDS-SupportedEncryptionTypes ist hier direkt relevant. Der KDC verwendet diese Information bei der Generierung eines Service-Tickets für das Konto. Microsofts aktuelle Kerberos-Guidance weist außerdem darauf hin, dass RC4 unsicher ist, schrittweise entfernt wird und dort auditiert und beseitigt werden sollte, wo stärkere Verschlüsselung verfügbar ist.

Das ist der operative Unterschied zwischen einem reinen Inventarposten und einer echten Kerberoasting-Exponierung. Ein SPN-Konto mit geringem Wert, langem zufälligem Geheimnis und kürzlich rotiertem Kennwort ist nicht dasselbe Problem wie ein benutzergebundenes SQL-Dienstkonto, das noch RC4 verwendet und weitreichende Serverrechte besitzt.

Wie Kerberoasting funktioniert

Microsoft dokumentiert SPNs als den Mechanismus, mit dem Kerberos eine Service-Instanz dem Konto zuordnet, das sich für diesen Dienst anmeldet. In der Praxis bedeutet das, dass ein Domänen-Principal mit gültigem TGT ein TGS für ein Dienstkonto mit SPN anfordern kann.

MITRE beschreibt Kerberoasting als das Erlangen eines TGS-Tickets, das für Brute Force anfällig sein kann. Der für Verteidiger entscheidende Punkt ist, dass das Knacken offline erfolgt. Sobald das Ticketmaterial gesammelt wurde, braucht der Angreifer keine fortlaufende Interaktion mit der Domäne mehr, um Kennwortvermutungen zu testen.

Die wichtigsten defensiven Aussagen sind:

• Der Anforderungspfad selbst ist legitimer Kerberos-Verkehr
• Das Ticket ist an das Geheimnis des Dienstkontos gebunden, nicht an eine interaktive Sitzung auf dem Zielhost
• Die praktische Ausnutzbarkeit hängt von Verschlüsselungstyp und Kennwortstärke ab
• Der geschäftliche Impact hängt von den Rechten des Dienstkontos nach einer Kompromittierung ab

Die richtige Frage lautet also nicht: „Kann Kerberoasting in dieser Domäne vorkommen?“ Die richtige Frage lautet: „Welche SPN-gebundenen Konten bleiben knackbar genug, um relevant zu sein, und was würden sie öffnen, wenn sie wiederhergestellt werden?“

Kerberoasting Erkennung Praevention: Was Verteidiger wirklich prüfen sollten

Kerberoasting-Erkennung muss als Korrelation aufgebaut werden, nicht als Theorie auf Basis eines einzelnen Events.

Mit Event ID 4769 beginnen

Microsoft dokumentiert 4769 als das Event, das entsteht, wenn der KDC ein Kerberos-Service-Ticket ausstellt. Es wird auf Domain Controllern protokolliert. Für die Kerberoasting-Prüfung ist es meist das nützlichste native Event, weil es den TGS-Anforderungspfad direkt abbildet.

Worauf zu achten ist:

• ein Burst von TGS-Anforderungen durch dasselbe Konto oder dieselbe Quelle in kurzer Zeit;
• Anforderungen für viele unterschiedliche SPNs, die nicht zum normalen Verhalten des Anforderers passen;
• TicketEncryptionType = 0x17 nur dann, wenn RC4 in dieser Umgebung nicht mehr nötig sein sollte;
• SPN-Anforderungen von Workstations oder Benutzern, die normalerweise nicht mit diesen Diensten interagieren.

Microsofts aktuelle RC4-Remediation-Guidance empfiehlt ausdrücklich, RC4-Nutzung in den Events 4768 und 4769 zu auditieren, und erklärt, dass RC4 schrittweise entfernt wird. Diese Telemetrie ist deshalb nützlich, aber nur im Kontext. RC4 allein beweist kein Kerberoasting. In manchen Domänen ist es eher ein Kompatibilitätsproblem als ein Hinweis auf feindliche Aktivität.

Event ID 4768 als Korrelationskontext verwenden

4768 dokumentiert die Ausstellung eines TGT, nicht die Service-Ticket-Anforderung, auf der Kerberoasting basiert. Es sollte daher als unterstützender Kontext und nicht als primärer Detektor behandelt werden.

Es hilft dabei, Fragen zu beantworten wie:

• Welches Konto hat das TGT erhalten, das einer ungewöhnlichen TGS-Aktivität vorausging?
• Welche Quellsysteme sind beteiligt?
• Was legen die Felder zu unterstützten Schlüsseln und Fallback-Verhalten nahe, wenn das erweiterte Event-Schema verfügbar ist?

Dieser Kontext ist hilfreich, wenn ein auffälliger 4769-Cluster untersucht wird. Er ersetzt 4769 nicht.

SPN-gebundene Konten kontinuierlich inventarisieren

Die Qualität der Erkennung verbessert sich deutlich, wenn Sie ein laufendes Inventar pflegen von:

• Konten mit SPNs;
• Kennwortalter;
• PasswordNeverExpires;
• der Einordnung als klassisches Benutzerkonto oder verwaltete Dienstidentität;
• effektiven Rechten und lokalem Admin-Reach;
• dem Verschlüsselungszustand, sofern er in Ihrer Umgebung relevant ist.

Schon eine einfache defensive Inventarprüfung kann ausreichen, um Hochrisiko-Kandidaten sichtbar zu machen, bevor verdächtiger Traffic überhaupt untersucht wird.

Get-ADUser -LDAPFilter "(servicePrincipalName=*)" -Properties servicePrincipalName,pwdLastSet,PasswordNeverExpires,msDS-SupportedEncryptionTypes |
  Select-Object SamAccountName,ServicePrincipalName,PasswordNeverExpires,pwdLastSet,msDS-SupportedEncryptionTypes

Es geht nicht darum, jeden SPN zu sammeln und dann in Panik zu geraten. Es geht darum, die Konten zu identifizieren, die SPN-Exponierung, schwache Geheimnis-Hygiene und relevante Privilegien kombinieren.

Baselining ist Pflicht

Eine ernsthafte Kerberoasting-Erkennung braucht eine Baseline normaler Service-Ticket-Muster. Das heißt, Sie müssen wissen:

• welche Hosts üblicherweise Tickets für welche Dienste anfordern;
• auf welche Dienstkonten in hoher Anzahl zugegriffen wird, weil das Anwendungen legitimerweise so verursachen;
• welche Admin-, Scan- oder Managementwerkzeuge legitimerweise breiten TGS-Verkehr erzeugen.

Ohne diese Baseline ist „viele 4769“ keine Erkennungsstrategie. Es ist nur ein Ausgangspunkt.

Prävention und Härtung

Kerberoasting-Prävention bedeutet vor allem, SPN-gebundene Dienstkonten zu schlechten Zielen für Offline-Knacken und für Privilegieneskalation zu machen.

1. Benutzergebundene Dienstkonten reduzieren, wo es möglich ist

Microsoft dokumentiert group Managed Service Accounts (gMSA) als verwaltete Domänenkonten, die automatische Kennwortverwaltung und vereinfachte SPN-Verwaltung bieten, auch über mehrere Server hinweg.

Das macht ein gMSA nicht magisch „außerhalb von Kerberos“. Es macht es aber zu einem deutlich besseren defensiven Standard als ein manuell verwaltetes Benutzerkonto, dessen Kennwort seit Jahren unverändert ist.

Wo die Plattform es zulässt, ist die Migration geeigneter Dienste von klassischen benutzergebundenen Dienstkonten auf gMSA eine der nützlichsten präventiven Maßnahmen.

2. Kennwörter von Legacy-Dienstkonten rotieren

Microsofts RC4-Guidance weist darauf hin, dass ältere Konten möglicherweise keine AES-Schlüssel besitzen, wenn ihr Kennwort nie zurückgesetzt wurde, nachdem moderner Kerberos-Support eingeführt wurde. Das ist wichtig, weil ein Kennwort-Reset nicht nur das Geheimnis ändert. Er kann auch das verwendbare Schlüsselmateral des Kontos aktualisieren.

Für Legacy-Dienstkonten, die noch nicht auf gMSA umgestellt werden können:

• rotieren Sie das Kennwort;
• machen Sie es lang und zufällig;
• prüfen Sie anschließend, dass der Dienst weiterhin sauber funktioniert;
• dokumentieren Sie den Owner, damit das Konto nicht erneut zu geteilter technischer Schuld wird.

3. RC4 kontrolliert reduzieren, nicht blind

Microsoft dokumentiert RC4 inzwischen ausdrücklich als unsicher, als auslaufend und als etwas, das über Kerberos-Telemetrie auditiert werden sollte. Microsoft dokumentiert auch konkrete Möglichkeiten, RC4 einzuschränken oder zu deaktivieren, einschließlich Richtlinien für zulässige Kerberos-Verschlüsselungstypen.

Die richtige Schlussfolgerung ist nicht: „RC4 sofort überall deaktivieren.“ Die richtige Schlussfolgerung ist:

• identifizieren, wo RC4 noch verwendet wird;
• klären, ob die Abhängigkeit real ist oder nur ungepflegte Alt-Konfiguration;
• geeignete Konten und Hosts auf AES-fähige Einstellungen umstellen;
• Authentifizierungsfehler während des Rollouts überwachen.

Microsofts eigene Guidance warnt davor, dass das Deaktivieren von RC4 Legacy-Abhängigkeiten brechen kann, wenn diese nicht vorher validiert wurden. Dieser Vorbehalt gehört in jeden ernsthaften Kerberoasting-Härtungsplan.

4. Die Rechte hinter dem Dienstkonto überprüfen

Prävention bleibt unvollständig, wenn nur das Kennwort verbessert und die Rechte unangetastet bleiben.

Prüfen Sie, ob das Dienstkonto über Folgendes verfügt:

• lokalen Admin auf vielen Servern;
• delegierte Rechte in AD;
• Backup-, Orchestrierungs- oder Deployment-Privilegien;
• hochkritischen Datenbank- oder Dateizugriff;
• implizite Pfade in AD-Gruppenverschachtelung oder Privileged Access Drift in Active Directory.

Ein gehärtetes, aber überprivilegiertes Dienstkonto macht aus einer wiederhergestellten Anmeldeinformation weiterhin einen schweren Vorfall.

5. SPNs bereinigen, die keine realen Dienste mehr repräsentieren

Microsoft dokumentiert setspn als Werkzeug zum Lesen, Hinzufügen, Entfernen und Abfragen von SPNs. Das ist operativ wichtig, weil veraltete oder doppelte SPNs nicht nur ein Hygieneproblem sind. Sie verschleiern Ownership und vergrößern unnötig die Prüfoberfläche.

Wenn ein SPN keinen realen Dienst mehr repräsentiert, entfernen Sie ihn. Wenn eine Anwendung keine benutzergebundene Identität mehr benötigt, ziehen Sie das Konto still, statt es unbegrenzt mitzuschleppen.

Validierung nach der Remediation

Eine Kerberoasting-Remediation ist nicht abgeschlossen, nur weil einmal ein Kennwort rotiert oder im Labor ein Tickettyp geändert wurde. Die Validierung muss belegen, dass sich die Exponierung in der Produktion tatsächlich verschoben hat.

Bewahren Sie mindestens ein Evidenzpaket wie dieses auf:

Die Validierungsfragen sollten konkret sein:

• Welche kritischen SPN-Konten basieren noch auf manuell verwalteten Kennwörtern?
• Welche zeigen noch hohes Kennwortalter oder Ausnahmen von der Ablaufregel?
• Welche Dienste benötigen noch RC4, und wer hat diese Abhängigkeit freigegeben?
• Welche Konten würden bei Wiederherstellung des Geheimnisses weiterhin nennenswerte laterale Bewegung eröffnen?
• Hat sich die 4769-Baseline der Domäne nach den Remediation-Maßnahmen materiell verbessert?

Das ist der Unterschied zwischen „wir haben einige Dienstkonto-Kennwörter geändert“ und „wir haben das Kerberoasting-Risiko messbar reduziert“.

Wie EtcSec das Kerberoasting-Risiko misst

EtcSec sollte die Bedingungen beschreiben, die Kerberoasting praktisch machen, und nicht so tun, als ließe sich damit ein laufender Angriff aus einem einzelnen Event beweisen.

Das Kern-Finding ist KERBEROASTING_RISK, sinnvoll dann, wenn ein Konto einen SPN besitzt und weiterhin ein oder mehrere Merkmale aufweist, die Offline-Knacken materiell realistischer machen.

Kontext-Findings mit höherer Priorität sind unter anderem:

• PASSWORD_NEVER_EXPIRES
• PASSWORD_POLICY_WEAK
• KERBEROS_RC4_FALLBACK

Zusammen helfen diese Checks dabei, eine wiederholbare Prüfung zu strukturieren von:

• welchen Dienstkonten exponiert sind;
• welche davon schwach genug bleiben, um relevant zu sein;
• welche auf bedeutsamen Privilegienpfaden liegen;
• welche nach Änderungen weiterhin Remediation-Nachweise benötigen.

Verwandte Kontrollen

Kerberoasting sollte zusammen mit benachbarten Identitätskontrollen betrachtet werden, die denselben Kompromittierungspfad häufig verstärken:

• AS-REP Roasting, weil beide Techniken Kerberos-Material in Offline-Cracking-Risiko verwandeln;
• AD-Passwortsicherheit, weil Kennwortqualität und Rotationshygiene die Ausnutzbarkeit bestimmen;
• Veraltete und überprivilegierte Konten in AD, weil vergessene Konten oft die gefährlichsten SPNs tragen;
• Kerberos-Delegation, weil Dienstidentitäten sich oft mit Delegations-Exponierungen überschneiden;
• Active Directory-Sicherheit auditieren, weil Kerberoasting nur ein Prüfpunkt in einem größeren, evidenzorientierten AD-Workflow ist;
• AD Sicherheitsüberwachung, weil 4769 erst dann nützlich wird, wenn Event-Sammlung und Baselining vorhanden sind.

Primärquellen

• MITRE ATT&CK T1558.003: Kerberoasting
• 4769(S, F): A Kerberos service ticket was requested
• 4768(S, F): A Kerberos authentication ticket (TGT) was requested
• Detect and remediate RC4 usage in Kerberos
• Kerberos authentication overview in Windows Server
• Group Managed Service Accounts overview
• Service principal names
• Setspn
• ms-DS-Supported-Encryption-Types attribute
• Audit Directory Service Access