Microsoft démantèle le réseau EvilTokens dopé à l’IA à l’origine de la compromission de 12 000 comptes de messagerie

Microsoft a perturbé les activités d’EvilTokens, une plateforme de phishing-as-a-service qui transformait un mécanisme d’authentification légitime de Microsoft en un système industrialisé de compromission de comptes de messagerie et de fraude aux communications professionnelles.

L’opération a permis de saisir 50 sites web et de désactiver plus de 150 domaines associés. Microsoft a attribué le développement, l’exploitation et le support client du service à l’acteur malveillant qu’elle suit sous le nom de Storm-2992.

EvilTokens serait lié à plus de 12 000 boîtes de réception compromises dans plus de 10 000 organisations à travers le monde. Au lieu de dérober directement les mots de passe, le service manipulait les victimes afin qu’elles autorisent des sessions contrôlées par les attaquants via le flux d’autorisation d’appareil OAuth 2.0 de Microsoft.

La Digital Crimes Unit de Microsoft a obtenu l’autorisation de mener cette opération auprès du tribunal fédéral du district oriental de Virginie, aux États-Unis. Health-ISAC, Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, The Shadowserver Foundation et TRM Labs ont apporté leur soutien à l’opération.

Une plateforme commerciale dédiée au vol de jetons et à la compromission de messageries professionnelles

Storm-2992 commercialisait EvilTokens sur Telegram sous la forme d’un service clé en main destiné aux cybercriminels. L’opérateur utilisait des canaux de discussion et des bots pour promouvoir ses produits, distribuer le kit de phishing, annoncer les mises à jour, aider les abonnés et proposer des récompenses en cryptomonnaie pour les recommandations de clients.

La plateforme est apparue en février 2026. Huntress l’a documentée en mars 2026, tandis que Sekoia décrivait une offre clé en main vendue sur Telegram depuis la mi-février. Microsoft a ensuite suivi une campagne liée à EvilTokens en avril 2026.

Les comptes Telegram signalés comprenaient les identifiants d’administrateur @eviltokensadmin, @eviltokensadmins et @EvilTokenscontact, ainsi que les bots de la boutique @EvilTokens_bot et @EvilTokensStorebot. L’opération gérait également le canal public @EvilTokensChannel et un groupe Telegram distinct.

Selon l’analyse technique de Microsoft, le kit principal coûtait 1 500 dollars, auxquels s’ajoutait un abonnement mensuel de 500 dollars donnant accès aux composants de phishing et au panneau de contrôle. Parmi les autres produits signalés figuraient un Antibot Redirector, un B2B Sender, un SMTP Sender et un Office 365 Capture Link.

Selon des informations distinctes attribuées à Sekoia, le B2B Sender était proposé à 600 dollars et le SMTP Sender à 1 000 dollars. Ces tarifs supplémentaires et les modalités de licence signalées n’étaient pas détaillés indépendamment dans l’avis Microsoft disponible.

Le panneau client permettait de faire bien davantage que créer des pages de phishing. Les abonnés pouvaient configurer des domaines et des hébergements, sélectionner la langue et la mise en page des pages, modifier le comportement des CAPTCHA et des redirections, surveiller les victimes, gérer les jetons volés, rechercher certains mots-clés dans les boîtes aux lettres et recevoir des alertes via Telegram.

Les options de déploiement comprenaient Cloudflare Workers ou l’infrastructure Bunny, ainsi que des hébergements PHP classiques. Ces choix permettaient aux clients de personnaliser leurs campagnes sans devoir développer leurs propres systèmes de diffusion et de prise de contrôle de comptes.

Comment une véritable page de connexion Microsoft est devenue un mécanisme de phishing

Le flux d’autorisation d’appareil est conçu pour les équipements dont les capacités de saisie sont limitées, comme les téléviseurs connectés, les imprimantes, les appareils Teams et les équipements de visioconférence. En temps normal, l’appareil affiche un code court que l’utilisateur saisit dans le navigateur d’un autre système afin d’approuver la connexion.

EvilTokens exploitait la séparation entre le navigateur utilisé pour effectuer cette approbation et la session à l’origine de la demande d’autorisation.

