Le device code phishing fonctionne parce que la victime se connecte sur une véritable page Microsoft : il n'y a ni fausse page de connexion à repérer, ni domaine imitant l'original à bloquer. La défense pratique consiste à désactiver le flux pour tous ceux qui n'en ont pas besoin. Microsoft recommande de s'approcher autant que possible d'un blocage généralisé du device code flow, et une seule politique Conditional Access suffit pour cela.
À quoi sert le device code flow
Ce flux existe pour les appareils dépourvus de navigateur ou trop peu pratiques pour saisir du texte. La RFC 8628 cite les téléviseurs connectés, les consoles multimédias, les cadres photo et les imprimantes. L'appareil n'affiche aucune page de connexion. Il invite l'utilisateur à se rendre sur une URL depuis un autre appareil, un téléphone par exemple, et à y saisir un code court.
Le client envoie son identifiant client au serveur d'autorisation et reçoit en retour un device_code, un user_code, une verification_uri et une valeur expires_in. Pendant que l'utilisateur se connecte sur le second appareil, le client interroge régulièrement (polling) le endpoint de jetons avec le device_code, jusqu'à recevoir un jeton d'accès, une erreur ou une consigne d'attendre encore.
Dans la plateforme d'identité Microsoft, les endpoints sont /devicecode et /token. La documentation Microsoft laisse par défaut 15 minutes à l'utilisateur pour se connecter, et un refresh token est émis si le scope demandé incluait offline_access.
Pourquoi ça fonctionne comme phishing
Celui qui demande le code est le client. Celui qui se connecte est la personne qui détient le code. Le protocole n'exige pas qu'il s'agisse de la même personne, et la RFC 8628 range le « Remote Phishing » parmi les considérations de sécurité (section 5.4).
Un attaquant peut donc jouer le rôle de l'appareil. Il demande un code avec un client_id (et un scope, que l'endpoint Microsoft exige), puis envoie le user_code à sa cible avec un prétexte. La cible ouvre la vraie page de vérification, se connecte et saisit le code. Le client de l'attaquant, qui interroge le endpoint en continu, reçoit les jetons.
Le mot de passe ne passe jamais par une page contrôlée par l'attaquant. C'est pourquoi les contrôles fondés sur les domaines et les URL, comme notre vérificateur de liens, n'ont rien à signaler ici.
L'attaquant reste toutefois tributaire de la victime. La cible doit se connecter et saisir le code avant la fin de expires_in (15 minutes par défaut), faute de quoi le polling échoue avec expired_token. Les utilisateurs de comptes personnels doivent en outre se reconnecter et consentir aux autorisations demandées.
Il existe un indice utile pour la sensibilisation. Microsoft ne prend pas en charge verification_uri_complete, le champ facultatif qui transporte le code dans l'URL. « Quelqu'un m'a envoyé un code à saisir sur une page de connexion Microsoft » est le schéma à enseigner.
Détecter les connexions par device code
Microsoft recommande une politique qui audite l'usage existant du flux, et le mode Report-only vous donne exactement cela. Créez la politique décrite ci-dessous en Report-only et consultez les résultats d'impact de la politique pour voir qui et quoi aurait été bloqué.
Pour une chasse continue, filtrez les journaux de connexion Entra sur les connexions par device code et regroupez-les par utilisateur et par application. Il s'agit d'une recommandation de praticien : les pages Microsoft citées ici ne la documentent pas. Une connexion d'un utilisateur qui n'a aucun appareil ni outil utilisant ce flux, ou d'une application que personne ne sait nommer, mérite une discussion. Demandez à l'utilisateur quel message il a reçu.
Bloquer le flux avec Conditional Access
Le parcours de clics figure dans le guide Conditional Access de Microsoft. Connectez-vous avec au minimum le rôle Conditional Access Administrator, allez dans Entra ID > Conditional Access > Policies et créez une nouvelle politique. Incluez tous les utilisateurs et All resources. Sous Conditions > Authentication Flows, réglez Configure sur Yes et sélectionnez Device code flow. Sous Grant, choisissez Block access, et réglez Enable policy sur Report-only. Passez-la sur On après avoir examiné les résultats.
La même page traite du blocage de l'authentication transfer, qui permet aux utilisateurs de basculer une connexion d'un PC vers un appareil mobile. Il repose sur la même condition Authentication Flows : tranchez donc cette question dans la même séance.
Microsoft conseille de n'autoriser le flux que dans des cas d'usage bien documentés et sécurisés, comme des outils hérités qui ne peuvent pas être mis à jour.
Pour ce qui doit rester autorisé, constituez un groupe d'exclusion dédié, dont le nom indique clairement l'usage. Consignez un responsable et une justification pour chaque membre, et auditez la liste régulièrement, comme le conseille Microsoft. Gardez également vos comptes d'accès d'urgence (break-glass) exclus, afin d'éviter un verrouillage si la politique est mal configurée.
Par ailleurs, Microsoft indique que les appels effectués par des service principals ne sont pas bloqués par des politiques ciblant des utilisateurs, et suggère de remplacer les comptes de service utilisés dans des scripts ou du code par des managed identities.
Si un code phishing a déjà réussi
Partez du principe que l'attaquant détient des jetons, pas seulement un mot de passe. Un refresh token permet d'obtenir de nouveaux jetons d'accès : révoquez donc d'abord les sessions de l'utilisateur, puis réinitialisez le mot de passe. Il s'agit d'une recommandation de praticien, qui ne provient pas des sources ci-dessus.
Examinez ensuite les applications d'entreprise et les consentements accordés liés au compte, et supprimez ceux que vous ne reconnaissez pas. Vérifiez dans la boîte aux lettres la présence de règles que vous n'avez pas créées, en particulier des règles de transfert ou de suppression.
Étendez la recherche au-delà d'un seul utilisateur en appliquant le filtre device code ci-dessus aux autres comptes et en cherchant la même application. Si plusieurs comptes peuvent être touchés, suivez un véritable processus de réponse : notre équipe de réponse à incident peut le conduire avec vous, et notre blog propose des conseils sur la réponse à incident et le phishing pour le volet sensibilisation.
Par où commencer
- Dressez la liste de tous les appareils, scripts et outils susceptibles de se connecter avec un code : imprimantes, téléviseurs, objets connectés, outils en ligne de commande. Demandez à chaque responsable si c'est le cas.
- Créez la politique Conditional Access avec Device code flow sélectionné, tous les utilisateurs dans le périmètre et les comptes break-glass exclus, en mode Report-only. Tranchez en même temps la condition d'authentication transfer.
- Lisez les résultats du mode report-only et les connexions par device code dans les journaux. Corrigez ou retirez chaque usage légitime, et placez ce qui reste dans un groupe d'exclusion nommé, avec un responsable.
- Passez la politique sur On, et inscrivez l'audit du groupe d'exclusion au calendrier.
- Documentez les étapes de réponse (révocation des sessions, revue des applications d'entreprise et des consentements accordés, vérification des règles de boîte aux lettres). Expliquez au personnel qu'un code qu'il n'a pas demandé lui-même, provenant d'un appareil qu'il n'a pas en main, est une tentative de phishing.
