Lorsque la plupart des personnes pensent au « phishing », elles imaginent généralement des utilisateurs incités à divulguer des identifiants ou à télécharger un malware.
L’une des méthodes d’attaque à la croissance la plus rapide ne fait ni l’un ni l’autre. Au lieu de cela, un utilisateur ciblé est incité à autoriser un client contrôlé par un attaquant. Ces attaques exploitent la confiance des utilisateurs dans les flux d’autorisation basés sur OAuth, utilisés pour accorder à une application l’accès aux données d’une autre application.
Début 2026, le phishing par code d’appareil est en forte hausse. Cette attaque exploite des vulnérabilités connues dans le mécanisme d’authentification par code d’appareil, une méthode selon laquelle les utilisateurs autorisent un client sur un appareil en se connectant depuis un autre appareil. Cette autorisation visait à faciliter la connexion sur des appareils « à entrée limitée », où la saisie d’un mot de passe est peu pratique. Mais nous constatons qu’elle est aussi utilisée pour de nombreux autres cas d’usage, notamment pour les collaborateurs. Les cybercriminels se sont désormais approprié ce flux avec un succès remarquable pour inciter les utilisateurs à autoriser leurs applications malveillantes.
Les spécialistes de la recherche sur les menaces chez Push Security ont constaté une multiplication par 15 des attaques de phishing par code d’appareil visant les utilisateurs de Microsoft 365 depuis le début de l’année. Les chercheurs d’Okta Threat Intelligence et de Proofpoint ont désormais observé des signes indiquant que certains cybercriminels sont passés des attaques de phishing AitM à des attaques de phishing par code d’appareil.
Le phishing par code d’appareil occupe désormais le devant de la scène, car les attaques ont été industrialisées via des opérations de « phishing as a service » telles que EvilTokens.
EvilTokens fournit à une personne malveillante peu expérimentée l’infrastructure, les leurres, les outils de contournement de la défense ainsi que les systèmes d’alerte et de messagerie nécessaires pour lancer des attaques de phishing par code d’appareil à grande échelle contre les clients de Microsoft, avec un effort minimal de la part de l’utilisateur.
Dans cet article, nous expliquons à quoi sert le flux de code d’appareil, comment il est exploité et dans quelles conditions cette forme d’attaque s’apparente à du « phishing explosif ».
L’autorisation par code d’appareil
Le phishing par code d’appareil exploite un flux d’autorisation OAuth 2.0 spécifique, conçu pour les appareils à entrée limitée : l’autorisation par code d’appareil OAuth 2.0 (RFC8628).
Un appareil à entrée limitée peut être une application de streaming sur votre télévision, des applications qui pilotent vos appareils électroménagers ou encore les systèmes de divertissement de votre voiture. Dans tout système où il est difficile de saisir un mot de passe long et complexe, le flux de code d’appareil permet à un utilisateur de se connecter hors bande sur un mobile ou un ordinateur portable et d’autoriser (donner son consentement) le client à accéder aux données de son compte.
Illustrons ce mécanisme avec l’exemple d’une application de streaming vidéo :
Un utilisateur souhaite se connecter à une application de streaming sur sa télévision.
Le navigateur du smartphone de l’utilisateur est l’appareil d’authentification hors bande.
Un serveur d’autorisation sert d’intermédiaire pour l’accès aux serveurs en arrière-plan du service de diffusion en continu.
Dans un flux d’autorisation de code d’appareil légitime :
- Un utilisateur tente de se connecter à son compte de service de streaming depuis une télévision.
- Une application sur la télévision demande l’accès à un serveur d’autorisation en envoyant un identifiant client dans une requête adressée à un terminal spécifié. Le serveur d’autorisation renvoie un code d’appareil, un code utilisateur et une URI de vérification.
- L’application invite l’utilisateur à se rendre sur l’URI de vérification, présentée soit sous forme d’adresse web, soit sous forme de code QR affiché à l’écran de la télévision, et fournit également un code utilisateur à huit caractères à saisir sur son smartphone pour autoriser l’application.
- Lorsque l’utilisateur se rend à l’adresse web indiquée, il est invité à saisir le code utilisateur et à vérifier son identité. L’utilisateur peut être invité à consentir à ce que l’application accède aux ressources hébergées sur le serveur (données de compte du service de streaming).
- En arrière-plan, l’application interroge en continu le serveur d’autorisation via des requêtes qui incluent l’identifiant client et le code de l’appareil. L’application cliente demande en réalité au serveur d’autorisation si l’utilisateur l’a autorisée. Une fois que l’utilisateur donne son consentement, le serveur d’autorisation répond à une requête de sondage avec un jeton d’accès. Ce jeton d’accès peut ensuite être utilisé pour effectuer des appels d’API au service de streaming.
Figure 1 : flux d’autorisation par code d’appareil OAuth 2.0
Toutes ces interactions se produisent en quelques secondes. Le flux est à la fois pratique et favorise l’utilisation de méthodes d’authentification plus robustes (notamment par rapport aux mots de passe courts et OTP saisis sur des appareils à entrée limitée).
Malheureusement, le flux de code d’appareil est également vulnérable aux abus lors d’attaques de social engineering.
Phishing par code d’appareil
Dans une attaque de phishing par code d’appareil, en revanche, c’est l’attaquant qui contrôle l’application cliente :
- L’attaquant enregistre soit une nouvelle application dans un tenant contrôlé par ses soins, soit utilise un identifiant client reconnu comme fiable par le serveur d’autorisation de l’utilisateur ciblé. Les requêtes adressées au serveur d’autorisation sont considérées comme valides, car le flux d’autorisation par code d’appareil ne nécessite pas que l’application cliente soit authentifiée ni même enregistrée auprès du serveur d’autorisation. Rien n’empêche un attaquant d’exploiter un identifiant client connu, et les identifiants clients ne sont généralement pas protégés comme des secrets.
- L’attaquant transmet le code utilisateur et l’URI de vérification à la personne ciblée via un site de phishing, ou par téléphone lors d’un appel de social engineering. Si la personne authentifiée se rend à cette adresse web et saisit le code utilisateur, c’est à l’application de l’attaquant qu’elle accorde l’accès à ses ressources. L’attaquant doit simplement interroger le serveur d’autorisation pour recevoir un jeton d’accès.
Figure 2. Phishing par code d’appareil
Phishing explosif
Dans les attaques que nous avons observées à ce jour, les attaquants ont manifesté un intérêt pour l’usurpation de l’identité de clients qui :
Sont autorisés par un serveur d’autorisation commun,
Sont attribués par défaut à tous les utilisateurs dans les nouveaux tenants (y compris les tenants gratuits ou d’essai)
Ont un identifiant client connu ou commun, identique dans chaque tenant
Malheureusement, les applications Microsoft répondent à ces critères à plusieurs égards :
Un utilisateur d’EvilTokens peut initier un flux de code d’appareil en envoyant une requête POST au même terminal commun applicable à chaque client Microsoft (/common/oauth2/devicecode).
Cette requête POST doit inclure un identifiant client légitime. Les identifiants clients des applications propriétaires disponibles par défaut dans les tenants Microsoft sont régulièrement listés et présentés dans des tableaux, et les relations particulières entre eux sont abordées ouvertement. Des spécialistes de la recherche sur les menaces ont remarqué que, par défaut, EvilTokens exploite l’identifiant client connu de Microsoft Office, mais d’autres chercheurs ont constaté des abus concernant d’autres applications Microsoft.
Cela signifie qu’un seul outil suffit pour cibler pratiquement tous les clients Microsoft dans le monde, qu’il s’agisse d’une personne mineure autorisant une application sur sa Xbox ou d’un responsable informatique autorisant une application pour une entreprise du Fortune 500.
L’avantage pour un attaquant lorsque toutes les personnes utilisatrices s’authentifient via un seul domaine (login.microsoft.com), c’est qu’il devient très facile de mener des attaques à grande échelle. Dans une attaque de phishing par code d’appareil visant des clients Microsoft, les attaquants redirigent tous les utilisateurs ciblés vers un terminal commun (login.microsoft.com/common/oauth2/v2.0/devicecode). À ce terminal, toute personne utilisant les services Microsoft est considérée comme un utilisateur valide, en particulier lorsque des identifiants clients susceptibles d’être attribués à de nombreuses personnes, voire à l’ensemble des utilisateurs, sont utilisés.
À l’inverse, la plateforme Okta a été conçue selon le principe que chaque organisation dispose de son propre serveur d’autorisation, indépendant et décentralisé. Il n’existe pas de concept de terminal « commun » où les utilisateurs de différentes organisations vérifient leur identité à un seul endroit.
Cela signifie que, même si les clients créés dans Okta ne sont pas à l’abri des attaques de phishing par code d’appareil, l’architecture d’Okta oblige les attaquants à effectuer beaucoup plus de recherches sur toute cible potentielle.
Ressources
Lire toute l’histoire
Pour en savoir plus sur l’approche d’Okta en matière de défense contre l’exploitation malveillante du flux de code d’appareil, les contacts sécurité des clients d’Okta peuvent se connecter pour accéder à une version longue de cet article sur security.okta.com
Recommandations
- N’autoriser l’utilisation du flux de code d’appareil qu’à titre exceptionnel. Les clients de Microsoft doivent mettre en place une politique d’accès conditionnel qui bloque tout accès utilisant le flux de code de l’appareil.
Lorsque le flux de code d’appareil est considéré comme le plus adapté pour une application client créée dans Okta :
Mettre sur liste d’autorisation la plage d’adresses IP à partir de laquelle un jeton peut être émis pour un client donné. Cela peut être configuré pour n’importe quel client dans Applications > Général > Réseau IP. Une fois la configuration effectuée, les demandes de jetons d’accès provenant d’un client contrôlé par un attaquant en dehors de la plage d’adresses IP figurant sur la liste d’autorisation seront refusées.
Surveiller les demandes de tokens et les autorisations d’utilisateurs anormales.
