Blog

Glitzer Tickets

25.5.2021 | 9 minutes read

In diesem Blogeintrag soll es um zwei bekannte “Angriffe” auf das Kerberos Protokoll gehen. Ich schreib “Angriffe” in Hochkomma, denn obwohl im Zusammenhang von “Golden” und Silver” Ticket häufig von Angriffen auf Kerberos gesprochen wird, so wird hier ledglich eine Information ansgenutzt die ein normaler Nutzer nicht haben sollte. Es wird keine Schwachstelle im eigentlichen Protokoll ausgenutzt.

Bei beiden Angriffen geht es darum Kerberos Ticket zu fälschen. Damit gehören sie zu T1558 (“Steal or Forge Kerberos Tickets”) der Mittre ATT&CK Matrix.

Hintergrund

Wie im Einführungsartikel zu Kerberos beschrieben, benötigt ein Client für den Zugriff auf einen Service ein Service Ticket oder auch TGS (Ticket-Granting Service). Das Ticket bekommt der Client vom Domain Controller wenn er seine Identität mit Hilfe seines Passworts (Zertifikat) nachweisen kann und keine Kerberos-Policy gegen die Ausstellung eines TGT/TGS gibt. Vereinfacht dargestellt ist der Ablauf wie folgt:

Client fragt beim Domain Controller ein TGT (AS-REQ) an. Dafür verschlüsselt der Client einen aktuellen Zeitstempel mit dem Hashwert seines Passworts.
Der Domain Controller holt den Passworthash des Benutzers aus der Datenbank und entschlüsselt damit den Zeitstempel. Ist dieser Ok erzeugt der Domain Controller ein TGT. Das TGT ist eine Datenstruktur, dass die Identität des Benutzers enthält. Zusätzlich erstellt der Domain Controller einen Sitzungschlüssel. Das TGT verschlüsselt der Domain Controller mit dem Passworthash vom Pseudobenutzer KRBTGT. Das TGT sendet der Domain Controller zusammen mit dem für den Client verschlüsselten Sitzungsschlüssel zurück (AS-REP)
Der Client nutzt die Daten und schickt einen TGS Anfrage (TGS-REQ) an den Domain Controller. Dafür verschlüsselt er wieder die aktuelle Uhrzeit, dieses mal mit dem Sitzungschlüssel den er vom Domain Controller bekommen hat und sendet die verschlüsselte Uhrzeit zusammen mit dem TGT an den Domain Controller.
Der Domain Controller entschlüsselt das TGT und liest den Sitzungschlüssel ein. Wenn der Domain Controller mit der Hilfe vom Sitzungschlüssel die Uhrzeit korrekt entschlüsseln kann, erzeugt ein ein TGS. Dazu kopiert er die anderen Daten aus dem TGT und verschlüsselt sie mit dem Passworthash vom Servicekonto des Ziels. Zusätzlich fügt er noch einen weitere Sitzungschlüssel, der ebenfalls für das Zielsystem gedacht ist, ein. Der Gleichzeitig verschlüsselt er den gleichen Sitzungschlüssel nochmal für den Client und schickt alles an den Client zurück.
Der Client nutzt das TGS und den neuen Sitzungschlüssel vom Domain Controller, um Zugriff auf den gewünschten Service anzufragen.
Das Zielsystem entschlüsselt das TGS und erzeugt eine Benutzersitzung.

Aus dem Ablauf ergeben sich einige Vorrausetzungen, die für die korrekte und sichere Arbeitsweise von Kerberos gelten müssen:

Jeder Teilnehmer (Client und Service) im Netzwerk hat ein eigenes Passwort und nur der Domain Controller kennt alle Passwörter.
Nur der Domain Controller kennt das Passwort vom KRBTGT Benutzer und kann TGT erzeugen.
Der Domain Controller kopiert das TGT blind in ein TGS (Stimmt in der Praxis solange das Ticket nicht älter als 20 Minuten ist)
Die Services “glauben” alles was im TGS steht

Hintergrund Golden Ticket

Bei einem Golden Ticket erstellt der Angreifer ein gefälschtes TGT inklusive eines Privileged Attribute Certificate (PAC). Das PAC enthält die Identität des Benutzers und damit seine SID, seine Gruppen und alles was sonst noch im PAC steht. Dies kann ein Angreifer tun, wenn in den Besitz - wie auch immer - vom Passworthash vom KRBTGT Benutzer kommt. Damit kann er Schritt 1 und 2 aus dem oben dargestellten Ablauf übergehen und gleich einen eigenen Sitzungschlüssel und ein TGT erzeugen. Mit den Daten kann er dann direkt die Service Tickets (TGS-REQ) beim Domain Controller anfragen.

Dafür benötigt der Angreifer folgende Daten:

Security Identifier (SID) der Domäne
Name der Domäne
KRBTGT Passwort Hash
Benutzername - egal ob dieser existiert oder nicht

Solange das Ticket nicht älter als 20 Minuten ist, wird der Domain Controller keine Überprüfung durchführen, ob der Benutzer aktiviert ist, geändert wurde oder überhaupt existiert.

Hintergrund Silver Ticket

