Les campagnes de Phishing ciblant les codes d'appareil OAuth se multiplient grâce à la boîte à outils EvilTokens

4 mai 2026

Par Rikesh Vekaria, Archa Archa, Hiwot Mendahun, Samantha Clarke et l'équipe de recherche sur les menaces de Mimecast

Présentation de la campagne

L'équipe Mimecast Threat Research a constaté une forte recrudescence des campagnes de Phishing visant à obtenir le code d'authentification OAuth des appareils des utilisateurs de Microsoft 365, toutes régions et tous secteurs d'activité confondus. Depuis mars 2026, plus de 50 000 campagnes d'e-mails malveillants ont exploité le processus d'autorisation OAuth 2.0 légitime de Microsoft, un mécanisme initialement conçu pour les appareils dépourvus de clavier, tels que les téléviseurs connectés et les appareils IoT, afin de voler des jetons d'authentification et de compromettre des comptes hébergés dans le cloud.

Cette technique est rapidement devenue l'une des méthodes d'attaque préférées des cybercriminels, à l'instar des attaques ClickFix qui avaient dominé le paysage des menaces l'année dernière. La facilité d'exécution de cette attaque a été renforcée par l'apparition d'EvilTokens, une boîte à outils de type « Phishing-as-a-Service » (PhaaS) commercialisée sur Telegram qui automatise l'ensemble de la chaîne d'attaque. EvilTokens intègre du contenu d'ingénierie sociale généré par l'IA, ce qui permet même aux attaquants peu expérimentés de mener à grande échelle des campagnes convaincantes d'usurpation d'identité de marques.

Comprendre le Device Code Phishing

Les attaques de Phishing traditionnelles visent à voler des identifiants en présentant de fausses pages de connexion qui imitent des services légitimes. Le « phishing par code d'appareil » marque une évolution fondamentale : plutôt que de se faire passer pour l'interface de connexion de Microsoft, les attaquants exploitent l'infrastructure d'authentification de Microsoft elle-même pour obtenir des jetons d'accès réels et valides. Dans le cadre d'une utilisation conforme, le processus d'autorisation des appareils via OAuth 2.0 se déroule comme suit :

