Device Code Phishing : abus OAuth dans Entra ID

Le device code phishing abuse d’un flux OAuth Device Authorization légitime pour amener une victime à autoriser une session contrôlée par l’attaquant. Dans les environnements Microsoft Entra ID, l’utilisateur peut saisir un code court sur la vraie page Microsoft de connexion par appareil, compléter l’authentification normale, satisfaire le MFA, puis laisser le client contrôlé par l’attaquant recevoir les tokens.

Cette distinction est importante. Le device code phishing n’est pas du password spraying, pas du phishing de consentement OAuth, pas de la MFA fatigue, et pas une simple page de vol d’identifiants. C’est un chemin d’attaque centré sur les tokens, qui abuse d’un flux d’authentification valide conçu pour les appareils avec interface limitée. Les défenseurs doivent donc l’évaluer avec Conditional Access, les journaux de connexion, l’investigation des tokens et l’activité post-authentification.

Pour les équipes qui travaillent déjà sur la MFA fatigue, le password spraying, les limites de MFA seul dans Azure, ou un audit de sécurité Microsoft Entra ID, le device code phishing mérite un article dédié. L’interaction utilisateur initiale et la session obtenue ne ressemblent pas à un faux formulaire de connexion classique.

Qu’est-ce que le Device Code Phishing ?

Le device code phishing est une technique de social engineering qui abuse de l’OAuth 2.0 Device Authorization Grant. L’attaquant initialise un device code flow depuis un client qu’il contrôle, reçoit un code utilisateur et une URI de vérification, puis pousse la cible à saisir ce code dans un navigateur. Si la cible termine l’authentification, le client contrôlé par l’attaquant peut recevoir des tokens pour la ressource et les scopes demandés.

Le flux légitime existe pour les appareils qui ne peuvent pas facilement afficher un navigateur complet ou recevoir une saisie riche. La documentation Microsoft cite des cas comme une smart TV, un appareil IoT ou une imprimante. L’appareil affiche un code, l’utilisateur se connecte sur un autre appareil, et le client à interface limitée interroge le token endpoint jusqu’à autorisation ou expiration.

Le device code phishing détourne ce modèle. L’appareil qui demande l’autorisation n’est pas une TV de salle de réunion ou une imprimante devant l’utilisateur. C’est une session client contrôlée par l’attaquant. La victime est invitée à saisir un code sur une page Microsoft légitime, ce qui rend l’expérience plus difficile à distinguer d’une authentification Microsoft normale.

Il faut donc être prudent avec l’expression “MFA bypass”. Dans beaucoup de scénarios de device code phishing, le MFA n’est pas cassé cryptographiquement. L’utilisateur peut réellement compléter le MFA pendant l’authentification Microsoft. Le problème est qu’il autorise la session device-code de l’attaquant. Le fait que le MFA ait réussi ne prouve pas que la session résultante appartient à un appareil, un emplacement ou un workflow de confiance.

Comment fonctionne le flux OAuth Device Code

L’OAuth Device Authorization Grant est défini par la RFC 8628. Le client demande une autorisation d’appareil au serveur d’autorisation et reçoit des valeurs comme device_code, user_code, verification_uri, une durée d’expiration et un intervalle de polling. L’utilisateur visite l’URI de vérification et saisit le code. Pendant ce temps, le client interroge le token endpoint avec le device_code.

La plateforme d’identité Microsoft implémente ce modèle avec le device code flow. Une réponse de token réussie peut inclure un access token, un ID token si openid est demandé, et un refresh token si le scope initial inclut offline_access. Dans un scénario de phishing, ce matériel token est l’objectif de l’attaquant. Il n’a pas besoin de connaître le mot de passe si la victime termine le flux d’autorisation.

Le flux a trois propriétés de sécurité que les défenseurs doivent comprendre :

Propriété	Sens défensif
L’utilisateur s’authentifie dans un navigateur séparé	Le navigateur qui approuve n’est pas forcément le même appareil ou client que celui qui recevra les tokens.
Le client demandeur interroge le token endpoint	Le client contrôlé par l’attaquant peut attendre que l’utilisateur termine l’authentification.
Les tokens restent du matériel bearer sauf s’ils sont liés ou contraints	La détection doit couvrir l’usage des tokens et l’activité workload, pas seulement la connexion initiale.

La RFC 8628 parle explicitement du remote phishing. Elle décrit qu’un flux peut être initié sur un appareil en possession de l’attaquant, puis que la victime peut recevoir un message lui demandant de visiter l’URL de vérification et de saisir le code utilisateur. La RFC recommande que le serveur d’autorisation informe l’utilisateur qu’il autorise un appareil et qu’il confirme que cet appareil est en sa possession.

