Ce qui a été annoncé et ce qu’établit la page judiciaire
Le 22 septembre 2026, Microsoft a publié une page intitulée « EvilTokens » dans sa rubrique de notifications de documents judiciaires. Les éléments vérifiés pour cet article confirment le titre, l’emplacement de la page et sa date de publication, mais ne suffisent pas à établir les détails concernant les parties, les mesures demandées ou l’état de la procédure. Il ne convient donc pas de présenter des allégations précises ou une décision de justice comme des faits établis sur la seule base de cette page. Cette distinction est importante : l’existence d’une notification ne constitue pas, à elle seule, un compte rendu complet de l’affaire.
L’article de CSO Online replace l’affaire dans le contexte plus large de la cybercriminalité liée à l’intelligence artificielle. Cet angle journalistique ne démontre pas, à lui seul, le rôle éventuel de l’IA dans des incidents précis. Les sources disponibles ici ne fournissent pas d’audit indépendant confirmant son utilisation, son ampleur ou ses effets dans des campagnes attribuées à EvilTokens. La même prudence s’impose pour les chiffres d’impact et l’ampleur de toute action visant la plateforme. Les documents vérifiés ne donnent aucun décompte indépendant des comptes touchés et ne décrivent pas les ressources techniques qui auraient été retirées. La page de Microsoft confirme l’existence d’une publication sur EvilTokens dans une rubrique judiciaire, mais ne permet pas de reconstituer tous les détails de l’affaire. Distinguer ce qui est documenté de ce qui n’a pas pu être vérifié évite de transformer une annonce ou une référence médiatique en bilan confirmé.
Le flux légitime qui peut devenir un leurre
L’authentification par code d’appareil est un flux d’autorisation OAuth légitime, utile pour les équipements dotés d’interfaces limitées, comme les téléviseurs, les imprimantes ou les appareils IoT. L’appareil demande un code et la personne termine l’authentification dans un navigateur sur un autre appareil. La documentation de Microsoft explique que le client attend la réponse du service d’autorisation pendant que l’utilisateur termine la procédure ; le code utilisateur n’est valable que pendant une durée limitée. Concrètement, le flux sépare l’appareil qui doit s’authentifier de celui que la personne utilise pour saisir ses identifiants et approuver la demande. Le code relie les deux pendant un intervalle limité, et les vérifications répétées du client permettent à l’appareil d’origine de savoir si l’autorisation a abouti, sans disposer de sa propre interface de connexion.
Cette simplicité est utile lorsqu’un appareil ne possède ni clavier ni navigateur adaptés, mais elle rend d’autant plus important de comprendre quelle demande est approuvée. La documentation permet de décrire le mécanisme général ; toutefois, les sources vérifiées pour cet article ne suffisent pas à confirmer qu’EvilTokens l’a utilisé dans une campagne précise ni à reconstituer ses étapes techniques. Comme risque général de ce type de flux, une personne peut être amenée à saisir un code et à approuver une demande qu’elle n’a pas initiée ou qu’elle ne reconnaît pas. Un portail légitime ne garantit pas que la demande approuvée soit légitime. Cette explication du risque ne doit pas être confondue avec une description vérifiée des méthodes d’EvilTokens.
Ce que l’on peut dire de l’IA
Le titre de l’article de CSO Online associe l’interruption d’EvilTokens au contexte plus large de la cybercriminalité alimentée par l’IA. Cependant, les sources vérifiées disponibles ne comprennent aucune enquête indépendante confirmant l’utilisation de capacités d’IA dans des incidents précis. L’IA ne peut donc pas être présentée comme une explication démontrée du succès d’une campagne liée à EvilTokens. Il faut distinguer l’angle d’un article d’actualité des preuves portant sur un incident particulier : le premier n’établit pas les faits du second.
Le risque général du flux s’explique sans l’attribuer à une technologie particulière : une personne peut être poussée à approuver une demande d’authentification qu’elle ne reconnaît pas. Si cette approbation permet de créer une session valide, les contrôles qui portent uniquement sur le mot de passe ne décrivent pas, à eux seuls, l’ensemble du risque. Le mécanisme d’autorisation et la décision d’approuver la demande comptent également, mais ces considérations générales ne prouvent pas le fonctionnement d’un service précis. L’IA mérite une attention particulière, mais il n’est pas nécessaire de lui attribuer un rôle dans cette affaire pour expliquer la précaution pratique. Les informations disponibles ne permettent pas de déterminer s’il y a eu automatisation, quelles tâches elle aurait effectuées ni quelle aurait été sa contribution. De même, sans source vérifiable sur le nombre de comptes touchés, il serait irresponsable de reprendre un chiffre comme s’il était corroboré. Les articles sur le contexte de l’IA doivent rester distincts des conclusions réellement étayées par la documentation.
Ce que signifie — et ne signifie pas — une interruption
La page de Microsoft confirme une publication intitulée « EvilTokens », mais les informations disponibles dans les sources vérifiées ne permettent pas de préciser le nombre ou le type de ressources techniques qui auraient été retirées. Elles ne permettent pas non plus d’affirmer que toute l’infrastructure associée a disparu. L’existence d’une page dans une rubrique de notifications de documents judiciaires ne suffit pas à attribuer un résultat technique précis à une opération. Même lorsqu’une interruption est annoncée, ses effets concrets et durables doivent être établis par des éléments allant au-delà de l’annonce.
De manière générale, interrompre une plateforme peut compliquer la poursuite de l’activité qui lui est attribuée, sans démontrer que toutes ses instances, ses opérateurs ou ses copies ont été identifiés ou supprimés. Cela ne prouve pas non plus que d’autres acteurs ne puissent pas utiliser une infrastructure différente ou reproduire une technique similaire. Il s’agit de limites générales à l’interprétation d’un démantèlement, et non d’affirmations vérifiées sur l’ampleur d’une action précise contre EvilTokens. Au vu des éléments vérifiables, il ne convient pas d’affirmer que tous les domaines ou services associés ont été supprimés ni de préciser les mesures prises contre chaque composant. Interrompre une opération identifiée peut en réduire la portée ; cela n’élimine pas à lui seul une technique de phishing et n’empêche pas d’autres acteurs de la reproduire. Distinguer l’état d’une plateforme de la possible poursuite de méthodes similaires évite de tirer des conclusions plus larges que ne le permettent les preuves disponibles.
Mesures de défense : évaluer avant de bloquer
Pour les organisations qui n’ont pas besoin du flux par code d’appareil, Microsoft documente son blocage au moyen d’une stratégie d’accès conditionnel. Avant de l’appliquer, il est utile de vérifier si l’organisation utilise ce flux et quelles connexions pourraient être concernées. La documentation de Microsoft sur les flux d’authentification explique comment utiliser ce type de flux comme condition dans une stratégie ; elle ne signifie pas que toutes les organisations doivent appliquer un blocage identique. Cette vérification préalable est importante, car un blocage indiscriminé pourrait interrompre des appareils ou des processus qui dépendent légitimement de cette méthode. Si des exceptions sont nécessaires, il est prudent de les limiter aux besoins identifiés et de les réexaminer lorsque les systèmes ou leurs usages évoluent.
La recommandation pratique consiste à réduire les flux inutiles sans supposer que le code d’appareil n’a aucun usage légitime, et à tester la configuration avant de la déployer largement. Il s’agit de conseils opérationnels fondés sur le contrôle documenté, et non d’une affirmation selon laquelle une stratégie unique conviendrait à tous les environnements. Pour les utilisateurs, une demande inattendue de copie d’un code ou d’approbation d’une connexion constitue un signal d’alerte utile. Si l’authentification n’a pas été lancée par la personne et qu’elle ne comprend pas quel appareil ou quelle application la demande, mieux vaut ne pas poursuivre et vérifier la demande par un canal connu. L’apparence du portail ne permet pas, à elle seule, de savoir qui a lancé la demande liée au code ; le contexte compte également. Les équipes de sécurité peuvent profiter de cette affaire pour examiner les flux activés et les connexions inhabituelles. Il ne s’agit pas d’abandonner l’authentification multifacteur, mais de l’associer à des stratégies adaptées aux besoins et à une attention particulière au contexte de chaque approbation.