Un employé reçoit un email contenant un code à entrer sur une page Microsoft officielle pour approuver un accès à un appareil. La page est bien celle de Microsoft, le code est légitime, et l'authentification se déroule normalement. Ce que l'employé ne sait pas, c'est que le code en question a été généré par un attaquant, et que les tokens d'authentification que Microsoft vient d'émettre ont été transmis directement à l'infrastructure de l'attaquant, pas à l'appareil de l'employé. L'attaquant a maintenant un accès complet à la boîte Outlook, aux fichiers SharePoint, et aux documents OneDrive, sans avoir jamais touché au mot de passe.
C'est la technique centrale d'EvilTokens, une plateforme de phishing-as-a-service (PhaaS) dont les capacités ont été exposées par la découverte d'ARToken, une plateforme affiliée analysée par les chercheurs de Cisco Talos en juillet 2026. ARToken possède un panneau de gestion React exposant plus de 80 endpoints API, que les chercheurs ont réussi à documenter en ingénierie inverse du code JavaScript côté client. Ce qu'ils ont trouvé dépasse largement ce qu'on attend d'une plateforme de phishing ordinaire.
Pour comprendre pourquoi ARToken est particulièrement difficile à défendre, il faut comprendre ce qu'est le device code phishing. Le flux d'autorisation OAuth 2.0 Device Authorization Grant a été conçu pour permettre l'authentification sur des appareils qui ne disposent pas d'un navigateur ou d'une interface de saisie complète, comme les téléviseurs connectés, les consoles de jeux, ou les imprimantes réseau. Le processus se déroule en trois étapes : l'appareil demande un code à Microsoft, affiche ce code à l'utilisateur, et attend que l'utilisateur entre ce code sur microsoft.com/devicelogin via un autre appareil. Une fois que l'utilisateur a saisi le code et consenti, Microsoft émet des tokens d'authentification vers l'appareil.
Dans le scénario d'attaque, l'attaquant joue le rôle de "l'appareil." Il génère un device code via l'API Microsoft, envoie ce code à la victime dans un email de phishing avec des instructions pour le saisir sur la vraie page Microsoft, et attend. Quand la victime saisit le code, pensant autoriser un accès légitime, Microsoft émet les tokens vers l'application de l'attaquant. Parce que l'authentification s'est effectuée via l'infrastructure réelle de Microsoft, l'authentification multifacteur (MFA) ne constitue pas un obstacle : la victime a bien authentifié la session, mais au profit de l'attaquant.
Cette technique contourne structurellement le MFA basé sur les mots de passe à usage unique et les applications d'authentification, car elle n'usurpe pas de credentials. Elle détourne un flux d'authentification légitime.
ARToken opère comme une plateforme affiliée d'EvilTokens, une infrastructure de phishing Microsoft 365 documentée plus tôt en 2026 par Sekoia. Les chercheurs de Cisco Talos ont découvert ARToken en enquêtant sur une infrastructure de phishing dans le cadre d'une mission de réponse à incident. Ils ont identifié un panneau de gestion React, baptisé "ARToken Panel," qui exposait plus de 80 endpoints API REST.
L'ingénierie inverse du code JavaScript côté client a permis de documenter des capacités qui dépassent celles d'une plateforme de phishing standard. Les liens avec EvilTokens sont solides : ARToken utilise les mêmes appels API pour le flux d'authentification par device code de Microsoft, incluant une requête POST /api/device/start identique à celle associée aux attaques EvilTokens. Il partage aussi les mêmes endpoints de gestion des Primary Refresh Tokens (PRT) documentés dans la recherche de Sekoia sur EvilTokens, notamment les endpoints de configuration, de rafraîchissement, de renouvellement, et de réacquisition après expiration.
Les similitudes techniques et opérationnelles suggèrent fortement qu'ARToken est une offre affiliée d'EvilTokens plutôt qu'un outil indépendant : il partage l'infrastructure, les techniques, et les cibles, tout en étant distribué à des affiliés qui gèrent leurs propres campagnes via des espaces de travail dédiés.
Les Primary Refresh Tokens (PRT) sont la fonctionnalité qui distingue ARToken d'une plateforme de vol de tokens ordinaire. Un token d'accès Microsoft 365 standard a une durée de vie courte, généralement une heure. Après expiration, l'attaquant devrait répéter l'attaque de phishing pour obtenir de nouveaux tokens. Les PRT changent cette dynamique.
Les PRT sont des tokens à longue durée de vie émis par Microsoft pour les appareils enregistrés dans Azure AD. Ils permettent d'obtenir de nouveaux tokens d'accès sans interaction de l'utilisateur, car l'appareil lui-même est considéré comme un facteur d'authentification. Un attaquant qui obtient un PRT peut maintenir un accès persistant à la messagerie et aux ressources M365 de la victime, non seulement pendant la durée de vie initiale du token, mais même après que ce token est officiellement expiré, en utilisant les endpoints de réacquisition qu'ARToken documente spécifiquement.
Les endpoints PRT documentés dans ARToken incluent la configuration initiale, le rafraîchissement, le renouvellement et la réacquisition après expiration. Cette dernière capacité est particulièrement préoccupante : elle signifie qu'un attaquant qui a compromis un appareil via device code phishing peut maintenir cet accès de manière quasi-indéfinie, à moins que l'organisation ne révoque explicitement les sessions et les tokens de l'appareil compromis.
ARToken déploie son infrastructure de phishing via Cloudflare Workers, une plateforme de calcul à la périphérie qui exécute du code JavaScript près des utilisateurs sans nécessiter de serveur traditionnel. Ce choix présente deux avantages pour l'attaquant. D'abord, Cloudflare est un service de confiance utilisé par des millions de sites légitimes, ce qui rend les blocages basés sur la réputation de domaine moins efficaces. Ensuite, l'infrastructure de Cloudflare distribue le trafic géographiquement, compliquant l'identification des serveurs d'origine et la prise down des opérations.
Le modèle multi-tenant d'ARToken est conçu pour les opérations à grande échelle. Chaque affilié gère ses propres campagnes via un espace de travail dédié dans le panneau ARToken, avec ses propres paramètres, ses propres leurres, et ses propres victimes. L'infrastructure centrale est partagée, mais les opérations sont segmentées. Ce modèle est identique à celui des plateformes de ransomware-as-a-service et permet à un petit groupe d'opérateurs centraux de générer des revenus à partir d'un grand nombre d'affiliés sans avoir à gérer chaque campagne individuellement.
Au-delà du vol de tokens, ARToken inclut des outils pour automatiser les opérations de compromission de messagerie professionnelle (BEC). Une fois en possession des tokens d'accès, l'attaquant peut accéder aux boîtes Outlook des victimes, aux sites SharePoint, et aux fichiers OneDrive via les API Microsoft 365 documentées dans le panneau. ARToken automatise plusieurs tâches BEC courantes : la lecture des threads de messagerie pour identifier les transactions financières en cours, l'identification des contacts privilégiés susceptibles de répondre à des demandes de virement, et la modification de règles de redirection de messagerie pour maintenir une visibilité continue sur les communications après que les tokens initiaux ont été révoqués.
L'automatisation de ces tâches via des API est plus fiable que l'accès manuel via une interface web, car elle fonctionne en arrière-plan sans interaction visible et peut être scriptée pour cibler plusieurs milliers de boîtes simultanément. La détection d'accès BEC automatisé via API est possible mais nécessite une surveillance des patterns d'accès inhabituels aux API Microsoft 365, en particulier les accès via des adresses IP ou des applications non reconnues.
La défense contre le device code phishing nécessite des contrôles qui dépassent les solutions MFA traditionnelles. Microsoft propose plusieurs configurations pour réduire l'exposition. La première est la restriction du flux Device Authorization Grant via les politiques d'accès conditionnel Azure AD : certaines organisations peuvent bloquer entièrement ce flux pour les utilisateurs qui n'ont pas d'appareils IoT légitimes nécessitant ce mode d'authentification. La deuxième est l'activation des politiques qui bloquent les tokens émis vers des applications non gérées.
La surveillance des logs de connexion Azure AD pour les authentifications via le flux Device Code Flow est un indicateur de détection direct. Microsoft enregistre le type de flux utilisé lors de chaque authentification. Une authentification via Device Code Flow vers une application non reconnue par l'organisation, ou depuis un appareil non enregistré dans Azure AD, est un signal d'anomalie qui mérite investigation immédiate.
La révocation proactive des sessions et des tokens associés à des appareils suspects est l'action de réponse à incident la plus efficace en cas de compromission suspectée via device code phishing. Cela inclut la révocation des PRT, qui ne se fait pas automatiquement lors d'un simple changement de mot de passe.
Pour la formation des utilisateurs, il est essentiel de leur apprendre que Microsoft ne demande jamais par email d'entrer un code sur microsoft.com/devicelogin, et que toute demande de ce type non initiée par l'utilisateur lui-même est une tentative de phishing. Cette règle simple couvre la grande majorité des vecteurs de device code phishing documentés à ce jour, y compris les campagnes ARToken et EvilTokens.
Les tokens Microsoft 365 volés via cette technique apparaissent fréquemment dans les marchés souterrains spécialisés dans l'accès initial aux entreprises. Ces marchés categorisent les accès par organisation, par type de données accessibles, et par niveau de privilège. Un attaquant qui a vendu un accès via ARToken continue de le vendre même après en avoir lui-même fait usage, si les tokens restent valides. La fenêtre entre la compromission initiale et la détection est le moment où cet accès a le plus de valeur.
L'une des idées reçues les plus répandues en matière de sécurité Microsoft 365 est que l'activation du MFA sur tous les comptes constitue une protection suffisante contre le phishing. ARToken et EvilTokens démontrent pourquoi cette hypothèse est fausse pour la catégorie d'attaque spécifique qu'ils représentent. Le device code phishing ne contourne pas le MFA. Il le traverse.
Quand un utilisateur entre un device code sur microsoft.com/devicelogin et complète le processus d'authentification incluant une notification push ou un code TOTP, il authentifie réellement la session. Le MFA est validé avec succès. Mais les tokens résultants sont émis vers l'application que l'attaquant contrôle, pas vers l'appareil légitime que l'utilisateur pense autoriser. Du point de vue de Microsoft, l'authentification est complète et correcte. Du point de vue de l'utilisateur, il a juste approuvé ce qui semblait être un accès légitime.
Cette distinction est importante pour la formation des utilisateurs. Expliquer qu'ils doivent "activer le MFA" et "ne pas cliquer sur des liens suspects" ne couvre pas ce scénario. Le lien dans un email ARToken peut être absent : l'email contient juste un code et des instructions pour aller sur la vraie page Microsoft. Il n'y a pas de faux site, pas de typosquatting, pas de certificat invalide à détecter. La seule défense comportementale fiable est de ne jamais entrer un device code non initié par l'utilisateur lui-même.
Pour comprendre le niveau de risque qu'ARToken représente, il est utile de dérouler la chaîne complète d'une attaque aboutissant à une fraude financière. L'objectif final d'une grande majorité des opérations de compromission de messagerie professionnelle est le détournement de virements : l'attaquant surveille les communications financières de la victime jusqu'à identifier une transaction importante en cours, puis intervient pour rediriger le virement vers un compte qu'il contrôle.
La chaîne commence par un email de phishing conçu pour paraître légitime : une invitation à approuver un accès à un nouvel appareil professionnel, une demande d'authentification pour une réunion Teams urgente, ou une notification de sécurité Microsoft. L'email contient le code device code généré par l'attaquant via l'API Microsoft et des instructions pour le saisir sur la vraie page Microsoft. L'employé qui suit ces instructions authentifie la session de l'attaquant.
Avec les tokens en main, l'attaquant accède à la boîte Outlook de la victime via l'API Microsoft 365. ARToken automatise la phase de reconnaissance : il parcourt les emails récents à la recherche de fils de discussion mentionnant des transactions financières, des virements en attente, des factures, ou des prestataires. Il identifie les contacts clés dans ces discussions et leur position dans l'organisation. Cette reconnaissance peut se faire en quelques minutes sur une boîte bien remplie.
Une fois une transaction cible identifiée, l'attaquant intervient dans le fil de discussion existant depuis l'adresse authentique de la victime. Un email envoyé depuis la vraie boîte de la victime ne déclenche aucun filtre antispam et contourne les contrôles de vérification d'expéditeur. L'attaquant peut modifier les instructions de virement, remplacer les coordonnées bancaires, ou demander une confirmation urgente depuis l'adresse légitime de la victime. Les destinataires de cet email n'ont aucune raison de suspecter une manipulation.
Les Primary Refresh Tokens acquis par ARToken maintiennent cet accès au-delà de l'expiration naturelle des tokens d'accès initiaux. L'attaquant peut revenir dans la boîte plusieurs jours après le phishing initial, se rafraîchir des tokens, et continuer la surveillance sans avoir à reconduire l'opération de phishing. C'est ce caractère persistant qui distingue les attaques ARToken/EvilTokens des vols de tokens classiques et qui justifie l'urgence de la réponse à incident en cas de détection.
EvilTokens représente une évolution importante dans la structuration des services de cybercriminalité. Le modèle Phishing-as-a-Service existe depuis les premières plateformes de phishing en kit des années 2010, mais la sophistication technique et l'automatisation opérationnelle d'EvilTokens placent cette génération de plateformes dans une catégorie différente. Ce n'est plus un kit à déployer manuellement : c'est une infrastructure de service avec un panneau de gestion, des API documentées, et un modèle affilié structuré.
La découverte d'ARToken comme plateforme affiliée d'EvilTokens illustre la fragmentation et la résilience de ces écosystèmes criminels. EvilTokens fournit l'infrastructure principale et la propriété intellectuelle (les techniques d'exploitation des flux OAuth Microsoft). ARToken est un produit dérivé qui exploite la même infrastructure en ajoutant sa propre interface de gestion. Des affiliés achètent l'accès à ARToken et gèrent leurs propres campagnes. Cette structure à trois niveaux, développeur principal, plateforme affiliée, affiliés opérationnels, est identique au modèle Ransomware-as-a-Service qui a dominé le paysage des menaces depuis 2020.
La résistance de ce modèle aux takedowns est une caractéristique délibérée. Arrêter les affiliés ne perturbe pas la plateforme. Prendre down la plateforme ARToken ne détruit pas EvilTokens. Perturber EvilTokens ne détruit pas les techniques de device code phishing qui pourront être réimplémentées par d'autres acteurs. Cisco Talos a publié ses indicateurs de compromission pour aider les équipes de défense à détecter les opérations ARToken spécifiquement, mais la défense structurelle nécessite de bloquer la technique, pas seulement les indicateurs d'une implémentation spécifique.
Azure Active Directory (maintenant Microsoft Entra ID) enregistre des informations détaillées sur chaque authentification, y compris le type de flux utilisé. Les logs de connexion Azure AD, accessibles via le portail Entra ou via l'API Microsoft Graph, contiennent un champ authenticationProtocol qui identifie les authentifications effectuées via le flux Device Authorization Grant. Surveiller les authentifications de ce type depuis des utilisateurs qui n'ont pas d'appareils IoT déclarés dans l'organisation est la méthode de détection la plus directe pour les attaques ARToken et EvilTokens.
Microsoft propose également une règle de détection dans Microsoft Sentinel, sa solution SIEM cloud, spécifiquement pour le device code phishing. Cette règle analyse les patterns temporels entre la génération d'un device code et son utilisation : un device code généré et utilisé dans un délai très court depuis des adresses IP différentes est un indicateur fort de phishing. Les organisations utilisant Sentinel peuvent activer cette règle directement depuis la galerie de règles analytiques.
Les indicateurs de compromission publiés par Cisco Talos pour ARToken incluent le domaine associé au panneau de gestion et plusieurs patterns de requêtes API spécifiques. Ces indicateurs peuvent être intégrés dans les règles de détection des plateformes SIEM et dans les listes de blocage des solutions de filtrage réseau. Leur durée de vie est limitée (les attaquants changent de domaines régulièrement), mais leur déploiement immédiat après la publication de la recherche réduit l'exposition pendant la période où ARToken utilise encore l'infrastructure documentée.
La mesure de protection à long terme la plus efficace reste la configuration des politiques d'accès conditionnel Azure AD pour bloquer ou restreindre le flux Device Authorization Grant pour les utilisateurs qui n'en ont pas besoin. Pour la majorité des employés d'une organisation standard, qui utilisent des postes de travail et des téléphones capables d'un flux d'authentification interactif, le flux Device Code Flow n'est pas nécessaire et peut être désactivé sans impact sur la productivité. Cette désactivation ciblée élimine le vecteur d'attaque ARToken pour la population protégée, indépendamment de l'évolution future de l'infrastructure des attaquants.
Les campagnes comme PolinRider, Avalon, Armored Likho ou ARToken ont toutes un point commun : elles ciblent les identifiants, les tokens d'authentification et les données d'entreprise avant que les victimes ne s'aperçoivent de la compromission. Defendis surveille en continu les marchés souterrains, les forums criminels et les sites de fuite où ces données apparaissent après une exfiltration. Si des credentials appartenant à votre organisation sont mis en vente ou publiés, vos équipes en sont informées avant que l'attaquant ne les exploite. Comprendre pourquoi la détection précoce change l'issue d'un incident ou demandez une démonstration adaptée à votre contexte.
