Calipia : le blog

Le phishing n’est plus ce qu’il était. Et ce n’est pas un compliment.

Pendant des années, on a cru qu’un mot de passe robuste plus un second facteur d’authentification constituaient un bouclier quasi infranchissable. Cette conviction est en train de s’effriter, et une campagne documentée début avril 2026 par l’équipe Microsoft Defender Security Research en apporte une démonstration particulièrement préoccupante. L’attaque combine l’intelligence artificielle générative, une automatisation bout en bout et l’exploitation d’un flux OAuth légitime pour compromettre des comptes Microsoft 365 à grande échelle, sans jamais toucher au mot de passe de la victime. Bienvenue dans l’ère du phishing augmenté.

Le flux Device Code : un mécanisme légitime détourné avec élégance

Pour comprendre l’attaque, il faut d’abord comprendre le flux d’authentification par code appareil (Device Code Authentication), un mécanisme OAuth 2.0 conçu pour les appareils sans interface de saisie classique : smart TV, imprimantes, terminaux industriels. Le principe est simple : l’appareil génère un code court, l’utilisateur le saisit sur un autre terminal (son navigateur), et l’authentification se réalise sur ce second terminal. Ce qui est pratique pour une télévision connectée devient une surface d’attaque lorsque c’est un acteur malveillant qui initie le flux et présente le code à la victime via un email de phishing.

La technique n’est pas nouvelle en elle-même : Microsoft avait déjà documenté le groupe Storm-2372 en février 2025. Ce qui est nouveau ici, c’est le niveau d’industrialisation et l’usage de l’IA pour rendre l’attaque à la fois plus scalable et plus convaincante.

Nous aborderons ces nouvelles menaces et les moyens d’y faire face lors d’une session dédiée du prochain Briefing Calipia de juin : tous les détails ici

Une infrastructure technique soigneusement construite (et ce n’est pas une bonne nouvelle)

La campagne identifiée par Microsoft repose sur un outillage sophistiqué, articulé autour d’EvilToken, une plateforme de Phishing-as-a-Service (PhaaS) disponible sous forme d’abonnement. Ce kit gère l’intégralité de la chaîne d’attaque, du ciblage initial jusqu’à l’exfiltration de données.

L’infrastructure d’authentification malveillante s’appuie sur des plateformes cloud réputées comme Railway.com, Cloudflare Workers et AWS Lambda pour héberger la logique de redirection. L’avantage est évident : le trafic phishing se fond dans le trafic cloud légitime de l’entreprise, rendant les blocages sur réputation de domaine quasi inefficaces. En parallèle, plusieurs domaines légitimes compromis sont utilisés pour héberger les pages de phishing, bénéficiant d’une réputation existante pour passer les filtres des passerelles email.

Le point le plus redoutable concerne la génération dynamique des codes appareil. Dans les attaques précédentes, le code était pré-généré et inclus dans l’email, ce qui laissait à peine 15 minutes à la victime pour compléter l’authentification avant expiration. Ici, le code n’est généré qu’au moment où la victime clique sur le lien malveillant. Le compte à rebours de 15 minutes démarre donc au bon moment, et pour maximiser les chances de succès, le script de la page copie automatiquement le code dans le presse-papiers de l’utilisateur via l’API navigator.clipboard.writeText. Chaque friction est éliminée.

L’IA générative comme moteur de personnalisation (séquence émotion…)

La dimension IA de la campagne intervient principalement dans la phase de construction des leurres. Les emails de phishing ne sont plus des messages génériques truffés de fautes d’orthographe. Ils sont générés par IA et calibrés au profil de la cible : un responsable des achats reçoit un email concernant un appel d’offres en cours, un comptable voit arriver une facture urgente, un opérateur de production est alerté sur un workflow bloqué. La pertinence contextuelle augmente mécaniquement le taux d’interaction.

