Phishing par code d'appareil : approuver une connexion que l'on n'a jamais lancée
En février 2025, le Microsoft Threat Intelligence Center a documenté une campagne active de l'acteur qu'il suit sous le nom de Storm-2372, qui dérobait des sessions de connexion à des organisations en Europe, en Amérique du Nord, en Afrique et au Moyen-Orient. Ce qui frappe dans la technique, le phishing par code d'appareil, c'est ce qu'elle évite : aucune fausse page de connexion à repérer, aucun mot de passe à voler, aucun logiciel malveillant à détecter. La victime ne tape aucun secret. Un code fourni par l'attaquant est saisi sur la véritable page de connexion de Microsoft, la victime approuve l'invite depuis son propre appareil, et l'attaquant repart avec une session fonctionnelle.
Une fonction légitime, retournée à l'envers
Le flux de code d'appareil (device code flow) est une véritable fonction d'OAuth 2.0, pas une contrefaçon. Il existe pour les matériels dépourvus de clavier ou de navigateur utilisables : imprimantes, téléviseurs, écrans de salles de réunion, boîtiers. L'appareil affiche un code court, l'utilisateur ouvre le portail de connexion sur un téléphone ou un ordinateur portable, saisit le code, se connecte et approuve. L'appareil reçoit alors ses jetons. Storm-2372 a inversé cette séquence. Selon Microsoft, le groupe a mené la campagne à partir d'août 2024, ouvrant des discussions dans Microsoft Teams en se faisant passer pour des cadres ou des responsables, puis déplaçant la conversation vers Signal ou WhatsApp sous prétexte de partager des documents. Les invitations aux réunions envoyées par courriel portaient le même appât, maquillé en trafic Teams ordinaire. La couverture de BleepingComputer de cette même campagne décrivait des victimes invitées à authentifier un appareil pour recevoir un document important : elles suivaient un lien vers la véritable page de connexion de Microsoft, saisissaient le code reçu et approuvaient la connexion, étape d'authentification multifacteur comprise. Les cibles documentées par Microsoft comprenaient des organismes publics, des fournisseurs de services informatiques, la défense, les télécommunications, la santé, l'enseignement supérieur et des entreprises du secteur de l'énergie.Pourquoi cela neutralise complètement la MFA
C'est l'ordre des opérations qui fait fonctionner l'attaque. L'attaquant lance d'abord une demande de code d'appareil légitime et n'implique la victime qu'ensuite. Quand la victime saisit le code et approuve, toutes les vérifications de la page se déroulent honnêtement : la page est réelle, le code est valide, et la personne qui interagit accomplit une connexion authentique, authentification multifacteur incluse. Les jetons que Microsoft délivre, y compris les refresh tokens à longue durée de vie, vont à l'initiateur de la demande, c'est-à-dire à l'attaquant. Du point de vue de l'annuaire, un utilisateur s'est simplement connecté avec succès. Il n'y a rien à signaler pour les filtres anti-courriel ou les proxys web, car l'infrastructure impliquée est entièrement légitime. Le billet de Microsoft consigne ce qui s'est passé ensuite dans les locataires compromis : les attaquants ont fouillé les boîtes aux lettres avec des requêtes Graph API visant des termes comme identifiants, mots de passe et admin, exfiltré de la correspondance et utilisé des comptes internes de confiance pour envoyer du phishing aux collègues, de sorte qu'une seule approbation pouvait se propager en cascade dans l'organisation. Dans une mise à jour publiée un jour après le billet d'origine, Microsoft a aussi documenté un passage à des demandes via le client Microsoft Authentication Broker, permettant d'enregistrer des appareils contrôlés par l'attaquant et de demander des primary refresh tokens. Proofpoint, qui a suivi la technique alors qu'elle se diffusait via des kits de phishing en 2026, note un raffinement supplémentaire : des codes générés à la demande au moment où la victime clique sur un lien, contournant l'expiration de quinze minutes d'un code pré-généré.Le conseil habituel, examiner attentivement la page de connexion avant de taper quoi que ce soit, ne sert à rien ici. L'analyse de Proofpoint sur des campagnes ultérieures souligne que vérifier l'URL échoue parce que le portail est bel et bien celui de Microsoft ; ce qui est détourné, c'est l'approbation de la victime, pas la barre d'adresse.
Des signaux d'alerte qui méritent d'être enseignés
Les signaux sont constants d'une campagne à l'autre, et aucun ne demande de compétence technique pour les remarquer.- une connexion que l'on n'a pas lancée : un code d'appareil n'existe que si quelqu'un l'a demandé
- l'urgence et la pression d'agir avant qu'un code n'expire ou qu'une réunion ne commence
- un courriel, une discussion ou un message demandant d'approuver ou d'authentifier quelque chose avec un code jamais demandé
- un contact qui change de plateforme, comme une conversation Teams qui migre vers Signal ou WhatsApp
- un document ou une invitation à une réunion qui ne se débloque qu'après vérification d'un code