Was ist ein Golden Ticket?
Ein Golden Ticket ist ein gefälschtes Kerberos Ticket Granting Ticket (TGT), das einem Angreifer unbegrenzten, dauerhaften Zugriff auf alle Ressourcen in einer Active Directory-Domain gewährt, ohne das Passwort eines Benutzers zu kennen.
Der Angriff missbraucht das KRBTGT-Konto, dessen Hash verwendet wird, um jedes in der Domain ausgestellte TGT zu signieren. Wenn ein Angreifer diesen Hash erhält, kann er gültige TGTs für jeden Benutzer erstellen, einschließlich Domain-Admins, mit beliebigen Gruppenmitgliedschaften und beliebigem Ablaufdatum.
⚠️ Wichtig: Ein Golden Ticket bleibt gültig, bis das KRBTGT-Passwort zweimal rotiert wurde. Das Zurücksetzen aller anderen Konten hat keinerlei Wirkung.
Funktionsweise
Die Kerberos-Authentifizierung basiert auf einer vertrauenswürdigen dritten Instanz: dem Key Distribution Center (KDC), das auf jedem Domain Controller läuft.
Normaler Ablauf:
- Ein Benutzer authentifiziert sich beim KDC und erhält ein TGT, signiert mit dem KRBTGT-Hash.
- Der Benutzer präsentiert das TGT, um Service Tickets (TGS) für bestimmte Ressourcen zu erhalten.
- Dienste validieren das TGS und gewähren Zugriff.
Kein Dienst validiert TGTs direkt beim KDC zum Zeitpunkt der Verwendung: Sie vertrauen der Signatur. Ein gefälschtes TGT, das mit dem echten KRBTGT-Hash signiert ist, ist von einem legitimen nicht zu unterscheiden.
Die Angriffskette
Schritt 1 - Domain Admin-Rechte erlangen
Der Angreifer benötigt ausreichende Berechtigungen, um den KRBTGT-Hash zu extrahieren, typischerweise durch Kompromittierung eines Domain Controllers oder Missbrauch von DCSync-Rechten.
Schritt 2 - KRBTGT-Hash via DCSync extrahieren
# Mimikatz
lsadump::dcsync /domain:corp.local /user:krbtgt
# Impacket (von Linux)
impacket-secretsdump -just-dc-user krbtgt corp.local/admin:[email protected]
Schritt 3 - Golden Ticket fälschen
# Mimikatz — fälschen und direkt in die aktuelle Sitzung injizieren
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /krbtgt:HASH /ptt
| Parameter | Beschreibung |
|---|---|
/user | Beliebiger Benutzername, real oder fiktiv |
/sid | Domain-SID (aus DCSync-Ausgabe) |
/krbtgt | NTLM-Hash des KRBTGT-Kontos |
/endin | Ticket-Lebensdauer in Minuten — Angreifer setzen oft 87600 (10 Jahre) |
/ptt | Pass-the-ticket: direkt in den Sitzungsspeicher injizieren |
Schritt 4 - Vollständiger Domainzugriff und Persistenz
Das gefälschte TGT wird von jedem Dienst in der Domain akzeptiert. Der Angreifer kann nun auf alle Dateifreigaben, RDP-Sitzungen, WMI-Endpunkte zugreifen, neue Backdoor-Konten erstellen und bösartige GPOs verteilen.
Erkennung
Windows Event IDs
| Event ID | Quelle | Worauf zu achten ist |
|---|---|---|
| 4768 | DC - Security | TGT-Anfragen von unbekannten IPs oder zu ungewöhnlichen Zeiten |
| 4769 | DC - Security | RC4-Verschlüsselung (0x17) obwohl AES Standard ist |
| 4672 | DC - Security | Sonderrechte an unerwartete Konten vergeben |
| 4624 | Workstation/Server | Netzwerkanmeldung (Typ 3) von Konten ohne vorherige Aktivität |
Verhaltensanomalien
- Ticket-Lebensdauer über 10 Stunden - Microsoft-Standard ist max. 10h; gefälschte Tickets haben oft jahrelange Laufzeiten
- Nicht existierende Benutzernamen in Kerberos-Ereignissen
- RC4-Verschlüsselung wenn die Domain AES erzwingt
- TGS-Anfrage ohne vorherigen AS-REQ auf dem DC
SIEM-Erkennungsabfrage (Elastic KQL)
event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")
💡 Tipp: Erzwingen Sie AES-only-Verschlüsselung in Ihrer Domain. Jeder RC4-Kerberos-Datenverkehr wird dann zu einem sofortigen Hochvertrauens-Alert.
Behebung
⚠️ Voraussetzung: Identifizieren und eindämmen Sie den Kompromittierungspfad, bevor Sie KRBTGT rotieren.
Sofortmassnahmen
KRBTGT-Passwort zweimal rotieren, mit einem Delay zwischen den Rotationen von mindestens einer Ticket-Lebensdauer (Standard: 10 Stunden):
# Microsoft-Skript verwenden
# https://github.com/microsoft/New-KrbtgtKeys.ps1
.\New-KrbtgtKeys.ps1 -Mode ModeSingle
# Mindestens 10 Stunden warten
.\New-KrbtgtKeys.ps1 -Mode ModeSingle
Härtung
| Massnahme | Beschreibung |
|---|---|
| Privileged Access Workstations (PAW) | Domain Admin-Anmeldungen auf dedizierte Workstations beschränken |
| Gestaffeltes Admin-Modell | Tier-0-Credentials von Tier-1/2-Systemen fernhalten |
| Protected Users-Gruppe | Privilegierte Konten hinzufügen: deaktiviert RC4, NTLM und Credential-Caching |
| AES erzwingen | msDS-SupportedEncryptionTypes = 24 auf KRBTGT setzen |
| DCSync-Rechte überwachen | Alert bei Nicht-DC-Konten mit DS-Replication-Get-Changes-All |
So Erkennt EtcSec Dies
EtcSec prüft die Bedingungen, die Golden Ticket-Angriffe in Ihrer Umgebung ermöglichen.
Die GOLDEN_TICKET_RISK-Erkennung markiert Umgebungen, in denen das KRBTGT-Konto-Passwort nicht kürzlich rotiert wurde.
Verwandte Prüfungen:
- WEAK_KERBEROS_POLICY - permissive Kerberos-Einstellungen verlängern das Angriffsfenster
- KERBEROS_RC4_FALLBACK - RC4 noch erlaubt erleichtert das Fälschen und erschwert die Erkennung
- UNCONSTRAINED_DELEGATION - Konten mit uneingeschränkter Delegation als häufiger Vorläufer
ℹ️ Hinweis: EtcSec prüft diese Schwachstellen automatisch bei jedem AD-Audit. Starten Sie ein kostenloses Audit, um zu prüfen, ob Ihre Umgebung exponiert ist.
