Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain

Was ist ein Golden-Ticket-Angriff?

Ein Golden-Ticket-Angriff ist ein gefälschtes Kerberos Ticket Granting Ticket (TGT), das einem Angreifer unbegrenzten, dauerhaften Zugriff auf jede Ressource in einer Active-Directory-Domäne verschafft — ohne das Passwort eines einzigen Benutzers zu kennen.

Der Angriff missbraucht das KRBTGT-Konto, dessen Hash verwendet wird, um jedes in der Domäne ausgestellte TGT zu signieren. Erhält ein Angreifer diesen Hash, kann er gültige TGTs für jeden beliebigen Benutzer fälschen — einschließlich Domain Admins — mit beliebigen Gruppenmitgliedschaften und beliebigem Ablaufdatum.

Das macht das Golden Ticket zu einer der schwerwiegendsten Post-Exploitation-Techniken in Active Directory: Ein einziger gestohlener Hash übersetzt sich in unbegrenzte, domänenweite Kontrolle.

Wie ein Golden-Ticket-Angriff funktioniert

Die Kerberos-Authentifizierung beruht auf einer vertrauenswürdigen dritten Partei: dem Key Distribution Center (KDC), das auf jedem Domain Controller läuft.

Der normale Ablauf:

1. Ein Benutzer authentifiziert sich beim KDC und erhält ein TGT, signiert mit dem KRBTGT-Hash.
2. Der Benutzer legt das TGT vor, um Service Tickets (TGS) für bestimmte Ressourcen anzufordern.
3. Dienste validieren das TGS und gewähren Zugriff.

Das KRBTGT-Konto ist die Vertrauenswurzel für jedes TGT in der Domäne. Kein Dienst validiert TGTs zum Zeitpunkt ihrer Nutzung direkt beim KDC — sie vertrauen der Signatur. Das bedeutet: Ein gefälschtes TGT, signiert mit dem echten KRBTGT-Hash, ist von einem legitimen nicht zu unterscheiden.

Die Angriffskette

Schritt 1 – Domain-Admin-Rechte (oder gleichwertig) erlangen

Der Angreifer benötigt ausreichende Rechte, um den KRBTGT-Hash zu extrahieren. Das bedeutet in der Regel die Kompromittierung eines Domain Controllers oder eines Kontos mit DS-Replication-Get-Changes-All-Rechten (DCSync).

Häufige Eskalationswege, die hierher führen: Kerberoasting eines privilegierten Dienstkontos, Missbrauch von ADCS ESC1/ESC8 oder die Ausnutzung uneingeschränkter Delegation.

Schritt 2 – KRBTGT-Hash per DCSync extrahieren

Der Angreifer führt mit Mimikatz oder Impacket einen DCSync-Angriff aus, um den NTLM-Hash von KRBTGT abzugreifen, ohne die Festplatte des DC zu berühren oder ein Anmeldeereignis auszulösen:

# Mimikatz
lsadump::dcsync /domain:corp.local /user:krbtgt

# Impacket (remote, von Linux aus)
impacket-secretsdump -just-dc-user krbtgt corp.local/admin:[email protected]

Die Ausgabe enthält den NTLM-Hash und die Domain-SID — beide werden zum Fälschen des Tickets benötigt.

Schritt 3 – Das Golden Ticket fälschen

Mit dem KRBTGT-Hash und der Domain-SID erstellt der Angreifer ein TGT für einen beliebigen Benutzer seiner Wahl:

# 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

Wichtige Parameter:

Schritt 4 – Vollständiger Domänenzugriff und Persistenz

Das gefälschte TGT wird von jedem Dienst in der Domäne akzeptiert. Der Angreifer kann nun:

• Auf jede Dateifreigabe, RDP-Sitzung, jeden WMI-Endpunkt oder DCOM-Dienst zugreifen
• Neue Backdoor-Konten anlegen und privilegierten Gruppen hinzufügen
• Bösartige GPOs auf alle Rechner verteilen
• Sich unbegrenzt halten — Passwort-Resets beliebiger Benutzerkonten haben keinerlei Wirkung

Erkennung

Golden Tickets sind schwer zu erkennen, weil gefälschte TGTs wie legitimer Kerberos-Verkehr aussehen. Das KDC wird zum Zeitpunkt der Ticket-Nutzung nicht konsultiert, sodass beim DC kein Authentifizierungsereignis ausgelöst wird, wenn das Ticket einem Dienst vorgelegt wird.