Bei einem Silver Ticket kennt der Angreifer den Passworthash von einem Service (meist Computerkonto), auf den er gerne Zugreifen würde. Mit der Hilfe des Passworthash erstellt der Angreifer dafür ein eigenes Service Ticket (TGS), inklusive der Benutzeridentität (PAC), die er gerne hätte. Er überspringt damit die Schritte 1 - 4 vom oben dargestellten Ablaufs. Wenn die sogenannte Privilege Attribute Certificate Validation nicht durchgeführt wird, was bei den meisten Operationen aus Performancegründer der Fall ist, so akzeptiert das Zielsystem, das Ticket so wie es ist. Ich habe es in meiner Demo Umgebung nicht geschafft eine PAC Validierung zu aktiveren.

Für ein Silver Ticket benötigt der Angreifer folgende Daten:

Security Identifier (SID) der Domäne
Name der Domäne
Passwort Hash vom Zielsystem
Benutzername - egal ob dieser existiert oder nicht

Auch wenn ich hier die ganze Zeit von einem Zielsystem schreibe, sind damit alle Teilnehmer im Kerberosnetzwerk gemeint, die ein Service Principal Name haben, für die also Kerberos Tickets erzeugt werden können.

Durchführung

Für beide Angriffe gibt es zahlrieche Tools, die es ermöglichen den Angriff durchzuführen. Eine Information die häufig zu beginn fehlt ist die Domänen-Sid. Diese kann beispielsweise mit der Hilfe folgenden Powershell-Einzeiler erhalten werden:

(New-Object Security.Principal.NTAccount krbtgt).Translate([Security.Principal.SecurityIdentifier]).Value

Das funktioniert natürlich nur, wenn ihr bereits auf einem Computer seid, der Mitglied in der Domäne ist.

Ein weitere Punkt der oftmals vergessen wird ist, dass Kerberos auf FQDNs aufbaut. Dies gilt vorallem wenn ihr Lateral Movement von einem Windows System auf das nächste System durchführen wollt. Sprich: wenn ein Ticket erzeugt wird und ihr das Ticket in einen Prozess einfügt, so wird das Ticket nur vom Windows Security Subsystem verwendet, wenn ihr für euer Ziel den FQDN (mindestens den Hostnamen) verwendet. Wenn ihr beispielsweise nach der Erstellung eines Tickets PSEXEC mit der IP-Adresse eures Ziels verwendet, so wird Windows versuchen die Anmeldung über NTLM durchzuführen. Was dann natürlich scheitert.

Golden Ticket

Windows

Mimikatz

Bei Mimikatz muss zum Erstellen von gefälschten Tickets, dass Modul Kerberos mit der Funktion golden verwendet werden. Die Funktion benötigt folgende Parameter:

/domain: Der FQDN der Domäne
/sid: Domänen-SID
/user: Benutzername für das Ticket (Egal ob der Name existiert oder nicht)
/krbtgt: Passworthasch vom Benutzer KRBTGT

Darüberhinaus existieren noch zahlreiche weitere Parameter, die verwendet werden können. Eine (vollständige) Liste finden ihr hier. Ein besonderer Schalter der Funktion, der gerade bei den ersten Gehversuchen immer wieder für Verwirrung sorgt, ist /ptt. Im Gegensatz zu sekrulsa::pth, bei dem ein neues Fenster aufgeht, wird hier das Ticket in den aktuellen Prozess injiziert. Das bedeutet, wenn der Schalter verwendet wird, muss Mimikatz beendet werden und es muss der aktuelle Prozess verwendet werden, um das Ticket zu verwenden. Alternativ könnt ihr auch mit misc::cmd eine neue CMD mit den aktuellen Anmeldedaten starten. Wenn der Schalter nicht verwendet wird, so wird das Ticket in einem KIRBI-File auf die Platte geschrieben.

Ein weitere Tipp den ich euch geben kann ist, dass ich immer den Befehl kerberos::purge verwende, bevor ich ein Ticket erzeuge. Damit verhindert ihr, dass Windows potentiell ein noch vorhandenes Ticket verwendet.

Mimikatz: Golden Ticket

Im Anschluss an die Erstellung vom Golden Ticket, könnt ihr euch jetzt mit den üblichen Methoden wie PSEXEC, WINRM, WMI oder was auch sonst die Windows integrierte Anmeldung unterstützt auf weitere Systeme verbinden. Da der Domain Controller davon ausgeht, dass nur er ein TGT erzeugen kann und solange das TGT noch jung ist, werden die Daten blind übernommen. Das kann beispielsweise beobachtet werden, wann ihr euch die Sitzung auf dem Zielsystem im Bild anschaut. In meiner Testumgebung gibt es weder einen IronMan mit RID 888, noch die Gruppe 666. Dennoch wird beides in die Benutzersitzung auf dem Zielsystem übernommen.

UserID

Gruppe

KerberosRun

Auch KerberosRun bietet die Möglichkeit unter Windows Golden Tickets zu erzeugen.

KerberosRun

Linux

Unter Linux können Kerberos Tickets erzeugt werden. Dafür kommt hier das Tool impacket zum Einsatz. Genauer gesagt kann das das Skript ticketer.py dazu verwendet werden.

impacket:Golden Ticket

Im Anschluss wird der Pfad zum Ticket in die Variable KRB5CCNAME gespeichert. Anschließend kann psexec.py, wmiexec.py oder eines der zahlreichen anderen Skripte aus dem Projekt verwendet werden.

impacket:PSExec