Différences avec les attaques voisines

Le device code phishing est proche d’autres attaques d’identité, mais son mécanisme est différent.

Attaque	Ce qui est abusé	Différence principale
Password spraying	Mots de passe faibles ou réutilisés sur de nombreux comptes	L’attaquant teste directement des mots de passe, souvent à faible volume par compte.
MFA fatigue	Pression sociale ou répétition de prompts MFA	L’attaquant possède souvent déjà les identifiants et pousse l’utilisateur à approuver.
Phishing de consentement OAuth	Consentement utilisateur ou admin pour une application malveillante	Le problème central est le consentement et les permissions de l’application.
Phishing AiTM	Reverse proxy qui capture identifiants, cookies ou tokens	L’attaquant proxifie le chemin de connexion; le device code phishing peut utiliser la vraie page Microsoft sans proxy.
Device code phishing	OAuth Device Authorization Grant	La victime autorise une session contrôlée par l’attaquant en saisissant un code utilisateur.

Ces distinctions changent les remédiations. Un tenant peut avoir de bons contrôles de mot de passe et rester exposé si le device code flow est largement autorisé. Un tenant peut imposer le MFA et quand même subir une compromission si des utilisateurs autorisent des sessions qu’ils ne contrôlent pas. À l’inverse, bloquer le device code flow ne remplace pas la correction des failles Conditional Access ou des politiques Identity Protection.

Pourquoi l’attaque fonctionne contre Entra ID

L’attaque fonctionne parce que la victime ne soumet pas son mot de passe à un domaine attaquant évident. Elle peut être envoyée vers une page Microsoft hébergée par Microsoft et voir des prompts d’authentification familiers. Les formations qui se limitent aux faux domaines ou aux pages de mot de passe suspectes ne couvrent pas complètement ce modèle.

Les recherches Microsoft 2025 et 2026 sur les campagnes de device code phishing décrivent le même comportement central : des acteurs abusent d’un flux d’authentification device code légitime, amènent la victime à authentifier la session de l’attaquant, puis reçoivent des tokens valides sans voler directement le mot de passe. Microsoft a aussi documenté en 2026 une évolution des campagnes, avec automatisation et génération dynamique de codes pour garder le code court valide au moment où l’utilisateur interagit avec le leurre.

La technique est particulièrement pertinente pour Entra ID et Microsoft 365 parce que les tokens obtenus peuvent être utilisés contre des ressources cloud comme Exchange Online, Microsoft Graph, SharePoint Online ou Teams, selon l’application, la ressource et les scopes concernés. Cela ne veut pas dire que toute connexion device code est malveillante. Cela veut dire que les défenseurs doivent savoir si ce flux est légitime dans leur tenant, pour quelles applications, depuis quels emplacements et sous quelles décisions Conditional Access.

Une erreur fréquente consiste à considérer une réussite MFA comme preuve finale de légitimité. Dans le device code phishing, l’événement MFA peut être réel. La question est de savoir si l’utilisateur voulait autoriser le client qui a reçu le token. La revue de connexion doit donc inclure le protocole d’authentification, l’application, la ressource, l’adresse IP, les détails d’appareil, le statut Conditional Access, les risques, les identifiants de session et l’activité workload après connexion.

Chaîne d’attaque

Une chaîne typique ressemble à ceci :

L’attaquant démarre une demande d’autorisation device code depuis une infrastructure ou un outil qu’il contrôle.
La plateforme d’identité retourne un code utilisateur, une URI de vérification, une expiration et un intervalle de polling.
L’attaquant transmet le code à la victime par email, chat, invitation collaborative, document leurre ou autre canal social.
La victime visite la page de vérification, saisit le code, se connecte et complète les étapes d’authentification requises.
Le client contrôlé par l’attaquant interroge le token endpoint et reçoit les tokens après autorisation.
L’attaquant utilise l’accès pour lire des mails, interroger Microsoft Graph, énumérer des données tenant, créer des règles de boîte aux lettres, accéder à des fichiers ou tenter d’autres actions permises par le token et les privilèges du compte.
Le défenseur peut voir une connexion device code réussie, suivie d’usage non interactif de tokens et d’activité workload.

La chaîne ne doit pas être réduite à un seul indicateur. Une valeur deviceCode dans le protocole d’authentification est importante, mais elle indique seulement le flux utilisé. Elle ne prouve pas l’intention malveillante à elle seule. L’investigation devient plus solide quand cet événement est corrélé avec un emplacement inhabituel, une application inattendue, des détails de risque, un accès à des ressources anormal, une création de règle email, de l’activité Graph, ou un utilisateur qui n’utilise normalement jamais ce flux.

