En 2026, un type de fraude basé sur OAuth 2.0 prend de l’ampleur à vitesse inquiétante : le device code phishing. Ce mécanisme ne cherche pas à “casser” la connexion au sens classique. Il exploite une étape différente du processus d’accès : l’autorisation qui suit l’authentification. Résultat, même des protections réputées solides peuvent ne pas empêcher l’attaque.
D’après des observateurs du secteur, la technique a évolué en moins de six mois, passant d’un usage plutôt confidentiel à des campagnes à grande échelle. Les équipes sécurité doivent donc comprendre comment elle fonctionne, pourquoi elle s’industrialise et où se situent les leviers de détection réellement efficaces.
1) Le device code phishing contourne toutes les formes de MFA
La première raison de la hausse du device code phishing est sa logique d’attaque. L’objectif n’est pas de viser le mécanisme d’authentification en lui-même, mais l’étape qui accorde l’accès à une application : la couche d’autorisation.
Dans de nombreux cas observés, la victime est déjà connectée au compte du fournisseur (par exemple via une session existante). Elle récupère ensuite un code court sur une page frauduleuse, saisit ce code sur la page d’approbation légitime, choisit son compte dans une liste et valide “autoriser”. L’attaque se résume alors à un enchaînement très court, difficile à distinguer d’un comportement attendu.
Ce modèle explique pourquoi passkeys, clés de sécurité matérielles et même une MFA dite “résistante au phishing” peuvent rester inefficaces. La raison n’est pas que l’identification soit faible, mais que le contrôle de sécurité traditionnel protège surtout l’étape “qui vous êtes”, pas toujours “ce à quoi vous donnez accès”.
2) Un écosystème de kits prêts à l’emploi industrialise l’attaque
Deuxième facteur : le device code phishing s’est transformé en produit. Il ne relève plus uniquement de prouesses techniques ou d’expérimentation. Il apparaît désormais comme une fonctionnalité dans des catalogues de phishing-as-a-service (PhaaS), avec des opérateurs qui profitent de la logistique “clé en main”.
Des chercheurs indiquent que plusieurs kits connus ont ajouté le device code phishing à leur offre. Le phénomène s’observe aussi via des similitudes structurelles entre outils : des agencements de pages proches, une architecture de code comparable, souvent attribués à des instructions générées de façon similaire par des modèles d’IA.
Plus largement, cette commercialisation suit un schéma déjà vu dans d’autres familles d’attaques : une technique passe de l’expérimentation à l’espionnage attribué à des acteurs avancés, puis devient un commodity pour des cybercriminels. La différence ici est la cadence : la transition décrite s’est opérée en quelques mois, ce qui traduit à la fois la maturité du marché et l’accélération apportée par le développement assisté par l’IA.
3) Des kits voient le jour trop vite pour être catalogués
Troisième raison : l’industrialisation s’accompagne d’une vitesse de production élevée. Les observateurs suivraient désormais plus de 25 kits distincts de device code phishing “dans la nature”. Pour mesurer l’ampleur du changement, le rythme de publication de nouvelles variantes de phishing par le passé était décrit comme beaucoup plus lent (avec des apparitions espacées de plusieurs mois).
Le cœur du problème est l’abaissement de la barrière à l’entrée. L’assistance par IA permet de construire plus rapidement des composants et d’aboutir à des kits exploitables. En conséquence, le “catalogage” par les équipes défensives ne suffit plus : la surface d’attaque se met à évoluer presque en continu.
Pour illustrer cette facilité de développement, des démonstrations existent montrant qu’un kit peut être monté rapidement, ce qui rend le suivi par IOC (indicateurs de compromission) de plus en plus fragile.
4) Ce n’est pas seulement un problème Microsoft
Quatrième point : le device code phishing n’est pas cantonné aux environnements Microsoft, même si la majorité des attaques observées ciblent aujourd’hui cette plateforme.
Le mécanisme OAuth 2.0 exploité par le device code flow n’est pas propre à un fournisseur unique. Toute application qui implémente le grant “device authorization” peut potentiellement devenir une cible. Des campagnes attribuées à des acteurs étatiques auraient déjà utilisé ce schéma contre des environnements Salesforce.
Il existe également des cas d’usage légitimes qui ouvrent des portes aux attaquants : certains services (comme GitHub ou AWS) supportent des flux device dans des contextes d’authentification CLI et d’outillage développeur, par exemple pour des tunnels ou l’accès à des composants depuis des environnements contraints. Lorsque les développeurs s’appuient sur ces mécanismes “normaux”, les opérateurs peuvent chercher à répliquer le même parcours de validation.
En bref : même si une partie des défenses se concentre sur un fournisseur, la logique d’attaque peut se répliquer ailleurs dès que l’implémentation OAuth est présente.
5) Une tendance plus large : l’attaque de l’autorisation
Cinquième raison : le device code phishing s’inscrit dans une évolution plus générale. Les attaquants déplacent leur focus de la couche d’authentification vers la couche d’autorisation, là où les contrôles sont parfois moins mûrs.
Les chercheurs décrivent une continuité avec d’autres techniques de phishing OAuth orientées consentement et validation post-connexion. L’idée est toujours la même : profiter du fait que l’accès à une ressource ne repose pas uniquement sur “l’identité”, mais sur l’acte d’autoriser un périmètre, une application ou une action.
Si les défenses n’adaptent pas leurs modèles à ce changement, l’écart s’élargira : de nouvelles formes d’abus des consent flows, de l’enregistrement des appareils ou de l’échange de tokens peuvent apparaître à mesure que l’écosystème se perfectionne.
6) Détecter là où l’attaque a réellement lieu
Dernier point, et peut-être le plus opérationnel : pour contrer le device code phishing, il faut détecter au bon endroit. Les pages frauduleuses peuvent être diffusées via de nombreux canaux : e-mail, messagerie, réseaux sociaux, résultats de recherche, ou sites compromis.
Mais l’étape décisive se déroule ensuite sur une interface d’approbation légitime. La victime saisit un code sur une URL du fournisseur, puis valide l’accès. Autrement dit, une partie de l’attaque transite par des infrastructures que des contrôles “réseau” ou “filtrage e-mail” ne bloquent pas forcément, puisque la validation finale s’effectue sur des pages authentiques.
Dans les environnements Microsoft, les conseils les plus fréquents évoquent des restrictions via des politiques d’accès conditionnel. La démarche est pertinente quand elle est applicable, mais elle peut être complexe : certains flux device ont des usages légitimes (outils développeur, workflows CLI, scénarios sur appareils contraints). Les grandes organisations indiquent souvent qu’elles ne peuvent pas simplement désactiver sans casser des activités essentielles.
De plus, même une restriction côté Microsoft ne protège pas contre des attaques visant GitHub, AWS ou d’autres plateformes où des politiques équivalentes ne sont pas toujours disponibles ou configurées de la même manière.
Pourquoi le navigateur devient un point de vue clé
Pour voir à la fois la “mécanique” du leurre et l’approbation device code, le navigateur est considéré comme l’observatoire le plus complet : il relie l’écran que la victime consulte et le moment où elle valide l’accès. C’est précisément ce que des approches de détection basées sur le comportement cherchent à exploiter.
Au lieu de se limiter à l’identification de signatures spécifiques de kits ou de domaines uniques, l’analyse peut porter sur la classe d’attaque et sur des signatures comportementales associées au flux device code. Ce choix devient crucial puisque de nouveaux kits apparaissent régulièrement, “éliminant” l’efficacité des stratégies IOC avant que celles-ci ne soient mises à jour.
Conclusion : anticiper vite, défendre plus finement
Le device code phishing progresse parce qu’il combine trois éléments : une logique d’attaque centrée sur l’autorisation (donc peu sensible à la MFA), une industrialisation via des kits prêts à l’emploi, et une vitesse d’évolution qui rend le suivi traditionnel difficile.
Pour les équipes sécurité, la réponse ne consiste pas uniquement à renforcer des règles autour de l’authentification. Il faut aussi comprendre où se produit le “oui” qui autorise l’accès, et construire une détection capable d’observer ce moment, même lorsque l’interface finale semble légitime.
En résumé : si vous protégez l’identité mais pas l’autorisation, vous laissez une porte ouverte. La bonne stratégie consiste à aligner politiques, contrôles et visibilité autour de l’ensemble du parcours d’accès, du leurre jusqu’à l’approbation device code.
Source: https://thehackernews.com/2026/07/6-reasons-why-device-code-phishing-is.html
