Attaques par code d'appareil dans Azure : de l'exploitation à la détection

TL; DR

Qu'est-ce que c'est: L'hameçonnage par code d'appareil est une technique d'abus OAuth où les attaquants initient un flux d'authentification légitime par code d'appareil contre Microsoft. Entra ID, puis tromper un utilisateur en lui faisant saisir le code résultant sur la véritable page login.microsoft.com/devicelogin, fournissant ainsi à l'attaquant un jeton d'accès valide sans jamais capturer de mot de passe. 

Pourquoi c'est important: En moins d'un an, cette technique est passée d'une approche étatique (STORM-2372, liée à la Russie et active depuis août 2024) à un kit d'attaque standard. Le kit d'outils EvilTokens PhaaS, révélé par Microsoft en avril 2026, automatise l'intégralité du processus, contournant la période d'expiration des codes de 15 minutes et exécutant 10 à 15 campagnes personnalisées toutes les 24 heures. 

Pourquoi est-ce difficile à détecter : Il n'y a ni fausse page de connexion, ni domaine usurpé, ni capture d'identifiants, ni charge utile malveillante à analyser. La seule URL concernée est login.microsoft.com/devicelogin. L'authentification multifacteur (MFA) s'effectue correctement sur l'appareil réel de la victime ; par conséquent, tous les signaux que les passerelles de messagerie, les solutions EDR et les produits de protection d'identité sont censés détecter sont négatifs. 

En quoi cela diffère d'AiTM : Les attaques de type « adversaire au milieu » utilisent un proxy pour faire apparaître une fausse page de connexion et voler les cookies de session. L'hameçonnage par code sur l'appareil, quant à lui, contourne complètement le proxy : la victime s'authentifie directement sur la véritable page Microsoft, ce qui rend impossible la détection, le blocage ou la neutralisation de l'attaque par une infrastructure AiTM. 

Signal de détection du noyau : Une connexion réussie utilisant l'authentification par code d'appareil, accédant à une ressource client Microsoft (par exemple, Azure CLI, Microsoft Office) et effectuée depuis un emplacement inhabituel ou par une entité n'utilisant généralement pas de code d'appareil, est suspecte. Ce schéma est extrêmement rare dans les flux de travail légitimes des utilisateurs finaux ; pour de nombreuses organisations, chaque occurrence justifie une investigation. 