L’attaquant commençait par lancer une demande de code d’appareil. EvilTokens transmettait ensuite le code obtenu à une cible au moyen d’une page de phishing, en incitant la victime à approuver une session contrôlée par l’attaquant.

Les campagnes utilisaient 44 thèmes d’appât, notamment des factures, des demandes de propositions, des documents partagés, des avertissements d’expiration de mot de passe, des messages vocaux, des messages eFax, des notifications de paiement et des services de signature électronique. Les liens malveillants pouvaient être transmis directement ou intégrés à des pièces jointes PDF et HTML.

Après avoir suivi l’appât, la victime arrivait sur une page contenant une automatisation en arrière-plan qui communiquait avec le fournisseur d’identité de Microsoft et générait un code d’appareil actif. La page affichait un bouton « Copy Code » ainsi qu’un bouton intitulé « Continue » ou « Continue with Microsoft ».

Ce bouton redirigeait la victime vers la page légitime microsoft.com/devicelogin. Le domaine authentique renforçait la crédibilité de la page, ce qu’une page clonée destinée à récupérer les identifiants n’aurait pas pu faire.

La victime saisissait le code généré par l’attaquant et, si nécessaire, suivait les étapes habituelles de saisie du mot de passe et d’authentification multifacteur. Le service d’autorisation de Microsoft fournissait alors les jetons d’accès et de renouvellement au client de l’attaquant.

L’opérateur d’EvilTokens n’avait pas besoin de connaître le mot de passe. L’authentification multifacteur n’empêchait pas non plus la compromission, car la victime approuvait une véritable demande d’authentification — simplement pas celle d’un appareil ou d’un service auquel elle pensait accéder.

Des jetons volés alimentaient une chaîne de fraude assistée par l’IA

Une fois les jetons valides obtenus par EvilTokens, les clients pouvaient accéder à la boîte aux lettres de la victime, exfiltrer des messages, créer des règles de boîte de réception pour dissimuler les échanges malveillants et enregistrer des appareils supplémentaires. Les jetons de renouvellement et les sessions actives pouvaient maintenir l’accès au-delà de l’intrusion initiale.

La plateforme utilisait également Microsoft Graph pour examiner les utilisateurs, les rôles, les autorisations, les liens hiérarchiques et d’autres relations au sein de l’organisation. Cette reconnaissance aidait à identifier les employés disposant d’une autorité financière ainsi que les contacts dont l’identité pouvait être usurpée.

Des fonctions d’IA étaient intégrées à ce processus post-compromission. L’assistant pouvait examiner le contenu des boîtes aux lettres afin de repérer des factures de fournisseurs, des validations de paiement, des échanges financiers, des responsabilités sensibles et les personnes autorisées à transférer de l’argent.

Il pouvait ensuite résumer ou traduire des messages dans plus de 20 langues, identifier les relations de confiance, proposer des stratégies de fraude et rédiger des messages imitant des contacts connus. Le contenu de phishing pouvait être adapté au rôle de la cible et au contexte découvert dans sa boîte aux lettres.

EvilTokens était donc bien davantage qu’un kit de récupération de jetons. La plateforme regroupait dans une même interface l’accès initial, l’exploitation des informations de la messagerie, la sélection des cibles, la cartographie de l’organisation, l’usurpation d’identité et la préparation de fraudes aux communications professionnelles.

Le niveau d’expertise nécessaire pour mener une fraude ciblée s’en trouvait réduit. Un affilié n’avait pas besoin de développer un système de phishing OAuth, d’examiner manuellement des milliers de messages ou de comprendre l’organisation de la victime avant de tenter de détourner un paiement.

Une infrastructure éphémère compliquait la détection

EvilTokens utilisait des redirections en cascade, de faux contrôles CAPTCHA et des hébergements serverless afin d’éviter un blocage simple des domaines. L’infrastructure observée comprenait notamment Vercel, Cloudflare Workers et AWS Lambda.

Dans la campagne suivie par Microsoft en avril 2026, des plateformes d’automatisation généraient des milliers de nœuds d’interrogation uniques et éphémères. Une logique backend Node.js complexe prenait en charge le processus, depuis la génération en temps réel du code d’appareil jusqu’aux activités ultérieures sur le compte.

La rotation rapide de l’infrastructure réduisait la valeur des indicateurs statiques et des signatures simples. Un domaine identifié dans un message pouvait disparaître ou devenir inutile, tandis que le même flux backend réapparaissait via un autre point de terminaison serverless.