1. Un appareil (tel qu'une télévision connectée) génère un code d'appareil et l'affiche à l'utilisateur
2. L'utilisateur accède à la page microsoft.com/devicelogin sur un appareil distinct
3. L'utilisateur saisit le code de l'appareil et s'authentifie à l'aide de ses identifiants
4. Microsoft délivre un jeton d'accès à l'appareil d'origine, lui accordant ainsi un accès autorisé

Dans le cadre des attaques de phishing par code embarqué, les cybercriminels exploitent ce processus en :

1. Enregistrement d'une application OAuth malveillante auprès de Microsoft Azure AD
2. Lancer un processus d'autorisation d'appareil sur leur infrastructure backend
3. Obtention d'un code d'appareil valide auprès des serveurs d'autorisation de Microsoft
4. La diffusion de ce code auprès des victimes par le biais d'e-mails de Phishing et de fausses pages de marques
5. Convaincre les victimes de se rendre sur la véritable page de connexion de Microsoft et d'y saisir le code
6. Capturer les jetons OAuth générés lorsque la victime termine l'authentification

Étant donné que les victimes s'authentifient sur l'infrastructure officielle de Microsoft et que les jetons émis sont légitimes, cette technique contourne l'authentification multifactorielle, passe tous les contrôles de réputation de domaine et échappe aux mécanismes traditionnels de détection du phishing. Cette attaque ne repose pas sur la capture d'identifiants : elle exploite la confiance que les utilisateurs accordent aux processus métier qu'ils connaissent bien pour autoriser des applications malveillantes.

L'écosystème EvilTokens

Selon une étude menée par Sekoia, EvilTokens constitue une innovation majeure dans le domaine des acteurs malveillants : il s'agit d'une plateforme de « phishing-as-a-service » entièrement automatisée qui banalise l'exploitation sophistiquée du protocole OAuth. Cette boîte à outils offre aux cybercriminels :

• Ingénierie sociale basée sur l'IA : génération automatisée d'e-mails de Phishing et de pages de destination convaincants, imitant des marques et des processus métier de confiance
• Infrastructure clé en main : systèmes backend préconfigurés qui gèrent la génération de code pour les appareils, le suivi des sessions des victimes et la collecte de jetons
• Surveillance en temps réel : interfaces de tableau de bord affichant les campagnes en cours, les interactions avec les victimes et les captures de jetons réussies
• Évolutivité : capacité à lancer des milliers de campagnes de Phishing simultanées avec un minimum de compétences techniques. Cette démocratisation des techniques d'attaque sophistiquées explique la croissance fulgurante observée depuis mars 2026. Alors qu’auparavant, le phishing par code d’appareil nécessitait des connaissances techniques pointues, EvilTokens permet désormais à tout acteur malveillant disposant de connaissances de base en matière de sécurité opérationnelle de mener des campagnes de compromission de comptes à l’échelle de l’entreprise.

Variantes de campagne

Campagne d'enregistrement des appareils Mimecast

Cette campagne, détectée pour la première fois le 16 avril, met en évidence une évolution préoccupante : des acteurs malveillants ont commencé à usurper le processus d'enregistrement des appareils de Mimecast, en exploitant le processus de sécurité légitime que les clients utilisent pour accéder à des contenus protégés.

Fausse procédure d'enregistrement d'un appareil Mimecast : les destinataires reçoivent des e-mails prétendant contenir des documents protégés ou des liens nécessitant l'enregistrement d'un appareil Mimecast. Lorsque les victimes cliquent sur le lien, elles accèdent à une page visuellement identique à l'interface d'enregistrement des appareils de Mimecast.

1. Page d'accueil : affiche le logo Mimecast ainsi que les instructions suivantes : « "» pour obtenir un code d'authentification"
2. Affichage du code : une fois que vous avez cliqué sur le bouton, la page s'actualise et affiche le code de l'appareil directement sur la page Web
3. Accès aux documents : une fenêtre « "» s'affiche avec le bouton « Document" ». Lorsque vous cliquez dessus, vous êtes redirigé vers microsoft.com/devicelogin
4. Invite d'authentification : La véritable page Microsoft demande le code et invite les utilisateurs à saisir sur "le code affiché dans leur application ou sur leur appareil afin d'accorder tous les droits d'accès à leur compte."
5. Vol de jetons : lors de l'authentification, le serveur de l'attaquant intercepte les jetons OAuth tandis que les victimes pensent avoir effectué une inscription légitime de leur appareil

Processus d'enregistrement légitime d'un appareil Mimecast :

Il est essentiel de bien comprendre le processus authentique pour sensibiliser les utilisateurs et détecter les menaces :

1. L'utilisateur clique sur un lien réécrit par Mimecast figurant dans un e-mail qui nécessite l'enregistrement d'un appareil et est redirigé vers la page d'enregistrement des appareils de Mimecast        
2. La page Web vous demande votre adresse e-mail, qui sera vérifiée par rapport à la base de données clients de Mimecast afin de confirmer que vous êtes bien un utilisateur légitime de Mimecast.
3. Après avoir cliqué sur « "Get Device Enrolment Code » (Obtenir le code d'inscription de l'appareil),", la page Web s'actualise pour afficher un champ de saisie destiné au code d'inscription et informe l'utilisateur que le code a été envoyé à son adresse e-mail. REMARQUE : le code n'apparaît PAS sur la page Web
 
4. L'utilisateur récupère le code dans son e-mail et le saisit dans le champ de saisie de la page Web
5. Une fois la validation effectuée, l'utilisateur est redirigé vers le contenu initialement demandé.

La différence essentielle réside dans le fait que, lors d'un enregistrement légitime d'un appareil Mimecast, les codes d'enregistrement n'apparaissent jamais directement sur les pages Web. Les codes sont toujours envoyés par e-mail, qui sert de canal de vérification secondaire.

Cette imitation est particulièrement efficace car :

• Les utilisateurs s'attendent à ce que des procédures de sécurité soient mises en place lorsqu'ils accèdent à des contenus protégés
• L'enregistrement des appareils apparaît comme une exigence de sécurité légitime
• La qualité visuelle de ces pages falsifiées correspond étroitement à l'identité visuelle authentique de Mimecast

Campagne de révision de documents DocuSign

La variante la plus répandue de cette campagne consiste à usurper l'identité de la marque DocuSign, en tirant parti de l'utilisation généralisée, dans le monde des affaires, des processus de signature électronique. Les destinataires reçoivent des e-mails prétendant nécessiter la consultation ou la signature d'un document, avec des objets tels que :

• "DocuSign - Vérifier un document"
• "Agreement_Review.pdf - Signature requise"
• "Urgent : contrat en attente de votre signature"

L'efficacité de cette campagne repose sur l'exploitation d'un véritable processus métier : de nombreuses organisations intègrent en effet DocuSign à Microsoft 365 pour la vérification d'identité, ce qui donne à la demande de vérification un caractère routinier plutôt que suspect.

Campagne de notification des messages vocaux dans Microsoft Teams

Une autre variante de cette campagne tire parti de l'omniprésence des notifications de messagerie vocale Microsoft dans les environnements d'entreprise. Les entreprises s'appuyant de plus en plus sur des plateformes de communications unified, les alertes de messagerie vocale sont désormais devenues des messages courants et attendus que les employés examinent rarement de près. Les destinataires reçoivent des e-mails conçus pour ressembler à de véritables notifications de messagerie vocale de Microsoft, avec des objets tels que :

• "Vous avez un nouveau message vocal de la part de [Nom]"
• "Appel manqué - Nouveau message vocal"
• "Microsoft Teams : nouveau message vocal"
• "Notification de message vocal - Action requise"

Analyse technique : obscurcissement et contournement

Schéma de chiffrement multicouche

Les campagnes récentes mettent en œuvre des mesures anti-analyse afin d'empêcher les chercheurs en sécurité et les systèmes automatisés d'examiner les infrastructures de Phishing. Le principal mécanisme d'obfuscation repose sur un chiffrement AES-GCM avec déchiffrement côté client.

Étape 1 : Charge utile initiale Lorsque les victimes accèdent pour la première fois à une URL de Phishing, elles reçoivent un document HTML contenant du code JavaScript

Une petite fonction de chargement JavaScript décode les chaînes Base64 en tableaux d'octets, importe la clé AES-GCM à l'aide de l'API Web Crypto, puis déchiffre le texte chiffré à l'aide de l'IV fourni.

Étape 2 : Remplacement dynamique du contenu Une fois le déchiffrement réussi, le script remplace l'intégralité du document HTML par le contenu déchiffré :

Cette approche garantit que la page de phishing proprement dite — qui contient les logos de la marque, des textes d'ingénierie sociale et des éléments de formulaire malveillants — reste invisible pour :

• Des outils de sécurité pour les e-mails qui analysent les destinations des liens
• Services d'évaluation de la réputation des URL qui explorent et analysent les pages
• Les chercheurs en sécurité chargés du triage initial
• Collecte automatisée d'informations sur les menaces

Ce n'est que lorsque le code JavaScript s'exécute dans un contexte de navigateur complet que le véritable contenu de Phishing devient visible. Les outils d'analyse statique qui examinent le code source HTML ne voient que la charge utile chiffrée et le script de chargement.

Étape 3 : Coordination avec le backend La page de phishing déchiffrée communique avec l'infrastructure backend contrôlée par le pirate afin de coordonner le flux de code sur l'appareil :

Lancement de la session :

Cette requête déclenche le lancement, par le backend, d'un flux d'autorisation OAuth légitime avec Microsoft pour l'appareil. La réponse contient :

• userCode : le code réel de l'appareil obtenu auprès des serveurs d'autorisation de Microsoft
• sessionId : un identifiant unique permettant de suivre la session de cette victime

Interrogation d'état :

La page de Phishing interroge en permanence le serveur pour déterminer à quel moment la victime a terminé son authentification sur la plateforme de Microsoft. Lorsque le backend a réussi à échanger le code de l'appareil contre des jetons OAuth, il renvoie le statut : « "completed" », ce qui déclenche l'affichage d'un message de réussite sur la page de phishing, puis la redirection vers le site web officiel de la marque.

Infrastructure et hébergement

Les pages de Phishing sont souvent hébergées sur :

• Compartiments AWS S3 : une solution de stockage dans le cloud fiable, offrant une haute disponibilité et une infrastructure sécurisée
• Serveurs web compromis : des domaines existants jouissant d'une réputation établie pour contourner les listes de blocage
• Domaines nouvellement enregistrés : domaines à faible réputation comportant des variantes de typosquatting de marques légitimes

Les points de terminaison de l'API backend qui gèrent la génération des codes des appareils et la capture des jetons fonctionnent sur une infrastructure distincte, en recourant souvent à :

• Serveurs privés virtuels (VPS) proposés par des fournisseurs exigeant une vérification d'identité minimale
• Des adresses IP dotées de certificats TLS valides émis par Let's Encrypt, qui leur confèrent une fausse légitimité

Cette séparation entre les pages de Phishing visibles et l'infrastructure de capture des jetons complique les efforts de démantèlement et l'identification des responsables.

Indicateurs de compromission (IOC)

Campagne DocuSign

Phishing Domains:

• 00a7af15-a112-4457-86c2-5c56751f0f47-endpoint[.]com
• index-yfb.kpenza-htrenchless-com-s-account.workers[.]dev

Exemples d'objets d'e-mail :

• "DocuSign - Vérifier un document"
• "Agreement_Review.pdf - Signature requise"
• "Urgent : contrat en attente de votre signature"
• "Document en attente de votre signature électronique"

Campagne sur la messagerie vocale de Microsoft

Phishing Domains:

• voice-mail-auth-office-com.saxeco7653.workers[.]dev
• auth-login-office-com.saxeco7653.workers[.]dev
• delicate-poetry-debc.dporozok.workers[.]dev

Exemples d'objets d'e-mail :

• "Notification de message vocal - Action requise"
• "Appel manqué - Nouveau message vocal"
• "Vous avez un nouveau message vocal de la part de [Nom]"

Campagne d'enregistrement des appareils Mimecast

Phishing Domains:

• sso-nodeconnect[.]icu/

Exemples d'objets d'e-mail :

• "Consulter le document"
• "Agreement_Review.pdf - Signature requise"

Objectifs

Portée géographique : mondiale — toutes les régions

Secteur d'activité : tous les secteurs ; particulièrement efficace contre les organisations utilisant DocuSign, Microsoft ou Mimecast

Recommandations

Formation à la sensibilisation à la sécurité destinée aux utilisateurs

• Sensibilisez vos collaborateurs aux caractéristiques spécifiques de ces campagnes
• Les utilisateurs ne doivent en aucun cas saisir les codes d'authentification provenant d'e-mails non sollicités, même si la page de connexion Microsoft semble authentique. Les procédures d'enregistrement des appareils proposées par Mimecast et d'autres services suivent des schémas bien précis : les codes sont envoyés par e-mail, ne s'affichent pas sur des pages Web et ne nécessitent jamais d'authentification sur la page de connexion aux appareils de Microsoft.
• Vérifiez les autorisations des applications OAuth. Les organisations devraient procéder à un audit des autorisations accordées aux applications tierces existantes sur l'ensemble de leurs locataires Microsoft 365, afin d'identifier et de révoquer les applications dont le nom est suspect, dont la date d'autorisation est récente ou dont l'éditeur est inconnu.

Recherche proactive des menaces

• Recherchez dans les journaux de réception des e-mails à l'aide des indicateurs de compromission (IOC) répertoriés

Le « phishing par code d'appareil » constitue un défi majeur pour l'authentification dans le cloud : cette attaque exploite une fonctionnalité légitime intégrée à la conception du protocole OAuth 2.0, et non une vulnérabilité pouvant faire l'objet d'un correctif. Alors que les kits d'outils de « phishing-as-a-service » tels qu'EvilTokens continuent de démocratiser des techniques sophistiquées, les organisations doivent faire évoluer leurs défenses au-delà des contrôles périmétriques traditionnels. Microsoft a mis en place des politiques d'authentification basées sur les risques ainsi que des fonctionnalités de gouvernance des applications, mais une protection optimale nécessite une défense en profondeur : des contrôles techniques limitant l'autorisation OAuth, une sensibilisation des utilisateurs leur permettant de repérer les utilisations abusives des codes d'appareil, et des opérations de sécurité capables de détecter rapidement les indicateurs de compromission. La recrudescence des attaques de Phishing par code sur appareil met en évidence le fait que les modèles d'authentification conçus pour faciliter la vie des utilisateurs ouvrent également la voie à des techniques d'ingénierie sociale à une échelle sans précédent.