Az - Pass the PRT
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Im Abschnitt SSO-Status sollten Sie sehen, dass AzureAdPrt
auf JA gesetzt ist.
In der gleichen Ausgabe können Sie auch sehen, ob das Gerät mit Azure verbunden ist (im Feld AzureAdJoined
):
Das PRT-Cookie wird tatsächlich x-ms-RefreshTokenCredential
genannt und es ist ein JSON Web Token (JWT). Ein JWT enthält 3 Teile, den Header, Payload und Signature, die durch einen .
getrennt und alle url-sicher base64-kodiert sind. Ein typisches PRT-Cookie enthält den folgenden Header und Body:
Der tatsächliche Primary Refresh Token (PRT) ist in dem refresh_token
eingekapselt, das durch einen Schlüssel, der unter der Kontrolle von Azure AD steht, verschlüsselt ist, wodurch sein Inhalt für uns undurchsichtig und nicht entschlüsselbar wird. Das Feld is_primary
kennzeichnet die Einkapselung des primären Refresh-Tokens innerhalb dieses Tokens. Um sicherzustellen, dass das Cookie an die spezifische Anmeldesitzung gebunden bleibt, für die es bestimmt ist, wird der request_nonce
von der Seite logon.microsoftonline.com
übertragen.
Der LSASS-Prozess sendet den KDF-Kontext an das TPM, und das TPM verwendet den Sitzungsschlüssel (der beim Registrieren des Geräts in AzureAD gesammelt und im TPM gespeichert wurde) und den vorherigen Kontext, um einen Schlüssel abzuleiten, und dieser abgeleitete Schlüssel wird verwendet, um das PRT-Cookie (JWT) zu signieren.
Der KDF-Kontext ist ein Nonce von AzureAD und dem PRT, das ein JWT gemischt mit einem Kontext (Zufallsbytes) erstellt.
Daher, selbst wenn der PRT nicht extrahiert werden kann, weil er sich im TPM befindet, ist es möglich, LSASS zu missbrauchen, um abgeleitete Schlüssel aus neuen Kontexten anzufordern und die generierten Schlüssel zu verwenden, um Cookies zu signieren.
Als normaler Benutzer ist es möglich, PRT-Nutzung anzufordern, indem man LSASS nach SSO-Daten fragt. Dies kann wie bei nativem Apps geschehen, die Tokens vom Web Account Manager (Token-Broker) anfordern. WAM leitet die Anfrage an LSASS weiter, das Tokens mit einer signierten PRT-Assertion anfordert. Oder es kann mit browserbasierten (Web-)Flows geschehen, bei denen ein PRT-Cookie als Header verwendet wird, um Anfragen an die Anmeldeseiten von Azure AS zu authentifizieren.
Als SYSTEM könnten Sie den PRT stehlen, wenn er nicht durch TPM geschützt ist oder mit PRT-Schlüsseln in LSASS interagieren, indem Sie Krypto-APIs verwenden.
Für weitere Informationen zu diesem Weg prüfen Sie diesen Beitrag. ROADtoken wird BrowserCore.exe
aus dem richtigen Verzeichnis ausführen und es verwenden, um ein PRT-Cookie zu erhalten. Dieses Cookie kann dann mit ROADtools verwendet werden, um sich zu authentifizieren und einen persistenten Refresh-Token zu erhalten.
Um ein gültiges PRT-Cookie zu generieren, benötigen Sie zunächst ein Nonce. Sie können dies mit:
Oder mit roadrecon:
Dann können Sie roadtoken verwenden, um ein neues PRT zu erhalten (führen Sie das Tool aus einem Prozess des Benutzers aus, um anzugreifen):
Dann können Sie das generierte Cookie verwenden, um Tokens zu generieren, um sich mit Azure AD Graph oder Microsoft Graph anzumelden:
Get-AADIntUserPRTToken
holt das PRT-Token des Benutzers von dem Azure AD-verbundenen oder Hybrid-verbundenen Computer. Verwendet BrowserCore.exe
, um das PRT-Token zu erhalten.
Oder wenn Sie die Werte von Mimikatz haben, können Sie auch AADInternals verwenden, um ein Token zu generieren:
Gehe zu https://login.microsoftonline.com, lösche alle Cookies für login.microsoftonline.com und gib ein neues Cookie ein.
Dann gehen Sie zu https://portal.azure.com
Der Rest sollte die Standardwerte sein. Stellen Sie sicher, dass Sie die Seite aktualisieren können und das Cookie nicht verschwindet. Wenn es das tut, haben Sie möglicherweise einen Fehler gemacht und müssen den Prozess erneut durchlaufen. Wenn nicht, sollten Sie in Ordnung sein.
Der PRT (Primary Refresh Token) wird aus LSASS (Local Security Authority Subsystem Service) extrahiert und für die spätere Verwendung gespeichert.
Der Session Key wird als nächstes extrahiert. Da dieser Schlüssel zunächst ausgegeben und dann vom lokalen Gerät erneut verschlüsselt wird, ist eine Entschlüsselung mit einem DPAPI-Masterkey erforderlich. Detaillierte Informationen zu DPAPI (Data Protection API) finden Sie in diesen Ressourcen: HackTricks und für ein Verständnis seiner Anwendung, siehe Pass-the-cookie attack.
Nach der Entschlüsselung des Session Keys werden der abgeleitete Schlüssel und der Kontext für den PRT erhalten. Diese sind entscheidend für die Erstellung des PRT-Cookies. Insbesondere wird der abgeleitete Schlüssel verwendet, um das JWT (JSON Web Token), das das Cookie bildet, zu signieren. Eine umfassende Erklärung dieses Prozesses wurde von Dirk-jan bereitgestellt und ist hier zugänglich.
Beachten Sie, dass, wenn der PRT im TPM und nicht in lsass
ist, mimikatz ihn nicht extrahieren kann.
Es wird jedoch möglich sein, einen Schlüssel aus einem abgeleiteten Schlüssel aus einem Kontext aus dem TPM zu erhalten und ihn zu signieren (siehe Option 3).
Sie finden eine detaillierte Erklärung des durchgeführten Prozesses, um diese Details hier zu extrahieren: https://dirkjanm.io/digging-further-into-the-primary-refresh-token/
Dies wird nach den Korrekturen im August 2021 nicht genau funktionieren, um die PRT-Token anderer Benutzer zu erhalten, da nur der Benutzer seinen PRT erhalten kann (ein lokaler Administrator kann nicht auf die PRTs anderer Benutzer zugreifen), aber auf seinen zugreifen kann.
Sie können mimikatz verwenden, um den PRT zu extrahieren:
(Images from https://blog.netwrix.com/2023/05/13/pass-the-prt-overview)
Kopiere den Teil, der mit Prt gekennzeichnet ist, und speichere ihn.
Extrahiere auch den Sitzungsschlüssel (den KeyValue
des ProofOfPossesionKey
-Feldes), den du unten hervorgehoben sehen kannst. Dieser ist verschlüsselt und wir müssen unsere DPAPI-Masterkeys verwenden, um ihn zu entschlüsseln.
Wenn du keine PRT-Daten siehst, könnte es sein, dass du keine PRTs hast, weil dein Gerät nicht mit Azure AD verbunden ist, oder es könnte sein, dass du eine alte Version von Windows 10 verwendest.
Um den Sitzungsschlüssel zu entschlüsseln, musst du deine Berechtigungen auf SYSTEM erhöhen, um im Computer-Kontext zu arbeiten, damit du den DPAPI-Masterkey zur Entschlüsselung verwenden kannst. Du kannst die folgenden Befehle verwenden, um dies zu tun:
Jetzt möchten Sie sowohl den Kontextwert kopieren:
Als auch den abgeleiteten Schlüsselwert:
Schließlich können Sie all diese Informationen verwenden, um PRT-Cookies zu generieren:
Gehe zu https://login.microsoftonline.com, lösche alle Cookies für login.microsoftonline.com und gib ein neues Cookie ein.
Gehe dann zu https://portal.azure.com
Der Rest sollte die Standardwerte sein. Stelle sicher, dass du die Seite aktualisieren kannst und das Cookie nicht verschwindet. Wenn es verschwindet, hast du möglicherweise einen Fehler gemacht und musst den Prozess erneut durchlaufen. Wenn nicht, solltest du in Ordnung sein.
Erneuere zuerst das PRT, das in roadtx.prt
gespeichert wird:
Jetzt können wir Token anfordern mit dem interaktiven Browser mit roadtx browserprtauth
. Wenn wir den Befehl roadtx describe
verwenden, sehen wir, dass das Zugriffstoken einen MFA-Anspruch enthält, da der PRT, den ich in diesem Fall verwendet habe, ebenfalls einen MFA-Anspruch hatte.
Mit dem Kontext und dem von mimikatz ausgegebenen abgeleiteten Schlüssel ist es möglich, roadrecon zu verwenden, um ein neues signiertes Cookie zu generieren mit:
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)