Golden Ticket: Erkennung und Behebung

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.

Prufprioritaten

Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain sollte als reale Exposition in Ihre Active-Directory-Umgebung behandelt werden und nicht als einzelner isolierter Fehler. Zuerst muss der tatsachliche Prufumfang definiert werden: welche privilegierte Gruppen, Dienstkonten, ACLs, GPO-Verknupfungen, Trusts, Delegationen, Zertifikatvorlagen und Admin-Workstations betroffen sind, welche Geschaftsprozesse davon abhangen, welche Privilegien freigelegt werden und welche Notfallausnahmen sich mit der Zeit angesammelt haben. Diese Einordnung verhindert oberflachliche Remediation, weil das technische Symptom oft kleiner ist als der operative Blast Radius. Wenn der gesamte Pfad von Konfiguration uber Berechtigung bis zur Nutzung dokumentiert ist, kann das Team Anderungen priorisieren, die Risiko schnell reduzieren, ohne den Betrieb zu blockieren.

Benachbarte Kontrollen Mitprufen

Sobald Angreifer in Ihre Active-Directory-Umgebung angekommen sind, bleiben sie selten beim ersten Schwachpunkt stehen. Rund um Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain testen sie meist, ob sich der Zugang mit veraltete privilegierte Konten, gefahrliche Gruppenverschachtelung, ubermassige Delegation, schwache Passwortrichtlinien und geerbter ACL-Missbrauch verketten lasst. Deshalb muss die Verteidigung nicht nur die Hauptschwache, sondern auch jede benachbarte Abhangigkeit prufen, die initialen Zugriff in Persistenz oder Eskalation verwandeln kann. Klarheit uber Identitaten, Rollen, Rechte und Vertrauensannahmen ist hier entscheidend. Wenn ein Fix nur ein einzelnes Objekt schliesst, wahrend benachbarte Privilegpfade offen bleiben, verandert sich das reale Risiko kaum. Eine saubere Kettenanalyse ist daher zentral fur eine belastbare Härtung.

Belege und Telemetrie sammeln

Eine belastbare Reaktion auf Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain braucht Belege, die Technik, Detection und Governance gemeinsam auswerten konnen. Ziehen Sie Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, SYSVOL-Anderungen und Zertifikatsaktivitat, vergleichen Sie frische Anderungen mit geplanten Wartungsfenstern und isolieren Sie Konten oder Objekte mit Verhalten ohne klare Geschaftsbegrundung. Diese Belege sollten drei Fragen beantworten: wann die Exposition entstanden ist, wer sie noch nutzen kann, und ob gleichartige Pfade an anderer Stelle in Ihre Active-Directory-Umgebung existieren. Gute Telemetrie trennt ausserdem alte technische Schuld von aktiv ausnutzbarem Verhalten. Diese Trennung ist wichtig, weil die Remediation fur Altlasten anders gesteuert wird als fur eine Schwache mit deutlichen Missbrauchssignalen.

Benachbarte Schwachen mitprufen

Kaum eine Umgebung enthalt Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain allein. In der Praxis finden sich in derselben Tenant- oder AD-Zone oft auch veraltete privilegierte Konten, gefahrliche Gruppenverschachtelung, ubermassige Delegation, schwache Passwortrichtlinien und geerbter ACL-Missbrauch, und genau diese Nachbarschwachen entscheiden, ob der Pfad nur unsauber oder wirklich kritisch ist. Prufen Sie gemeinsame Owner, geerbte Rechte, doppelte Ausnahmen und administrative Abkurzungen, die nie zuruckgebaut wurden. Wenn dieselbe risikoreiche Entscheidung an mehreren Stellen auftaucht, liegt meist ein Prozessproblem und nicht nur ein Einzelfehler vor. Diese erweiterte Sicht verbessert die Chance, den gesamten Angriffspfad zu entfernen statt nur eine sichtbare Stelle zu glatten.

Remediation in sinnvoller Reihenfolge

Bei Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain sollte die Remediation zuerst dort ansetzen, wo Risiko am schnellsten sinkt. Entfernen Sie zunachst die Pfade mit dem hochsten Eskalationswert, harten Sie danach die wichtigsten Identitaten oder Objekte, und bereinigen Sie erst anschliessend sekundare Hygieneprobleme. Nutzen Sie Tiering, Delegationsbereinigung, ACL-Review, Hygiene fur Dienstkonten, GPO-Berechtigungsprufung und ADCS-Hardening als Zielbild. Jede Anderung braucht einen Verantwortlichen, eine Rollback-Notiz und einen klaren Validierungsschritt. So verhindert man, dass ein Verbesserungsprojekt nach dem ersten technischen Erfolg stehen bleibt. Wenn ein kompletter Umbau heute nicht realistisch ist, definieren Sie Zwischenkontrollen und planen Sie die strukturelle Arbeit in den nachsten wochentliche Privilegienprufung und monatliche Kontrollvalidierung.

Validierung nach jeder Anderung

Nach jeder Anderung rund um Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain muss das Ergebnis sowohl aus Admin-Sicht als auch aus Angreifer-Sicht validiert werden. Bestatigen Sie, dass legitime Nutzer und Systeme weiter funktionieren, und zeigen Sie zugleich, dass der gefahrliche Pfad nicht mehr dieselbe Wirkung hat. Wiederholen Sie die Sammlung auf Basis von Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, SYSVOL-Anderungen und Zertifikatsaktivitat, prufen Sie Genehmigungen und stellen Sie sicher, dass kein Nachbarobjekt denselben Umgehungsweg offenhalt. Gute Validierung enthalt ausserdem schriftliche Erfolgskriterien. In reifen Teams gilt ein Fix erst dann als abgeschlossen, wenn der Risikopfad geschlossen, der Betrieb intakt und der neue Zustand mit dem gewunschten Härtungsziel deckungsgleich ist.

Ownership, Eskalation und Governance

Themen wie Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain scheitern, wenn das technische Symptom verschwindet, aber niemand die dauerhafte Kontrolle ubernimmt. Verteilen Sie klare Verantwortung uber Directory Engineering, SOC-Analysten, Identity-Admins und Server-Verantwortliche, definieren Sie Ausnahmeregeln und legen Sie fest, welche Rolle einen risikoreichen Re-Import oder eine Lockerung freigeben darf. Diese Governance ist nicht Selbstzweck. Sie verhindert, dass Migrationen, Notfallanderungen oder Drittanbieter-Integrationen denselben Pfad in wenigen Wochen erneut offnen. Dokumentieren Sie daher, welche Entscheidungen die Schwache moglich gemacht haben, und aktualisieren Sie den Prozess so, dass neue Anfragen gegen die neue Baseline gepruft werden statt gegen alte Abkurzungen.

Fragen fur die Review-Runde

In Review-Terminen zu Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain helfen konkrete Fragen mehr als allgemeine Aussagen. Welche Objekte haben mehr Rechte als notig? Welche Ausnahme lebt nur weiter, weil nach Projektende niemand mehr zuruckgeschaut hat? Welches Team wurde einen Missbrauch zuerst erkennen, und auf welche Belege wurde es sich stutzen? Welche Geschaftsabhangigkeit blockiert die Korrektur heute, und welcher Kompensationskontroll existiert bis dahin? Solche Fragen decken operative Unklarheiten auf, die aus reinen Konfigurationslisten nicht sichtbar werden. Gleichzeitig verbinden sie Identitatsdesign, Logging-Qualitat, Ownership und Change Management in einer gemeinsamen Bewertung.

Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain