La perturbation de Microsoft EvilTokens révèle une chaîne de fraude guidée par l’IA

Microsoft a perturbé EvilTokens après que le service a compromis plus de 12 000 boîtes de réception de messagerie dans plus de 10 000 organisations à travers le monde. L’opération Microsoft EvilTokens visait une infrastructure soutenant un système clé en main de phishing, d’accès aux comptes, d’analyse de boîtes aux lettres et de fraude financière.

Cette opération est importante car EvilTokens ne se contentait pas d’aider les criminels à rédiger des messages convaincants. Son assistant IA examinait les boîtes de réception volées, cartographiait les relations commerciales, identifiait les pouvoirs de paiement et recommandait des personnes à usurper.

Cette capacité a condensé un travail qui exigeait autrefois patience et connaissances spécialisées. Toutefois, neutraliser une infrastructure n’élimine pas la technique sous-jacente. Le phishing par code d’appareil reste possible, les sessions volées peuvent survivre à une réinitialisation de mot de passe, et des services connexes peuvent reproduire ce modèle opérationnel.

La perturbation de Microsoft EvilTokens a frappé une plateforme de fraude complète

Microsoft et ses partenaires se sont attaqués à l’infrastructure reliant le phishing initial à la tromperie financière ciblée.

Microsoft a annoncé l’action coordonnée le 22 septembre 2026. Sa Digital Crimes Unit a obtenu l’autorisation judiciaire de saisir une infrastructure active et de rediriger des domaines associés au service.

L’action a réuni Health-ISAC, des entreprises technologiques, des enquêteurs financiers, des chercheurs en sécurité et les forces de l’ordre. Cloudflare a séparément désactivé des projets Workers et des comptes soutenant les campagnes EvilTokens.

Selon des documents judiciaires, Microsoft et Health-ISAC ont déposé leur plainte dans le district oriental de Virginie. Les défendeurs nommés sont Felix Utomi, Waidi Segun Adams et plusieurs personnes non identifiées.

Microsoft attribue le développement et le soutien d’EvilTokens à un acteur malveillant qu’il suit sous le nom de Storm-2992. Dans ce contexte, cette attribution représente l’évaluation de Microsoft, et non une condamnation pénale.

L’opération aurait saisi 50 sites web et désactivé plus de 150 domaines supplémentaires. La police britannique a également arrêté deux hommes liés à EvilTokens, selon des informations indépendantes.

Les hommes ont été libérés sous caution avec conditions pendant la poursuite de l’enquête. Leurs arrestations ne doivent pas être considérées comme des constats de culpabilité.

Cloudflare a indiqué que l’opération coordonnée contre l’infrastructure avait commencé le 15 septembre. L’entreprise a identifié des centaines de comptes clients liés à l’activité EvilTokens et désactivé les projets concernés.

Cette approche juridique et technique combinée était nécessaire car EvilTokens dépendait de services opérés par des fournisseurs non liés entre eux. Son infrastructure traversait des plateformes d’hébergement, des registraires de domaines, des services de communication, des systèmes de paiement et des réseaux cloud.

EvilTokens est apparu au début de 2026 et a rapidement été adopté par des attaquants motivés financièrement. Microsoft l’a lié à plus de 12 000 boîtes de réception compromises dans plus de 10 000 organisations en quelques mois.

Les plus fortes concentrations d’activité observée chez les victimes sont apparues aux États-Unis, au Canada, en Grande-Bretagne, en Australie, en Inde et en France. Les secteurs concernés comprenaient la construction, la finance, la santé, l’immobilier, la distribution en gros et l’enseignement supérieur.

Ces chiffres décrivent une activité observée, et non un recensement exhaustif. Certains comptes compromis peuvent rester non détectés, tandis qu’une même organisation peut compter plusieurs boîtes de réception affectées.

L’orientation commerciale était particulièrement marquée. Des données de SpyCloud citées par des journalistes spécialisés en sécurité ont classé environ 97,5 % des comptes identifiés comme appartenant à des domaines d’entreprise.

EvilTokens a également généré des revenus substantiels. Coinbase aurait retracé environ 1,1 million de dollars de recettes vers l’opération tout en aidant l’enquête.