Réponse immédiate en cas de détection : Révoquez immédiatement l'accès de l'utilisateur (voir Documentation de MicrosoftDésactivez l'utilisateur compromis et supprimez ses rôles. Notez que la révocation des jetons d'actualisation n'invalide pas les jetons d'accès déjà émis ; ceux-ci restent valides jusqu'à leur expiration. Recherchez toute activité malveillante provenant de la session suspecte. La révocation des jetons ne suffit pas : l'attaquant a peut-être déjà établi une présence persistante.

Mesures politiques clés : Bloquez le flux de code d'appareil via l'accès conditionnel pour tout utilisateur n'ayant pas de besoin métier documenté. Les recommandations de Microsoft préconisent désormais cette pratique. La plupart des utilisateurs en entreprise, y compris la plupart des développeurs, n'utilisent quasiment jamais cette méthode d'authentification légitime. Lorsque l'authentification par code d'appareil est réellement requise, limitez-la aux emplacements de confiance via le géorepérage. 

Ce que les équipes de sécurité doivent savoir sur le phishing par code d'appareil

Un acteur de menace étatique (STORM-2372, lié aux intérêts de l'État russe) mène depuis août 2024 une campagne d'hameçonnage de code d'appareil ciblant des agences gouvernementales, des entrepreneurs de défense, des ONG, des organisations de télécommunications, d'énergie et de soins de santé dans le monde entier. 

Il ne s'agit pas d'une vulnérabilité que Microsoft peut corriger ; c'est une caractéristique inhérente au protocole de code de périphérique OAuth 2.0, pris en charge par tous les principaux fournisseurs d'identité. L'attaque contourne authentification multi-facteur (la victime remplit le formulaire volontairement), ne laisse aucune infrastructure suspecte susceptible d'être détectée par les outils de sécurité (la seule URL est microsoft.com), et les jetons obtenus résistent aux réinitialisations de mot de passe. Les passerelles de messagerie classiques, les CASB et les analyseurs d'URL considèrent le lien d'attaque comme sûr car il is sûr — il renvoie à la page de connexion de Microsoft. 

Après la compromission, on a observé que les attaquants enregistraient des dispositifs persistants en moins de 10 minutes, cartographiaient les structures organisationnelles via Microsoft Graph, filtraient les cibles de grande valeur (rôles financiers, de direction et administratifs), créaient des règles de boîte de réception cachées et exfiltraient les détails des virements bancaires et la correspondance des dirigeants — la matière première pour la compromission de la messagerie professionnelle et la fraude financière. 

Action organisationnelle immédiate : bloquer le flux d’authentification par code d’appareil via l’accès conditionnel pour tous les utilisateurs qui n’en ont pas explicitement besoin, assurez-vous que votre réponse à l'incident Ce guide inclut la révocation des jetons OAuth (et pas seulement la réinitialisation des mots de passe) et le déploiement de la liaison de jetons pour les comptes stratégiques. Consultez les recommandations stratégiques ci-dessous pour obtenir le cadre de décision complet.

Que se passe-t-il si l'URL d'hameçonnage est microsoft.com ?

L'hameçonnage par code d'appareil est une technique de vol de jetons qui exploite l'implémentation par Microsoft du flux de code d'appareil OAuth. Contrairement à la plupart des campagnes d'hameçonnage, les attaquants redirigent la victime vers une véritable URL Microsoft – et non vers un domaine similaire, un proxy inverse ou un site de type typosquatt. La victime se connecte à la page de connexion Microsoft officielle, effectue l'authentification multifacteur (MFA) et voit un écran de confirmation normal. Cependant, les jetons d'authentification – une méthode d'authentification supplémentaire lui conférant des privilèges – sont discrètement transmis à l'attaquant sur une machine totalement différente. Aucun vol d'identifiants, aucun détournement de session, aucune infrastructure de l'attaquant à détecter ou à neutraliser. Il s'agit simplement d'un flux OAuth légitime fonctionnant comme prévu, mais au profit d'une personne mal intentionnée. 

Elle est aujourd'hui exploitée à grande échelle, et bien que le défaut sous-jacent réside dans la norme OAuth elle-même, Entra IDC’est la mise en œuvre de cette technologie qui la rend si facile à instrumentaliser. Microsoft lui a attribué un campagne en cours contre STORM-2372, un acteur de la menace considéré avec un degré de confiance modéré comme étant aligné sur les intérêts de l'État russe. L'opération a ciblé des agences gouvernementales, des entreprises de défense, des ONG, des fournisseurs de télécommunications, des sociétés énergétiques et des organismes de santé sur plusieurs continents depuis au moins août 2024. En avril 2026, Microsoft a documenté une escalade significative : l'émergence d'EvilTokens, une boîte à outils de phishing en tant que service (PhaaS) basée sur l'IA qui automatise l'exploitation abusive du code des appareils de bout en bout— Générer des codes en temps réel à la demande pour contourner la fenêtre d'expiration de 15 minutes, concevoir des leurres hyper-personnalisés grâce à l'IA générative et exécuter 10 à 15 campagnes distinctes toutes les 24 heures. Cette technique, autrefois réservée aux États, est devenue un outil d'attaque courant en moins d'un an.  

Dans cet article de blog, nous allons détailler précisément le fonctionnement de cette attaque au niveau du protocole et réaliser une simulation pratique avec des données réelles. Entra ID Les captures de journaux fournissent des requêtes de recherche KQL que vous pouvez exécuter dès aujourd'hui dans votre propre environnement, et développent la logique de détection dérivée des journaux générés par l'attaque. 

Quel est le flux de code du périphérique ?

L'autorisation d'appareil OAuth 2.0, définie dans la RFC 8628 et publiée en août 2019, est un flux d'authentification conçu pour les appareils dépourvus de navigateur ou disposant de capacités d'entrée limitées : téléviseurs connectés, consoles de jeux, capteurs IoT, affichage dynamique, équipements de salles de conférence et outils en ligne de commande tels qu'Azure CLI ou AWS CloudShell. Au lieu de se connecter directement sur l'appareil, l'utilisateur voit apparaître un court code alphanumérique et une URL ; il ouvre cette URL sur un autre appareil (généralement un téléphone ou un ordinateur portable), saisit le code et finalise l'authentification, y compris toute demande d'authentification multifacteur (MFA). Pendant ce temps, l'appareil d'origine interroge le serveur d'autorisation en arrière-plan et reçoit un jeton d'accès une fois l'autorisation de l'utilisateur obtenue. 

Ce flux est largement pris en charge : Microsoft Entra IDGoogle, GitHub, Okta et la plupart des principaux fournisseurs d'identité l'implémentent, et il s'agit de la méthode de connexion par défaut pour Azure CLI (`az login`). Bien qu'il ne s'agisse pas du flux OAuth le plus courant dans les applications web quotidiennes, il constitue le mécanisme standard pour les environnements sans interface graphique et à entrées limitées, et est largement utilisé dans les outils d'entreprise, les pipelines DevOps et les plateformes de streaming grand public. 

Les risques liés à la conception sont inhérents à la norme, mais Entra IDL'implémentation de Microsoft les amplifie, ce qui explique pourquoi tous les kits de phishing actuellement utilisés ciblent Microsoft. Microsoft recommande désormais de bloquer ce flux via l'accès conditionnel lorsqu'il n'est pas explicitement requis. 

Le défaut de conception critique : Le code d'accès est le seul lien entre le périphérique d'interrogation et l'utilisateur qui s'authentifie. Microsoft ne vérifie pas que le périphérique d'interrogation est bien celui que l'utilisateur souhaitait autoriser. Il ne vérifie ni l'identité du périphérique, ni sa localisation réseau, ni son niveau de confiance. Seul celui qui possède le code et l'interroge obtient les jetons. 

Analyse des attaques

La simplicité d'utilisation du flux de codes d'appareil est précisément ce qui le rend vulnérable. Le protocole n'établissant jamais de lien direct entre l'appareil d'interrogation et l'utilisateur authentifié, un attaquant qui obtient un code d'appareil valide peut discrètement récupérer les jetons d'accès et d'actualisation dès que la victime se connecte. Aucune infrastructure de phishing, aucune interception d'identifiants, aucun contournement de l'authentification multifacteur : il s'agit simplement d'une page de connexion Microsoft légitime, fonctionnant comme prévu, mais au profit d'une personne mal intentionnée. 

Comment les attaquants instrumentalisent ce flux

Le point de terminaison du code de périphérique de Microsoft est ouvert par conception : pas de secret client, pas d’enregistrement de périphérique, pas de preuve de possession.

Un attaquant envoie une simple requête POST non authentifiée à l'aide d'un identifiant client Microsoft connu (Azure CLI, Microsoft Office ou tout autre client public Microsoft – ces identifiants sont publics, facilement répercutables et Microsoft ne peut les révoquer sans compromettre le fonctionnement des outils légitimes qui en dépendent) et reçoit instantanément un code d'appareil valide. Ces identifiants clients Microsoft sont une aubaine pour l'attaquant : ils sont approuvés par défaut, bénéficient d'un consentement étendu et sont disponibles en permanence. L'identifiant du locataire peut être facilement obtenu une fois que l'attaquant a identifié le domaine cible. 

curl -X POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/devicecode \ 
  -d "client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46&scope=https://management.azure.com/.default" 

L'attaquant dissimule l'URL de vérification et le code utilisateur dans un appât convaincant (invitation à une réunion Teams, notification de partage de document, alerte de sécurité informatique) et le diffuse par e-mail, Teams, WhatsApp, Signal ou tout autre moyen. STORM-2372 a notamment été observé en train d'usurper les notifications de réunions Teams et les invitations de groupes WhatsApp. Pendant que la victime lit l'e-mail, le script de l'attaquant interroge déjà le système. Dès que la victime s'authentifie, la boucle d'interrogation reçoit la paire de jetons complète. 

Pourquoi les contrôles de sécurité existants échouent-ils ?

Ce qui rend l'hameçonnage par code d'appareil particulièrement dangereux, c'est le nombre de défenses conventionnelles qu'il neutralise simultanément : 

Du point de vue de la plateforme d'identité de Microsoft, il s'agissait d'une connexion parfaitement légitime. 

• L'authentification multifacteur (MFA) est détournée, et non contournée. La victime effectue l'authentification multifacteur normalement. Le jeton résultant contient l'attribut mfaAuthenticated=true.
• Aucune infrastructure d'attaquant détectable. La seule URL de la chaîne d'attaque est microsoft.com ; elle bénéficie d'une réputation irréprochable auprès de tous les services de veille sur les menaces et possède un certificat EV valide. Votre passerelle de messagerie, votre CASB, votre sandbox d'URL et votre réécriture de liens sécurisée par proxy l'inspectent tous et la jugent sûre.
• Les jetons d'actualisation survivent à la réinitialisation du mot de passe. Contrairement aux cookies de session (que les attaques AiTM dérobent), les jetons d'actualisation OAuth sont conçus pour un accès permanent et multi-appareils. Ils peuvent être échangés silencieusement contre de nouveaux jetons d'accès sans intervention de l'utilisateur ni nouvelle demande d'authentification multifacteur. La réinitialisation du mot de passe de la victime ne les révoque pas : l'attaquant conserve l'accès tant que les jetons ne sont pas explicitement révoqués.
• L'empreinte numérique est minimale. Les journaux de connexion indiquent une connexion réussie avec un niveau de risque nul et une authentification multifacteur réussie. Aucune tentative de connexion infructueuse multiple, aucune modification d'identifiants ni création d'objet suspect n'ont été constatées. Le seul signal potentiel est une actualisation de jeton non interactive provenant d'une adresse IP inattendue, et ce uniquement si vous effectuez une surveillance spécifique. 

Important : Il ne s’agit pas d’une attaque de type « adversaire du milieu » (AiTM). Les outils AiTM comme EvilProxy interceptent les sessions via un proxy inverse, capturant les cookies après l’authentification multifacteur (MFA). Cela nécessite une infrastructure contrôlée par l’attaquant (domaines, certificats, serveurs actifs), autant d’éléments qui laissent des traces. Le phishing par code sur appareil ne requiert qu’une simple requête HTTP POST et un courriel convaincant. Les jetons obtenus ont une durée de vie plus longue et une portée plus large que les cookies de session, et aucune infrastructure de l’attaquant ne peut être analysée ou neutralisée.

Point de vue de l'attaquant : Déroulement étape par étape

Pour démontrer la chaîne d'attaque complète, nous l'avons reproduite dans un environnement de laboratoire contrôlé, à l'aide d'un locataire de recherche dédié (glich.net). La simulation modélise un adversaire opérant sous le nom d'utilisateur helpdesk@glich.net ciblant l'utilisateur roni@glich.net avec un leurre d'hameçonnage basé sur le code de l'appareil, déguisé en… demande de vérification des références. 

Phase 1 : Génération du code du périphérique

L'attaquant envoie une requête POST à Entra IDLe point de terminaison d'autorisation de l'appareil utilise l'ID client public de l'interface de ligne de commande Azure (Azure CLI), reçoit un code d'appareil et un code utilisateur, et commence immédiatement à interroger le point de terminaison du jeton. 

Phase 2 : Conception et diffusion de l’appât de phishing

L'attaquant intègre le code de l'appareil et l'URL login.microsoft.com/devicelogin dans un courriel à l'allure urgente, déguisé en invitation à une réunion Teams, en demande de vérification d'identifiants ou en alerte de sécurité informatique. 

Phase 3 : Approbation de l'utilisateur

L'utilisateur reçoit le courriel et accorde l'accès à l'attaquant. 

Lorsque la victime fournit le code et les identifiants dans son navigateur, la boucle d'interrogation récupère les jetons. 

Phase 4 : Post-exploitation

Muni d'un jeton d'accès valide et d'un jeton d'actualisation à longue durée de vie, l'attaquant a authentifié son accès à l'environnement Microsoft 365 de la victime — et le temps presse. Analyse d'avril 2026 Une campagne d'hameçonnage par code malveillant utilisant l'IA (évolution directe de l'activité STORM-2372 signalée pour la première fois en février 2025) a permis de documenter le mode opératoire post-compromission mis en œuvre par les acteurs malveillants. La progression suit un schéma constant : 

Enregistrement de l'appareil pour la persistance 

Dans certains cas, dans les 10 minutes suivant l'intrusion initiale, les acteurs malveillants ont enregistré de nouveaux appareils sur le compte compromis afin de générer un jeton d'actualisation principal (PRT). Ce PRT offre un accès permanent via l'authentification unique (SSO) qui résiste aux révocations individuelles de jetons, conférant ainsi à l'attaquant un accès persistant bien plus difficile à détecter et à neutraliser qu'un simple jeton d'actualisation volé. 

Reconnaissance graphique Microsoft 

À l'aide des jetons volés, les attaquants ont interrogé l'API Microsoft Graph afin de cartographier par programmation les structures organisationnelles internes, les rôles des utilisateurs et les attributions d'autorisations. Cette reconnaissance automatisée leur a permis d'identifier rapidement quels comptes compromis avaient accès à des ressources sensibles et où. les déplacements verticaux et élévations de privilèges était possible. 

Filtrage des cibles à haute valeur ajoutée 

Plutôt que d'exploiter indistinctement tous les comptes compromis, les cybercriminels ont ciblé les victimes les plus importantes, notamment les personnes occupant des postes à responsabilité dans les domaines financier, de la direction ou de l'administration. Cette approche sélective a permis de concentrer les actions post-compromission les plus intrusives sur les comptes présentant le potentiel de gain le plus élevé. 

Règles de boîte de réception malveillantes pour la persistance 

Pour certaines cibles, les acteurs malveillants ont créé des règles de messagerie dans Microsoft Office afin de rediriger, masquer ou supprimer les courriels entrants. Ces règles avaient un double objectif : maintenir un accès permanent aux communications par courriel sans avoir à se reconnecter constamment et dissimuler les preuves de la compromission à la victime (par exemple, la suppression automatique des alertes de sécurité ou des notifications de réinitialisation de mot de passe). 

Exfiltration ciblée d'emails 

Les activités les plus intrusives étaient réservées aux utilisateurs disposant d'un pouvoir financier. Les cybercriminels effectuaient des recherches approfondies dans les communications par courriel, ciblant notamment les détails des virements bancaires, les factures en attente et la correspondance des dirigeants – autant d'éléments essentiels pour la compromission de messagerie professionnelle (BEC) et la fraude financière. 

Exécution différée pour échapper à la détection 

Tous les acteurs malveillants n'ont pas agi immédiatement. Dans plusieurs cas observés, les attaquants ont attendu des heures après la compromission initiale avant d'entreprendre toute action post-exploitation — une technique d'évasion délibérée visant à dissocier l'événement d'authentification suspect de l'activité malveillante dans les journaux, rendant ainsi la corrélation temporelle plus difficile pour les équipes de défense. Au moment où l'activité malveillante débute, l'événement d'authentification qui l'a permise a déjà disparu des files d'attente de triage à court terme et des fenêtres d'alerte en temps réel. Les équipes de défense examinant une connexion suspecte à T+0 peuvent ne constater aucune activité ultérieure et la classer comme bénigne — pour ensuite voir l'attaquant commencer l'exfiltration de données des heures plus tard, lorsque l'alerte initiale n'est plus visible. Ce décalage délibéré entre l'accès et l'action explique pourquoi le phishing de code sur appareil est particulièrement résistant à la détection temporelle : la violation et son impact n'apparaissent jamais simultanément, sauf si les équipes de défense effectuent une corrélation explicite sur des périodes prolongées. 

Point de vue du défenseur : que devons-nous rechercher dans les journaux ?

Pour les chasseurs de menaces et les analystes SOC — de vrais Entra ID Captures d'écran des journaux montrant exactement ce qu'il faut rechercher. 

Nous avons capturé Entra ID Les entrées du journal de connexion générées par ce flux sont enregistrées. Les requêtes d'interrogation de l'attaquant (les réponses répétées « authorization_pending ») ne sont pas enregistrées. Seule l'émission réussie du jeton génère des entrées, réparties sur deux onglets : 

Entrée 1 : Interactif (côté navigateur/victime)

La victime s'est rendue sur microsoft.com/devicelogin et a approuvé le code. L'authentification multifacteur a été validée grâce à une session précédente : la victime n'a rencontré aucune difficulté après avoir cliqué sur « Approuver ». 

Entrée 2 : Non interactive (Client d’interrogation/Côté attaquant)

Comparaison côte à côte

Le principe de détection est clair : les deux entrées partagent un identifiant de corrélation, mais l’agent utilisateur et potentiellement l’adresse IP diffèrent. L’entrée relative au navigateur indique Chrome sur Mac ; celle relative à l’interrogation indique curl. Lors d’une attaque réelle, cette paire de journaux présentant ces différences – notamment une séparation géographique révélatrice d’un déplacement impossible ou d’une source suspecte – constitue le signal principal sur lequel baser le système d’alerte. 

L'enrichissement de l'adresse IP du serveur d'interrogation à l'aide de flux de renseignements sur les menaces, de listes de réputation d'adresses IP, de valeurs d'agent utilisateur suspectes (comme l'exemple « curl » dans les journaux) et de métadonnées ASN renforce la détection : l'infrastructure des attaquants provient souvent de fournisseurs d'hébergement, de VPN commerciaux ou d'ASN sans présence légitime parmi vos utilisateurs. Une adresse IP d'interrogation qui correspond à un ASN connu pour être malveillant ou qui figure sur une liste noire est un indicateur très fiable, même en l'absence de correspondance d'adresse IP entre les deux serveurs.

Détection du phishing par code d'appareil dans votre environnement

Pour les chasseurs de menaces : copiez-collez les requêtes KQL pour Azure Monitor, Microsoft Sentinel ou tout SIEM compatible KQL. 

Les requêtes KQL suivantes peuvent être utilisées pour détecter les activités d'hameçonnage de code d'appareil dans votre système. Entra ID Journaux de connexion. Ils sont conçus pour être prêts à être copiés-collés dans Azure Monitor, Microsoft Sentinel ou tout SIEM compatible KQL. 

L'objectif est de détecter les abus de code sur les appareils le plus près possible de leur déclenchement. Chaque requête ci-dessous cible un signal différent : schémas d'utilisation anormaux du code, incohérences d'adresse IP ou d'agent utilisateur entre les phases d'interaction et d'interrogation, et génération massive de code pouvant indiquer une campagne active. 

1. Afficher tous les événements de flux de code du périphérique pour analyse de corrélation

Cette requête récupère les deux segments (interactifs et non interactifs) de chaque flux de code de périphérique. Triez ou fusionnez-les par CorrelationId pour les comparer côte à côte et rechercher les incohérences d'adresse IP ou d'agent utilisateur : le signal de détection principal. 

SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| project CorrelationId, UserPrincipalName, IPAddress, UserAgent, 
          IsInteractive, TimeGenerated, AppDisplayName, 
          AuthenticationProtocol 
| order by CorrelationId, TimeGenerated asc

2. Détecter les flux de code des périphériques présentant une incompatibilité d'adresse IP entre les segments

Cette requête combine les entrées interactives et non interactives de chaque flux de code d'appareil par CorrelationId et signale les flux dont les adresses IP diffèrent, ce qui indique fortement que le client d'interrogation n'est pas le même appareil ou le même emplacement que le navigateur d'authentification. Pour des alertes plus précises, enrichissez l'adresse IP d'interrogation avec des recherches ASN et des flux de renseignements sur les menaces : signalez les flux où l'adresse IP d'interrogation appartient à un fournisseur d'hébergement, un VPN commercial ou une plage d'adresses IP sur liste noire, même si les adresses IP se trouvent dans le même pays. 

let interactive = SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    and IsInteractive == true 
| project CorrelationId, UserPrincipalName, BrowserIP = IPAddress, 
          BrowserUA = UserAgent, TimeGenerated; 
let polling = AADNonInteractiveUserSignInLogs 
| join kind=inner interactive on CorrelationId 
| project CorrelationId, PollingIP = IPAddress, PollingUA = UserAgent; 
interactive 
| join kind=inner polling on CorrelationId 
//| where BrowserIP != PollingIP 
| project TimeGenerated, UserPrincipalName, BrowserIP, BrowserUA, 
          PollingIP, PollingUA, CorrelationId 

3. Surveiller la génération de code périphérique en grand volume à partir d'une seule application

Un attaquant menant une campagne d'hameçonnage par code d'appareil génère de nombreux codes en un court laps de temps. Cette requête met en évidence les applications présentant un nombre anormalement élevé de flux de codes d'appareil provenant d'utilisateurs différents au cours des dernières 24 heures. 

SigninLogs 
| where TimeGenerated > ago(24h) 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| summarize DistinctUsers = dcount(UserPrincipalName), 
            FlowCount = count() 
    by AppDisplayName, AppId 
| where DistinctUsers > 3  // adjust threshold to your environment 
| order by DistinctUsers desc

Ajustez les seuils et les plages horaires en fonction de votre environnement. Les organisations qui utilisent légitimement les flux de code d'appareil (par exemple, pour Azure CLI ou l'intégration d'appareils IoT) doivent établir une liste de clients valides et les exclure. 

Une paire de journaux suspecte a été trouvée – et maintenant ?

Tous les flux de code réussis avec une incompatibilité d'agent utilisateur ne sont pas malveillants ; des scénarios légitimes existent (par exemple, un développeur exécutant `az login` sur un serveur distant et s'authentifiant depuis son ordinateur portable). Il est conseillé d'enquêter avant de déclencher une alerte. Cependant, si les journaux présentent des signes d'abus (une adresse IP de sondage inconnue, un ASN de fournisseur d'hébergement, un utilisateur n'ayant pas initié le flux de code), considérez cela comme un vol de jeton confirmé et exécutez immédiatement les étapes suivantes : 

1. Révoquer immédiatement tous les jetons d'actualisation 

Révoquez immédiatement l'accès de l'utilisateur (voir Documentation de MicrosoftDésactivez l'utilisateur compromis et supprimez ses rôles. Cela invalide tous les jetons d'actualisation actifs et empêche l'attaquant d'obtenir discrètement de nouveaux jetons d'accès. Procédez ainsi avant de réinitialiser le mot de passe : une réinitialisation de mot de passe seule ne révoque pas les jetons d'actualisation OAuth. 

2. Mettre fin aux sessions actives 

La révocation des jetons d'actualisation n'invalide pas les jetons d'accès déjà émis ; ceux-ci restent valides jusqu'à leur expiration. Si votre locataire utilise l'évaluation continue des accès (CAE), forcez une réévaluation de toutes les sessions actives de l'utilisateur afin de vider le cache des jetons. Pour les charges de travail n'utilisant pas la CAE, révoquez les sessions de l'utilisateur dans Entra ID (Utilisateurs → Révoquer les sessions) pour invalider tous les jetons mis en cache sur les services Microsoft 365. 

3. Vérifier les mécanismes de persistance 

Recherchez les appareils nouvellement enregistrés, les règles de boîte de réception, les consentements d'applications OAuth et toute autre action effectuée au cours de la même session. Portez une attention particulière aux enregistrements d'appareils (qui génèrent des jetons d'actualisation principaux), aux règles de boîte de réception qui transfèrent, redirigent ou suppriment des courriels, ainsi qu'aux modifications des méthodes d'authentification (par exemple, l'ajout d'un nouveau numéro de téléphone pour l'authentification multifacteur). La révocation du jeton ne suffit pas : l'attaquant a peut-être déjà établi une persistance ; supprimez tout élément que l'utilisateur ne reconnaît pas. 

4. Contenir mouvements latéraux 

Si l’utilisateur compromis détient des rôles privilégiés (administrateur général, administrateur Exchange, etc.) ou a accès à des ressources sensibles, restreignez son compte via l’accès conditionnel pendant la durée de l’enquête. Vérifiez si l’attaquant a utilisé les jetons volés pour accéder à des ressources SharePoint, Teams ou Azure : les journaux d’audit unifiés et d’activité Microsoft Graph indiqueront l’étendue de cet accès. 

5. Préservez les preuves et alertez le SOC 

Exportez les entrées pertinentes du journal de connexion (connexions interactives et non interactives, liées par l'identifiant de corrélation), l'activité récente du journal d'audit de l'utilisateur, ainsi que les règles de messagerie et les enregistrements d'appareils supprimés. Ces éléments sont essentiels pour déterminer l'étendue de l'impact et pour répondre aux exigences de déclaration d'incidents ultérieurs.

Recommandations et bonnes pratiques

Recommandations stratégiques

Pour les dirigeants et les responsables de la sécurité : les décisions politiques les plus importantes. 

• Bloquez l'authentification par code d'appareil pour tous les utilisateurs qui n'en ont pas explicitement besoin. Cette modification de la politique d'accès conditionnel élimine totalement la surface d'attaque pour la majeure partie de vos employés.
• Mettez à jour votre procédure de réponse aux incidents afin d'y inclure la révocation des jetons OAuth comme étape obligatoire, au même titre que la réinitialisation des mots de passe. Une simple réinitialisation de mot de passe ne révoque pas les jetons d'actualisation : l'attaquant conserve un accès indéfini tant que les jetons ne sont pas explicitement révoqués.
• Il est fortement recommandé d'activer la liaison de jetons (protection des jetons) pour les comptes à haute valeur ajoutée (dirigeants, services financiers, administrateurs). Cette fonctionnalité est généralement disponible sous Windows (en préversion sur iOS/macOS) et constitue la meilleure protection contre la réutilisation des jetons à partir de flux de code provenant d'appareils volés.
• Vérifiez quelles applications de votre environnement ont activé le flux de code d'appareil. De nombreuses organisations possèdent des applications OAuth avec des autorisations de code d'appareil non configurées intentionnellement. Réduire la surface d'exposition est un gain rapide.
• Assurez-vous que votre équipe de sécurité surveille les journaux de connexion non interactifs, et pas seulement les journaux interactifs. L'activité de renouvellement de jeton de l'attaquant n'apparaît que dans les journaux non interactifs, que de nombreux SOC ne consultent pas systématiquement.

Recommandations tactiques

À l'intention des ingénieurs et administrateurs de sécurité — guide de mise en œuvre : 

Restreindre ou bloquer le flux de code du périphérique via l'accès conditionnel

Si votre organisation n'a pas recours à l'authentification par code d'appareil pour des cas d'utilisation légitimes (outils CLI, appareils IoT, matériel de salles de conférence), bloquez complètement le flux à l'aide de politiques d'accès conditionnel. Entra IDCréez une stratégie qui cible Tous les utilisateurs → Ressources cibles → Toutes les ressources (anciennement applications cloud) → Conditions → Flux d'authentification → Flux de code de l'appareil = Bloquer. Si certaines équipes en ont besoin, limitez la portée de la stratégie d'autorisation à des utilisateurs ou groupes spécifiques et aux plateformes d'appareils connues uniquement, tout en respectant les règles. principe du moindre privilège. 

Énoncer les mesures pertinentes pour atténuer le vol de jetons

La réinitialisation du mot de passe ne suffit pas à révoquer les jetons d'actualisation OAuth. En cas de compte compromis, votre procédure doit inclure : (1) la révocation de l'accès de l'utilisateur et la désactivation du compte, (2) la réévaluation de toutes les sessions d'évaluation continue des accès (CAE) actives, et (3) la vérification des consentements OAuth de l'utilisateur et la suppression de tout principal de service inconnu. Sans ces mesures, l'attaquant conserve l'accès via le jeton d'actualisation jusqu'à son expiration (jusqu'à 90 jours par défaut). Entra ID configuration. 

Surveiller les journaux de connexion non interactifs pour détecter les anomalies géographiques

L'onglet de connexion non interactif dans Entra ID C'est là que les événements de rafraîchissement de jeton apparaissent. Un attaquant utilisant un jeton de rafraîchissement volé générera des connexions non interactives à partir d'une adresse IP et d'un agent utilisateur qui diffèrent très probablement de ceux de l'utilisateur. Configurez des alertes pour les connexions non interactives dont l'adresse IP source se situe dans un pays ou un ASN différent de celui de la dernière connexion interactive de l'utilisateur. Allez plus loin en recoupant l'adresse IP source avec les flux de renseignements sur les menaces et les bases de données de réputation IP : les activités de sondage ou de rafraîchissement provenant d'adresses IP sur liste noire, de fournisseurs d'hébergement réputés « bulletproof » ou de réseaux proxy résidentiels constituent un indicateur très fiable, quelle que soit la zone géographique. Cette combinaison de facteurs géographiques est cruciale. Détection d'une anomalie et le filtrage basé sur la réputation est le signal le plus précoce et le plus fiable pour détecter le vol de jetons de code d'appareil. 

Comment se protéger contre le phishing par code d'appareil

L'hameçonnage par code d'appareil représente un changement fondamental dans le paysage des menaces d'usurpation d'identité : l'attaquant n'a besoin d'aucune infrastructure, l'authentification multifacteur est détournée plutôt que contournée, et l'accès persiste malgré les réinitialisations de mot de passe. L'attaque fonctionne précisément parce qu'elle est légitime : une véritable page de connexion Microsoft, une véritable invite d'authentification multifacteur, un véritable écran de confirmation. Les jetons sont simplement envoyés à la mauvaise machine. 

La réponse stratégique est simple : bloquer le flux de code de l’appareil lorsqu’il n’est pas nécessaire, s’assurer que vos procédures de réponse aux incidents incluent la révocation des jetons et surveiller les journaux de connexion non interactifs, souvent négligés par les organisations. L’analyse technique approfondie présentée dans cet article – de l’analyse de protocole à la capture de journaux en passant par les requêtes KQL – fournit à votre équipe de sécurité tous les outils nécessaires pour détecter ce type d’activité dès aujourd’hui. 

À mesure que les attaques d'identité basées sur OAuth évoluent, l'écart entre ce que les outils de périmètre traditionnels peuvent détecter et ce qui se passe au niveau de l'identité ne fera que se creuser. Les organisations qui investissent dans la sécurité au niveau du protocole sont donc cruciales. détection et réponse— et pas seulement la surveillance des terminaux et du réseau — sera la seule à permettre de déceler la prochaine évolution de cette technique avant qu'elle n'atteigne la phase de post-exploitation. 

SilverfortL'équipe de recherche de [Nom de l'entreprise] continue de suivre l'évolution des techniques d'attaque basées sur OAuth.