EvilTokens est un kit de phishing par code d’appareil qui détourne le flux OAuth légitime de Microsoft. Le 13 juillet 2026, le CERT gouvernemental bangladais BGD e-GOV CIRT a décrit le kit comme un service visant les comptes Microsoft 365 : la victime peut se connecter sur le vrai site Microsoft et valider sa MFA, tout en autorisant la session de l’attaquant et en lui remettant des jetons d’accès et de renouvellement. Le mot de passe n’a pas forcément besoin d’être volé.
Pour réduire le risque, bloquez le flux de code d’appareil dans Microsoft Entra s’il n’est pas requis par un usage métier, et refusez tout code que vous n’avez pas demandé vous-même. Après une validation suspecte, révoquez les sessions et jetons depuis le processus de réponse à incident de votre organisation; ne supposez pas que tous les jetons actifs cessent d’être valides immédiatement.
Le piège : la page est vraie, la demande ne l’est pas
Les campagnes de phishing classiques imitent une page de connexion pour récupérer un mot de passe. EvilTokens joue sur une confusion plus subtile : la victime peut arriver sur le véritable site Microsoft, saisir son mot de passe et valider sa MFA normalement. Pourtant, elle autorise alors la session que l’attaquant a préparée.
Le kit, décrit par le BGD e-GOV CIRT en juillet 2026 et analysé par Microsoft, transforme le flux OAuth de code d’appareil en service de phishing. Cette fonction est conçue pour les téléviseurs, outils en ligne de commande ou appareils qui ne disposent pas d’une interface de connexion complète. Elle demande de saisir un court code sur un autre appareil.
Le problème vient du contexte : le code peut avoir été demandé par l’attaquant, puis présenté à la victime dans un faux aperçu de document, une facture ou une demande urgente. Le domaine Microsoft est réel, mais l’autorisation est mal dirigée.
Comment EvilTokens détourne le flux
Le scénario suit généralement plusieurs étapes :
- Un message crédible pousse la personne à ouvrir un document, une facture ou une demande de signature.
- Une page intermédiaire lui demande son adresse et prépare dynamiquement un code d’appareil.
- La page redirige vers la vraie adresse Microsoft et invite à saisir le code.
- La victime accomplit son authentification et sa MFA, pensant ouvrir sa propre session.
- Le serveur de l’attaquant récupère les jetons d’accès associés à la session qu’il a initiée.
Les kits récents génèrent le code au moment du clic, ce qui évite qu’un code statique expire avant son utilisation. Certains détournent aussi le presse-papiers ou chiffrent le contenu de la page jusqu’à son affichage dans le navigateur. Ces détails compliquent la détection, mais ne changent pas le réflexe essentiel : un code d’appareil doit correspondre à une action commencée volontairement par l’utilisateur.
Pourquoi la MFA ne suffit pas ici
La MFA vérifie bien l’identité de la personne. Elle ne vérifie pas toujours qui a commencé la demande ni quel contexte applicatif recevra le jeton. Dans ce scénario, l’attaquant ne casse pas la MFA : il fait valider à la victime une demande qu’il contrôle.
Une page authentique n’est donc pas une preuve suffisante. Il faut aussi reconnaître l’application, l’action attendue et l’origine de la demande. Toute invitation inattendue à entrer un code sur microsoft.com/devicelogin, ou à approuver une connexion, doit être annulée et signalée.
Les mesures utiles pour une TPE-PME
Côté administrateur
- Bloquer le flux de code d’appareil dans Microsoft Entra ID lorsqu’aucun appareil ou outil métier ne l’exige ; documenter les exceptions nécessaires.
- Privilégier des méthodes résistantes au phishing, comme les passkeys ou les clés FIDO2, et désactiver les protocoles d’authentification hérités.
- Activer les protections anti-phishing et les liens sécurisés disponibles dans la suite de sécurité utilisée.
- Surveiller les connexions par code d’appareil, les nouvelles inscriptions d’appareils, les règles de boîte aux lettres ajoutées et les accès Graph inhabituels.
- Tester une procédure de révocation : sessions, jetons, appareils nouvellement inscrits, règles de messagerie et secrets associés.
Côté utilisateur
- Ne jamais entrer un code reçu dans un message ou affiché par une page inattendue.
- Refuser toute MFA que l’on n’a pas déclenchée soi-même, même si la notification semble familière.
- Ouvrir Microsoft 365 depuis un favori connu plutôt que depuis un lien urgent.
- Prévenir l’IT au moindre doute, sans attendre de savoir si la connexion a réussi.
Réagir vite, sans supposer les jetons invalidés immédiatement
Après une validation suspecte, alertez l’administrateur, désactivez temporairement le compte si nécessaire, révoquez les jetons de renouvellement et les sessions, retirez les appareils récemment inscrits et vérifiez les règles de messagerie ainsi que les journaux Microsoft Entra. BGD e-GOV CIRT avertit qu’un jeton d’accès déjà émis peut rester valide jusqu’à une heure après la révocation standard d’un jeton de renouvellement. La réponse doit donc suivre les procédures Microsoft 365 de l’organisation et continuer à surveiller les connexions pendant cette fenêtre; changer seulement le mot de passe ne suffit pas.
La fiche pratique sur les infostealers et le vol de sessions aide à organiser le confinement d’un poste potentiellement infecté. Pour une attaque qui commence sur un Wi-Fi de voyage, voyez aussi notre analyse de CaptiveCrunch et des portails captifs compromis.
Le lien avec Soclyde
La gestion des secrets complète cette réponse sans la remplacer. Des mots de passe uniques par service évitent qu’un secret réutilisé ouvre d’autres comptes. Soclyde conserve un coffre chiffré sur les appareils plutôt que dans un coffre cloud centralisé exploité par Soclyde; cette architecture ne bloque toutefois ni le flux OAuth détourné, ni le vol d’un jeton Microsoft 365. Le guide Soclyde sur les gestionnaires local-first explique ce que ce modèle change et les contrôles qui restent à la charge de l’organisation.
Soclyde ne protège pas le tenant Microsoft 365, ne bloque pas le flux OAuth et ne remplace ni la MFA ni l’EDR. Son rôle est plus précis : conserver les mots de passe des comptes dans un coffre chiffré sur les appareils, plutôt que dans un coffre cloud centralisé exploité par Soclyde. La gestion et la révocation des jetons Microsoft 365 restent du ressort de l’organisation. Face à EvilTokens, la défense efficace combine donc contrôle de l’identité, vigilance humaine, journalisation et capacité de révocation.
À retenir
Une page Microsoft peut être authentique alors que le code saisi autorise une session créée par l’attaquant. Refusez les demandes inattendues, bloquez le flux lorsqu’il n’est pas utile et, après une approbation douteuse, appliquez une réponse complète aux jetons, sessions, appareils et règles de boîte. Échangez avec Soclyde sur la gestion des accès de votre équipe.