Ces chiffres expliquent l’ampleur du phénomène, mais ne capturent pas le changement essentiel. EvilTokens a relié plusieurs tâches criminelles auparavant distinctes via une interface unique et administrée.

Les abonnés disposaient d’outils de campagne, de modèles de phishing, de gestion de jetons, de suivi des victimes, de recherches dans les boîtes aux lettres et de conseils après compromission. Les canaux d’assistance et les tableaux de bord administratifs donnaient à l’opération l’apparence d’un service logiciel commercial.

Cette distinction est importante pour les défenseurs. Supprimer un domaine malveillant peut interrompre une campagne, mais ne démantèle pas un modèle de service transférable.

Microsoft a décrit l’action comme une perturbation plutôt que comme la preuve que chaque opérateur, abonné et système associé avait disparu. Les équipes de sécurité doivent donc s’attendre à une baisse d’activité, non à une élimination permanente.

Comment EvilTokens a transformé une connexion légitime en accès à un compte

EvilTokens exploitait la confiance des utilisateurs dans la véritable page d’authentification Microsoft plutôt que de s’appuyer uniquement sur un faux formulaire de connexion.

La plateforme reposait sur le phishing par code d’appareil. Cette technique détourne un flux d’authentification OAuth conçu pour les appareils qui ne disposent pas de claviers pratiques ou de navigateurs complets.

Les téléviseurs intelligents, les imprimantes, les équipements de conférence et certains appareils Teams peuvent utiliser ce processus. Un appareil affiche un code court, tandis que l’utilisateur termine l’authentification sur un autre écran.

Dans un flux malveillant, l’attaquant lance la demande et envoie son code à la cible. Un message trompeur persuade cette personne de saisir le code via la page légitime de connexion d’appareil de Microsoft.

La victime peut voir un domaine Microsoft valide et effectuer une authentification multifacteur normale. Toutefois, cette approbation autorise la session en attente de l’attaquant plutôt que l’activité attendue par la victime.

Aucun mot de passe ne doit transiter par un site web contrefait. Cette caractéristique affaiblit les conseils habituels centrés sur la vérification d’un domaine ou le refus de saisir des identifiants sur des pages suspectes.

Le panneau EvilTokens aidait les abonnés à intégrer ce processus dans des leurres réalistes. Microsoft a identifié 44 thèmes couvrant les factures, les fichiers partagés, les demandes de signature, les notifications de mot de passe, les avantages sociaux, les propositions et les partenariats commerciaux.

Les campagnes utilisaient des liens, des documents PDF, des pièces jointes HTML, des redirections et des pages de vérification imitées. Le service s’appuyait également sur des plateformes cloud légitimes et des sites web compromis afin de rendre l’infrastructure plus difficile à classifier.

Une fois le code approuvé par une victime, EvilTokens capturait un jeton d’authentification. Un jeton est un artefact numérique qui permet à une session autorisée d’accéder à des services spécifiques sans ressaisir le mot de passe.

Les jetons volés pouvaient donner accès aux e-mails et à des ressources Microsoft 365 associées. Les opérateurs pouvaient aussi actualiser les jetons, examiner les privilèges administratifs et recevoir des alertes par mot-clé sur les boîtes aux lettres via Telegram.

Microsoft a observé des cas où les attaquants créaient des règles de boîte de réception malveillantes pour masquer des messages. Dans certains incidents, ils enregistraient des appareils afin d’établir un accès plus durable peu après la compromission initiale.

Cette persistance modifie la réponse aux incidents. Réinitialiser un mot de passe ne met pas nécessairement fin à une session déjà autorisée et ne supprime pas un appareil enregistré.

Les défenseurs doivent révoquer les sessions et actualiser les jetons, examiner les enregistrements d’authentification, supprimer les appareils non autorisés et analyser les règles de boîte aux lettres. Sinon, l’attaquant peut conserver l’accès après la modification visible de l’identifiant.

L’analyse technique recommande de bloquer l’authentification par code d’appareil lorsqu’une organisation n’en a pas besoin. Les exceptions nécessaires devraient être limitées à des comptes spécifiques et à des appareils approuvés.

Les organisations doivent également surveiller les demandes inattendues de code d’appareil et les connexions à risque. Les utilisateurs doivent refuser les codes associés à des processus d’authentification qu’ils n’ont pas eux-mêmes initiés.

Une authentification résistante au phishing, notamment les passkeys et les clés de sécurité FIDO2, peut renforcer la protection. Pourtant, une authentification plus robuste ne peut pas à elle seule corriger tous les scénarios d’ingénierie sociale lorsque les utilisateurs sont trompés pour approuver une demande valide.

Cette limite constitue le compromis de sécurité plus profond. L’authentification par code d’appareil prend en charge des matériels aux interfaces limitées, mais son processus d’approbation séparé affaiblit le lien entre l’intention de l’utilisateur et la session demandeuse.

Les attaquants n’ont pas brisé le chiffrement de Microsoft ni calculé le mot de passe d’une victime. Ils ont manipulé un mécanisme d’autorisation légitime jusqu’à ce que la victime accorde l’accès.

La leçon dépasse une seule plateforme. Tout flux de sécurité qui sépare une demande de son approbation requiert un contexte clair et des contrôles de politique stricts.

Les utilisateurs doivent comprendre ce qu’ils autorisent, quelle application a demandé l’accès et où la session résultante fonctionnera. Les invites d’approbation génériques créent un espace propice à la tromperie.

EvilTokens a rendu cette tromperie reproductible. Sa contribution n’a pas été d’inventer le phishing par code d’appareil, mais de le conditionner pour une utilisation plus large et plus rapide.

L’IA est passée de la rédaction de leurres au choix de cibles de fraude

La capacité déterminante d’EvilTokens est apparue après la compromission d’un compte, lorsque l’IA a transformé une boîte de réception inconnue en plan de fraude concret.

L’IA générative est souvent associée à des e-mails de phishing soignés. EvilTokens l’a appliquée à un problème plus précieux : comprendre l’organisation d’une victime après avoir obtenu un accès.

Une boîte aux lettres compromise peut contenir des années de conversations, pièces jointes, factures, approbations, noms et relations hiérarchiques. Ces informations sont précieuses, mais leur examen manuel exige du temps et du discernement.

EvilTokens a automatisé une grande partie de ce travail. Ses outils pouvaient résumer et traduire les messages, identifier les discussions financières, cartographier les rôles organisationnels et faire émerger des relations externes de confiance.

Des recherches prédéfinies permettaient apparemment de localiser des conversations sur les virements, des factures, des responsabilités de paiement et des employés habilités à autoriser des transactions. Microsoft a indiqué que l’assistant pouvait également recommander la personne qu’un attaquant devrait usurper.

La plateforme aidait ensuite à générer des messages correspondant au contexte volé. Une demande frauduleuse pouvait faire référence à un projet réel, un fournisseur, un responsable, une facture ou une conversation en cours.

Ce processus favorise la compromission de messagerie professionnelle, ou BEC. Dans une attaque BEC, les criminels usurpent des participants de confiance afin de détourner des paiements ou de provoquer d’autres actions financièrement avantageuses.

Le BEC traditionnel dépend souvent d’opérateurs expérimentés. Ils doivent étudier les modes de communication, reconnaître les niveaux d’autorité, attendre une transaction utile et construire une intervention plausible.

EvilTokens a réduit cette charge d’investigation. Selon les informations publiées sur l’opération, des tâches pouvant nécessiter plusieurs jours pouvaient être condensées en quelques heures.

Cette compression compte davantage qu’une amélioration marginale de la grammaire. Un e-mail de phishing générique bien rédigé doit encore atteindre la bonne personne au bon moment.

L’analyse de boîte aux lettres donne à l’attaquant le moment opportun, le contexte et les connaissances organisationnelles. L’IA peut transformer ces détails dispersés en une liste classée d’opportunités prometteuses.

La technologie a également aidé des abonnés moins expérimentés. Un nouvel opérateur n’avait pas besoin de connaissances approfondies des systèmes d’identité, de l’ingénierie sociale, de la reconnaissance par e-mail et de la fraude aux paiements.

EvilTokens a réuni ces spécialités dans un flux de travail guidé. Son chatbot agissait moins comme un assistant de rédaction que comme un analyste conseillant la prochaine étape de l’attaquant.

Microsoft a également trouvé des éléments montrant que de larges portions de la plateforme elle-même avaient été construites avec du code assisté par IA. Cette conclusion suggère que l’IA a abaissé les barrières tant pour les développeurs de plateforme que pour les clients.

