L’authentification par Device Flow Code permet de connecter un appareil IoT facilement sans avoir à retaper ses identifiants sur l’appareil en question.
Un exemple courant pourrait être la configuration d’un compte Disney+ sur une nouvelle TV.
Un code est généré sur la TV, puis l’utilisateur doit saisir ce code sur son téléphone déjà authentifié.
L’identité du compte utilisateur est ensuite transmise à la TV, lui permettant finalement d’accéder aux 36 saisons des Simpson.
Ce système est également disponible sur Azure Entra ID, sous le nom de Device Code Flow Authentication.
À la différence du scénario précédent, le code généré n’est pas associé à l’identité d’un utilisateur, mais à une application avec les droits qui lui sont attribués.
Générer un code est assez simple, il suffit de fournir deux paramètres :
- Le Client ID
- La ressource sur laquelle les droits sont nécessaires
Client ID
Le Client ID permet d’identifier à quelle application l’utilisateur souhaite s’authentifier.
Nous pouvons soit créer notre propre application sur Azure Entra ID,
soit utiliser une application officielle de Microsoft.
00b41c95-dab0-4487-9791-b9d2c32c80f2 - Office 365 Management
04b07795-8ddb-461a-bbee-02f9e1bf7b46 - Microsoft Azure CLI
0ec893e0-5785-4de6-99da-4ed124e5296c - Office UWP PWA
18fbca16-2224-45f6-85b0-f7bf2b39b3f3 - Microsoft Docs
1950a258-227b-4e31-a9cf-717495945fc2 - Microsoft Azure PowerShell
1b3c667f-cde3-4090-b60b-3d2abd0117f0 - Windows Spotlight
1b730954-1685-4b74-9bfd-dac224a7b894 - Azure Active Directory PowerShell
1fec8e78-bce4-4aaf-ab1b-5451cc387264 - Microsoft Teams
22098786-6e16-43cc-a27d-191a01a1e3b5 - Microsoft To-Do client
268761a2-03f3-40df-8a8b-c3db24145b6b - Universal Store Native Client
26a7ee05-5602-4d76-a7ba-eae8b7b67941 - Windows Search
27922004-5251-4030-b22d-91ecd9a37ea4 - Outlook Mobile
29d9ed98-a469-4536-ade2-f981bc1d605e - Microsoft Authentication Broker
2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8 - Microsoft Bing Search for Microsoft Edge
4813382a-8fa7-425e-ab75-3b753aab3abb - Microsoft Authenticator App
4e291c71-d680-4d0e-9640-0a3358e31177 - PowerApps
57336123-6e14-4acc-8dcf-287b6088aa28 - Microsoft Whiteboard Client
57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0 - Microsoft Flow Mobile PROD-GCCH-CN
60c8bde5-3167-4f92-8fdb-059f6176dc0f - Enterprise Roaming and Backup
66375f6b-983f-4c2c-9701-d680650f588f - Microsoft Planner
844cca35-0656-46ce-b636-13f48b0eecbd - Microsoft Stream Mobile Native
872cd9fa-d31f-45e0-9eab-6e460a02d1f1 - Visual Studio - Legacy
87749df4-7ccf-48f8-aa87-704bad0e0e16 - Microsoft Teams - Device Admin Agent
90f610bf-206d-4950-b61d-37fa6fd1b224 - Aadrm Admin PowerShell
9ba1a5c7-f17a-4de9-a1f1-6178c8d51223 - Microsfot Intune Company Portal
9bc3ab49-b65d-410a-85ad-de819febfddc - Microsoft SharePoint Online Management Shell
a0c73c16-a7e3-4564-9a95-2bdf47383716 - Microsoft Exchange Online Remote PowerShell
a40d7d7d-59aa-447e-a655-679a4107e548 - Accounts Control UI
a569458c-7f2b-45cb-bab9-b7dee514d112 - Yammer iPhone
ab9b8c07-8f02-4f72-87fa-80105867a763 - OneDrive Sync Engine
af124e86-4e96-495a-b70a-90f90ab96707 - OneDrive iOS App
b26aadf8-566f-4478-926f-589f601d9c74 - OneDrive
b90d5b8f-5503-4153-b545-b31cecfaece2 - AADJ CSP
c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12 - Microsoft Power BI
c58637bb-e2e1-4312-8a00-04b5ffcd3403 - SharePoint Online Client Extensibility
cb1056e2-e479-49de-ae31-7812af012ed8 - Microsoft Azure Active Directory Connect
cf36b471-5b44-428c-9ce7-313bf84528de - Microsoft Bing Search
d326c1ce-6cc6-4de2-bebc-4591e5e13ef0 - SharePoint
d3590ed6-52b3-4102-aeff-aad2292ab01c - Microsoft Office
e9b154d0-7658-433b-bb25-6b8e0a8a7c59 - Outlook Lite
e9c51622-460d-4d3d-952d-966a5b1da34c - Microsoft Edge
eb539595-3fe1-474e-9c1d-feb3625d1be5 - Microsoft Tunnel
ecd6b820-32c2-49b6-98a6-444530e5a77a - Microsoft Edge
f05ff7c9-f75a-4acd-a3b5-f4b6a870245d - SharePoint Android
f448d7e5-e313-4f90-a3eb-5dbb3277e4b3 - Media Recording for Dynamics 365 Sales
f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34 - Microsoft Edge
fb78d390-0c51-40cd-8e17-fdbfab77341b - Microsoft Exchange REST API Based PowerShell
fc0f3af4-6835-4174-b806-f7db311fd2f3 - Microsoft Intune Windows Agent
Ressource
Pour la démonstration, nous utiliserons l’Application ID de Microsoft Azure CLI et, comme ressource, l’API Graph de Microsoft.
Une fois que le code est généré, l’utilisateur doit le saisir sur le site de Microsoft : microsoft.com
Une fois le code validé par l’utilisateur sur le site de Microsoft, nous pouvons récupérer les tokens d’identification de l’application grâce à la requête suivante :
Dans le body de la requête, nous devons renseigner :
- L’Application ID de l’application choisie
- Le code d’appareil généré dans la requête précédente
- Le grant_type =
urn:ietf:params:oauth:grant-type:device_code
Dans la réponse, nous retrouvons donc :
- Les droits associés au token
- L’access token
- Son refresh token pour utiliser l’API Graph
Exploitation du Device Flow Code par un attaquant
Pour un attaquant, ce mécanisme est très intéressant. Une personne mal intentionnée pourrait générer un code à l’avance, demander à une victime de le saisir sur le site officiel de Microsoft, puis récupérer l’access token pour effectuer toutes les actions autorisées à l’application choisie.
Cela permettrait d’extraire des données de l’organisation sur Azure, de modifier les utilisateurs d’Entra ID, et bien plus encore.
De plus, le refresh token permet de régénérer des tokens valides pendant une période de 90 jours, laissant ainsi largement le temps à un attaquant de commettre ses méfaits.
L’expiration du Device Code
Cependant, un problème majeur est à considérer : le code d’appareil généré expire après 15 minutes.
Cela signifie que la victime d’un mail de phishing ne pourra entrer le code que dans les 15 premières minutes suivant sa génération.
Contournement de la restriction
Pour contourner cette restriction mise en place par Microsoft, nous allons déployer une infrastructure qui permettra de générer dynamiquement un device code lorsque la victime recevra l’email.
Une fois le code validé par la victime, il sera récupéré par un serveur d’écoute chargé d’enregistrer l’access token et le refresh token.
Alors, créons cette infrastructure ! 🙂
L’infrastructure de phishing
Le serveur d’écoute
Pour le déploiement du serveur qui va réceptionner les tokens d’application, nous utiliserons une machine virtuelle sur le cloud Azure.
Étapes:
Créer une clé SSH pour pouvoir se connecter à la machine virtuelle par la suite :
ssh-keygenSe connecter à son infrastructure Azure pour le déploiement :
az loginLancer le script Bash pour la génération du serveur d’écoute dans le cloud :
Lien vers le script de déploiement : https://github.com/pierre-louis-mobeta/auto-generate-device-code/blob/main/capture-server/deploy.sh
Ce script va créer une machine virtuelle sur Azure avec le port 443 ouvert pour écouter si un nouveau code a été généré par une victime.
Les certificats SSL seront intégrés pour permettre l’utilisation du protocole HTTPS.
Pour l’exécuter, vous aurez besoin des paramètres suivants :
- Nom du groupe de ressources dans lequel sera contenu le serveur d’écoute
- Nom de domaine sur lequel la machine sera accessible
- Clé publique SSH générée précédemment pour s’y connecter
- Région Azure dans laquelle les ressources seront créées
./deply.sh captureRessourceGroupe codecapture <vmPublicDNSName> <pubKey> eastusLancer le serveur d’écoute
ssh -i <privateKey> azureuser@<vmPublicDNSName> cd TokenTactics/capturetokenphish sudo python3 [capturetokenphish.py](<http://capturetokenphish.py/>)Si vous voulez voir en temps réel les tokens capturés, supprimez le
"nohup",Sinon, les résultats seront stockés dans des fichiers.
Vous devriez maintenant avoir le serveur d’écoute lancé.
Déploiement de la page de phishing
Une fois le serveur d’écoute déployé, nous devons mettre en place la page de phishing qui va générer dynamiquement les codes d’appareil.
Pour ce faire, nous allons déployer une Static Web Application sur Azure contenant un script qui :
- Génère un nouveau code d’appareil à chaque fois qu’un client se connecte à la page
- Envoie une requête au endpoint de Microsoft pour obtenir ce code
- Transmet ensuite le device code généré à notre serveur d’écoute configuré plus haut
💡 Gestion du CORS :
Une requête venant d’un site vers un autre peut être bloquée par la politique CORS.
Pour contourner cette restriction mise en place par Microsoft, nous allons utiliser un proxy en ligne qui servira d’intermédiaire.
Étapes :
-
Récupérer la page HTML de phishing
🔗 Lien : auto-generate-device-code/phishing-static-website/index.html
-
Modifier l’adresse du serveur d’écoute pour qu’elle corresponde à votre infrastructure
-
Déployer la page sur une Web App
az webapp up --name PhishingDevicePage --html⚠️ Cette commande doit être exécutée dans un dossier contenant l’index.html
Vous devriez obtenir cette page 👇
Exploitation du phishing
À partir de là, si un client se connecte sur cette page, une demande de génération de code sera envoyée à Microsoft via le proxy.
Une fois le code récupéré, il sera transmis à notre serveur d’écoute, qui va continuellement vérifier si ce code a été validé.
⚠️ Cette vérification dure 15 minutes, après quoi le code expire et devient inutilisable.
Tout est prêt ! 🎉
Il ne reste plus qu’à envoyer le lien de notre Web App déployée à la victime et à attendre que le serveur d’écoute récupère les tokens.
Récupération des tokens
Dès que la victime saisit le code, vous devriez récupérer les tokens dans le serveur d’écoute, comme ceci :
Et voilà ! 🎯 Vous avez maintenant un accès au tenant Azure de la victime.
Il ne vous reste plus qu’à faire une énumération à l’aide des tokens récupérés, afin de pivoter si l’administrateur n’est pas déjà sous votre contrôle.
Mitigation
Pour empêcher cette attaque, la seule défense efficace est la mise en place d’une Conditional Access Policy (CAP).
Restriction des enregistrements d’applications
Il est essentiel de créer une règle qui autorise uniquement les administrateurs à enregistrer de nouvelles applications.
💡 Bonnes pratiques :
- Former les administrateurs Azure à ne pas enregistrer n’importe quelle application.
- Limiter l’usage du device code flow aux seules applications de confiance.
Mise en place d’une politique d’accès conditionnel
🚨 Prérequis : vous devez disposer d’un abonnement Azure Entra ID P1 au minimum.
Étapes de configuration
- Accédez au portail Entra → https://entra.microsoft.com/
- Créez une politique d’accès conditionnel
- Exclure les administrateurs de cette politique (ou non, selon vos besoins)
- Sélectionner toutes les applications cloud
- Définir comme condition : authentification via device code flow
- Bloquer l’accès
- Activer la politique et enregistrer
Vous voilà maintenant protégé contre ce type d’attaque.
À suivre dans la partie 2 : maintenant que nous avons récupéré les tokens via le phishing, nous allons voir comment exploiter ces derniers pour obtenir un Primary Refresh Token (PRT) et aller encore plus loin dans la compromission. 🚀
