EvilTokens fait passer une autorisation d’accès pour une vérification nécessaire à l’ouverture d’un document. L’utilisateur peut alors authentifier la demande de l’attaquant sur une véritable page Microsoft. Le parcours décrit par Microsoft éclaire ce piège, les traces à examiner après une suspicion et les mesures de sécurisation à adapter à son environnement.
Une attaque contre le sens de l’autorisation
Un code de connexion relie deux actions : la demande d’un client logiciel et sa validation par un utilisateur. Dans le parcours EvilTokens, le leurre dissimule qui a lancé cette demande. La personne croit vérifier son identité pour accéder à un document, alors qu’elle accorde un accès au client contrôlé par l’attaquant. Le mot de passe et la vérification multifacteur peuvent être saisis sur le bon site sans corriger ce décalage.
Dans son analyse du 22 septembre 2026, Microsoft décrit une plateforme de phishing par abonnement qui organise cette chaîne, depuis la préparation du message jusqu’à l’exploitation des comptes. L’entreprise lui associe plus de 12 000 boîtes compromises dans plus de 10 000 organisations et attribue son développement et son support à Storm-2992. Ces chiffres et cette attribution restent les conclusions de Microsoft ; les autres sources fournies ne les valident pas indépendamment.
Huntress a relié à EvilTokens une campagne observée sur Railway, tandis que Cloudflare rapporte l’utilisation de ses Workers et sa participation à une opération coordonnée de démantèlement. Ces observations corroborent des mécanismes et des infrastructures dans leurs périmètres respectifs. Elles ne constituent pas une mesure indépendante de l’ensemble des victimes annoncé par Microsoft.
Les neuf captures publiées dans l’analyse Microsoft permettent de suivre l’organisation du service et le parcours proposé à la victime. Les écrans commerciaux documentent des options et des promesses, dont l’affichage ne prouve pas l’efficacité. Les observations d’incidents apportent une autre information : elles décrivent les actions effectivement rapportées dans les cas étudiés.
Le code appareil : un usage légitime détourné
Le flux OAuth par code appareil répond à une contrainte réelle. Un téléviseur, une imprimante ou certains équipements Teams ne permettent pas une connexion interactive confortable. Le client demande alors un code à Microsoft, l’affiche, puis attend. L’utilisateur saisit ce code dans un navigateur, éventuellement sur un autre appareil, et termine l’authentification. Après cette autorisation, le client demandeur reçoit un jeton d’accès et, selon le cas, un jeton de renouvellement.
Le jeton d’accès permet d’utiliser les ressources autorisées ; le jeton de renouvellement sert à obtenir de nouveaux jetons d’accès. La distinction compte pour la suite : récupérer ces éléments ne revient pas seulement à connaître un mot de passe. L’attaquant dispose d’un moyen d’exercer l’accès accordé au client, dans les limites des autorisations obtenues et de la validité des jetons.
Dans le détournement décrit par Microsoft, le client demandeur est contrôlé par l’attaquant. Le code est présenté à la victime comme une étape nécessaire pour consulter un document ou vérifier son identité. L’utilisateur effectue une authentification légitime, mais au bénéfice d’une demande qu’il n’a pas lui-même initiée. Parler simplement de « MFA contournée » masque cette mécanique : la victime peut accomplir elle-même l’authentification multifacteur, ou MFA, pendant qu’elle autorise la mauvaise session.
Une boutique, un support et un panneau de campagne
Selon Microsoft, EvilTokens rassemble dans une même plateforme les éléments nécessaires à une campagne : modèles de messages, pièces jointes, pages d’arrivée, hébergement, redirections et suivi des victimes. Les abonnés peuvent ainsi préparer leurs opérations avec l’assistance du service, plutôt que de construire séparément chaque composant technique.
Le profil du bot Telegram présenté comme la boutique EvilTokens affiche un contact d’administration, un site et un contact de secours. Ces différents points de contact donnent au service l’apparence d’une offre suivie, avec plusieurs moyens de joindre ses opérateurs. Microsoft rapporte que Telegram sert également aux annonces, aux mises à jour, à la coordination des abonnés et au support. Le profil ne permet pas d’identifier les personnes derrière ces comptes.
Source : Microsoft Security Blog
L’offre affichée dans le bot mêle vocabulaire d’entreprise et promesses offensives. Elle présente notamment des jetons qui « n’expirent pas » et un accès persistant après changement de mot de passe. Dans son analyse de septembre 2026, Microsoft rapporte un achat initial de 1 500 dollars américains et un abonnement mensuel de 500 dollars. Ces tarifs décrivent l’offre étudiée, sans établir sa disponibilité actuelle. Les promesses de non-expiration et de persistance ne remplacent pas l’examen des autorisations et de la validité réelle des jetons.
Source : Microsoft Security Blog
La page d’accueil du panneau répartit la préparation entre deux familles d’hébergement : Cloudflare Workers/Bunny et hébergement PHP. Elle présente ensuite des réglages de mode de capture, de modèle, d’affichage du code, de langue, de CAPTCHA et de personnalisation. L’intérêt de cette interface guidée est de rapprocher des choix habituellement dispersés : où héberger le leurre, quelle apparence lui donner et comment présenter l’étape d’autorisation à la cible.
Source : Microsoft Security Blog
Le panneau de gestion des jetons annonce l’accès à la messagerie, la détection de comptes administrateurs, le renouvellement automatique et des alertes par mots-clés. Il présente donc l’authentification de la cible comme le début d’un travail sur le compte, plutôt que comme la fin de l’attaque. Les possibilités étendues promises pour certains jetons administrateurs restent toutefois des affirmations du service : les permissions réellement obtenues, notamment sur les autres boîtes d’une organisation, ne sont pas établies par cet écran.
Source : Microsoft Security Blog
La page d’outils complémentaires propose un navigateur ET, un redirecteur antibot, un expéditeur B2B, un expéditeur SMTP et un validateur d’adresses Office. Les boutons d’acquisition et de tutoriel, ainsi que l’offre de parrainage, prolongent la logique de boutique. Microsoft rapporte des frais supplémentaires pour plusieurs modules et une récompense en cryptomonnaie pour les recommandations. Ce catalogue montre comment le service commercialise des fonctions autour du leurre, de sa diffusion et de l’exploitation des accès ; il ne mesure pas leur contribution aux incidents.
Source : Microsoft Security Blog
Microsoft rapporte aussi l’usage d’assistants d’IA pour adapter les messages au rôle de la cible et analyser des messageries compromises. Cette assistance s’inscrit dans la même organisation du travail : préparer un message pertinent, puis chercher des comptes ou des échanges intéressants après l’accès. Les observations fournies ne permettent ni de quantifier le gain apporté par l’IA ni de conclure qu’elle intervient dans toutes les campagnes.
Des modèles familiers pour faire accepter une étape inhabituelle
Le sélecteur de thèmes présente notamment la signature Adobe, DocuSign, une notification vocale, la quarantaine de messagerie, l’expiration de mot de passe et le partage de fichiers. Des champs permettent de modifier la couleur, le nom du document et le pied de page. Microsoft décrit 44 thèmes au total, dont seule une partie apparaît dans la capture. Ces réglages permettent d’envelopper la demande de code dans plusieurs situations professionnelles familières, sans changer le principe de l’autorisation recherchée.
Source : Microsoft Security Blog
Le ressort du leurre est de rendre cohérente une étape qui, isolément, devrait interroger. La signature d’un document peut servir de prétexte à une vérification d’identité ; un avis d’expiration suggère une action urgente ; une proposition commerciale donne une raison d’ouvrir un lien. Microsoft décrit des messages adaptés aux fonctions des destinataires. Huntress rapporte également des propositions de chantier, des accords commerciaux, des messages sur la rémunération et des avis d’expiration de mot de passe.
Le courriel présenté en exemple invite le destinataire à soumettre une proposition pour un projet et renvoie vers un dossier annoncé comme accessible via Adobe. Une référence de document et une invitation à poser des questions lui donnent le ton d’un échange professionnel ordinaire. Le message fournit ainsi une raison d’ouvrir le lien avant toute demande de connexion. La capture ne révèle cependant ni l’identité réelle de l’expéditeur, ni la destination effective du lien, ni le résultat de l’interaction.
Source : Microsoft Security Blog
Les points d’entrée décrits par Microsoft comprennent des URL, des PDF et des fichiers HTML. L’interaction avec le lien ou la pièce jointe amorce le parcours vers la page de phishing. Le leurre n’a donc pas besoin de demander immédiatement un mot de passe : il peut d’abord conduire la personne vers une étape intermédiaire qui prépare l’autorisation.
Du faux document à la véritable connexion Microsoft
La page aux couleurs d’Adobe Acrobat Sign associe un document nommé Important_update.pdf à une demande de vérification d’identité avec Microsoft. Elle affiche un code, propose de le copier, puis de continuer vers Microsoft. L’accès au document devient ainsi le motif apparent de l’opération. Cette mise en scène est visible dans la capture ; la génération du code en temps réel et la récupération ultérieure des jetons sont décrites par l’analyse Microsoft.
Source : Microsoft Security Blog
Selon Microsoft, la page exécute un script d’automatisation qui échange avec le fournisseur d’identité pour obtenir un code valide. Le bouton de continuation dirige ensuite la victime vers le portail officiel microsoft.com/devicelogin. L’analyse décrit aussi une copie automatique fréquente du code dans le presse-papiers, destinée à réduire les manipulations demandées à l’utilisateur. Le passage vers un véritable portail de connexion fait donc partie du piège.
Pendant ce temps, l’infrastructure suit l’avancement de la session. Dans la séquence étudiée, Microsoft décrit une fonction checkStatus() qui interroge un point de terminaison /state toutes les trois à cinq secondes, pendant une fenêtre de quinze minutes. Ce suivi transmet un identifiant secret de session et reste en attente tant que la victime n’a pas terminé l’authentification. Il renseigne l’état du parcours côté plateforme ; il ne constitue pas, à lui seul, la preuve d’une autorisation réussie.
L’écran Microsoft de saisie du code avertit que l’application ou l’appareil concerné obtiendra l’accès au compte et qu’il ne faut pas saisir un code provenant d’une source non fiable. C’est le changement de sens crucial entre les deux pages : le leurre parle de consulter un document, tandis que le portail parle d’accorder un accès. Microsoft présente cette capture comme son écran de connexion par code appareil ; l’authenticité de la page de destination ne garantit pas la fiabilité de l’origine du code.
Source : Microsoft Security Blog
Si la victime n’a pas de session active, elle peut être invitée à saisir son mot de passe et à effectuer la MFA. Si elle est déjà connectée, la saisie du code et la confirmation peuvent suffire dans le parcours décrit. Lorsque l’autorisation aboutit, le client contrôlé par l’attaquant peut obtenir les jetons. Le secret n’a pas nécessairement été tapé dans une imitation de page de connexion : c’est l’autorisation donnée au mauvais client qui fait basculer l’accès.
Une livraison à plusieurs étapes pour compliquer l’analyse
Microsoft décrit des liens portés par des images, des pièces jointes et plusieurs redirections avant la page finale. Certaines pages imposent un faux CAPTCHA ou une vérification nécessitant une interaction humaine avant de montrer le contenu. Ces étapes cherchent à compliquer l’examen par des analyseurs d’URL et des environnements automatisés. Elles constituent des techniques d’évasion observées, sans garantir un passage à travers toutes les protections.
L’analyse rapporte l’utilisation de domaines légitimes compromis et de plateformes comme Vercel, Cloudflare Workers et AWS Lambda pour héberger la logique de redirection. L’objectif est de faire passer des éléments de l’attaque au milieu de trafic cloud habituel et de limiter l’efficacité d’un filtrage fondé uniquement sur la réputation du domaine. Cela n’autorise pas à qualifier de malveillant tout usage de ces plateformes.
Pour une campagne suivie en avril 2026, Microsoft rapporte des milliers de nœuds de suivi uniques et de courte durée, avec une logique serveur en Node.js. Le fournisseur associe cette infrastructure dynamique à des difficultés pour les détections par signature ou motif. Cloudflare confirme, dans son propre compte rendu, avoir observé des usages de Workers et supprimé des projets et domaines associés lors de l’opération coordonnée de septembre. Ces observations portent sur des périmètres distincts : Cloudflare ne valide pas ici le détail des nœuds suivis en avril par Microsoft.
Après les jetons : lire, sélectionner et prolonger l’accès
Selon Microsoft, l’accès obtenu peut servir à lire et extraire des courriels, mais aussi à envoyer de nouveaux messages aux collègues et contacts externes de la victime. La confiance attachée au compte compromis devient alors un moyen de poursuivre le phishing. L’analyse rapporte également des règles de boîte malveillantes utilisées pour faciliter l’exploitation de la messagerie et dissimuler des communications. Ces règles ne prolongent pas, par elles-mêmes, la validité d’un jeton OAuth.
Dans un incident rapporté, les attaquants ont sélectionné des profils financiers, de direction ou d’administration parmi les comptes compromis. Microsoft décrit une analyse assistée par IA de l’activité des boîtes et une reconnaissance par Microsoft Graph pour cartographier la structure interne et les permissions. Les recherches dans les courriels visaient notamment des instructions de virement, des factures en attente et des échanges de dirigeants. Ces observations ne démontrent pas que chaque compte autorisé subit toutes ces actions.
La temporalité varie également. Microsoft rapporte certains enregistrements de nouveaux appareils dans les dix minutes suivant la compromission, afin de produire un Primary Refresh Token, ou PRT, pour une persistance durable. Dans d’autres cas, les acteurs attendent plusieurs heures avant de créer des règles ou d’extraire des messages. L’enquête doit donc couvrir la suite de l’autorisation, sans supposer que l’absence d’action immédiatement visible clôt le scénario.
Après une suspicion : reconstruire la chronologie dans les journaux
Le premier objectif est de relier une demande par code appareil à l’activité ultérieure du compte. Dans les connexions Entra, les éléments à examiner comprennent le compte, l’heure, le résultat, le protocole Device code flow, l’application, la ressource, l’adresse IP, les informations d’appareil et les politiques d’accès conditionnel. La propriété Original transfer method peut indiquer qu’une connexion ou un renouvellement provient d’une session initialement créée par code appareil. Elle aide à comprendre cette origine, sans être à elle seule un identifiant unique de corrélation ni une preuve d’activité malveillante.
Une connexion réussie, même avec MFA, ne suffit pas à exclure l’attaque. Inversement, un flux par code appareil, une adresse IP ou une localisation inhabituelle ne prouvent pas isolément un vol de jeton. L’interprétation repose sur la concordance entre l’autorisation, l’application concernée, les usages attendus et les actions suivantes. Un clic documente une interaction ; il ne démontre pas à lui seul que l’utilisateur a terminé l’autorisation.
Les journaux d’audit et l’état des appareils permettent ensuite d’examiner un éventuel enregistrement nouveau. Côté Exchange, les opérations New-InboxRule, Set-InboxRule et MailItemsAccessed fournissent des pistes sur les règles et les accès aux messages. Les transferts et l’état des règles doivent également être examinés. Un appareil ou une règle nouvellement créé demande une vérification de son caractère autorisé ; un événement d’accès aux messages ne décrit pas, à lui seul, toute une exfiltration.
La reconnaissance Graph exige une précaution supplémentaire : vérifier que les journaux d’activité correspondants étaient collectés avant l’incident. Ils nécessitent Entra ID P1 ou P2 et une intégration vers un stockage ou un outil d’analyse ; Entra ne les conserve pas nativement par défaut. Une recherche vide peut donc refléter un manque de données. Activer cette collecte après l’attaque ne restitue pas les appels passés.
La fenêtre disponible doit être vérifiée avant de tirer des conclusions. Les journaux de connexion et d’audit Entra sont conservés par défaut sept jours avec Entra ID Free, et trente jours avec P1 ou P2. La chasse avancée Defender XDR porte sur au plus trente jours de données natives. Ces durées concernent des ensembles distincts ; elles ne garantissent pas que tous les événements utiles existent dans l’environnement Microsoft 365 de l’organisation.
Ce que les recherches Defender apportent, et ce qu’elles ne prouvent pas
La première requête publiée par Microsoft part d’alertes Defender for Office 365, relie l’URL au message et au destinataire, puis recherche un événement BrowserLaunchedToOpenUrl sur le poste associé. Ses jointures utilisent notamment les tables AlertInfo, AlertEvidence, EmailEvents, IdentityInfo et DeviceEvents. Elle aide à rapprocher un message signalé et un clic observé ; elle n’établit pas directement l’émission d’un jeton ni son utilisation par l’attaquant.
La seconde requête filtre EmailEvents pour repérer des messages dont ThreatTypes est renseigné et qui ont été remis dans la boîte de réception ou les courriers indésirables. Elle identifie donc une livraison associée à une menace détectée, pas nécessairement une ouverture ou une autorisation. Microsoft explique qu’une recherche utile peut devenir une règle de détection personnalisée. Les requêtes du billet restent des points d’entrée à compléter par l’examen des connexions et des actions après compromission.
La présence de données dépend des produits et de leur intégration. CloudAppEvents, par exemple, repose sur Defender for Cloud Apps et la connexion des activités Microsoft 365. Microsoft associe aussi Safe Links et Entra ID Protection à des alertes de forte confiance sur le phishing par code appareil. Leur présence effective et l’ensemble de leurs conditions de licence n’ont pas été vérifiés dans un environnement donné : disposer de Microsoft 365 ne garantit donc pas l’accès à toutes ces données et alertes.
Les rapports Threat Analytics cités par Microsoft nécessitent une licence pour au moins un produit Defender XDR. Le billet liste des profils sur la technique, l’outil et l’acteur, mais affiche Storm-2922 dans cette liste alors que le corps de l’analyse attribue EvilTokens à Storm-2992. Cette discordance demeure dans la source. Le profil lié n’ayant pas pu être vérifié publiquement dans les éléments fournis, l’hypothèse d’une coquille ne permet pas de trancher.
Les conseils Microsoft : contenir l’accès, puis réduire les occasions de phishing
En cas de compromission présumée, Microsoft recommande une désactivation temporaire du compte, la révocation des sessions et des jetons de renouvellement, puis l’examen des appareils, des méthodes MFA, des consentements d’applications, des transferts et des règles de boîte. Le billet mentionne la révocation des sessions de connexion et la possibilité de forcer une nouvelle authentification par accès conditionnel. Ces actions doivent être adaptées au compte et à l’incident, en tenant compte de leur impact sur l’activité.
La révocation ne doit pas être interprétée comme une coupure instantanée de tout accès. Dans les campagnes étudiées, Microsoft rapporte que des jetons d’accès déjà émis peuvent rester utilisables jusqu’à une heure après une révocation ordinaire des sessions. Cette fenêtre rapportée n’est pas un maximum universel : la durée résiduelle effective dépend du jeton, de la ressource et des mécanismes de révocation applicables. Microsoft recommande donc de désactiver temporairement le compte compromis. Si un appareil et son PRT sont impliqués, l’entreprise recommande aussi de désactiver l’appareil et de révoquer les jetons de renouvellement existants afin de traiter cette voie de persistance.
Pour réduire la surface exposée, Microsoft recommande de bloquer le flux par code appareil partout où il n’est pas nécessaire. La documentation conseille d’en inventorier les usages avec une politique en mode rapport seul avant le blocage. Certains équipements Teams peuvent nécessiter des exceptions ciblées sur leurs comptes de ressources. Microsoft indique également d’exclure la ressource Device Registration Service pour préserver les usages d’enregistrement concernés ; cette exception ne s’applique pas indistinctement à toutes les politiques. L’accès conditionnel nécessite une licence Entra ID P1, P2 ou un essai adapté.
La sensibilisation doit expliquer ce que l’écran Microsoft autorise réellement. Le nom de l’application attendue et l’origine du code comptent autant que l’apparence de la page. Microsoft recommande de se méfier des liens suspects dans les messages externes et de ne pas se connecter à des ressources proposées par des expéditeurs inconnus. L’exemple Adobe illustre précisément pourquoi une vérification d’identité présentée comme banale peut cacher une demande d’accès différente.
Sur la messagerie, Microsoft conseille les politiques antiphishing, Safe Links, un Advanced Phishing Threshold réglé à 2 ou 3 et Zero-hour auto purge, ou ZAP, pour traiter rétroactivement des messages à partir de nouvelles informations de menace. Le fournisseur recommande également des alertes sur les créations suspectes de règles de boîte, SmartScreen dans les navigateurs compatibles, ainsi que les protections réseau et Web. Ces couches visent à réduire les occasions d’attaque ; elles ne remplacent pas la vérification de l’autorisation et de ses suites.
Microsoft recommande enfin la MFA, des méthodes résistantes au phishing comme les clés FIDO ou les passkeys de Microsoft Authenticator, le blocage de l’authentification héritée et des politiques fondées sur le risque de connexion. Les politiques intégrant le risque Entra ID Protection exigent P2, contrairement au simple blocage du flux par code appareil disponible avec P1. Elles répondent à des conditions différentes et ne doivent pas être confondues. La MFA reste utile contre de nombreuses attaques, mais les éléments fournis ne démontrent pas qu’un changement de méthode MFA, isolément, empêcherait toute autorisation piégée par code appareil.
Les recommandations plus générales portent sur le moindre privilège, l’audit des comptes privilégiés et la centralisation des données d’identité. En environnement hybride, Microsoft préconise de conserver une frontière pour les comptes administratifs et fortement privilégiés plutôt que de tous les synchroniser. Pour appliquer ces conseils, l’organisation doit vérifier les produits, licences, collectes et exceptions réellement présents. Dans l’enquête comme dans la prévention, cette vérification détermine ce qu’elle peut observer et ce qu’elle peut effectivement bloquer.
Sources
- Microsoft Security Blog, Unmasking EvilTokens
- Huntress, Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure
- Cloudflare Cloudforce One, Operation to disrupt EvilTokens
- Microsoft Learn, OAuth 2.0 device authorization grant
- Microsoft Learn, Conditional Access: Authentication flows
- Microsoft Learn, Microsoft Entra data retention
- Microsoft Learn, Respond to a compromised email account in Microsoft 365
- Microsoft Learn, Advanced hunting overview in Microsoft Defender XDR
- Microsoft Learn, CloudAppEvents table
- Microsoft Learn, Exchange audit record properties
- Microsoft Learn, Access Microsoft Graph activity logs
- Microsoft Learn, Plan Your Microsoft Entra Conditional Access Deployment
- Microsoft Learn, Access tokens in the Microsoft identity platform