EvilTokens : comment l’IA a servi à pirater 12 000 boîtes mail
Microsoft détaille EvilTokens, une opération cybercriminelle utilisant l'IA pour cibler et fouiller plus de 12 000 boîtes mail professionnelles.

👁 116 lectures
Situation au 10 octobre 2026
Microsoft a détaillé EvilTokens, une opération cybercriminelle exploitant l’intelligence artificielle pour personnaliser des leurres et analyser les boîtes de messagerie compromises afin d’y repérer des cibles à forte valeur. L’analyse a été publiée le 22.09.2026. Le problème central ne se limite pas à un e-mail particulièrement bien rédigé : accéder aux échanges permet aux pirates d’identifier la prochaine cible et d’aligner leur requête sur ses dossiers en cours. Ce cas, issu de notre série sur les cas d’usage de l’IA, montre pourquoi la sécurité d’une boîte mail ne peut être dissociée du contrôle des décisions prises à partir de son contenu.
En résumé
- Les attaquants ont obtenu la validation de leur session en détournant la procédure légitime d’authentification par code d’appareil (22.09.2026).
- L’opération a touché plus de 12 000 boîtes de messagerie dans plus de 10 000 organisations à travers le monde (22.09.2026).
- Le nombre de boîtes ne correspond pas au nombre d’individus, et l’IA n’a pas cassé mathématiquement le MFA (22.09.2026).
Chronologie de l’attaque
- Février : le service était déjà identifié (Microsoft, 22.09.2026).
- Publication de Microsoft : le rapport couvre les campagnes et les mesures prises sur le semestre étudié, dont une perturbation coordonnée de l’infrastructure (22.09.2026).
- Octobre : le CERT-EU communique sur les actions menées contre l’infrastructure et sur des arrestations (2026-10).
Ce que révèlent les chiffres
| Domaine | Constat | Limite d’interprétation |
|---|---|---|
| Infrastructure | 50 sites saisis, plus de 150 domaines supplémentaires désactivés (CERT-EU, 2026-10). | Il s’agit du résultat de l’intervention, pas du bilan des comptes récupérés. |
| Action policière | La police de Londres a arrêté deux hommes (CERT-EU, 2026-10). | Une arrestation ne vaut pas condamnation. |
Déroulement : validation de l’accès puis tri des données
D’après le rapport de Microsoft, l’accès à la messagerie et l’exploitation de son contenu constituent deux étapes bien distinctes. Une autorisation extorquée ouvrait la session aux attaquants ; l’IA intervenait ensuite à la fois pour concevoir des leurres et pour passer au crible les messages dérobés (22.09.2026). Cette séparation clarifie l’ensemble de l’affaire : l’outil d’IA n’était pas l’auteur autonome du délit, et l’accès initial au compte ne garantit pas la réussite de chaque tentative ultérieure.
Notre analyse : le contexte compte bien plus que la grammaire
Une formulation soignée produit une bonne première impression. En revanche, le contenu d’une boîte mail apporte une valeur bien plus redoutable : il fournit le contexte nécessaire pour qu’une demande frauduleuse apparaisse comme la suite logique d’un dossier en cours. La nuance est majeure. Améliorer la forme d’un message relève du style ; sélectionner les bonnes informations oriente le choix du sujet, du destinataire et des justifications avancées. C’est un potentiel d’exploitation des données, non la preuve que chaque tentative a abouti.
Cela implique de repenser votre approche défensive. La question n’est plus seulement de savoir si un message paraît suspect, mais si l’expéditeur est légitime pour exiger une telle action. Un sujet familier, un texte impeccable et la concordance avec des échanges passés ne valent pas autorisation pour accorder un accès ou modifier des coordonnées bancaires. Vous devez évaluer séparément la crédibilité du récit et la légitimité de la demande.
L’IA doit être jugée à l’aune du travail accompli, et non sur sa seule étiquette technologique. Concevoir un leurre et fouiller une boîte mail exigent des parades différentes. Sur le premier point, l’essentiel est d’empêcher toute validation injustifiée d’une session. Sur le second, il faut éviter que la confiance accordée à une boîte mail ne se reporte aveuglément sur chaque requête qui en sort. Interdire simplement l’usage des IA aux collaborateurs ne règle aucun de ces deux problèmes.
Rien ne justifie non plus d’attribuer à un texte généré une quelconque intention humaine. Ce sont bien les criminels qui choisissent les cibles et exploitent les accès obtenus. Dissocier ces rôles aide à fixer les responsabilités et à bâtir une défense efficace : votre procédure doit bloquer une décision non autorisée, peu importe l’outil utilisé pour rédiger l’e-mail. Elle n’a pas besoin de déterminer qui a écrit le texte pour fonctionner.
Gains réels, pertes constatées et risques résiduels
Le résultat documenté du côté des attaquants reste la prise de contrôle des boîtes de messagerie. L’économie de temps réalisée lors du tri des messages ne correspond pas automatiquement à un gain financier prouvé. Structurer l’information facilite de futures escroqueries, sans pour autant sceller leur issue. Faute de données sur les étapes suivantes, nous ne pouvons pas mesurer l’impact réel de l’IA sur l’efficacité globale de l’opération.
Les propriétaires des boîtes compromises ont perdu la maîtrise de leurs accès. Les répercussions potentielles touchent aussi les contacts présents dans les fils de discussion : clients, collaborateurs ou partenaires. Une raison suffisante pour que votre réaction ne s’arrête pas au simple changement de mot de passe. Cela ne signifie pas que chaque organisation ciblée a subi un préjudice identique, ni que son carnet d’adresses a été exploité avec succès.
La mise hors d’état de nuire de l’infrastructure marque une victoire pour la défense. Mais pour une entreprise touchée, un autre bilan s’impose : les accès suspects ont-ils été coupés, le périmètre de l’incident a-t-il été circonscrit et les processus financiers à risque ont-ils été vérifiés ? L’intervention externe des autorités et la remédiation interne sont deux choses distinctes qu’il faut évaluer séparément.
Les leçons à retenir pour votre organisation
Les règles les plus efficaces s’appliquent au moment précis où un message invite à agir. Elles doivent être simples, connues avant tout incident et applicables sans chercher à deviner les intentions de l’expéditeur.
- Validation des sessions : chaque collaborateur doit comprendre quel accès il autorise et à quelle action initiée par lui-même se rattache la demande. Tout processus suspect doit être interrompu et signalé via un canal de support officiel.
- Changement de RIB ou coordonnées bancaires : exigez toujours une contre-confirmation indépendante. Les coordonnées figurant dans l’e-mail demandant la modification ne doivent jamais servir de base de contrôle.
- Gestion d’une compromission : votre plan de réponse doit désigner les responsables chargés de révoquer les accès, de mesurer l’étendue de l’intrusion, de préserver les journaux utiles à l’enquête et d’avertir les parties prenantes.
- Droit d’interrompre un processus : chaque collaborateur doit savoir où faire remonter un doute et qui arbitrera un éventuel arbitrage entre urgence opérationnelle et sécurité.
Pour un utilisateur individuel, la priorité est de dissocier le message reçu du canal utilisé pour le vérifier. Contactez vous-même votre administrateur ou votre fournisseur de services, au lieu de suivre les instructions du courriel suspect. En cas de doute sur un piratage, appliquez la procédure officielle sans tenter d’expérimenter avec le mécanisme d’attaque.
Cas pratique : la modification urgente d’un compte bancaire
Imaginons qu’une entreprise reçoive une demande de changement de coordonnées bancaires d’un fournisseur alors qu’un règlement est en cours. Le message fait référence à un dossier réel et l’échéance de paiement est proche. Il s’agit ici d’une illustration de nos recommandations, non d’un cas extrait d’EvilTokens. Le dilemme consiste à choisir entre exécuter rapidement une demande familière ou suspendre le virement jusqu’à confirmation formelle.
L’employé n’a pas à deviner si le texte a été généré par une IA. Il doit faire valider la modification par un canal convenu au préalable, totalement indépendant du nouvel e-mail. Si la confirmation ne peut être obtenue, le dossier remonte à la personne habilitée à trancher. L’urgence ne supprime pas le contrôle : elle active un protocole dédié.
Si un doute surgit simultanément sur la compromission d’une boîte mail, les rôles doivent rester séparés. L’administrateur sécurise les accès pendant que le responsable comptable contrôle l’ordre de paiement. Verrouiller le compte ne garantit pas la légitimité du virement en attente. Toute l’utilité de la procédure repose sur ce principe : chaque décision dispose d’un responsable désigné et de critères clairs de clôture.
Ce qui reste à éclaircir
Les éléments disponibles ne précisent ni le montant des pertes financières, ni le nombre exact de victimes individuelles, ni le volume de comptes restaurés, ni la part directe de l’IA dans la rentabilité des attaques. La conclusion opérationnelle est néanmoins limpide : protégez vos accès de messagerie, mais sécurisez tout autant les décisions déclenchées par leur contenu.
Un exercice sans faux e-mail de phishing
Nous vous conseillons de tester votre chaîne de décision à l’aide d’un scénario fictif de changement de coordonnées bancaires, sans envoyer de faux courriel de phishing ni manipuler de vrais échanges. L’objectif est d’identifier qui a le pouvoir de suspendre un paiement, où trouver le contact officiel vérifié et qui arbitre en cas d’absence du responsable du dossier. C’est un audit de vos processus internes, pas un examen de vigilance pour vos salariés.
Google · Vos sourcesPromptif plus haut dans Google - en un clicAjouter aux sources préférées →Sources
- Microsoft : analyse d’EvilTokens - 22.09.2026.
- CERT-EU : bulletin sur les menaces - octobre 2026 ; les données publiées ne précisent pas le jour exact.
Microsoft démantèle EvilTokens, plateforme cybercriminelle alimentée par l’IA qui a compromis 12 000 comptesActualités
Des agents OpenAI ont tenté de pirater RubyGems en mai, un mois avant l’incident Hugging FaceActualités
Des mathématiciens réclament à OpenAI la preuve que leurs travaux n’ont pas servi à entraîner ses modèlesActualitésMore on this from PROMPTIF
état de l'ia·Cas d’usage IA : retours d’expérience réels, chiffres et leçonsL'IA dans la pratique : déploiements en entreprise, failles, deepfakes et agents. Des dossiers documentés, des chiffres clairs et des enseignements concrets.