Az - Pass the PRT
Was ist ein PRT
Az - Primary Refresh Token (PRT)Überprüfen, ob du einen PRT hast
Im Abschnitt SSO State sollte der AzureAdPrt
auf YES gesetzt sein.
Im selben Output können Sie auch sehen, ob das Gerät mit Azure verbunden ist (im Feld AzureAdJoined
):
PRT Cookie
Das PRT-Cookie wird tatsächlich x-ms-RefreshTokenCredential
genannt und ist ein JSON Web Token (JWT). Ein JWT enthält 3 Teile, den Header, Payload und Signatur, getrennt durch einen .
und alle url-sicher base64-codiert. Ein typisches PRT-Cookie enthält den folgenden Header und Body:
Der eigentliche Primary Refresh Token (PRT) ist im refresh_token
gekapselt, der durch einen Schlüssel verschlüsselt ist, der unter der Kontrolle von Azure AD steht, wodurch sein Inhalt für uns undekodierbar und undurchsichtig wird. Das Feld is_primary
kennzeichnet die Kapselung des Primary Refresh Token innerhalb dieses Tokens. Um sicherzustellen, dass das Cookie an die spezifische Anmeldesitzung gebunden bleibt, für die es vorgesehen war, wird der request_nonce
von der Seite logon.microsoftonline.com
übertragen.
PRT-Cookie-Fluss unter Verwendung von TPM
Der LSASS-Prozess sendet den KDF-Kontext an das TPM, und das TPM verwendet den Sitzungsschlüssel (gesammelt, als das Gerät in AzureAD registriert wurde und im TPM gespeichert ist) 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 der PRT, der ein JWT mit einem Kontext (zufällige Bytes) mischt.
Daher ist es, selbst wenn der PRT nicht extrahiert werden kann, weil er sich im TPM befindet, möglich, LSASS zu missbrauchen, um abgeleitete Schlüssel aus neuen Kontexten anzufordern und die generierten Schlüssel zu verwenden, um Cookies zu signieren.
PRT-Missbrauchsszenarien
Als normaler Benutzer ist es möglich, PRT-Nutzung anzufordern, indem man LSASS nach SSO-Daten fragt. Dies kann wie native Apps erfolgen, die Token vom Web Account Manager (Token-Broker) anfordern. WAM leitet die Anfrage an LSASS weiter, das Token unter Verwendung einer signierten PRT-Bestätigung anfordert. Oder es kann mit browserbasierten (Web-) Flows erfolgen, bei denen ein PRT-Cookie als Header verwendet wird, um Anfragen an Azure AS-Anmeldeseiten 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 unter Verwendung von Krypto-APIs interagieren.
Pass-the-PRT-Angriffsszenarien
Angriff - ROADtoken
Für weitere Informationen zu diesem Weg siehe diesen Beitrag. ROADtoken wird BrowserCore.exe
aus dem richtigen Verzeichnis ausführen und 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 zuerst ein Nonce. Dies können Sie mit folgendem Befehl erhalten:
Oder mit roadrecon:
Dann können Sie roadtoken verwenden, um einen neuen PRT zu erhalten (im Tool aus einem Prozess des anzugreifenden Benutzers ausführen):
Als Einzeiler:
Dann können Sie den generierten Cookie verwenden, um Tokens zu generieren, um sich mit Azure AD Graph oder Microsoft Graph anzumelden:
Angriff - Verwendung von roadrecon
Angriff - Verwendung von AADInternals und einem geleakten PRT
Get-AADIntUserPRTToken
holt das PRT-Token des Benutzers vom 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 füge ein neues Cookie ein.
Dann gehe zu https://portal.azure.com
Der Rest sollte die Standardeinstellungen sein. Stellen Sie sicher, dass Sie die Seite aktualisieren können und das Cookie nicht verschwindet. Wenn es verschwindet, haben Sie möglicherweise einen Fehler gemacht und müssen den Prozess erneut durchlaufen. Wenn nicht, sollten Sie in Ordnung sein.
Angriff - Mimikatz
Schritte
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 neu verschlüsselt wird, erfordert dies eine Entschlüsselung mit einem DPAPI-Masterkey. Detaillierte Informationen über 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 Key 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 zum Signieren des JWT (JSON Web Token) verwendet, das das Cookie bildet. Eine umfassende Erklärung dieses Prozesses wurde von Dirk-jan bereitgestellt, zugänglich hier.
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 vom TPM zu erhalten und ihn zu verwenden, um ein Cookie zu signieren (siehe Option 3).
Eine detaillierte Erklärung des durchgeführten Prozesses zur Extraktion dieser Details finden Sie hier: https://dirkjanm.io/digging-further-into-the-primary-refresh-token/
Dies wird nach den Fixes vom August 2021 nicht genau funktionieren, um PRT-Tokens 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 eigenen zugreifen kann.
Sie können mimikatz verwenden, um den PRT zu extrahieren:
(Bilder von 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 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 Privilegien auf SYSTEM erhöhen, um im Computer-Kontext auszuführen und den DPAPI-Masterkey zur Entschlüsselung verwenden zu können. Du kannst die folgenden Befehle verwenden, um dies zu tun:
Option 1 - Full Mimikatz
Jetzt möchten Sie beide Context-Werte kopieren:
Und 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 füge ein neues Cookie ein.
Then go to https://portal.azure.com
Der Rest sollte die Standardeinstellungen sein. Stellen Sie sicher, dass Sie die Seite aktualisieren können und das Cookie nicht verschwindet. Wenn es verschwindet, haben Sie möglicherweise einen Fehler gemacht und müssen den Prozess erneut durchlaufen. Wenn nicht, sollten Sie in Ordnung sein.
Option 2 - roadrecon using PRT
Erneuern Sie zuerst den PRT, der in
roadtx.prt
gespeichert wird:
Jetzt können wir Tokens anfordern mit dem interaktiven Browser mittels
roadtx browserprtauth
. Wenn wir den Befehlroadtx describe
verwenden, sehen wir, dass das Access Token einen MFA-Anspruch enthält, da das in diesem Fall verwendete PRT ebenfalls einen MFA-Anspruch hatte.
Option 3 - roadrecon mit abgeleiteten Schlüsseln
Mit dem Kontext und dem von mimikatz abgeleiteten Schlüssel ist es möglich, roadrecon zu verwenden, um ein neues signiertes Cookie zu generieren mit:
Referenzen
Last updated