Détection

Baseline de l’usage légitime

La détection doit commencer par une baseline de ce qui est légitime. Beaucoup d’organisations n’ont aucun besoin réel de device code flow. D’autres l’utilisent pour certains outils legacy, équipements de salle, workflows développeur ou scénarios d’enregistrement d’appareil. La première question est donc : ce flux est-il attendu ?

Dans les journaux de connexion Microsoft Entra exportés vers Log Analytics, la table SigninLogs inclut AuthenticationProtocol. Microsoft documente deviceCode comme valeur possible. La table inclut aussi OriginalTransferMethod, AppDisplayName, ResourceDisplayName, IPAddress, DeviceDetail, UserAgent, ConditionalAccessStatus, RiskLevelDuringSignIn, RiskEventTypes_V2, SessionId et UniqueTokenIdentifier.

Chasser le protocole device code

Une requête de base peut inventorier les usages réussis et échoués :

SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
          IPAddress, Location, DeviceDetail, UserAgent, ConditionalAccessStatus,
          RiskLevelDuringSignIn, RiskEventTypes_V2, ResultType, ResultDescription,
          SessionId, UniqueTokenIdentifier
| order by TimeGenerated desc

Utilisez cette requête comme point de départ, pas comme détection complète. Vérifiez si l’application et la ressource sont cohérentes avec le rôle de l’utilisateur. Un développeur qui authentifie un CLI connu depuis un réseau connu n’a pas la même signification qu’un utilisateur finance qui autorise soudainement un device code flow depuis un nouveau pays puis génère de l’activité Graph ou Exchange.

Pour une détection plus forte, comparez les connexions récentes à l’historique :

let lookback = 30d;
let recent = 1d;
let knownUsers = SigninLogs
| where TimeGenerated between (ago(lookback) .. ago(recent))
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| where ResultType == 0
| distinct UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(recent)
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| where ResultType == 0
| where UserPrincipalName !in (knownUsers)
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
          IPAddress, Location, DeviceDetail, UserAgent, ConditionalAccessStatus,
          RiskLevelDuringSignIn, RiskEventTypes_V2, SessionId, UniqueTokenIdentifier

Prioriser par contexte

Priorisez les événements avec ces caractéristiques :

premier device code flow observé pour l’utilisateur ou son département
application ou ressource inhabituelle pour le rôle de l’utilisateur
connexion depuis IP, ASN, pays ou réseau non associé à l’utilisateur
valeurs RiskEventTypes_V2 liées à une IP anonyme ou à du threat intelligence
device code flow réussi suivi d’usage non interactif de tokens depuis une infrastructure inattendue
nouvelles règles de boîte aux lettres, accès mail suspect, activité Graph inhabituelle, accès SharePoint ou Teams après la connexion
enregistrement ou jonction d’appareil proche dans le temps et non lié à un onboarding normal

Les identifiants corrélables Microsoft Entra rendent la phase post-authentification plus exploitable. Commencez avec SessionId ou UniqueTokenIdentifier dans le journal de connexion, puis corrélez avec les journaux Exchange Online, Microsoft Graph, SharePoint Online ou Teams. Microsoft documente ce modèle pour tracer les activités réalisées par une session ou un token précis.

Microsoft Defender et Entra ID Protection peuvent ajouter des signaux de confiance plus forte. La documentation Microsoft décrit des détections de risque comme IP anonyme, Microsoft Entra threat intelligence, anomalous token et suspicious API traffic. Traitez ces signaux comme de l’enrichissement et de la priorisation. Ils ne remplacent pas la question de fond : le device code flow aurait-il dû se produire ?

Remediation et durcissement

Bloquer ou contraindre le device code flow

Le contrôle le plus direct consiste à restreindre ou bloquer le device code flow avec Conditional Access. Microsoft recommande de se rapprocher autant que possible d’un blocage unilatéral, d’auditer d’abord l’usage existant, puis d’autoriser le flux uniquement pour des cas documentés et sécurisés. Pour les organisations qui n’utilisent pas ce flux, Microsoft fournit un modèle Conditional Access ciblant la condition “authentication flows”, sélectionnant le device code flow, puis bloquant l’accès.

Un chemin de durcissement réaliste :

Inventorier l’usage actuel du device code flow dans les journaux Entra.
Identifier les utilisateurs, applications, ressources, emplacements et dépendances légitimes.
Créer une politique Conditional Access en mode report-only ciblant le device code flow.
Exclure les comptes break-glass et les cas d’usage explicitement documentés.
Revoir l’impact de la politique et les journaux de connexion.
Passer la politique en mode enabled quand l’impact est compris.
Surveiller les tentatives bloquées et les exclusions inattendues.