Cette découverte ne signifie pas que l’IA a créé ou exploité le service de manière autonome. Des humains ont toujours construit l’activité, sélectionné les cibles, géré l’infrastructure et appliqué les recommandations du système.

Elle n’établit pas non plus qu’un modèle commercial particulier a fourni l’ensemble des capacités d’IA. Microsoft a indiqué que les enquêteurs avaient observé l’utilisation de plusieurs modèles d’IA.

Les éléments publics étayent donc une conclusion plus restreinte. Les outils d’IA existants ont aidé les criminels à développer des logiciels et à interpréter plus efficacement les informations volées.

Cela représente une évolution significative de l’économie criminelle. Un tri plus rapide des boîtes mail permet à un opérateur d’examiner davantage de victimes sans accroître proportionnellement ses effectifs ou son expertise.

L’échelle améliore également la sélection. Les attaquants peuvent abandonner plus tôt les opportunités peu prometteuses et se concentrer sur les comptes liés au contrôle des paiements, à des fournisseurs de confiance ou à des cadres dirigeants.

L’opération contre Microsoft EvilTokens visait cette couche de conversion entre l’accès non autorisé et la monétisation. Cette couche explique pourquoi le service a attiré une attention dépassant celle accordée à une infrastructure de phishing ordinaire.

Une boîte de réception volée est déjà nuisible en elle-même. Un système qui explique rapidement comment exploiter cette boîte peut accroître à la fois la vitesse et la valeur attendue de l’intrusion.

Ce modèle exercera une pression sur les équipes chargées de l’identité, les fournisseurs de sécurité email et les entreprises d’IA. Chacun ne contrôle qu’une partie d’une chaîne d’attaque qui traverse plusieurs services indépendants.

Les fournisseurs d’IA peuvent suspendre les comptes abusifs, mais les attaquants peuvent changer de modèle. Les plateformes d’hébergement peuvent retirer l’infrastructure, mais les opérateurs peuvent passer d’un fournisseur à l’autre.

Les fournisseurs d’identité peuvent bloquer les sessions suspectes, mais les fonctions d’authentification légitimes doivent toujours servir de vrais appareils. Les défenseurs doivent coordonner leurs actions à travers ces frontières plus vite que les criminels ne peuvent reconstruire leur dispositif.

Pourquoi le démantèlement d’EvilTokens ne met pas fin au phishing par code d’appareil

L’opération a supprimé une infrastructure importante, mais la faiblesse d’authentification sous-jacente et la demande criminelle restent intactes.

Les rapports de sécurité ont déjà identifié APToken comme un service apparenté ou dérivé. Son apparition illustre la manière dont des affiliés peuvent reproduire une conception de phishing-as-a-service ayant fait ses preuves.

La relation exacte entre ces clones et Storm-2992 reste incertaine. Des fonctionnalités similaires ne prouvent pas une propriété commune ni une infrastructure partagée.

Le risque de copie reste néanmoins clair. EvilTokens a démontré qu’il existe une demande pour un produit intégré associant le vol de jetons, l’analyse des boîtes mail et la préparation de fraudes.

Ses opérateurs ont également diffusé des connaissances par le biais du support client, de tutoriels, d’interfaces et de relations avec des partenaires. Désactiver des serveurs ne peut effacer les compétences déjà acquises par les abonnés.

C’est pourquoi le terme « perturbation » est important. Microsoft et ses partenaires ont entravé les opérations en cours, recueilli des renseignements, augmenté les coûts opérationnels et soutenu des enquêtes toujours en cours.

Ces résultats peuvent réduire le volume immédiat des attaques. Ils ne garantissent pas que chaque client ait perdu son accès, que chaque jeton volé ait été révoqué ou que chaque victime ait été informée.

L’affaire judiciaire pourrait révéler davantage d’informations sur l’organisation et le réseau financier de la plateforme. Les enquêtes des forces de l’ordre pourraient également aboutir à d’autres arrestations, inculpations ou saisies.

D’ici là, plusieurs affirmations centrales reposent principalement sur la télémétrie de Microsoft et des entreprises participantes. Leur accès leur donne une visibilité précieuse, mais aucun fournisseur ne voit l’ensemble du marché criminel.

