Az - Pass the PRT
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
In the SSO State section, you should see the AzureAdPrt set to YES.
In the same output you can also see if the device is joined to Azure (in the field AzureAdJoined):
The PRT cookie is actually called x-ms-RefreshTokenCredential and it's a JSON Web Token (JWT). A JWT contains 3 parts, the header, payload and signature, divided by a . and all url-safe base64 encoded. A typical PRT cookie contains the following header and body:
The actual Primary Refresh Token (PRT) is encapsulated within the refresh_token, which is encrypted by a key under the control of Azure AD, rendering its contents opaque and undecryptable to us. The field is_primary signifies the encapsulation of the primary refresh token within this token. To ensure that the cookie remains bound to the specific login session it was intended for, the request_nonce is transmitted from the logon.microsoftonline.com page.
The LSASS process will send to the TPM the KDF context, and the TPM will used session key (gathered when the device was registered in AzureAD and stored in the TPM) and the previous context to derivate a key, and this derived key is used to sign the PRT cookie (JWT).
The KDF context is a nonce from AzureAD and the PRT creating a JWT mixed with a context (random bytes).
Therefore, even if the PRT cannot be extracted because it's located inside the TPM, it's possible to abuseLSASS to request derived keys from new contexts and use the generated keys to sign Cookies.
As a regular user it's possible to request PRT usage by asking LSASS for SSO data. This can be done like native apps which request tokens from Web Account Manager (token broker). WAM pasess the request to LSASS, which asks for tokens using signed PRT assertion. Or it can be down with browser based (web) flows where a PRT cookie is used as header to authenticate requests to Azure AS login pages.
As SYSTEM you could steal the PRT if not protected by TPM or interact with PRT keys in LSASS using crypto APIs.
For more info about this way check this post. ROADtoken will run BrowserCore.exe from the right directory and use it to obtain a PRT cookie. This cookie can then be used with ROADtools to authenticate and obtain a persistent refresh token.
To generate a valid PRT cookie the first thing you need is a nonce. You can get this with:
Or using roadrecon:
Then you can use roadtoken to get a new PRT (run in the tool from a process of the user to attack):
As oneliner:
Then you can use the generated cookie to generate tokens to login using Azure AD Graph or Microsoft Graph:
Get-AADIntUserPRTToken gets user’s PRT token from the Azure AD joined or Hybrid joined computer. Uses BrowserCore.exe to get the PRT token.
Or if you have the values from Mimikatz you can also use AADInternals to generate a token:
Go to https://login.microsoftonline.com, clear all cookies for login.microsoftonline.com and enter a new cookie.
Then go to https://portal.azure.com
The rest should be the defaults. Make sure you can refresh the page and the cookie doesn’t disappear, if it does, you may have made a mistake and have to go through the process again. If it doesn’t, you should be good.
The PRT (Primary Refresh Token) is extracted from LSASS (Local Security Authority Subsystem Service) and stored for subsequent use.
The Session Key is extracted next. Given that this key is initially issued and then re-encrypted by the local device, it necessitates decryption using a DPAPI masterkey. Detailed information about DPAPI (Data Protection API) can be found in these resources: HackTricks and for an understanding of its application, refer to Pass-the-cookie attack.
Post decryption of the Session Key, the derived key and context for the PRT are obtained. These are crucial for the creation of the PRT cookie. Specifically, the derived key is employed for signing the JWT (JSON Web Token) that constitutes the cookie. A comprehensive explanation of this process has been provided by Dirk-jan, accessible here.
Note that if the PRT is inside the TPM and not inside lsass mimikatz won't be able to extract it.
However, it will be possible to get a key from a derive key from a context from the TPM and use it to sign a cookie (check option 3).
You can find an in depth explanation of the performed process to extract these details in here: https://dirkjanm.io/digging-further-into-the-primary-refresh-token/
This won't exactly work post August 2021 fixes to get other users PRT tokens as only the user can get his PRT (a local admin cannot access other users PRTs), but can access his.
You can use mimikatz to extract the PRT:
(Images from https://blog.netwrix.com/2023/05/13/pass-the-prt-overview)
Copy the part labeled Prt and save it.
Extract also the session key (the KeyValue of the ProofOfPossesionKey field) which you can see highlighted below. This is encrypted and we will need to use our DPAPI masterkeys to decrypt it.
If you don’t see any PRT data it could be that you don’t have any PRTs because your device isn’t Azure AD joined or it could be you are running an old version of Windows 10.
To decrypt the session key you need to elevate your privileges to SYSTEM to run under the computer context to be able to use the DPAPI masterkey to decrypt it. You can use the following commands to do so:
Now you want to copy both the Context value:
And the derived key value:
Finally you can use all this info to generate PRT cookies:
Go to https://login.microsoftonline.com, clear all cookies for login.microsoftonline.com and enter a new cookie.
Then go to https://portal.azure.com
The rest should be the defaults. Make sure you can refresh the page and the cookie doesn’t disappear, if it does, you may have made a mistake and have to go through the process again. If it doesn’t, you should be good.
Renew the PRT first, which will save it in roadtx.prt:
Now we can request tokens using the interactive browser with roadtx browserprtauth. If we use the roadtx describe command, we see the access token includes an MFA claim because the PRT I used in this case also had an MFA claim.
Having the context and the derived key dumped by mimikatz, it's possible to use roadrecon to generate a new signed cookie with:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
