Kurzfassung: Golden Ticket (ATT&CK T1558.001) und Silver Ticket (T1558.002) sind gefälschte Kerberos-Tickets. Mit dem gestohlenen krbtgt-Hash fälscht der Angreifer ein TGT für beliebige Identitäten (Golden), mit dem Hash eines Dienstkontos ein Diensticket für einen einzelnen Dienst (Silver). Beide entstehen offline und erzeugen keine normale Anmeldung. Erkennung: Anomalien in 4769 und 4624 ohne vorausgehendes 4768, unmögliche Ticket-Lebensdauern, RC4 wo AES erwartet wird, und beim Silver Ticket ein Dienstzugriff ohne passendes TGT-Ereignis auf dem DC. Die eigentliche Antwort ist, den krbtgt-Hash gar nicht erst preiszugeben und ihn nach Verdacht zweimal zurückzusetzen.
Golden Ticket und Silver Ticket erkennen ist die Fortsetzung von DCSync: Wer den krbtgt-Hash abgezogen hat, kann sich damit Kerberos-Tickets selbst ausstellen und braucht danach keinen Domain Controller und keine Anmeldung mehr, um als beliebiger Benutzer aufzutreten. Das macht diese Technik zur dauerhaftesten Hintertür in Active Directory und zur schwierigsten Erkennung, weil ein gefälschtes Ticket offline entsteht und der Domain Controller es akzeptiert, ohne es ausgestellt zu haben. Dieser Beitrag erklärt beide Ticket-Arten, warum sie so schwer zu fassen sind, welche Anomalien sie trotzdem hinterlassen, eine Erkennungslogik und den Grund, warum die Reaktion bei krbtgt eine Besonderheit hat.
Was der Angreifer tut
Kerberos funktioniert über zwei Ticket-Stufen. Zuerst holt sich ein Benutzer beim Domain Controller ein Ticket Granting Ticket (TGT), das mit dem Passwort-Hash des Sonderkontos krbtgt verschlüsselt ist; danach tauscht er dieses TGT gegen Diensttickets (TGS) für einzelne Dienste. Beide Fälschungen setzen genau an diesen Schlüsseln an. Eine ausführliche Erklärung des Ticket-Flusses steht unter Kerberos verstehen.
- Golden Ticket (T1558.001). Mit dem krbtgt-Hash, den der Angreifer per DCSync oder vom Domain Controller geholt hat, fälscht er ein komplettes TGT: beliebiger Benutzername, beliebige Gruppenmitgliedschaften, beliebige Lebensdauer. Weil das TGT mit dem echten krbtgt-Schlüssel signiert ist, akzeptiert es jeder Domain Controller. Der Angreifer ist damit jeder, den er sein will, inklusive Domain-Admin, und bleibt es, bis krbtgt zurückgesetzt wird.
- Silver Ticket (T1558.002). Mit dem Hash eines einzelnen Dienstkontos oder Computerkontos fälscht der Angreifer direkt ein Diensticket für genau diesen einen Dienst, ohne den Domain Controller überhaupt zu kontaktieren. Das ist leiser als das Golden Ticket, weil es keine TGT-Anforderung gibt, aber begrenzt auf den Dienst, dessen Hash er hat.
Werkzeug ist meist Mimikatz oder Impacket. In MITRE ATT&CK stehen beide unter Steal or Forge Kerberos Tickets. Der gemeinsame Nenner: Das Ticket entsteht auf dem Rechner des Angreifers, nicht auf dem Domain Controller, und deshalb fehlt die Spur, die eine echte Ausstellung hinterlassen würde.
Warum die Erkennung schwer ist
Bei einer echten Anmeldung entsteht auf dem Domain Controller zuerst ein 4768 (TGT ausgestellt), dann bei jedem Dienstzugriff ein 4769 (Diensticket ausgestellt), und auf dem Ziel ein 4624 (Anmeldung). Ein Golden Ticket überspringt das 4768, weil das TGT nicht angefordert, sondern gefälscht wurde; ein Silver Ticket überspringt sogar 4768 und 4769, weil weder TGT noch TGS beim Domain Controller angefordert werden. Auf dem Zielserver erscheint trotzdem ein 4624, weil dort eine Sitzung entsteht. Genau diese fehlenden Vorstufen sind das Erkennungsprinzip: eine Ticket-Nutzung ohne die Ausstellungsereignisse, die ihr vorausgehen müssten. Das ist schwer zu messen, weil es das Zusammenführen von Ereignissen über mehrere Systeme verlangt, aber es ist die verlässlichste Spur.
Welche Anomalien bleiben
| Anomalie | Quelle | Was sie verrät |
|---|---|---|
| 4624 ohne vorheriges 4768 | Ziel und Domain Controller, Security-Log | Eine Anmeldung mit einem TGT, das der DC nie ausgestellt hat: das Kennzeichen des Golden Ticket. Verlangt den Abgleich über beide Systeme. |
| 4769 ohne passendes 4768 | Domain Controller | Ein Diensticket wird auf Basis eines TGT angefordert, das nie ausgestellt wurde. |
| Unmögliche Ticket-Lebensdauer | Kerberos-Ereignisse | Standard-TGTs leben zehn Stunden. Mimikatz setzte früher oft zehn Jahre; auffällig ist jede Lebensdauer, die von der Domain-Richtlinie abweicht. |
| RC4, wo AES erwartet wird | 4768, 4769 | Gefälschte Tickets nutzen häufig RC4 (0x17), während die Umgebung längst AES verwendet. |
| Ungereimte Kontodaten | 4627, 4624 | Ein Benutzername, den es nicht gibt, oder Gruppenmitgliedschaften im Ticket, die nicht zum Konto passen: beim Golden Ticket frei erfunden. |
| Dienstzugriff ohne DC-Kontakt | Zielserver gegen Domain Controller | Beim Silver Ticket ein 4624 oder Dienstzugriff auf einem Server, ohne dass der Domain Controller ein passendes 4769 für diese Sitzung zeigt. |
Kein einzelnes dieser Signale ist für sich beweisend, weil es harmlose Ursachen gibt; in Kombination und mit dem Abgleich über Systeme werden sie tragfähig. Die Details zu den Kerberos-Ereignissen stehen in der Referenz zu den Event-IDs.
Erkennungslogik
Die wirksamste Erkennung ist die Korrelation der Ausstellungs- und Nutzungsereignisse. In Worten: Sammle pro Konto und Sitzung die 4768-, 4769- und 4624-Ereignisse über Domain Controller und Zielserver und suche nach Nutzungen ohne die zugehörige Ausstellung. Eine Skizze in Kusto-Syntax für den einfacheren Fall, ein 4769 ohne vorheriges 4768 desselben Kontos im TGT-Lebenszeitfenster:
let tgt = SecurityEvent
| where EventID == 4768
| project Account = TargetUserName, TgtZeit = TimeGenerated;
SecurityEvent
| where EventID == 4769
| project Account = TargetUserName, TgsZeit = TimeGenerated, ServiceName
| join kind=leftouter tgt on Account
| where isempty(TgtZeit) or TgtZeit > TgsZeit or TgsZeit - TgtZeit > 10h
| project Account, ServiceName, TgsZeit, TgtZeitDiese Skizze zeigt das Prinzip, ist aber in der Praxis anspruchsvoll: TGT-Ereignisse können aus Zeitgründen fehlen, Konten haben viele Tickets, und das Zusammenführen über alle Domain Controller ist Voraussetzung. Deshalb ist die realistische Erkennung ein Baukasten aus einfacheren Regeln, die zusammen wirken: eine Regel auf TGTs oder TGS mit RC4, wo die Umgebung AES nutzt; eine auf Ticket-Lebensdauern jenseits der Domain-Richtlinie; eine auf Anmeldungen mit Konten, die nicht existieren; und für das Silver Ticket der Abgleich, ob zu einer Dienstsitzung auf einem Server ein 4769 auf dem Domain Controller existiert. Fertige, gepflegte Regeln für diese Muster liefern die Community-Sammlung und die Sentinel-Vorlagen; wie aus einer Idee eine dauerhafte Regel wird, steht im Beitrag zu Sigma-Regeln. Ein guter Teil dieser Erkennung liefert außerdem ein EDR mit Kerberos-Analyse oder ein spezialisiertes AD-Monitoring, das den Ticket-Fluss versteht.
Der Test
Beide Techniken lassen sich im Homelab nachstellen, gehören aber ausschließlich dorthin, weil sie mit echten Hashes arbeiten. Atomic Red Team hat für T1558.001 und T1558.002 Tests, die mit Mimikatz ein Golden beziehungsweise Silver Ticket erzeugen und nutzen. Vorbereitung ist beim Golden Ticket der krbtgt-Hash aus dem Lab-Domain-Controller, beim Silver Ticket der Hash eines Dienstkontos. Nach der Nutzung wird geprüft, ob die Anmeldung auf dem Ziel als 4624 erscheint, ohne dass auf dem Domain Controller die passende Ausstellung steht, und ob die Regeln auf RC4 und Lebensdauer greifen. Weil dieser Test den gefährlichsten Persistenzweg nachbildet, gehört er in die regelmäßige Purple-Team-Übung, und das Lab wird danach aus dem Snapshot zurückgesetzt.
Reaktion und Gegenmaßnahme: der krbtgt-Doppelreset
Die Reaktion auf ein Golden Ticket hat eine Besonderheit, die man kennen muss: Ein Golden Ticket bleibt gültig, solange der krbtgt-Hash gültig ist, und dieser ändert sich nur durch das Zurücksetzen des krbtgt-Passworts. Wegen der Art, wie Active Directory die aktuelle und die vorherige Passwortversion parallel akzeptiert, muss krbtgt zweimal zurückgesetzt werden, mit genügend Abstand für die Replikation dazwischen, um beide Versionen zu invalidieren. Ein einmaliges Zurücksetzen lässt gefälschte Tickets weiter funktionieren. Microsoft stellt dafür ein Skript bereit, und der Doppelreset gehört in jedes Playbook für einen Active-Directory-Vollkompromiss, wie ihn der Beitrag zu DCSync beschreibt. Beim Silver Ticket genügt das Zurücksetzen des betroffenen Dienst- oder Computerkontos. Und die beste Gegenmaßnahme ist die vorgelagerte: Wenn der krbtgt-Hash nie abfließt, gibt es kein Golden Ticket, weshalb der Schutz der privilegierten Konten und die Erkennung von Pass-the-Hash und DCSync die eigentliche Verteidigungslinie sind.
Fazit
Golden und Silver Ticket sind das Ende der Angriffskette in Active Directory: Wer sie einsetzt, hat die Schlüssel bereits und macht sich damit zur beliebigen Identität. Die Erkennung ist schwer, weil das Ticket offline entsteht, aber nicht unmöglich, denn die fehlenden Ausstellungsereignisse, RC4 statt AES und unmögliche Lebensdauern bleiben als Spuren. Wer diese Signale korreliert und den krbtgt-Doppelreset im Playbook hat, kann den Angriff erkennen und beenden. Am wichtigsten aber ist, es gar nicht so weit kommen zu lassen: Golden Ticket ist die Quittung für einen bereits verlorenen krbtgt-Hash, und deshalb liegt die Verteidigung für ein Blue Team vor allem in den Techniken davor.