Die Erkennung stützt sich auf Anomalieanalyse statt auf direkte Ereigniskorrelation.

Windows Event IDs

Verhaltensanomalien

• Ticket-Lebensdauer über 10 Stunden – Microsofts Standardmaximum liegt bei 10 Stunden; gefälschte Tickets haben oft eine Lebensdauer von mehreren Jahren
• Nicht existierende Benutzernamen in Kerberos-Ereignissen – Golden Tickets lassen sich auch für Konten fälschen, die im AD gar nicht existieren
• RC4-Verschlüsselung, obwohl die Domäne AES-only erzwingt – ältere Tools verwenden standardmäßig RC4 (0x17)
• TGS-Anfrage ohne vorherigen AS-REQ – eine Service-Ticket-Anfrage an einen DC ohne zugehörige TGT-Anfrage ist ein starker Indikator
• SID-Mismatch – die im Ticket eingebettete SID stimmt mit keinem realen AD-Konto überein

SIEM-Erkennungsabfrage (Elastic KQL)

event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")

event.code: "4768" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
winlog.event_data.PreAuthType: "0"

Behebung

Sofortmaßnahmen

Rotieren Sie das KRBTGT-Passwort zweimal, mit einer Verzögerung zwischen den Rotationen, die der maximalen Kerberos-Ticket-Lebensdauer entspricht (Standard: 10 Stunden).

• Die erste Rotation macht alle aktuell aktiven gefälschten Tickets ungültig.
• Die zweite Rotation entfernt den vorherigen Hash aus dem DC-Speicher und verhindert die Nutzung von Tickets, die mit dem alten Hash gefälscht wurden.

Verwenden Sie das aktiv gepflegte krbtgt-Reset-Skript, das die Replikationsprüfungen über mehrere DCs hinweg automatisch übernimmt:

# Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 herunterladen und ausführen
# https://github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.md

.\Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -modeOfOperation resetModeKrbTgtProdAccountsResetOnce -targetedADforestFQDN corp.local -targetedADdomainFQDN corp.local -targetKrbTgtAccountScope allRWDCs
# Mindestens 10 Stunden warten (maximale Ticket-Lebensdauer)
.\Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -modeOfOperation resetModeKrbTgtProdAccountsResetOnce -targetedADforestFQDN corp.local -targetedADdomainFQDN corp.local -targetKrbTgtAccountScope allRWDCs

Härtung zur Vermeidung der Erstkompromittierung

DCSync-Exposition prüfen

# Konten mit DCSync-Rechten finden (Nicht-DC-Konten mit Replikationsrechten)
Get-ADObject -Filter * -Properties nTSecurityDescriptor | Where-Object {
    $_.nTSecurityDescriptor.Access | Where-Object {
        $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" -and
        $_.IdentityReference -notmatch "Domain Controllers"
    }
}

Wie EtcSec dies erkennt

EtcSec prüft die Bedingungen, die Golden-Ticket-Angriffe in Ihrer Umgebung möglich und dauerhaft machen.

Die Erkennung GOLDEN_TICKET_RISK markiert Umgebungen, in denen das Passwort des KRBTGT-Kontos nicht kürzlich rotiert wurde – ein direkter Hinweis darauf, dass ein zuvor gefälschtes Golden Ticket noch gültig sein könnte.

Weitere verwandte Prüfungen:

• WEAK_KERBEROS_POLICY – Kerberos-Einstellungen für Ticket-Lebensdauer und -Erneuerung, die das Zeitfenster für gefälschte Tickets verlängern
• KERBEROS_RC4_FALLBACK – RC4-Verschlüsselung, die in der Domäne noch erlaubt ist und zum Fälschen von Tickets mit älteren Tools benötigt wird, was die Erkennung erschwert
• UNCONSTRAINED_DELEGATION – Konten mit uneingeschränkter Delegation, die zum Abfangen von TGTs genutzt werden können, ein häufiger Vorläufer von Golden-Ticket-Angriffen

Prüfprioritäten

