Kerberos-basierte Angriffe zählen zu den gefährlichsten Techniken im Arsenal eines Angreifers — wer sie versteht, kann sein Active Directory wirksam schützen.
Kerberos-Angriffsvektoren — vom Ticket-Diebstahl zur Domänenübernahme
Das Kerberos-Protokoll wurde 1988 am MIT entwickelt und bildet seit Windows 2000 die Standard-Authentifizierung in Active Directory. Seine Stärke — die ticketbasierte, passwortlose Authentifizierung nach dem initialen Login — ist gleichzeitig seine größte Schwachstelle. Angreifer, die ein einziges Ticket oder einen einzigen Hash extrahieren können, bewegen sich lateral durch das gesamte Netzwerk, ohne jemals ein Passwort im Klartext zu benötigen. Der MITRE ATT&CK Framework ordnet diese Techniken unter TA0006 (Credential Access) ein, und sie bilden in nahezu jeder Red-Team-Operation den kritischen Pfad zur Domänenübernahme. Was viele Administratoren nicht wissen: Die meisten dieser Angriffe hinterlassen in einer Standard-AD-Konfiguration keinerlei Spuren in den Security-Event-Logs.
Kerberoasting ist der mit Abstand häufigste Kerberos-Angriff und zugleich erschreckend einfach: Jeder authentifizierte Domänenbenutzer — selbst ohne administrative Rechte — kann für jeden im AD registrierten Service Principal Name (SPN) ein Ticket Granting Service (TGS) Ticket anfordern. Dieses TGS-Ticket ist mit dem NTLM-Hash des zugehörigen Service-Accounts verschlüsselt. Der Angreifer exportiert das Ticket und crackt es offline mit hashcat -m 13100 oder john --format=krb5tgs. Service-Accounts mit schwachen Passwörtern fallen in Minuten. Tools wie Rubeus kerberoast oder Impackets GetUserSPNs.py automatisieren den gesamten Vorgang in einem einzigen Befehl. Das Tückische: Das Anfordern eines TGS-Tickets ist eine völlig legitime Kerberos-Operation — in einer Standard-Konfiguration wird kein einziges Alert ausgelöst.
Jenseits von Kerberoasting existieren weitere, oft übersehene Angriffsvektoren, die selbst in gehärteten Umgebungen möglich sein können. Das Diamond Ticket ist die neueste und tückischste Variante: Statt ein gefälschtes Ticket von Grund auf zu erstellen (wie beim Golden Ticket), entschlüsselt der Angreifer ein echtes TGT, modifiziert das darin enthaltene Privilege Attribute Certificate (PAC) — etwa um sich Domain-Admin-Rechte zu geben — und verschlüsselt es wieder mit dem KRBTGT-Hash. Da das Ticket-Format und die Metadaten identisch mit einem legitimen Ticket sind, ist die Erkennung extrem schwierig. Selbst fortschrittliche Intrusion-Detection-Systeme, die Golden Tickets anhand von Anomalien im Ticket-Format erkennen, versagen bei Diamond Tickets.
- Kerberoasting (T1558.003): Jeder Domänenbenutzer fordert TGS-Tickets für SPN-registrierte Accounts an. Das Ticket wird offline gecrackt (
hashcat -m 13100). Service-Accounts mit Passwörtern unter 25 Zeichen fallen in Stunden.Rubeus kerberoast /outfile:hashes.txtextrahiert alle angreifbaren SPNs in einem Schritt. Besonders gefährdet: SQL-Server-Service-Accounts, die häufig mit schwachen Passwörtern und Domain-Admin-Rechten laufen. - AS-REP Roasting (T1558.004): Accounts mit dem Flag „Do not require Kerberos preauthentication“ können ohne gültiges Passwort ein AS-REP-Ticket anfordern.
Rubeus asreproastoderGetNPUsers.pyidentifizieren und extrahieren diese Tickets. Crack mithashcat -m 18200. Dieses Flag wird häufig für Legacy-Kompatibilität gesetzt und dann vergessen — ein klassisches Konfigurationsrelikt, das Jahre später zur Kompromittierung führt. - Golden Ticket (T1558.001): Mit dem NTLM-Hash des KRBTGT-Accounts kann ein Angreifer beliebige TGTs fälschen — für jeden Benutzer, mit beliebiger Gruppenzugehörigkeit, mit beliebiger Gültigkeitsdauer (bis zu 10 Jahre).
mimikatz kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /krbtgt:HASH. Selbst das Zurücksetzen aller Benutzerpasswörter hilft nicht — nur ein doppeltes KRBTGT-Reset invalidiert bestehende Golden Tickets. - Silver Ticket (T1558.002): Statt den KRBTGT-Hash benötigt der Angreifer nur den NTLM-Hash eines Service-Accounts, um TGS-Tickets für genau diesen Dienst zu fälschen. Der Vorteil für den Angreifer: Das gefälschte Ticket wird nie beim Domain Controller validiert, da der Zieldienst es selbst entschlüsselt. Das bedeutet: kein Event 4769, kein Log-Eintrag auf dem DC — der Angriff ist praktisch unsichtbar.
- DCSync (T1003.006): Mimikatz
lsadump::dcsync /domain:corp.local /user:krbtgtsimuliert das Replikationsprotokoll eines Domain Controllers (MS-DRSR), um jeden beliebigen Passwort-Hash aus dem AD zu extrahieren — inklusive KRBTGT. Voraussetzung: Der Angreifer-Account besitzt die Rechte „Replicating Directory Changes“ und „Replicating Directory Changes All“. Diese Rechte sind standardmäßig nur Domain Admins und Domain Controllers zugewiesen, werden aber häufig für Synchronisationstools (Azure AD Connect, SIEM-Konnektoren) vergeben und nie wieder entzogen. - Diamond Ticket: Die neueste und am schwierigsten zu erkennende Technik. Ein echtes TGT wird mit dem KRBTGT-Hash entschlüsselt, das PAC (Privilege Attribute Certificate) modifiziert — z. B. um die RID 500 (Administrator) oder Domain-Admin-Gruppen-SIDs einzufügen — und erneut verschlüsselt. Das resultierende Ticket ist kryptographisch korrekt und von einem legitimen Ticket nicht zu unterscheiden. Rubeus unterstützt Diamond Tickets mit
Rubeus diamond /krbkey:AES256KEY /ticketuser:admin /ticketuserid:500 /groups:512.
Erkennung & Monitoring — Angriffe sichtbar machen
Die größte Herausforderung bei Kerberos-Angriffen ist ihre Unsichtbarkeit in Standard-Konfigurationen. Viele der beschriebenen Techniken erzeugen in einer typischen Windows-Server-Umgebung keinerlei Alerts — sie nutzen legitime Kerberos-Funktionen auf eine Weise, die vom Protokoll nicht als bösartig erkannt wird. Um diese Angriffe sichtbar zu machen, müssen Administratoren die Advanced Audit Policy gezielt konfigurieren und die richtigen Event-IDs korrelieren. Die Schlüsselkonfiguration ist die Aktivierung von „Audit Kerberos Service Ticket Operations“ und „Audit Kerberos Authentication Service“ unter Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Account Logon. Ohne diese Einstellung werden viele der folgenden Erkennungsmethoden nicht funktionieren.
Ein besonders wirkungsvolles — und kaum bekanntes — Erkennungsmuster sind Honey Tokens und Honey SPNs. Dabei werden gezielt falsche Benutzerkonten im AD angelegt, die wie attraktive Angriffsziele aussehen (z. B. svc_sql_backup mit einem SPN), aber niemals für legitime Zwecke verwendet werden. Jede Interaktion mit diesen Accounts — sei es ein TGS-Request, ein Login-Versuch oder eine LDAP-Abfrage — ist per Definition ein Indicator of Compromise (IoC). Ein einzelner Event 4769 für den Honey-SPN-Account bedeutet mit 100 % Sicherheit, dass jemand Kerberoasting betreibt. Diese Technik ist kostenfrei, erfordert keine zusätzliche Software und ist in unter einer Stunde implementiert. Zusätzlich bietet BloodHound — ursprünglich als offensives Red-Team-Tool entwickelt — enormen Wert für die Verteidigung: Blue Teams können damit Angriffspfade identifizieren, bevor ein Angreifer sie findet, und gezielt die Verbindungen kappen, die einen Pfad zum Domain Admin ermöglichen.
Für Unternehmen mit Microsoft-E5-Lizenzierung bietet Microsoft Defender for Identity (ehemals Azure ATP / Advanced Threat Analytics) automatisierte Erkennung für Kerberoasting, Pass-the-Ticket, DCSync und anomale Replikationsanfragen. Das Tool installiert Sensoren direkt auf den Domain Controllern und analysiert den Netzwerktraffic in Echtzeit. Für Umgebungen ohne E5-Lizenz liefert eine Kombination aus Windows Event Forwarding (WEF) an einen zentralen Log-Collector und Sigma-Regeln (Open-Source-Detection-Rules) eine kostengünstige Alternative. Entscheidend ist die Fähigkeit, anomale TGT-Lebensdauern zu erkennen: Ein Golden Ticket hat typischerweise eine Gültigkeitsdauer, die weit über den Standard von 10 Stunden hinausgeht — wer nach TGTs mit überdurchschnittlicher Lifetime filtert, kann Golden Tickets aufspüren.
- Event ID 4769 + Encryption Type 0x17 (RC4): Ein TGS-Request mit RC4-Verschlüsselung (Ticket Encryption Type = 0x17) ist ein starker Indikator für Kerberoasting, da moderne Systeme AES256 (0x12) verwenden. Ausnahme: Legacy-Systeme, die kein AES unterstützen, erzeugen ebenfalls 0x17-Requests. Die Korrelation mit dem angefragten Service-Account und dem anfragenden Benutzer ist entscheidend — wenn ein normaler Benutzer plötzlich TGS-Tickets für 50 verschiedene SPNs anfordert, ist das hochgradig verdächtig.
- Event ID 4768 ohne Pre-Authentication: AS-REP Roasting erzeugt Event 4768 (TGT Request) mit dem Result Code
0x0und Pre-Authentication Type0(None). Filtern Sie nach Accounts, bei denen Pre-Auth deaktiviert ist, und korrelieren Sie mit unerwarteten Quell-IPs. Regulieren Sie die Anzahl der AS-REP-Requests pro Zeiteinheit — mehr als 5 Requests in 60 Sekunden von derselben Quell-IP sind anomal. - Event ID 4662 + DCSync-GUID: DCSync-Angriffe erzeugen Event 4662 (Directory Service Access) mit der Property-GUID
{1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}(DS-Replication-Get-Changes) und{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}(DS-Replication-Get-Changes-All). Wenn diese Events von einem Account ausgelöst werden, der kein Domain Controller ist, handelt es sich mit hoher Wahrscheinlichkeit um einen DCSync-Angriff. Überwachen Sie diese GUIDs in Ihrem SIEM. - Honey Tokens / Honey SPNs: Erstellen Sie attraktive Fake-Accounts wie
svc_sql_prod,svc_backup_adminodersvc_exchange_svcmit registrierten SPNs, aber deaktivierten Passwörtern (240+ Zeichen). Jeder TGS-Request (4769), Login-Versuch (4625) oder LDAP-Query gegen diese Accounts ist ein IoC. Konfigurieren Sie High-Priority-Alerts in Ihrem SIEM. Kosten: null. Implementierungszeit: 30 Minuten. Erkennungsrate für Kerberoasting: nahezu 100 %. - BloodHound für Blue Teams: Führen Sie
SharpHound(oder den Python-Collectorbloodhound-python) regelmäßig als Scheduled Task aus und importieren Sie die Daten in BloodHound. Analysieren Sie die Angriffspfade vom „Shortest Path to Domain Admin“ und beseitigen Sie unnötige Berechtigungen. Besonders kritisch: Accounts mit GenericAll, WriteDACL oder Owns-Rechten auf privilegierte Gruppen. BloodHound 4.x zeigt auch Azure-Angriffspfade (Entra ID). - Anomale TGT-Lifetime-Erkennung: Standard-TGT-Lifetime in AD ist 10 Stunden (konfigurierbar via GPO). Golden Tickets werden häufig mit einer Lifetime von 10 Jahren erstellt. Filtern Sie Event 4768-Einträge, bei denen die Ticket-Optionen eine überdurchschnittliche Lifetime andeuten. Microsoft Defender for Identity erkennt dies automatisch. Für manuelle Analyse:
klist ticketsauf verdächtigen Systemen zeigt die tatsächliche TGT-Lebensdauer.
Härtungsmaßnahmen — Active Directory resilient machen
Die effektivste Härtungsmaßnahme gegen Kerberos-Angriffe ist die regelmäßige Rotation des KRBTGT-Passworts — und hier machen die meisten Administratoren einen kritischen Fehler. Active Directory speichert nicht nur das aktuelle, sondern auch das vorherige KRBTGT-Passwort, um Tickets zu validieren, die noch mit dem alten Schlüssel ausgestellt wurden. Das bedeutet: Ein einzelnes Passwort-Reset invalidiert bestehende Golden Tickets nicht, da diese noch gegen den vorherigen Hash validiert werden können. Die korrekte Prozedur erfordert ein doppeltes Reset mit mindestens 12 Stunden Abstand. Der Grund für die Wartezeit: Nach dem ersten Reset müssen alle legitimen Kerberos-Tickets erneuert werden (Standard-TGT-Lifetime: 10 Stunden). Erst nach Ablauf dieser Zeitspanne kann das zweite Reset durchgeführt werden, das den alten Hash endgültig verwirft. Ein zu schnelles doppeltes Reset würde alle aktiven Benutzersitzungen in der gesamten Domäne unterbrechen.
Die zweite revolutionäre Härtungsmaßnahme sind Group Managed Service Accounts (gMSA). Diese speziellen AD-Accounts generieren automatisch 240 Zeichen lange, kryptographisch zufällige Passwörter, die alle 30 Tage rotiert werden — ohne manuellen Eingriff. Da das Passwort eines gMSA niemals einem Menschen bekannt ist und 240 Zeichen nicht in realistischer Zeit gecrackt werden können, sind gMSA-basierte Service-Accounts immun gegen Kerberoasting. Die Migration bestehender Service-Accounts zu gMSA erfordert Aufwand (jeder Dienst muss umkonfiguriert werden), ist aber die wirksamste Einzelmaßnahme gegen den häufigsten Kerberos-Angriff. Für Dienste, die keine gMSA unterstützen, sollten Passwörter mit mindestens 30 Zeichen und AES256-only Verschlüsselung konfiguriert werden.
Zusätzlich bietet die Protected Users Sicherheitsgruppe seit Windows Server 2012 R2 einen umfassenden Schutz für privilegierte Accounts: Mitglieder können sich nicht per NTLM authentifizieren, keine DES- oder RC4-Verschlüsselung verwenden, kein Unconstrained Delegation nutzen und ihre TGTs haben eine maximale Lifetime von 4 Stunden. In Kombination mit Windows Defender Credential Guard, das NTLM-Hashes und Kerberos-Tickets in einer virtualisierten Umgebung (VSM — Virtual Secure Mode) isoliert, wird das Extrahieren von Credentials aus dem Speicher — selbst mit Mimikatz und SYSTEM-Rechten — unmöglich. Für Unternehmen, die den höchsten Sicherheitsstandard anstreben, empfiehlt Microsoft das Enhanced Security Admin Environment (ESAE), auch bekannt als „Red Forest“: Eine separate, isolierte AD-Gesamtstruktur ausschließlich für die Verwaltung privilegierter Identitäten, verbunden über einen PAM Trust (Privileged Access Management), der zeitlich begrenzte, JIT-aktivierte Gruppenzugehörigkeiten ermöglicht.
- KRBTGT-Doppel-Reset-Prozedur: Erstes Reset:
Reset-KrbtgtKeyInteractive(Microsoft-Skript) oder manuell über ADUC. Warten Sie mindestens 12 Stunden (länger als die TGT-Maximum-Lifetime + Clock-Skew-Toleranz). Zweites Reset: erneut ausführen. Erst jetzt sind alle Golden Tickets invalidiert. Empfohlener Zyklus: alle 90 Tage. Testen Sie die Prozedur zuerst in einer Testumgebung — ein zu schnelles Doppel-Reset verursacht einen domänenweiten Authentifizierungsausfall. - Group Managed Service Accounts (gMSA): Erstellen mit
New-ADServiceAccount -Name svc_sql -DNSHostName svc_sql.corp.local -ManagedPasswordIntervalInDays 30 -PrincipalsAllowedToRetrieveManagedPassword SQL_Servers$. 240-Zeichen-Passwort, automatische Rotation, kein manuelles Management. Installieren auf dem Zielserver mitInstall-ADServiceAccount -Identity svc_sql. Dienste konfigurieren mit „Log on as: DOMAIN\svc_sql$“ (Dollarzeichen am Ende). Eliminiert Kerberoasting vollständig für migrierte Accounts. - RC4-Verschlüsselung deaktivieren (AES256 erzwingen): GPO: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → „Network security: Configure encryption types allowed for Kerberos“ → nur AES128_HMAC_SHA1 und AES256_HMAC_SHA1 aktivieren. Achtung: Vorher alle Systeme und Service-Accounts auf AES-Fähigkeit prüfen — Legacy-Systeme (Windows Server 2003, ältere Linux-Kerberos-Clients) unterstützen möglicherweise kein AES.
- Protected Users Sicherheitsgruppe: Alle privilegierten Accounts (Domain Admins, Enterprise Admins, Schema Admins, Server-Operatoren) in die Gruppe Protected Users aufnehmen. Wirkung: Kein NTLM, kein DES/RC4, keine Unconstrained Delegation, TGT-Lifetime auf 4 Stunden begrenzt, keine Credential-Caching. Wichtig: Testen Sie alle Anwendungen — Dienste, die NTLM benötigen, werden für Protected-Users-Mitglieder nicht funktionieren.
- AdminSDHolder & SDProp prüfen: Der AdminSDHolder-Container definiert die ACL-Vorlage für alle privilegierten Gruppen. Der Prozess SDProp überschreibt alle 60 Minuten die ACLs geschützter Accounts mit dieser Vorlage. Angreifer manipulieren den AdminSDHolder, um persistente Backdoor-Berechtigungen zu setzen. Prüfung:
Get-ACL "AD:\CN=AdminSDHolder,CN=System,DC=corp,DC=local" | Select-Object -ExpandProperty Access | Where IdentityReference -notmatch "NT AUTHORITY|BUILTIN|Domain Admins|Enterprise Admins". Jeder unbekannte Eintrag ist ein potenzieller Backdoor. - Credential Guard + PingCastle-Audits: Windows Defender Credential Guard aktivieren via GPO (erfordert UEFI Secure Boot + VBS). Isoliert NTLM-Hashes und TGTs in einem virtualisierten Container, den selbst SYSTEM-Prozesse nicht auslesen können — Mimikatz
sekurlsa::logonpasswordsliefert nur Platzhalter. Ergänzend: PingCastle monatlich ausführen für eine Risikobewertung des AD (Score 0–100). BloodHound quartalsmäßig für Angriffspfad-Analyse. Ziel: PingCastle-Score unter 30, keine Tier-0-Angriffspfade in BloodHound.
Sie benötigen Unterstützung?
Kerberos-Angriffe zählen zu den gefährlichsten Bedrohungen für Ihr Active Directory. Wir prüfen Ihre AD-Konfiguration mit BloodHound und PingCastle, implementieren gMSA-Migration, KRBTGT-Rotation und Tier-Modell — damit Angreifer keinen Pfad zum Domain Admin finden.
Active Directory ansehen →