SpyCloud a fourni des données de phishing récupérées couvrant 8 708 comptes victimes uniques associés à 6 585 domaines de messagerie professionnels dans 79 pays. Les captures récupérées les plus anciennes dataient du 18 février 2026.

Les plus fortes concentrations de victimes observées se trouvaient aux États-Unis, au Canada, au Royaume-Uni, en Australie, en Inde et en France. Les secteurs touchés comprenaient la distribution en gros, la construction, les services financiers, l’immobilier, l’enseignement supérieur et la santé.

Les informations communiquées par les partenaires ont également attribué environ 1,1 million de dollars de revenus liés à la plateforme à quatre adresses Tron entre octobre 2025 et juin 2026. Coinbase aurait identifié plus de 1 000 dépôts provenant de plus de 700 adresses de cryptomonnaie. Microsoft n’a pas quantifié séparément ces éléments financiers dans son avis.

Une opération de démantèlement ordonnée par la justice et accompagnée de deux arrestations

La Digital Crimes Unit de Microsoft s’est appuyée sur l’ordonnance du tribunal fédéral de Virginie pour saisir 50 sites web utilisés dans l’exploitation d’EvilTokens et désactiver plus de 150 domaines associés.

Le Metropolitan Police Service a arrêté deux hommes, âgés de 32 et 38 ans, le 11 septembre 2026, dans le cadre de cette activité commerciale, selon les informations publiées sur l’opération coordonnée. Leurs noms n’ont pas été communiqués dans les documents disponibles.

Microsoft a publié son analyse le 22 septembre 2026. Le démantèlement supprime une part importante de l’infrastructure, mais aucune liste complète des comptes touchés, des identités des clients ou des systèmes encore contrôlés par des affiliés n’a été rendue publique.

Les organisations doivent donc rechercher d’éventuelles compromissions plutôt que considérer la perturbation de l’infrastructure comme une remédiation suffisante pour les environnements déjà compromis.

Les défenseurs doivent révoquer les jetons, pas seulement réinitialiser les mots de passe

Microsoft recommande de bloquer l’authentification par code d’appareil partout où elle n’est pas requise sur le plan opérationnel. Les organisations peuvent utiliser Conditional Access pour désactiver ce flux ou en limiter strictement l’usage.

Lorsque des équipements Teams dépendent de l’authentification par code d’appareil, les exceptions doivent être limitées aux comptes de ressources désignés pour les appareils Teams. Microsoft recommande également d’exclure la ressource Device Registration Service de la règle Conditional Access concernée.

Après une compromission présumée, les défenseurs doivent révoquer les sessions actives et les jetons de renouvellement, supprimer les appareils enregistrés sans autorisation et réinitialiser les identifiants. Un changement de mot de passe à lui seul peut laisser intact l’accès existant de l’attaquant, fondé sur des jetons.

Les équipes de sécurité doivent également examiner :

• Les appareils nouvellement enregistrés et les autorisations OAuth suspectes.
• Les règles de boîte de réception malveillantes, les messages masqués et les redirections inhabituelles.
• Les requêtes Microsoft Graph anormales concernant les utilisateurs, les rôles, les autorisations ou la structure organisationnelle.
• Les liens non sollicités utilisant des plateformes serverless telles que Vercel, Cloudflare Workers ou AWS Lambda.
• Les appâts liés aux factures, aux demandes de propositions, aux fichiers partagés, à l’expiration des mots de passe, aux paiements, aux messages vocaux, à eFax et à la signature électronique.
• Les connecteurs tiers susceptibles de permettre à des messages usurpés de contourner les protections habituelles de la messagerie.

Les utilisateurs doivent considérer comme suspectes les demandes inattendues les invitant à saisir un code sur microsoft.com/devicelogin, même si le site lui-même est légitime. La question déterminante est de savoir si l’utilisateur a lui-même lancé un processus d’authentification d’appareil nécessitant une approbation.

Cette distinction était au cœur du fonctionnement d’EvilTokens : la connexion Microsoft était réelle, le code était valide et l’authentification multifacteur fonctionnait comme prévu. La tromperie portait sur l’identité de la session que la victime autorisait.