Le nombre de victimes peut aussi évoluer à mesure que les partenaires recoupent leurs dossiers. Les 12 000 boîtes de réception signalées représentent un seuil documenté lié aux observations actuelles.

Mesurer les pertes financières directes présente un problème encore plus difficile. Chaque boîte compromise n’a pas donné lieu à une fraude au paiement réussie, tandis que certaines organisations peuvent éviter toute divulgation publique.

Le rôle de l’IA exige également de la précision. EvilTokens a utilisé l’IA pour le développement logiciel, la création d’appâts, la traduction, l’analyse des boîtes mail et les recommandations de cibles.

Cependant, les rapports publics ne quantifient pas la fréquence à laquelle ces fonctionnalités ont permis des fraudes réussies. Ils ne comparent pas non plus les taux de réussite à ceux de campagnes sans assistance IA.

Les éléments montrent une intégration opérationnelle, et non un test contrôlé de l’efficacité. Affirmer que l’IA seule a causé l’ampleur de la plateforme irait donc au-delà des données disponibles.

EvilTokens bénéficiait de plusieurs capacités non liées à l’IA. Parmi elles figuraient la persistance des jetons, l’infrastructure automatisée, les modèles réutilisables, les redirections évasives et l’accès à des services cloud légitimes.

Sa popularité reflétait probablement cet ensemble complet. L’IA a accéléré certaines parties du flux de travail, mais le service environnant a transformé ces capacités en opérations reproductibles.

Les défenseurs devraient éviter de répondre uniquement par un autre produit d’IA. Les contrôles immédiats restent les politiques d’identité, la visibilité sur les sessions, la vérification des utilisateurs, le renseignement sur l’infrastructure et une réponse coordonnée aux incidents.

Les organisations qui n’ont pas besoin de l’authentification par code d’appareil peuvent la désactiver. Celles qui en ont besoin peuvent la limiter grâce à Conditional Access et à des comptes de ressources dédiés.

Les équipes de sécurité devraient également rechercher les enregistrements d’appareils inattendus, l’activité de rafraîchissement des jetons, les modifications de règles de boîte de réception, les accès Graph inhabituels et les approbations d’applications inconnues.

Les conseils de Microsoft sur les codes d’appareil fournissent une voie de politique pour restreindre ce flux d’authentification. La mise en œuvre exige toujours des tests avec les équipements légitimes et les processus métier.

Les défenses email doivent tenir compte des messages qui dirigent les utilisateurs vers des domaines authentiques. Une destination de confiance ne peut compenser une demande frauduleuse ou un contexte trompeur.

La formation devrait donc mettre l’accent sur l’initiation et l’intention. Les utilisateurs ne devraient saisir un code d’appareil que lorsqu’ils ont eux-mêmes lancé la connexion correspondante sur un appareil connu.

Les organisations ont également besoin de procédures rapides en cas de suspicion de vol de jeton. Les services d’assistance doivent savoir qu’une simple réinitialisation du mot de passe peut laisser la session hostile active.

La documentation est importante durant ces incidents, car les équipes chargées de l’identité, de l’email, du juridique, de la finance et de la direction ont souvent besoin des mêmes éléments de preuve. Une base de connaissances technique consultable peut préserver les décisions, les indicateurs et la responsabilité des remédiations.

Cette discipline opérationnelle aide à combler la faille exploitée par EvilTokens. Les criminels ont utilisé l’automatisation pour coordonner leur côté, tandis que de nombreux défenseurs répartissent encore les preuves entre des systèmes déconnectés.

Ce qui vient après l’opération contre Microsoft EvilTokens

Trois signaux montreront si cette opération a créé une pression durable ou seulement un recul temporaire des campagnes.

Le premier signal est l’activité EvilTokens mesurable après l’action contre l’infrastructure. Les fournisseurs de sécurité devraient surveiller la réduction du phishing par code d’appareil, les changements de domaines et la migration vers d’autres services cloud.

Un recul durable indiquerait que les saisies de domaines et la coordination entre fournisseurs ont endommagé davantage qu’une couche de campagne jetable. Un retour rapide suggérerait que les opérateurs ont conservé leurs clients, leurs outils et une infrastructure alternative.