Golden-Ticket-Angriff: Die Schlüssel zu Ihrer Domäne sollte als reale Exposition innerhalb Ihrer Active-Directory-Umgebung behandelt werden, nicht als isolierte Einzeleinstellung. Definieren Sie zunächst den Prüfperimeter: welche privilegierten Gruppen, Dienstkonten, ACLs, GPO-Verknüpfungen, Trusts, Delegationseinstellungen, Zertifikatsvorlagen und Admin-Workstations betroffen sind, welche Geschäftsprozesse davon abhängen, welche Rechte dadurch exponiert werden und welche Notfallausnahmen sich im Laufe der Zeit angesammelt haben. Dieser Scoping-Schritt verhindert oberflächliche Remediation, weil das technische Symptom oft kleiner ist als der operative Blast Radius. Indem das Team den vollständigen Pfad von der Konfiguration bis zum Recht dokumentiert, kann es Änderungen priorisieren, die das Risiko schnell reduzieren, ohne den Produktivbetrieb zu unterbrechen. Das schafft zudem eine belastbare Baseline für die spätere Validierung und liefert dem Management eine klare Begründung, warum das Thema jetzt relevant ist.

Benachbarte Kontrollen zur Prüfung

Wenn Angreifer Ihre Active-Directory-Umgebung erreichen, bleiben sie selten beim ersten Schwachpunkt stehen. Rund um Golden-Ticket-Angriff: Die Schlüssel zu Ihrer Domäne testen sie üblicherweise, ob sich der exponierte Pfad mit veralteten privilegierten Konten, unsicherer Gruppenverschachtelung, übermäßiger Delegation, schwachen Passwortrichtlinien, beschreibbaren GPO-Pfaden und geerbtem ACL-Missbrauch verketten lässt. Das bedeutet: Verteidiger sollten nicht nur die Hauptschwachstelle prüfen, sondern jede benachbarte Abhängigkeit, die aus Zugriff Persistenz oder Rechteausweitung macht. Bestätigen Sie, welche Identitäten, Rollen, Berechtigungen und Vertrauensannahmen von einem motivierten Angreifer wiederverwendet werden können. Schließt eine Korrektur nur ein einzelnes Objekt und lässt benachbarte Rechtepfade unangetastet, ändert sich das tatsächliche Risiko kaum. Eine disziplinierte Prüfung solcher Verkettungsmöglichkeiten macht aus diesem Artikelthema eine praktische Härtungsübung statt einer einmaligen Checkbox.

Weiterführende Beiträge

Betrachten Sie dieses Thema gemeinsam mit Kerberos-Delegation: unkontrolliert bis RBCD, Kerberoasting Erkennung Praevention: Wie sich knackbar erscheinende Dienstkonten finden und schützen lassen, ACL-Missbrauch und DCSync: Wie stille Rechte Domain Admin öffnen, AD-Trust-Angriffe: Wie Unterdomänen das Gesamtstruktur-Risiko erhöhen und AS-REP Roasting: Hashes Ohne Anmeldedaten Sammeln. Diese benachbarten Beiträge zeigen, wie dieselben Identitätsschwächen sich in einer echten Bewertung normalerweise gegenseitig verstärken, statt als isolierte Einzelbefunde aufzutreten.

• Kerberos-Delegation: unkontrolliert bis RBCD
• Kerberoasting Erkennung Praevention: Wie sich knackbar erscheinende Dienstkonten finden und schützen lassen
• ACL-Missbrauch und DCSync: Wie stille Rechte Domain Admin öffnen
• AD-Trust-Angriffe: Wie Unterdomänen das Gesamtstruktur-Risiko erhöhen
• AS-REP Roasting: Hashes Ohne Anmeldedaten Sammeln

Diese internen Verweise halten die Remediation-Diskussion auf den vollständigen Angriffspfad fokussiert, statt sich auf eine einzelne Kontrolllücke zu beschränken.

Validierungscheckliste

Führen Sie vor dem Abschluss der Prüfung dieselben Checks erneut aus, die die Schwachstelle aufgedeckt haben, und bestätigen Sie, dass der riskante Pfad aus Angreiferperspektive nicht mehr existiert. Verifizieren Sie die relevanten Identitäten, Rechte, Vererbungspfade und kompensierenden Kontrollen im Produktivsystem, nicht nur in der Staging-Umgebung oder in der Dokumentation. Halten Sie den technischen Verantwortlichen, die erwartete geschäftliche Abhängigkeit und die Nachweise fest, die zeigen, dass die neue Konfiguration sowohl sicherer als auch operativ tragfähig ist. Dieser abschließende Validierungsschritt ist es, der den Artikel in der Realität verankert, wie Teams Identitätsrisiken tatsächlich reduzieren.