Device Code Phishing : la menace qui rend inutile le MFA

Si l’authentification multifacteur n’est plus une barrière suffisante, l’explication s’appelle le device code phishing. La technique exploite le device authorization grant d’OAuth 2.0 (RFC 8628) pour dérober des jetons d’accès à une session déjà authentifiée, contournant n’importe quel second facteur : passkeys, jetons matériels, codes OTP. Il ne s’agit plus d’une curiosité présentée en 2020 : c’est aujourd’hui un phénomène industriel, alimenté par des kits prêts à l’emploi et de plus en plus souvent générés à l’aide de modèles de langage.

Comment contourner le MFA, même avec les passkeys

Le mécanisme contourne complètement la phase d’authentification parce qu’il exploite la confiance accordée au flux d’autorisation des appareils. L’attaquant lance la procédure de code d’appareil sur un service (par exemple Microsoft Entra ID), obtenant un code alphanumérique et une URL de vérification. Il trompe ensuite la victime en l’incitant à visiter cette URL – une adresse parfaitement légitime, comme login.microsoftonline.com – et à saisir le code. L’utilisateur, voyant la page authentique du fournisseur, se connecte avec ses propres identifiants et valide le MFA, accordant sans le savoir le consentement OAuth. À ce moment-là, le client de l’attaquant reçoit les jetons (d’accès et d’actualisation) qui garantissent un accès persistant, sans qu’aucune page de connexion n’ait été clonée.

La défense classique, basée sur la reconnaissance d’URL contrefaites, est inefficace. L’ensemble de la chaîne se déroule sur des domaines de confiance ; le phishing consiste à convaincre quelqu’un de saisir un code, pas à voler un mot de passe.

L’escalade : des attaques étatiques aux 7 millions d’attaques en quatre semaines

Après les premières timides descriptions de 2020, le device code phishing a fait son apparition sur le terrain avec des acteurs étatiques en 2024. La véritable industrialisation est arrivée en 2025 avec la campagne de ShinyHunters contre Salesforce : plus de 1 000 organisations compromises et 1,5 milliard d’enregistrements exfiltrés. Ce fut le signal que la technique était devenue une arme de consommation courante.

En février 2026, le kit EvilTokens a encore abaissé la barrière d’entrée, rendant l’attaque reproductible même pour des criminels sans compétences avancées. En avril, Microsoft signalait entre 10 et 15 nouvelles campagnes par jour, tandis qu’au cours des quatre semaines frénétiques qui ont suivi, Barracuda comptait 7 millions d’attaques. En mai, la plateforme PhaaS Tycoon2FA a intégré nativement le flux de code d’appareil. Aujourd’hui, Push Security suit plus de 25 familles de kits dédiés – un écosystème auquel s’ajoutent des kits comme ARToken, capable d’obtenir des Primary Refresh Tokens (PRT) pour assurer la persistance, l’accès à la messagerie, l’exfiltration depuis SharePoint et des automatismes BEC.

Le FBI a émis un avertissement autonome sur le kit Kali365, première communication fédérale américaine dédiée à un service de phishing-as-a-service spécifique. Pendant ce temps, la génération assistée par intelligence artificielle – ce qu’on appelle le « vibe‑coding » – accélère l’apparition de nouvelles variantes, rendant la menace de plus en plus difficile à contenir.

Plus seulement le login : le changement de paradigme vers l’autorisation

Le phénomène s’inscrit dans une tendance plus large qui déplace la cible de l’authentification vers l’autorisation. Des techniques comme ConsentFix, apparue fin 2025, visent directement l’abus du consentement OAuth, et le device code phishing lui-même agit au niveau de l’octroi des permissions plutôt qu’à la capture des identifiants. Le résultat est une classe d’attaques que les systèmes de détection d’intrusion classiques, calibrés sur la phase de connexion, ne détectent pas.

Aujourd’hui, 99 % des attaques observées ciblent des comptes Microsoft, mais le flux de code d’appareil est aussi pris en charge par GitHub, AWS et d’autres fournisseurs cloud, qui deviennent automatiquement des cibles potentielles. La compromission ne s’arrête pas à l’accès initial : le vol de PRT permet de maintenir une présence dans le tenant pendant de longues périodes. Et les données montrent que les dégâts sont déjà réels, pas seulement une projection.

Ce qu’une organisation peut faire

• Limiter l’octroi de code d’appareil : désactiver le flux d’autorisation d’appareil pour toutes les applications qui n’en ont pas réellement besoin. Lorsque ce n’est pas possible, appliquer des stratégies d’accès conditionnel qui bloquent les demandes de code d’appareil provenant d’IP, d’appareils ou de contextes non reconnus.
• Surveiller les consentements OAuth : être attentif à chaque octroi de permissions à des applications inconnues, même si l’authentification sous-jacente semble légitime. Des plateformes comme Microsoft Entra ID permettent d’activer des alertes sur les nouveaux consentements et de les révoquer automatiquement grâce à la détection du consent phishing.
• Former les utilisateurs : expliquer qu’il ne faut jamais saisir un code d’appariement reçu par e-mail, SMS ou chat, même si le lien mène à une page de connexion familière. La présence du MFA n’est pas une garantie de sécurité.
• Intégrer l’autorisation dans les SOC : introduire des règles de détection qui observent les motifs anormaux dans les flux OAuth et les jetons d’actualisation. Les défenses centrées sur l’authentification, à elles seules, sont aveugles face à une attaque qui commence alors que l’utilisateur est déjà connecté.

Le device code phishing n’est pas une évolution marginale : c’est la preuve que le jeu s’est définitivement déplacé au-delà du périmètre du mot de passe. Ignorer ce changement revient à laisser la porte ouverte après avoir renforcé la serrure.