Last updated
Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
Dans la section État SSO, vous devriez voir le AzureAdPrt défini sur OUI.
Dans la même sortie, vous pouvez également voir si le dispositif est joint à Azure (dans le champ AzureAdJoined) :
Le cookie PRT s'appelle en réalité x-ms-RefreshTokenCredential et c'est un JSON Web Token (JWT). Un JWT contient 3 parties, l'en-tête, le corps et la signature, divisées par un . et toutes encodées en base64 sécurisée pour l'URL. Un cookie PRT typique contient l'en-tête et le corps suivants :
Le Primary Refresh Token (PRT) actuel est encapsulé dans le refresh_token, qui est chiffré par une clé sous le contrôle d'Azure AD, rendant son contenu opaque et indécryptable pour nous. Le champ is_primary signifie l'encapsulation du jeton de rafraîchissement principal dans ce jeton. Pour s'assurer que le cookie reste lié à la session de connexion spécifique pour laquelle il était destiné, le request_nonce est transmis depuis la page logon.microsoftonline.com.
Le processus LSASS enverra au TPM le KDF context, et le TPM utilisera la session key (rassemblée lorsque l'appareil a été enregistré dans AzureAD et stockée dans le TPM) et le contexte précédent pour dériver une clé, et cette clé dérivée est utilisée pour signer le cookie PRT (JWT).
Le KDF context est un nonce d'AzureAD et le PRT créant un JWT mélangé avec un contexte (octets aléatoires).
Par conséquent, même si le PRT ne peut pas être extrait car il est situé à l'intérieur du TPM, il est possible d'abuser de LSASS pour demander des clés dérivées à partir de nouveaux contextes et utiliser les clés générées pour signer des cookies.
En tant qu'utilisateur régulier, il est possible de demander l'utilisation du PRT en demandant à LSASS des données SSO. Cela peut être fait comme des applications natives qui demandent des jetons au Web Account Manager (courtier de jetons). WAM passe la demande à LSASS, qui demande des jetons en utilisant une assertion PRT signée. Ou cela peut être fait avec des flux basés sur le navigateur (web) où un cookie PRT est utilisé comme en-tête pour authentifier les demandes aux pages de connexion Azure AS.
En tant que SYSTEM, vous pourriez voler le PRT s'il n'est pas protégé par TPM ou interagir avec les clés PRT dans LSASS en utilisant des API cryptographiques.
Pour plus d'infos sur cette méthode vérifiez ce post. 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 :
Ou en utilisant roadrecon :
Ensuite, vous pouvez utiliser roadtoken pour obtenir un nouveau PRT (exécutez l'outil à partir d'un processus de l'utilisateur à attaquer) :
En une ligne :
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 :
Get-AADIntUserPRTToken récupère le jeton PRT de l'utilisateur à partir de l'ordinateur joint à Azure AD ou joint hybride. Utilise BrowserCore.exe pour obtenir le jeton PRT.
Ou si vous avez les valeurs de Mimikatz, vous pouvez également utiliser AADInternals pour générer un jeton :
Allez sur https://login.microsoftonline.com, effacez tous les cookies pour login.microsoftonline.com et entrez un nouveau cookie.
Puis allez sur https://portal.azure.com
Le reste devrait être les valeurs par défaut. Assurez-vous que vous pouvez actualiser la page et que le cookie ne disparaît pas, si c'est le cas, vous avez peut-être fait une erreur et devez recommencer le processus. Si ce n'est pas le cas, vous devriez être bon.
Le PRT (Primary Refresh Token) est extrait de LSASS (Local Security Authority Subsystem Service) et stocké pour une utilisation ultérieure.
La clé de session est extraite ensuite. Étant donné que cette clé est initialement émise puis ré-encrypté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 à Pass-the-cookie attack.
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.
Notez que si le PRT est à l'intérieur du TPM et non à l'intérieur de lsass, mimikatz ne pourra pas l'extraire.
Cependant, il sera possible d'obtenir une clé à partir d'une clé dérivée d'un contexte du TPM et de l'utiliser pour signer un cookie (voir option 3).
Vous pouvez trouver une explication approfondie du processus effectué pour extraire ces détails ici : https://dirkjanm.io/digging-further-into-the-primary-refresh-token/
Cela ne fonctionnera pas exactement après les correctifs d'août 2021 pour obtenir les tokens PRT d'autres utilisateurs, car seul l'utilisateur peut obtenir son PRT (un administrateur local ne peut pas accéder aux PRT d'autres utilisateurs), mais peut accéder au sien.
Vous pouvez utiliser mimikatz pour extraire le PRT :
(Images from https://blog.netwrix.com/2023/05/13/pass-the-prt-overview)
Copiez la partie étiquetée Prt et enregistrez-la.
Extrayez également la clé de session (le KeyValue du champ ProofOfPossesionKey) que vous pouvez voir mise en surbrillance ci-dessous. Cela est chiffré et nous devrons utiliser nos clés maîtresses DPAPI pour le déchiffrer.
Si vous ne voyez aucune donnée PRT, il se peut que vous n'ayez pas de PRT parce que votre appareil n'est pas joint à Azure AD ou il se peut que vous exécutiez une ancienne version de Windows 10.
Pour déchiffrer la clé de session, vous devez élever vos privilèges à SYSTEM pour fonctionner sous le contexte de l'ordinateur afin de pouvoir utiliser la clé maîtresse DPAPI pour le déchiffrer. Vous pouvez utiliser les commandes suivantes pour ce faire :
Maintenant, vous voulez copier à la fois la valeur Context :
Et la valeur de clé dérivée :
Enfin, vous pouvez utiliser toutes ces informations pour générer des cookies PRT :
Allez sur https://login.microsoftonline.com, effacez tous les cookies pour login.microsoftonline.com et entrez un nouveau cookie.
Ensuite, allez sur https://portal.azure.com
Le reste devrait être par défaut. Assurez-vous de pouvoir actualiser la page et que le cookie ne disparaisse pas, si c'est le cas, vous avez peut-être fait une erreur et devez recommencer le processus. Si ce n'est pas le cas, vous devriez être bon.
Renouvelez d'abord le PRT, ce qui l'enregistrera dans roadtx.prt :
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.
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 :
Apprenez et pratiquez le hacking AWS :HackTricks Formation Expert Red Team AWS (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Formation Expert Red Team GCP (GRTE)
