Quand nous ouvrons une session sur un poste joint à Entra ID, nous arrivons sur Teams, Outlook et le portail web sans jamais ressaisir nos identifiants. Ce SSO tient à un artefact unique, le Primary Refresh Token (PRT). C’est l’équivalent, côté Entra, du TGT que nous avions lu dans l’article sur Kerberos: un jeton de longue durée qui en débloque d’autres.
Regarder sa structure, où vivent ses clés et comment il signe ses requêtes, c’est comprendre d’un même mouvement pourquoi il est si pratique et où se situe le risque. Les mécanismes décrits ici sont ceux que Microsoft documente pour Windows; les captures de poste réel ne sont pas nécessaires, dsregcmd et la documentation suffisent.
Le PRT, un TGT pour le cloud
Le PRT est délivré aux « brokers » de jetons de Microsoft (CloudAP et WAM sur Windows) pour assurer le SSO. Du point de vue du poste, c’est un blob chiffré que le client ne sait pas lire: seul Entra ID en connaît le contenu. Il est émis pendant l’ouverture de session Windows sur un appareil joint ou joint hybride, par le plugin CloudAP, puis le plugin WAM s’en sert pour obtenir des jetons d’accès et de rafraîchissement pour chaque application.
Sa durée de vie est de 90 jours, renouvelé toutes les 4 heures tant que l’appareil sert. Surtout, il transporte des revendications d’appareil et d’utilisateur, dont la revendication MFA, qu’Entra ID évalue ensuite pour l’accès conditionnel. Un détail lourd de conséquences: l’accès conditionnel n’est pas évalué au moment où le PRT est émis ou renouvelé, seulement quand on s’en sert pour demander un jeton d’application.
Deux paires de clés et le TPM
Tout repose sur l’enregistrement de l’appareil, qui génère deux paires de clés: la clé d’appareil (dkpub/dkpriv) et la clé de transport (tkpub/tkpriv). Les parties privées sont scellées dans le TPM quand il y en a un.
En même temps que le PRT, Entra ID émet une clé de session symétrique, chiffrée avec la clé de transport publique (tkpub). Le poste ne peut la déchiffrer qu’avec tkpriv, à l’intérieur du TPM, qui la re-chiffre aussitôt avec sa propre clé avant que CloudAP ne la range dans son cache. Cette clé de session est la clé de preuve de possession de toutes les requêtes liées au PRT, et elle est aussi incluse dans le PRT lui-même. La documentation est explicite: « no other OS component can access it ». Sur un poste avec TPM, la clé de session ne se promène donc jamais en clair hors du module.
Comment cette clé arrive-t-elle sur le poste? La cérémonie d’émission, que Microsoft documente étape par étape, tient en cinq temps. À l’ouverture de session, CloudAP découvre le fournisseur d’identité de l’utilisateur, obtient un nonce d’Entra, puis construit une requête d’authentification — identifiants et nonce — qu’il signe avec la clé d’appareil (dkpriv). Entra valide le tout, puis renvoie le PRT chiffré accompagné de la clé de session, elle-même chiffrée avec la clé de transport publique (tkpub). Le poste ne peut rien en faire sans le TPM, qui seul détient tkpriv.
Émission du PRT à l’ouverture de session: la clé de session n’existe en clair que le temps d’un passage dans le TPM.
Ce PRT vaut 90 jours et CloudAP le renouvelle toutes les 4 heures tant que le poste sert; chaque renouvellement est signé par la clé de session, pas par les identifiants, si bien qu’un poste actif ne redemande jamais le mot de passe. Il existe deux variantes: le PRT d’appareil enregistré, lié à une identité d’appareil dans Entra et seul à satisfaire les politiques d’appareil de l’accès conditionnel, et le PRT d’appareil non enregistré, rattaché à une simple paire de clés locale — par exemple un navigateur sur un poste personnel. C’est le premier qui nous intéresse ici: c’est lui qui porte la confiance de l’appareil, et donc la valeur qu’un attaquant convoite.
Lire l’état du PRT avec dsregcmd
La commande dsregcmd /status, lancée dans le contexte de l’utilisateur, donne l’essentiel sans rien décoder. Le bloc « SSO State » indique la présence du PRT, le bloc « Device Details » indique si les clés sont dans le TPM:
+----------------------------------------------------------+
| Device Details |
+----------------------------------------------------------+
KeyProvider : Microsoft Platform Crypto Provider
TpmProtected : YES
DeviceAuthStatus : SUCCESS
+----------------------------------------------------------+
| SSO State |
+----------------------------------------------------------+
AzureAdPrt : YES
AzureAdPrtUpdateTime : 2026-10-28 06:12:44.000 UTC
AzureAdPrtExpiryTime : 2027-01-26 06:12:44.000 UTC
AzureAdPrtAuthority : https://login.microsoftonline.com/<tenant>AzureAdPrt: YES confirme qu’un PRT est présent pour l’utilisateur connecté. Les deux lignes à surveiller sont TpmProtected et KeyProvider: Microsoft Platform Crypto Provider avec TpmProtected: YES veut dire que les clés sont dans le matériel; Microsoft Software Key Storage Provider avec TpmProtected: NO veut dire qu’elles sont en logiciel, et nous verrons que l’écart de robustesse est énorme.
Le cookie x-ms-RefreshTokenCredential et le SSO web
Le plus instructif est le SSO vers un site web, car c’est là qu’un objet signé circule. Quand le navigateur ouvre une page de connexion Entra, une extension (native dans Edge, via l’extension « Microsoft Single Sign On » dans Chrome) reconnaît l’URL et appelle un hôte natif local, BrowserCore.exe. Celui-ci demande à CloudAP un cookie de PRT, que CloudAP fabrique et signe avec la clé de session scellée par le TPM. Le cookie repart dans l’en-tête x-ms-RefreshTokenCredential vers login.microsoftonline.com.
SSO web par PRT: le cookie est signé dans le TPM, jamais le secret lui-même.
Entra ID vérifie la signature de la clé de session, le nonce (qui lie le cookie à une ouverture de session précise) et la validité de l’appareil, puis renvoie un jeton d’identité et un cookie de session. Ce cookie de session est lui aussi lié à la clé de session ou d’appareil: rejoué depuis une autre machine, il est refusé. Nous retrouvons l’idée vue avec les passkeys: ce qui protège, c’est la liaison cryptographique, pas le secret partagé.
Qui gère le PRT: CloudAP, WAM et les brokers
Le PRT n’est jamais manipulé par les applications elles-mêmes. Entre elles et Entra ID s’intercalent des composants Microsoft spécialisés, et savoir qui fait quoi éclaire autant le fonctionnement que la surface d’attaque.
Sur Windows. Tout part de CloudAP (Cloud Authentication Provider), le fournisseur d’authentification moderne chargé dans le processus LSASS à l’ouverture de session. Le plugin CloudAP Microsoft Entra est l’autorité du PRT sur un poste joint ou joint hybride: c’est lui qui le demande, le met en cache et le renouvelle. Quand une application veut un jeton, elle ne parle pas à Entra directement mais à WAM (Web Account Manager), le courtier de jetons de Windows; le plugin WAM Microsoft Entra se sert alors du PRT pour obtenir jetons d’accès et de rafraîchissement, et c’est lui aussi qui injecte le PRT dans les requêtes du navigateur. Un troisième composant, Dsreg, gère l’enregistrement de l’appareil et les clés décrites plus haut.
Le cas du navigateur. Edge sait parler nativement à ces courtiers. Chrome, lui, a besoin de l’extension « Microsoft Single Sign On » — l’ancienne « Windows 10 Accounts », d’où le nom de broker « W10 account » qu’on croise encore (identifiant ppnbnpeolgkicgegkbkbjmhlideopiji). Cette extension appelle, par le native messaging de Chrome, l’hôte natif BrowserCore.exe qui, lui, a le droit de demander un cookie de PRT à CloudAP. Firefox depuis la version 91 fait de même via un réglage « Windows SSO ». Sous le capot, c’est l’API Windows IProofOfPossessionCookieInfoManager qui produit l’en-tête signé.
Hors de Windows. Le même rôle de courtier est tenu par une application selon la plateforme: Microsoft Authenticator sur iOS, Intune Company Portal accompagné du plugin SSO entreprise (ou le Platform SSO) sur macOS, et Authenticator, Company Portal ou Link to Windows sur Android. Sur Mac, le courtier n’est actif que si l’appareil est géré par MDM et que le profil d’extension SSO est déployé. Partout l’idée est la même: une brique Microsoft de confiance détient le PRT et le transforme en jetons pour les applications, sans jamais exposer les clés.
Où se situe le risque: pass-the-PRT
Le point faible n’est pas la cryptographie, c’est l’architecture: un broker tourne sur le poste et transforme le PRT en jetons pour qui le lui demande dans le bon contexte. Quiconque exécute du code sous l’identité de l’utilisateur peut donc solliciter ce même broker. Dirk-jan Mollema l’a montré dès 2020 dans son analyse de référence: demander un cookie de PRT via BrowserCore.exe ne réclame pas de droits d’administrateur, seulement l’exécution de code dans la session. C’est du post-exploitation, pas de l’accès initial: l’attaquant est déjà sur le poste.
Ce qu’il obtient est un cookie x-ms-RefreshTokenCredential, donc des jetons qui portent déjà les revendications MFA et appareil, et satisfont un accès conditionnel exigeant le MFA ou un appareil conforme. Des outils publics automatisent cette demande de cookie — ROADtoken, RequestAADRefreshToken de Lee Christensen, ou roadtx de la suite ROADtools — en interrogeant le même hôte natif que le navigateur. Je les cite pour que vous sachiez ce que vous verrez dans un rapport d’incident; je ne détaille pas leur mise en œuvre.
Reste la voie plus brutale: extraire le PRT et la clé de session eux-mêmes. C’est là que le TPM change tout. Sur un poste TpmProtected: YES, la clé de session est scellée: un attaquant même administrateur peut tout au plus l’utiliser sur la machine, pas la copier ailleurs. Sur un poste sans TPM (Software Key Storage Provider), les clés sont récupérables avec des droits élevés, et des outils comme Mimikatz savent le faire. La ligne TpmProtected de dsregcmd n’est donc pas cosmétique: elle sépare « il faut rester sur le poste » de « on emporte le jeton ».
L’impact est le même que pour un relais NTLM: la force de la preuve initiale ne compte plus si le jeton qu’elle produit peut être réutilisé. Pire, désactiver l’appareil dans Entra ID n’invalide pas les jetons de rafraîchissement déjà émis à partir du PRT; il faut une révocation explicite.
Pour mesurer le rayon d’impact, il faut voir le PRT comme une clé maîtresse temporaire. Un mot de passe volé ouvre une porte mais bute encore sur le MFA; un PRT compromis livre une session qui a déjà franchi le MFA et porte la confiance de l’appareil. L’attaquant hérite de la posture de sécurité du poste légitime: il ne contourne pas les contrôles, il passe au travers parce qu’ils ont déjà été satisfaits. MITRE ATT&CK range cette réutilisation sous la technique T1550.001 (Use Alternate Authentication Material: Application Access Token), parmi les mouvements qui échappent aux défenses d’authentification classiques. Ce n’est pas théorique: les campagnes adversary-in-the-middle de ces dernières années combinent un proxy de phishing pour la première session et le vol de jetons pour la persistance, ce qui a fait de ces jetons une cible de premier plan.
Le scénario de compromission, de bout en bout
Pour saisir le risque, suivons un vol de PRT comme une chaîne, de l’entrée à la persistance. Le PRT n’est jamais une voie d’accès initial: il suppose que l’attaquant exécute déjà du code sur le poste. C’est une arme de post-exploitation, et c’est précisément ce qui la rend redoutable, car elle hérite de tout ce que le poste a de légitime.
La chaîne d’un vol de PRT : post-exploitation, pas accès initial. Chaque étape hérite de la légitimité du poste.
Le pied dans la place. L’attaquant obtient d’abord l’exécution de code sous l’identité de l’utilisateur: pièce jointe piégée, logiciel malveillant, ou proxy adversary-in-the-middle qui capte une première session. À ce stade il est sur un poste, dans une session ouverte, rien de plus.
Solliciter le broker. C’est l’étape qui distingue le PRT d’un simple vol de mot de passe. Plutôt que de chercher un secret, l’attaquant demande au broker local ce que celui-ci sait faire: produire un cookie de PRT pour une page de connexion. En contexte utilisateur, via l’hôte natif décrit plus haut, cela ne réclame pas de droits d’administrateur. Avec une élévation, il peut viser plus bas, les clés elles-mêmes, et c’est là que le TPM l’arrête.
Sortir de la boîte. Le cookie, ou les jetons qu’il permet d’obtenir, servent ensuite à s’authentifier comme l’utilisateur vers Microsoft 365 ou Azure, depuis l’infrastructure de l’attaquant.
Ce que ça rapporte. C’est le nœud du problème: ces jetons portent déjà les revendications MFA et appareil du poste légitime. Ils franchissent donc un accès conditionnel qui exige le MFA ou un appareil conforme, sans que l’attaquant n’ait jamais vu de second facteur. Il n’a pas contourné le MFA, il a hérité d’une session qui l’avait déjà passé. Un mot de passe volé ouvre une porte; un PRT volé livre la session entière, MFA compris.
La persistance. Les jetons de rafraîchissement dérivés du PRT vivent longtemps, et désactiver l’appareil dans Entra ID n’invalide pas ceux déjà émis. Sans révocation explicite, l’accès survit au nettoyage du poste. C’est pourquoi la réponse à incident ne peut pas se limiter à réinstaller la machine, et c’est l’objet de la dernière section.
L’accès conditionnel, là où les revendications comptent
Si le PRT a autant de valeur, c’est à cause de ce qu’il transporte pour l’accès conditionnel. Un PRT porte des revendications d’appareil (l’appareil est-il enregistré, conforme, joint hybride?) et, selon la façon dont l’utilisateur s’est authentifié, une revendication MFA. Quand le plugin WAM échange le PRT contre un jeton d’application, ces revendications passent dans le jeton, et c’est à ce moment — pas à l’émission du PRT — qu’Entra ID évalue les politiques d’accès conditionnel.
Ce détail de calendrier a deux conséquences. D’abord, activer une politique après coup ne rejoue pas les PRT déjà émis: l’évaluation se fait au prochain échange de jeton. Ensuite, et c’est le cœur du risque, un attaquant qui réutilise un PRT hérite de ses revendications: le jeton qu’il obtient présente déjà le MFA et la conformité de l’appareil, et franchit donc une politique qui les exige.
C’est pourquoi l’accès conditionnel est à la fois la cible et la défense. Côté défense, plusieurs leviers s’empilent: exiger un appareil conforme ou joint hybride pour accéder aux ressources; la Token Protection, un contrôle de session qui n’accepte qu’un jeton lié cryptographiquement à l’appareil; une fréquence de connexion qui force une réauthentification périodique; un contexte d’authentification qui réclame une authentification interactive résistante au phishing pour les opérations sensibles, comme l’activation d’un rôle dans PIM; et des politiques basées sur le risque qui, sur un jeton anormal, exigent une réauthentification que l’attaquant ne peut pas produire. Aucun de ces leviers n’est évalué à l’émission du PRT: ils ne mordent qu’au moment où le jeton sert, ce qui en fait le bon endroit pour arrêter un jeton volé.
Défenses
Les trois temps de la défense selon Microsoft : réduire la surface, détecter, empêcher le rejeu.
La première défense est matérielle: exiger le TPM. Un parc en TpmProtected: YES fait passer le vol de « copier un blob » à « compromettre durablement la machine ». C’est le socle sur lequel tout le reste s’appuie.
La deuxième est la Token Protection (protection des jetons), un contrôle de session de l’accès conditionnel qui n’accepte que des jetons de session liés à l’appareil: un jeton volé est refusé depuis un autre poste. Elle est en disponibilité générale pour les applications natives sous Windows (Exchange Online, SharePoint Online, Teams, plus AVD et Windows 365), encore en préversion pour le navigateur et limitée à Azure Resource Manager. Elle demande Entra ID P2 à la disponibilité générale, et Microsoft recommande de la déployer d’abord en mode « report-only » pour mesurer la compatibilité des applications.
Le reste relève de la défense en profondeur: accès conditionnel exigeant un appareil conforme ou joint hybride et tenant compte du risque de connexion; surveillance des journaux de connexion pour repérer un PRT utilisé depuis un appareil inattendu ou un voyage impossible; réduction de la surface d’exécution de code (moins d’administrateurs locaux, Credential Guard, EDR sur le broker). Et en cas de doute, la seule réponse fiable est la révocation des jetons de rafraîchissement (horodatage refreshTokensValidFromDateTime, via revokeSignInSessions dans Graph) et, pour un PRT obtenu par mot de passe, le changement de mot de passe.
Détecter et répondre
Microsoft range la défense contre le vol de jetons en trois temps: réduire la surface, détecter et atténuer, empêcher le rejeu. Le premier temps est celui des défenses vues plus haut, TPM et Token Protection en tête. Restent la détection et la réponse, car aucun durcissement n’est parfait, et la documentation de Microsoft sur la protection des jetons les décrit en détail.
Détecter. Un PRT rejoué ne ressemble pas tout à fait à une connexion normale, et c’est là que ça se voit. Entra ID Protection lève des détections dédiées — « Anomalous Token », « Attacker in the Middle », « Unfamiliar sign-in properties » — et Microsoft Defender XDR, via les connecteurs Defender for Cloud Apps, alerte « Stolen session cookie was used » quand un cookie de session est rejoué. Sur le poste, Defender for Endpoint détecte les tentatives d’accès aux artefacts du PRT sous Windows. Côté journaux, c’est dans les connexions non interactives qu’il faut chercher: une même session vue depuis plusieurs adresses IP ou pays, ou un enchaînement jeton de rafraîchissement puis PRT depuis le même appareil en moins d’une heure, trahissent un rejeu. Le guide de réponse au vol de jetons de Microsoft détaille la marche à suivre.
Un atout du nonce. Le cookie de PRT est lié à un nonce de la page de connexion. Un cookie capturé une fois expire donc vite; pour en produire à volonté, l’attaquant doit garder son exécution de code sur le poste, ce qui multiplie les occasions de le repérer par l’EDR. La liaison cryptographique ne se contente pas de compliquer le rejeu, elle force l’attaquant à rester visible.
Répondre. Désactiver l’appareil ne suffit pas. La seule coupure fiable est la révocation des jetons de rafraîchissement — l’horodatage refreshTokensValidFromDateTime, posé par revokeSignInSessions dans Graph — doublée d’un changement de mot de passe pour un PRT obtenu par mot de passe. Les applications compatibles Continuous Access Evaluation (CAE) appliquent cette révocation en quasi temps réel, et un score de risque utilisateur élevé peut déclencher automatiquement le blocage ou la réinitialisation du compte. Associée à la Token Protection, cette réponse ramène la fenêtre d’exploitation de quelques jours à quelques minutes.
Le PRT est la charnière entre l’ouverture de session Windows et le SSO web. Bien scellée dans le TPM, protégée par la Token Protection et révocable, elle reste une commodité. Négligée sur un poste sans TPM et sans révocation, elle devient un passe-partout.
Rémi Vernier
Responsable des opérations cybersécurité dans un grand groupe international. Identité, Active Directory, Entra ID, cloud hybride, et désormais SAP, IA et modèles en local.