Avec la généralisation des environnements hybrides et du modèle Zero Trust, Microsoft Entra ID (ex Azure AD) s’est imposé comme un composant central de l’authentification moderne. Pour offrir une expérience fluide aux utilisateurs tout en maintenant un niveau de sécurité élevé, Microsoft s’appuie sur un mécanisme clé : le Primary Refresh Token (PRT).
Présent sur les postes ou enregistrés auprès d’Entra ID, le PRT joue un rôle essentiel dans le Single Sign-On (SSO) et l’accès aux ressources cloud de l’entreprise. De fait, son importance dans la chaîne d’authentification en fait une cible intéressante pour des attaquants.
Dans cet article, nous reviendrons sur le fonctionnement du Primary Refresh Token, son rôle au sein de l’écosystème Microsoft, ainsi que les implications de sécurité associées à son utilisation. Nous aborderons également les principales approches d’exploitation connues et les mesures permettant de réduire les risques associés.
Le Primary Refresh Token (PRT) est un composant central du mécanisme d’authentification de Microsoft Entra ID. Délivré à un utilisateur sur un appareil de confiance, il permet de maintenir une expérience de Single Sign-On (SSO) transparente vers les applications et services fédérés à Entra ID.
Concrètement, grâce au PRT, un utilisateur connecté à son poste peut accéder à des services tels qu’Outlook, Teams, SharePoint ou encore au portail Azure sans avoir à saisir à nouveau ses identifiants à chaque authentification.
Pour les environnements Microsoft modernes, le PRT joue un rôle comparable à celui du Ticket Granting Ticket (TGT) dans un environnement Active Directory traditionnel : il constitue le point de départ permettant d’obtenir les jetons nécessaires à l’accès aux différentes ressources de l’entreprise.
Cette position centrale dans la chaîne d’authentification en fait également une cible particulièrement attractive pour un attaquant ayant compromis un poste utilisateur. La capacité à exploiter ou détourner un PRT peut, selon le contexte, permettre d’accéder à de nombreuses ressources protégées par l’écosystème d’authentification Microsoft.
Comprendre les scénarios d’exploitation nécessite toutefois de maîtriser plusieurs mécanismes internes du PRT. Avant d’aborder les techniques d’exploitation, nous allons donc détailler les différents composants impliqués dans son obtention, son stockage et son utilisation.
Le tableau suivant présente les principaux termes qui seront utilisés tout au long de cet article.
| Acronyme / Terme | Rôle |
| PRT (Primary Refresh Token) | Jeton d’authentification délivré par Entra ID à un utilisateur sur un appareil de confiance. Il permet d’obtenir de nouveaux jetons d’accès sans réauthentification interactive. |
| Session Key | Clé cryptographique symétrique associée au PRT. Elle sert à prouver la légitimité de son utilisation et à protéger certains échanges avec Entra ID. |
| WAM (Web Account Manager) | Courtier d’authentification Windows utilisé par les applications pour demander et obtenir des jetons auprès d’Entra ID. |
| CloudAP (Cloud Auth Provider) | Composant d’authentification Windows chargé de gérer les secrets liés à Entra ID et d’interagir avec le TPM. |
| LSASS | Processus système Windows hébergeant plusieurs mécanismes d’authentification et les composants de sécurité associés, dont CloudAP. |
| TPM (Trusted Platform Module) | Composant matériel sécurisé utilisé pour protéger certaines clés cryptographiques et empêcher leur exportation hors de la machine. |
L’acquisition du PRT est un processus de bas niveau orchestré par le système d’exploitation dès l’ouverture de session (Windows Logon).
lsass.exe. Si le PRT est opaque, la Session Key, elle, est protégée par la DPAPI système. Dans un scénario sécurisé (Hybrid Join ou Entra Joined), la partie privée de cette clé est liée cryptographiquement au TPM de la machine.Le PRT possède une validité « roulante » de 14 jours, renouvelée en continu tant que l’appareil est utilisé. Son utilisation est déléguée au Web Account Manager (WAM), le courtier de jetons de Windows, selon deux modes distincts :
BrowserCore.exe ou nativement) qui génère un dérivé temporaire appelé PRT Cookie (ou x-ms-RefreshTokenCredential). Ce cookie est un JWT signé à courte durée de vie, injecté dans les en-têtes HTTP pour initialiser la session web. C’est souvent ce cookie, plus facile à générer que d’extraire le PRT maître, qui est la cible privilégiée des attaquants.Pour les experts de l’Active Directory (On-Premise), le PRT est l’équivalent strict du TGT (Ticket Granting Ticket) Kerberos : une « preuve mère » acquise au login permettant de demander des tickets de service ultérieurs.
Cependant, une différence structurelle change la donne pour le mouvement latéral :
Cette fusion est cruciale : voler un PRT (ou en abuser sur place) permet non seulement d’usurper l’utilisateur, mais aussi de « voler » l’état de conformité de la machine (Device Claims : Managed, Compliant). C’est l’unique vecteur permettant de contourner les politiques d’Accès Conditionnel qui bloqueraient une simple utilisation de mot de passe volé depuis une machine attaquante non gérée.
Pourquoi le PRT est-il devenu la cible numéro un des attaquants sur les postes de travail modernes ? La réponse tient en un mot : Pivot.
Historiquement, compromettre un poste permettait de chasser des hashes ou des tickets Kerberos pour se déplacer latéralement sur le réseau local (On-Prem). Aujourd’hui, avec l’hybridation, l’accès initial à une machine compromise offre, via le PRT, un accès direct et transparent à l’identité numérique de l’utilisateur dans le Cloud.
Concrètement, cela signifie qu’un malware ou un attaquant physique peut transformer un accès local en un accès global au tenant Microsoft de l’entreprise (Outlook, SharePoint, Azure Portal), le tout en contournant le MFA (puisque le PRT est une preuve de Strong Auth déjà validée).
Afin d’évaluer les avantages et limites des différentes techniques présentées dans cette section, nous considérerons deux contextes opérationnels distincts.
Cette technique consiste à extraire le blob du PRT ainsi que la Session Key déchiffrée depuis la mémoire de LSASS pour les emporter sur la machine de l’attaquant. Une fois exfiltrés, ces éléments sont utilisés avec un outil comme roadtx (de la suite ROADtools) pour obtenir des tokens d’accès depuis l’extérieur.
Sur la machine de la victime, l’attaquant peut utiliser mimikatz depuis un environnement privilégié pour dumper et parser la mémoire du module CloudAP.
mimikatz.exe "privilege::debug" "sekurlsa::cloudap" "exit"
Cela permet d’obtenir le PRT ainsi que la Session Key (ProofOfPossesionKe.Keyvalue) associée.
La valeur de la Session Key obtenue est chiffrée par DPAPI, il est nécessaire de la déchiffrer afin d’obtenir réellement le couple PRT / Session key convoité.
mimikatz.exe "token::elevate" "Dpapi::cloudapkd /keyvalue:<KeyValue> /unprotect" "exit"
Maintenant que ces deux éléments ont été collectés, il n’est plus nécessaire d’interagir avec la victime. Depuis n’importe quelle machine, roadtx peut être utilisé pour obtenir des tokens pour les ressources Azure souhaitée. Dans l’exemple suivant, le PRT et la Session Key sont utilisés pour obtenir un Access Token valide pour graph.microsoft.com.
roadtx gettokens --prt <PRT> --prt-sessionkey <Session Key> --resource https://graph.microsoft.com/
Le token obtenu peut être utilisé tel quel pour accéder au compte Microsoft de la victime.
Le PRT pourrait aussi être utilisé pour générer un “PRT cookie” permettant de se connecter aux applications Microsoft depuis un navigateur.
Avantages et inconvénient de la méthode :
Cette méthode est excellente d’un point de vue pédagogique, elle permet de comprendre toutes les clés du fonctionnement des PRT et elle est la plus directe d’un point de vue méthodologique : l’attaquant va droit au but et extrait directement le PRT et sa Session Key pour les utiliser par la suite.
Le grand intérêt est que le PRT volé est valable 14 jours, et peut être renouvelé grâce à la Session Key afin d’étendre cette durée.
Note : La documentation de Microsoft indique que lors du renouvellement d’un PRT, une nouvelle Session Key est générée, et est transmise après avoir été chiffrée avec une “Transport Key” (ce qui devrait empêcher de renouveler le PRT sans avoir cette dernière). Cependant dans la pratique, on observe via des outils comme roadtx que le renouvellement simple conserve souvent la même Session Key (voir image ci-dessous). Cela permet à un attaquant possédant le PRT et la Session Key de maintenir son accès très longtemps sans avoir besoin de la Transport Key, tant que Microsoft ne force pas une rotation cryptographique complète des clés.
Le premier inconvénient majeur de cette méthode est qu’elle repose sur le fait d’être capable d’extraire la Session Key. Or, dans l’immense majorité des cas, la machine cible est équipée d’un TPM, qui empêche d’accéder à cette dernière. Si un attaquant tente d’utiliser Mimikatz sur une machine équipée d’un TPM, le PRT sera bien extrait, mais le champ KeyValue ne contiendra pas la clé privée nécessaire. Il contiendra un handle ou une référence opaque.
Le second inconvénient concerne la “discretion” de l’attaque. En effet, sans parler de l’outil mimikatz dont la signature est connue de tous les EDR, le fait de dumper la mémoire de LSASS est extrêmement bruyant et a donc de forte chance d’être détecté.
Enfin, cette méthode nécessite d’avoir un accès administrateur à la machine, ce qui peut un point bloquant selon les scénarios.
Cette méthode ne convient donc que dans certains cas très spécifique. Elle conviendrait par exemple dans le cadre improbable d’un audit sur une machine ne possédant pas de TPM.
Comme évoqué précédemment, la présence d’un TPM rend la « Session Key » principale inexploitable, car elle est scellée matériellement. Pour contourner cette limitation sans abandonner l’idée d’exfiltrer les données, il faut s’intéresser à la mécanique interne de génération des tokens.
Pour éviter de solliciter la puce TPM (une opération lente) à chaque requête web, le processus CloudAP génère une clé intermédiaire appelée Derived Key. Cette clé, calculée à partir de la Session Key (TPM) et d’un Context aléatoire, est stockée en clair dans la mémoire de LSASS pour signer rapidement les demandes de « PRT Cookies ».
L’attaque consiste donc à voler ce trio : PRT (Cookie) + Context + Derived Key.
Note : L’attaque présentée dans cette partie n’est plus possible depuis l’introduction de KDFv2 en 2021.
Sur la machine victime, l’attaquant procède de la même manière que précédemment en dumpant la mémoire de CloudAP via Mimikatz. Cependant, il ne cherche plus la Session Key principale (qui est protégée par le TPM), mais les champs spécifiques au contexte dérivé.
En reprenant l’exemple présenté en fin de partie précédente, où le TPM empêchait d’obtenir la clé souhaitée, on constate que le contexte et la Derived Key associée restent parfaitement accessibles en clair.
Depuis la machine de la victime, l’attaquant extrait aussi un premier PRT Cookie (voir partie suivante).
Concrètement, ce cookie PRT prend la forme d’un JWT standard regroupant trois éléments clés : le PRT lui-même, un nonce qui rattache le cookie à la tentative d’authentification en cours, et le contexte ayant servi à générer la Derived Key pour signer le jeton.
Exemple de PRT cookie :
À la réception, EntraID vérifie d’abord que le nonce correspond au challenge émis lors de l’initialisation. Il déchiffre ensuite le PRT pour en extraire la Session Key associée. En combinant cette dernière avec le contexte présent dans le cookie, le service est alors capable de recalculer la Derived Key et de valider la signature du JWT, garantissant ainsi que l’émetteur détient bien le PRT légitime.
On obtient donc à ce moment les trois éléments cruciaux :
Une fois ces éléments exfiltrés, l’attaquant peut utiliser roadrecon sur sa propre machine pour générer de nouveaux cookies PRT à la volée.
Note : C’est cette étape qu’il n’est plus possible d’effectuer depuis la mise en place de KDFv2 (Key Derivation Function Version 2). En effet cette nouvelle fonction de dérivation génère la Derived Key en fonction d’un contexte, mais aussi de l’ensemble du body du JWT, ce qui empêche l’exfiltration d’une Derived Key dans l’optique de la réutiliser plus tard.
roadrecon auth --prt-cookie <old_prt_cookie> --prt-context <context> --derived-key <derived-key>>Cette commande modifie le payload JWT du premier cookie PRT (qui expire rapidement) et re-signe ce dernier pour qu’il “paraisse” authentique.
Ce cookie peut ensuite être utilisé dans un navigateur (au moment de l’authentification Microsoft) pour accéder aux ressources Microsoft de la victime.
Après avoir ajouté le cookie, il suffit à l’attaquant de recharger la page d’authentification pour accéder au compte de la victime.
Avantages et inconvénients de la méthode :
Cette technique est nettement plus robuste que la précédente, car elle est compatible avec la présence d’un TPM, équipement standard sur la quasi-totalité des ordinateurs récents. Elle permet à l’attaquant de « ramener » l’identité de la victime chez lui et de l’utiliser de manière autonome.
Tant que le PRT principal est valide (jusqu’à 14 jours) et que le contexte n’est pas invalidé côté serveur, l’attaquant peut générer de nouveaux cookies à volonté depuis sa machine.
Cette méthode est donc plus réaliste que la précédente dans le cadre d’un audit où la discrétion n’est pas un objectif. Cependant, elle partage les mêmes défauts majeurs en termes d’OPSEC. Elle nécessite toujours des privilèges d’administrateur sur la machine victime et implique l’utilisation de Mimikatz (ou d’un dump mémoire manuel) sur le processus critique lsass.exe.
C’est une action extrêmement « bruyante » : la quasi-totalité des EDR modernes bloquera l’accès à LSASS ou détectera la signature de l’outil, ce qui rend cette méthode difficilement applicable lors d’une mission Red Team discrète face à une surveillance active.
Les deux méthodes précédentes reposaient sur une approche « brutale” : extraire les secrets cryptographiques (Clés et PRT) de la mémoire de lsass.exe. Bien qu’intuitives et extrêmement puissantes, elles se heurtent aujourd’hui à de multiples sécurités comme les TPM, KDFv2 ou même PPL (Protected Process Light) et la surveillance comportementale des EDR qui interdisent l’accès à ce processus critique.
Pour contourner ces protections, l’approche moderne consiste à adopter une stratégie « Living Off the Land » (LotL). Au lieu de tenter de voler la clé (ce qui est interdit), nous allons simplement demander au système d’exploitation de l’utiliser pour nous (ce qui est légitime).
Le concept est simple : Windows possède des API natives (COM) utilisées par les navigateurs (Edge, Chrome) pour demander un SSO. L’attaquant peut invoquer ces mêmes API pour demander la génération d’un cookie valide, sans jamais toucher à LSASS ni connaître les clés de chiffrement.
Pour illustrer cette technique, nous utiliserons RoadToken, un PoC développé par Dirk-jan Mollema. Il simule le comportement de l’extension Chrome officielle « Windows Accounts » en interagissant directement avec le binaire BrowserCore de Windows.
Contrairement aux attaques précédentes qui nécessitent des droits administrateur, cette attaque peut s’exécuter dans le contexte de l’utilisateur courant, ce qui réduit considérablement la surface d’attaque nécessaire.
L’attaquant doit d’abord obtenir un nonce, un challenge délivré par Microsoft qui doit être intégré au cookie PRT.
roadrecon auth --prt-init
Ensuite, depuis la machine cible (ou via un C2 comme Cobalt Strike), l’attaquant exécute l’outil pour demander un cookie PRT de manière “légitime”.
Windows reçoit la demande, et demande à CloudAP de signer le token. Le système renvoie ensuite proprement le Cookie PRT à l’application appelante, ici notre outil malveillant.
.\ROADtoken.exe <nonce>
Une fois le cookie obtenu, il peut être utilisé comme présenté précédemment.
Avantages et inconvénients de la méthode :
C’est de loin la méthode la plus discrète et nécessitant le moins de prérequis.
Cependant, elle présente un inconvénient majeur de persistance. Contrairement aux méthodes précédentes où l’on volait les éléments permettant de générer un cookie PRT ou des Access Token à volonté, ici on ne récupère qu’un cookie ou un token prêt à l’emploi.
Ces derniers ont une durée de vie limitée (souvent 1 heure pour un Access Token, ou lié à la session courante pour un cookie). Si l’attaquant veut maintenir son accès, il doit ré-exécuter l’attaque sur la machine victime régulièrement.
Note : Bien que la technique soit furtive (« Living Off the Land »), l’outil RoadToken lui-même est un exécutable non signé et très connu. Dans un environnement réel, un EDR le détecterait / bloquerait certainement. Un attaquant avancé réimplémenterait cet outil directement dans son implant (Beacon) ou via un script PowerShell obfusqué.
L’exploitation des PRT n’est pas une « vulnérabilité » au sens classique du terme, mais plutôt un abus de fonctionnalité. Le SSO (Single Sign-On) est conçu pour être transparent et fluide pour l’utilisateur, ce qui implique nécessairement une certaine surface d’attaque.
Microsoft a implémenté plusieurs protections au fil des années, rendant l’abus des PRT de plus en plus complexe. Les principales protections sont :
lsass.exe, ce mécanisme empêche les processus non signés par Microsoft (comme Mimikatz) d’ouvrir un handle sur LSASS, même avec les droits Administrateur. Bien qu’il existe des techniques de contournement, cela rend l’attaque beaucoup plus bruyante et complexe.Mais malgré ces protections, il n’existe pas de « patch » miracle.
Le cœur du problème réside dans la légitimité de l’action : pour que le SSO fonctionne, le navigateur (ou le plugin CloudAP) doit pouvoir obtenir un token de manière transparente. Si un processus légitime le peut, un processus malveillant s’exécutant dans le même contexte utilisateur pourra théoriquement toujours trouver un moyen de le faire aussi.
Puisque la prévention totale est impossible, la défense moderne se déporte sur la détection d’anomalie comportementale. Ces anomalies peuvent prendre de nombreuses formes :
roadtx)Si cet article s’est focalisé sur l’exploitation des PRT dans l’écosystème Windows (terrain de jeu historique des entreprises), il est crucial de rappeler que le concept de « Primary Refresh Token » est désormais agnostique au système d’exploitation.
Dans une stratégie « Zero Trust » moderne, l’identité doit être vérifiée partout. C’est pourquoi les mécanismes de PRT (ou leurs équivalents fonctionnels) ont été portés sur macOS (via le plug-in Microsoft Enterprise SSO) et sur Linux (via l’agent Intune et les brokers d’authentification).
Cela ouvre un champ d’investigation immense pour les auditeurs et les attaquants qui doivent être en mesure de s’adapter à la multitude d’environnements qu’il est possible de rencontrer en fonction des compagnies ciblées.
Sources :
Auteur : Maël BRZUSZEK – Pentester @Vaadata
