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 surestimer les garanties
Après une validation suspecte, l’ordre des actions compte : isoler le contexte, alerter l’administrateur, révoquer les sessions et jetons, contrôler les règles de messagerie et les appareils ajoutés, puis évaluer les données consultées. Une simple modification du mot de passe peut être insuffisante si une session ou un jeton reste utilisable.
La gestion des secrets complète cette réponse sans la remplacer. Des mots de passe uniques par service empêchent qu’un secret réutilisé transforme un compte compromis en incident généralisé. Le guide Soclyde sur les gestionnaires local-first explique comment conserver un coffre chiffré sous le contrôle de l’organisation et préparer ses sauvegardes.
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 : générer des secrets uniques, limiter les copies centralisées et rendre leur renouvellement praticable. Face à EvilTokens, la défense efficace combine donc contrôle de l’identité, vigilance humaine, journalisation et capacité de révocation.
Le bon réflexe tient en une phrase : une page Microsoft peut être vraie, et la demande qu’elle exécute quand même frauduleuse.