L’évaluation des menaces de Cloudflare fournit des indicateurs utiles et décrit le démantèlement coordonné. Les futures mises à jour des fournisseurs participants pourront montrer si une infrastructure liée réapparaît.

Le deuxième signal est l’adoption par les clones et les concurrents. APToken et les services similaires méritent l’attention, car ils peuvent préserver le modèle commercial sans réutiliser la marque EvilTokens.

Les chercheurs devraient comparer leurs méthodes d’authentification, leurs fonctions d’analyse de boîtes mail, leurs réseaux de support et leur infrastructure. Du code ou des opérateurs partagés renforceraient l’hypothèse d’une continuité.

Des services indépendants adoptant la même conception indiqueraient une évolution plus large du marché. Cela montrerait que l’analyse post-compromission guidée par l’IA est devenue une fonctionnalité standard des produits criminels.

Le troisième signal est l’issue judiciaire et investigative. L’action civile de Microsoft identifie des opérateurs présumés, tandis que les autorités britanniques poursuivent leur enquête distincte.

De nouveaux dépôts judiciaires pourraient clarifier la propriété, les flux de revenus, les relations clients et le contrôle de l’infrastructure. Des poursuites pénales ou des saisies financières accroîtraient la pression sur les opérateurs comme sur les acheteurs du service.

Un résultat d’application de la loi limité n’invaliderait pas la perturbation technique. Il pourrait toutefois réduire l’effet dissuasif si les opérateurs de remplacement estiment que le risque juridique reste gérable.

Les défenseurs devraient aussi surveiller la réponse produit de Microsoft. EvilTokens a abusé d’un flux de travail légitime plutôt que d’une vulnérabilité logicielle pouvant être corrigée simplement.

Microsoft peut améliorer les invites, la détection, les contrôles des jetons et la visibilité des administrateurs. Il doit toutefois préserver l’authentification par code d’appareil pour les équipements pris en charge et les scénarios de connexion accessibles.

Cet équilibre rend les paramètres de politique par défaut particulièrement importants. Des valeurs par défaut sécurisées peuvent réduire l’exposition sans exiger que chaque organisation comprenne une technique spécialisée d’abus OAuth.

Les fournisseurs cloud et d’identité font face à une question de conception plus large. Les écrans d’approbation doivent indiquer clairement quel appareil, quelle application et quelle session recevront l’accès.

Les utilisateurs ont également besoin d’un avertissement clair lorsque le contexte demandeur diffère de leur appareil actuel. Un meilleur contexte peut rendre une page de connexion légitime moins utile comme preuve sociale pour les attaquants.

Les entreprises d’IA ont un autre rôle à jouer. La détection des abus peut identifier les comptes qui analysent de manière répétée des correspondances volées, génèrent des messages d’usurpation d’identité ou automatisent des flux de travail criminels connus.

Ces contrôles ne stopperont pas les modèles exploités en dehors des principales plateformes. Ils peuvent néanmoins augmenter les coûts et contribuer aux éléments de preuve lorsque les criminels s’appuient sur des services commerciaux.

L’affrontement plus large oppose l’automatisation criminelle packagée à une défense coordonnée. EvilTokens a réussi parce qu’il réunissait l’abus d’identité, l’infrastructure cloud, l’analyse par IA et l’expertise en fraude.

La réponse a utilisé un modèle tout aussi connecté. Microsoft a combiné autorité judiciaire, renseignement sur les menaces, application des règles de plateforme, traçage financier et coopération avec les forces de l’ordre.

Cette symétrie constitue la leçon centrale de l’opération contre Microsoft EvilTokens. Aucun produit de sécurité unique ne peut répondre à une chaîne d’attaque construite à travers plusieurs systèmes légitimes.

Les organisations devraient commencer par confirmer si l’authentification par code d’appareil est nécessaire, puis examiner les politiques, les procédures de révocation de session et la couverture de surveillance. Elles devraient également tester la rapidité avec laquelle les équipes financières peuvent valider des demandes de paiement inhabituelles.

Le prochain service malveillant pourrait porter un autre nom, utiliser un autre modèle ou un autre fournisseur d’hébergement. La question importante est de savoir si les défenseurs peuvent reconnaître le flux de travail avant qu’une communication volée ne devienne un plan de fraude convaincant.