[Anmerkung der Redaktion: Dieser Blog wurde von Andrew Schwartz von TrustedSec mitverfasst. Eines Tages stießen wir beim Durchstöbern von YouTube auf eine Black Hat 2015 Präsentation von Tal Be'ery und Michael Cherny. In ihrem Vortrag und dem anschließenden Briefing Watching the Watchdog: Protecting Kerberos Authentication with Network Monitoring (Schutz der Kerberos-Authentifizierung mit Netzwerküberwachung), stellten Be'ery und Cherny etwas vor, von dem wir noch nie gehört hatten: den Diamond Privilege Attribute Certificate (PAC) Angriff. Wir haben uns beide im letzten Jahr für das Fälschen von Tickets interessiert, so dass diese Technik sofort unsere Aufmerksamkeit erregte und uns auf eine Reise der Untersuchung und PoC-Bewaffnung führte. Das Ergebnis? Das Diamant-Ticket.
Verwandte Lektüre
Goldenes Ticket vs. Diamant-Ticket
Sowohl Golden-Angriffe als auch Diamond Ticket-Angriffe erfordern den Zugriff auf den KRBTGT-Schlüssel. Diamond Ticket-Angriffe erfordern jedoch mit ziemlicher Sicherheit auch Zugriff auf den AES256-Schlüssel. Während Golden-Ticket-Angriffe die Möglichkeit ausnutzen, ein Ticket-Gewährungsticket (TGT) von Grund auf zu fälschen, nutzen Diamond-Ticket-Angriffe die Möglichkeit, echte TGTs, die von einem Domänencontroller (DC) angefordert wurden, zu entschlüsseln und erneut zu verschlüsseln.
Diamant PAC gegen Diamant Ticket
Der ursprüngliche Diamond PAC-Angriff:
- Beantragt einen TGT ohne PAC
- Stellt sicher, dass das Dienstkonto für den Dienst, auf den zugegriffen werden soll, nicht das NA-Bit in seinem Attribut UserAccountControl (UAC) gesetzt hat
- Fälscht ein PAC und signiert es mit dem KRBTGT-Schlüssel
- Injiziert die PAC in das resultierende Service-Ticket, indem es die PAC in die Datei enc_authorization_data Abschnitt der TGS-REQ
Das NA-Bit im UAC-Attribut hat den Wert 33554432 (siehe Abbildung 1).
Nach dem Setzen des NA-Bit im UAC-Attribut eines Servicekontos, haben Service-Ticket-Anfragen an dieses Servicekonto keinen PAC (siehe Abbildung 2).
Immer, wenn Autorisierungsdaten in der Datei enc_authorization_data Abschnitt einer TGS-REQ enthalten sind (siehe Abbildung 3), werden sie in den Abschnitt authorization_data Abschnitt des verschlüsselten Teils des resultierenden Service-Tickets kopiert.
Diamond PAC nutzte dieses Verhalten aus, um ein PAC in das resultierende Dienstticket zu injizieren, wenn das Zieldienstkonto nicht das NA-Bit gesetzt war (siehe Abbildung 4).
Beachten Sie den Größenunterschied in der Ticketausgabe zwischen Abbildung 2 und Abbildung 4.
Wie Abbildung 5 zeigt, gehört das Ticket Loki, aber das PAC hat andere Benutzerinformationen (z.B. Thor).
Dank derKerberos/AD-Patches vom November 2021 ist die Verwendung eines TGT ohne PAC auf ganz aktuellen DCs nicht mehr möglich. Wir wussten also sofort, dass diese Version des Angriffs nicht mehr funktionieren würde. Aber nachdem wir darüber gelesen hatten, fragten wir uns, warum der Angriff so komplex sein musste. Im Zuge der Vereinfachung des Angriffs haben wir die meisten seiner Anforderungen gestrichen, so dass er auf völlig aktuellen DCs möglich ist.
Der KRBTGT-Schlüssel war eine Voraussetzung, und der Angriff nutzte jedes andere gültige Konto, um einen TGT anzufordern. Warum nicht einfach dieses TGT entschlüsseln, es nach Belieben verändern, die PAC-Signaturen neu berechnen und es erneut verschlüsseln? Wir nannten diesen Ansatz einen Diamond Ticket-Angriff.
Bewaffnung von Rubeus
Wir haben unser Diamond Ticket in Rubeus mit einem neuen Befehl implementiert - diamond
-innerhalb dieses PR. In der folgenden Demonstration verwenden wir diesen neuen Befehl, um ein Diamond Ticket zu erstellen und zu verwenden.
Wir beginnen den Angriff, indem wir versuchen, auf die C$ Dateifreigabe (CIFS) auf einem DC zuzugreifen, und zwar mit unserem niedrig privilegierten Benutzer(Loki). Wie Abbildung 6 zeigt, erhalten wir die Antwort Access is denied .
Angenommen, wir haben den KRBTGT-Schlüssel bereits kompromittiert, dann können wir den neuen Befehl diamond verwenden
in Rubeus, um ein Diamond Ticket zu erstellen. Dieser Befehl fordert zunächst ein normales TGT für den niedrigprivilegierten Benutzer Loki an (siehe Abbildung 7). Anschließend entschlüsselt der Befehl das TGT, ändert die relevanten Teile, berechnet die Signaturen neu und verschlüsselt das TGT erneut (siehe Abbildung 8).
Das daraus resultierende Ticket kann dann wie jedes andere TGT verwendet werden, jetzt aber mit Änderungen. Wie Abbildung 9 zeigt, haben wir dann ein Service-Ticket für den CIFS-Dienst auf unserem Ziel-DC(Earth-DC) angefordert.
Schließlich können wir im selben Terminal nun auf die Datei C$ auf dem DC zugreifen, wobei wir uns als ein anderer Benutzer authentifizieren als das Konto, das den TGT angefordert hat (siehe Abbildung 10).
OPSEC Vorteile
Es gibt viele Möglichkeiten, die Verwendung des Goldenen Tickets oder die für den Zugriff auf den KRBTGT-Schlüssel erforderlichen Aktionen (wie DCSync) zu erkennen. Eine Technik: Überwachen Sie auf Service-Ticket-Anfragen (TGS-REQs), die keine entsprechende TGT-Anfrage (AS-REQ) haben. Beachten Sie jedoch, dass die Diamond Ticket-Technik diese Art der Erkennung eher umgeht, indem sie ein gültiges TGT anfordert, bevor sie das resultierende Ticket verwendet. Da das Ticket zunächst von einem DC erstellt wird, ist es außerdem wahrscheinlicher, dass einige Werte (z. B. die Ticketzeiten) standardmäßig korrekt sind, als dass die korrekten Zeiten für die Erstellung des OPSEC Golden Ticket berechnet werden müssen.
Anleitung zur Erkennung
In der ursprünglichen Diamond PAC-Studie wurden die folgenden Hinweise zur netzwerkbasierten Erkennung aufgeführt:
- Eine AS-REQ mit einer PA-PAC-ANFRAGE auf falsch gesetzt
- Das Hinzufügen von Autorisierungsdaten in einer nachfolgenden TGS-Nachricht
- Der Zieldienst NA-Bit auf false gesetzt, was PAC für die Autorisierung erfordert
Angesichts unserer verbesserten Technik gilt dieser Hinweis nicht. Für den Diamond Ticket-Angriff ist es nicht erforderlich, ein TGT ohne PAC anzufordern oder ein gefälschtes PAC innerhalb einer enc_authorization_data Abschnitt einer TGS-REQ oder das Setzen des NA-Bit in einem Servicekonto zu setzen.
Einige Erkennungslogiken für Angriffe auf Goldene Tickets (z. B. die Aktionen, die erforderlich sind, um Zugriff auf den KRBTGT-Schlüssel zu erhalten) könnten jedoch auch für die Erkennung eines Angriffs auf Diamantene Tickets gelten. Viele andere Techniken, die zur Erkennung jeder Art von gefälschten Tickets (Golden, Silver oder Diamond) verwendet werden können, hängen weitgehend von der Sorgfalt ab, die bei der Erstellung des Tickets an den Tag gelegt wird - zum Beispiel, wenn die Ticketzeiten anders als vorgesehen festgelegt werden.
Keine dieser Methoden ist eine Garantie für die Entdeckung dieses Angriffs, so wie es auch keine Silberkugeln für die Entdeckung von Goldenen Eintrittskarten gibt.
Eine neue Sichtweise auf Tickets
Dieser Beitrag hat versucht, eine minimale PoC-Bewaffnung von Diamond Tickets zu demonstrieren, wenn auch eine Implementierung im Stil von Mimikatz. Diese Forschung kann leicht erweitert werden, um die vollständige Kontrolle und Manipulation beliebiger Tickets zu ermöglichen, wenn man die richtigen Schlüssel hat.
Nachdem wir unsere Recherchen abgeschlossen und eine PoC-Waffe erstellt hatten, schickte uns Elad Shamir den Vortrag von Tim Medin von der DerbyCon 2014, Angriff auf Microsoft Kerberos durch Tritte gegen den Wachhund des Hades. In diesem Vortrag erörtert Tim die gleiche Technik im Zusammenhang mit Service-Tickets.
Obwohl unsere Technik eine etwas andere Variante der Goldenen und Silbernen Scheine ist, könnte sie in bestimmten Umgebungen eine nützliche und bevorzugte Alternative darstellen.