Vérifier la compatibilité avant enforcement

Il existe une caveat importante. Microsoft indique que si l’organisation utilise le device code flow avec le Device Registration Service et qu’une politique authentication flows cible toutes les ressources, il peut être nécessaire d’exclure la ressource Device Registration Service pour éviter un impact. Microsoft documente l’ID client de ce service et explique comment filtrer les journaux pour cette ressource et le device code flow. Ne bloquez pas aveuglément toutes les ressources avant de vérifier les dépendances d’enregistrement d’appareil.

Les grant controls Conditional Access doivent aussi être interprétés précisément. Microsoft documente que, quand le device-code OAuth flow est utilisé, les grant controls exigeant un appareil managé ou un état d’appareil ne sont pas supportés de la même manière, car l’appareil qui effectue l’authentification ne peut pas fournir son état à l’appareil qui fournit un code. Un modèle basé seulement sur l’exigence d’appareil compliant ou hybrid-joined peut donc ne pas se comporter comme prévu pour ce flux. Utilisez la condition authentication flows pour contrôler le flux lui-même.

Réduire le blast radius après autorisation

Les contrôles complémentaires comptent parce que le device code phishing est souvent un chemin vers un incident d’identité plus large :

exiger une authentification phishing-resistant pour les rôles privilégiés quand c’est supporté, sans supposer que la force d’authentification bloque chaque scénario device-code
utiliser Conditional Access basé sur le risque et les politiques Identity Protection pour challenger ou bloquer les sessions risquées
limiter l’exposition des comptes privilégiés et éviter les comptes quotidiens avec rôles tenant larges, comme dans les revues Accès privilégié Azure
revoir le consentement applicatif et les permissions pour réduire l’impact d’un token abusé
surveiller Exchange, Graph, SharePoint et Teams après des connexions suspectes
utiliser Safe Links, contrôles anti-phishing et workflows de signalement utilisateur pour réduire la livraison des leurres et accélérer le triage
envisager la token protection là où elle est supportée, en comprenant que la couverture dépend du client, de la plateforme et du workload

Réponse à incident après Device Code Phishing

Préserver les preuves de connexion et de workload

Lorsqu’un événement est suspecté, la réponse doit se concentrer sur le confinement des tokens et le périmètre workload, pas seulement sur la réinitialisation du mot de passe.

Capturez d’abord les preuves de connexion : utilisateur, application, ressource, IP, emplacement, AuthenticationProtocol, OriginalTransferMethod, résultat Conditional Access, détails de risque, SessionId et UniqueTokenIdentifier. Préservez le message de phishing original si disponible, y compris headers et URLs, mais ne comptez pas seulement sur la réputation d’URL puisque la victime peut avoir été envoyée vers une vraie page Microsoft.

Révoquer les sessions avant de déclarer le confinement

Révoquez ensuite les sessions actives. Microsoft Graph revokeSignInSessions invalide les refresh tokens émis aux applications pour un utilisateur et les cookies de session navigateur en réinitialisant le timestamp de validité de session de l’utilisateur. Microsoft note qu’il peut y avoir un délai de quelques minutes avant révocation et que les utilisateurs externes s’authentifient via leur tenant d’origine. Si l’identité compromise est un compte invité, coordonnez le chemin côté tenant d’origine au lieu de supposer le même comportement. L’exposition des invités doit être revue à part, notamment quand les comptes invités Azure sont oubliés.

Réinitialisez les identifiants seulement si l’investigation le justifie. Le device code phishing peut compromettre des tokens sans voler directement le mot de passe. Une réinitialisation peut être nécessaire en cas de vol d’identifiants, règles mailbox, modification MFA, enregistrement d’appareil suspect ou autre chemin de compromission. Le point clé : un reset de mot de passe seul ne suffit pas si les refresh tokens et sessions actives restent valides.

Délimiter l’activité aval

Délimitez ensuite l’activité aval. Utilisez les identifiants corrélables pour tracer Exchange Online, Microsoft Graph, SharePoint Online et Teams associés à la session ou au token. Recherchez création de règles mailbox, lectures et exports de messages, téléchargements de fichiers, changements OAuth app, modifications de groupes, changements de méthodes d’authentification, enregistrements d’appareils et actions administratives.

Enfin, fermez l’écart de contrôle. Si le device code flow n’était pas nécessaire, bloquez-le. S’il était nécessaire pour un workflow étroit, contraignez-le à des utilisateurs, applications, emplacements et ressources documentés. Puis alertez sur tout usage hors de ce modèle approuvé.