La phase de reconnaissance préalable est elle-même automatisée. Dix à quinze jours avant l’envoi des emails, les attaquants interrogent le point de terminaison GetCredentialType de Microsoft pour valider l’existence et l’activité des comptes ciblés dans un tenant. Seuls les comptes confirmés actifs sont ensuite ciblés, optimisant le ratio signal/bruit de l’attaque.

Ce qui se passe après la compromission

Une fois le token d’accès obtenu, l’attaquant dispose d’une session authentifiée valide, sans que le mot de passe n’ait jamais été exposé. Le MFA a bien fonctionné, techniquement : l’utilisateur a approuvé la connexion. C’est précisément là que réside la perversité du Device Code Phishing.

Les étapes post-compromission suivent un schéma méthodique. L’acteur malveillant commence par une phase de triage : parmi tous les comptes compromis, il identifie via Microsoft Graph les profils à haute valeur, notamment les personnes ayant des responsabilités financières ou exécutives. Pour ces cibles prioritaires, une exploration approfondie des emails est réalisée, avec recherche active d’ordres de virement, de factures en attente et de correspondances avec des dirigeants. Des règles de messagerie malveillantes sont créées pour rediriger ou dissimuler des communications, assurant la persistance de l’accès même si un mot de passe est réinitialisé, puisque les tokens restent valides tant qu’ils ne sont pas révoqués. Dans certains cas, des appareils sont enregistrés pour générer un Primary Refresh Token et garantir une persistance long terme.

Ce que cela implique pour les DSI et RSSI

La leçon première de cette campagne est que le MFA, bien qu’indispensable, ne constitue plus une ligne de défense suffisante dès lors que l’attaquant exploite un flux d’authentification légitime auquel l’utilisateur consent sans en comprendre les implications. La vigilance humaine seule ne peut pas compenser cette faille de perception.

Microsoft formule plusieurs recommandations concrètes. La plus directe consiste à bloquer le flux Device Code via des politiques d’accès conditionnel dans Entra ID, sauf pour les cas d’usage métier qui le nécessitent réellement, ce qui reste rare dans un environnement de travail standard. Il est également recommandé de migrer vers des méthodes MFA résistantes au phishing, notamment les clés FIDO2 ou les passkeys via Microsoft Authenticator, nous vous en parlons au Briefing Calipia depuis plusieurs années, en abandonnant les méthodes basées sur SMS ou les notifications push simples, trop facilement contournées. La configuration de Safe Links dans Defender for Office 365 permet de détecter avec un haut niveau de confiance les tentatives de phishing par code appareil. Enfin, la mise en place de politiques de risque de connexion dans Entra ID Protection, couplée à la révocation automatique des tokens en cas de comportement suspect, réduit significativement la fenêtre d’exploitation post-compromission.

Pour les équipes utilisant Microsoft Sentinel, plusieurs requêtes de chasse aux menaces ont été publiées par Microsoft pour détecter les activités suspectes liées à ce type d’attaque : corrélation entre clics sur des liens dans des emails de sources rares et authentifications par code appareil, création de règles de messagerie anormales, accès aux éléments de boîte mail via Graph API.

Et sans surprise… la menace va continuer de s’industrialiser

Ce que cette campagne illustre au-delà du cas technique, c’est la maturation rapide d’une économie criminelle structurée. Les outils comme EvilToken abaissent le niveau de compétence requis pour mener des attaques sophistiquées, tout en élevant le plafond d’impact possible. Le phishing en 2026 n’est plus un jeu de volume mais une discipline d’ingénierie, où l’objectif n’est plus de tromper l’utilisateur en cliquant sur un mauvais lien, mais de déjouer les défenses automatisées conçues pour bloquer ce lien avant même qu’il n’arrive en boîte de réception.

Les DSI et RSSI doivent intégrer cette réalité dans leur modèle de menace : une identité peut être compromise sans qu’aucun mot de passe n’ait jamais circulé, sans que le MFA n’ait échoué au sens strict, et sans que l’utilisateur n’ait commis d’erreur manifeste. C’est l’architecture du flux d’authentification lui-même qui est exploitée, et c’est à ce niveau que la réponse doit se construire.