Validation après durcissement

Valider la prévention

La validation doit prouver à la fois la prévention et la visibilité.

Pour la prévention, confirmez que la politique Conditional Access ciblant les authentication flows est activée et s’applique aux utilisateurs et ressources voulus. Testez avec un compte non privilégié dans un chemin contrôlé avant un déploiement large. Un device code flow bloqué doit apparaître dans les journaux de connexion avec la décision Conditional Access correspondante. Les comptes break-glass doivent rester exclus, mais cette liste doit être revue régulièrement.

Pour la compatibilité, vérifiez l’enregistrement d’appareil et les outils legacy légitimes. Si le Device Registration Service utilise le device code flow, validez l’exclusion documentée et confirmez que seule la ressource voulue est exclue. Ne créez pas d’exclusions larges qui recréent l’exposition initiale.

Valider la supervision et la réponse

Pour la détection, confirmez que les connexions device code sont visibles dans le portail Entra et dans Log Analytics. Vérifiez que AuthenticationProtocol, OriginalTransferMethod, application, ressource, IP, détails d’appareil, champs de risque, SessionId et UniqueTokenIdentifier sont disponibles aux analystes. Confirmez que les analystes peuvent pivoter depuis une connexion vers les journaux Exchange, Graph, SharePoint et Teams lorsque votre licence et votre configuration de logs le permettent.

Pour la réponse, jouez un exercice de table. Partez d’une connexion deviceCode suspecte et exigez que l’analyste identifie l’utilisateur, l’application, la ressource, l’ID de session, l’identifiant de token, l’activité workload aval, le chemin de révocation des sessions et la preuve finale de confinement. C’est la différence entre avoir un contrôle et savoir l’exploiter pendant un incident d’identité.

Comment EtcSec détecte l’exposition liée

EtcSec doit traiter le device code phishing comme un chemin d’attaque identité et un problème de posture, pas seulement comme un problème email. Les findings à forte valeur sont les conditions qui transforment un événement de social engineering centré sur les tokens en compromission tenant.

Les expositions pertinentes incluent les politiques Conditional Access qui ne restreignent pas le device code flow, l’absence ou la faiblesse des politiques de risque, les comptes privilégiés hors isolation administrative forte, les rôles admin permanents excessifs, les comptes invités sans contrôles forts et les app registrations trop permissives. Ces zones déterminent directement le blast radius d’un device code phishing réussi.

Pour les équipes techniques, la sortie utile n’est pas un avertissement générique sur le phishing. C’est une liste courte d’identités et politiques à corriger : qui peut utiliser le device code flow, quels utilisateurs sont exemptés, si les sign-ins risqués sont bloqués ou seulement journalisés, quels comptes privilégiés peuvent autoriser des sessions cloud depuis des contextes moins fiables, et quelles applications ou permissions déléguées rendraient une session volée plus dangereuse. Cette lecture posture doit aussi entrer dans le durcissement du tenant Azure.

Contrôles associés

Contrôle	Ce qu’il réduit	Preuve de validation
Politique Conditional Access authentication flows	Usage large du device code flow	Revue report-only, puis connexions `deviceCode` bloquées hors périmètre approuvé.
Conditional Access basé sur le risque	Abus de token depuis emplacements ou signaux threat intelligence risqués	Politiques de risque utilisateur/sign-in et revue des détections de risque.
Isolation de l’accès privilégié	Blast radius si un utilisateur privilégié est phishé	Comptes privilégiés séparés des comptes quotidiens et protégés par des contrôles plus forts.
Gouvernance du consentement et des permissions applicatives	Impact de l’abus OAuth ou token	Revue des app registrations, permissions déléguées et workflows d’admin consent.
Corrélation d’audit cross-workload	Temps nécessaire pour délimiter l’abus de token	Pivots `SessionId` et `UniqueTokenIdentifier` vers Exchange, Graph, SharePoint et Teams.
Signalement utilisateur et protections email	Livraison des leurres et délai de triage	Workflow de signalement, politique Safe Links et preuves d’investigation message.

Le device code phishing est efficace parce qu’il se situe dans l’écart entre un design d’authentification légitime et l’intention réelle de l’utilisateur. La correction durable n’est pas un slogan sur le MFA. C’est une posture tenant où les flux d’authentification risqués sont contraints, les connexions device-code suspectes sont visibles, l’activité token peut être tracée et l’accès privilégié ne dépend pas d’utilisateurs qui prennent toujours la bonne décision sous pression sociale.

Device Code Phishing : comment le flux OAuth compromet les comptes Entra ID