Une demande de connexion peut sembler parfaitement normale tout en donnant accès à la session d’un attaquant. Microsoft décrit une campagne où des utilisateurs saisissent un code appareil fourni par un courriel piégé, puis valident sans le savoir la connexion de l’adversaire. Le problème ne vient pas d’un mot de passe transmis au fraudeur : il vient de l’autorisation accordée au mauvais appareil.
Cette technique, appelée hameçonnage par code appareil, s’appuie sur un flux d’authentification OAuth conçu pour les téléviseurs, imprimantes, appareils Teams ou systèmes de visioconférence qui ne disposent pas d’un navigateur complet. Microsoft Threat Intelligence affirme qu’EvilTokens, une plateforme de hameçonnage à la demande apparue en février 2026, a contribué à des campagnes ayant compromis plus de 12 000 boîtes aux lettres dans plus de 10 000 organisations. Ces chiffres sont ceux de Microsoft et ne constituent pas une mesure indépendante.
Le code est légitime, mais la demande ne l’est pas
Le flux par code appareil répond à un besoin réel. Un appareil limité affiche un court code et demande à l’utilisateur de le saisir dans un navigateur déjà ouvert sur un autre écran. Le service d’identité reçoit alors la demande et établit la session de l’appareil. Dans un usage normal, ce mécanisme évite de taper un mot de passe sur un équipement peu pratique.
Dans le scénario décrit par Microsoft, l’attaquant démarre lui-même une demande de code. Il l’intègre ensuite dans un leurre qui peut prendre la forme d’une facture, d’un document partagé, d’une demande de signature ou d’une alerte de mot de passe. La victime arrive sur la page officielle de connexion, saisit le code et confirme l’opération. La page peut être authentique : c’est l’intention de la demande qui a été dissimulée.
L’authentification multifacteur n’est donc pas « cassée » au sens où le second facteur serait inutile. Elle est validée par la personne, mais pour une session qu’elle n’a pas identifiée. Cette nuance explique pourquoi un simple réflexe de vérification reste nécessaire lorsque l’écran demande de confirmer une connexion inattendue.
Après la validation, le risque change d’échelle
Le jeton obtenu permet à l’attaquant de conserver un accès sans connaître directement le mot de passe. Microsoft indique que les opérateurs d’EvilTokens pouvaient examiner les boîtes aux lettres compromises, rechercher des cibles intéressantes et créer des règles destinées à masquer des messages. L’accès pouvait aussi servir à enregistrer de nouveaux appareils ou à extraire des courriels.
Cette étape rend le piège plus difficile à repérer. Un compte compromis peut envoyer de nouveaux messages à des collègues ou à des partenaires habituels. Le destinataire reconnaît l’adresse et baisse sa garde, tandis que l’attaquant exploite les informations déjà présentes dans la messagerie pour rendre ses demandes plus crédibles. Pour une salle de formation, un centre ou une petite entreprise, le risque touche donc autant les comptes administratifs que les boîtes utilisées pour échanger des documents et des factures.
Le réglage utile concerne le flux, pas seulement les courriels
Microsoft recommande de bloquer le flux par code appareil lorsqu’il n’est pas indispensable. Une organisation qui utilise réellement ce mécanisme doit limiter l’exception aux appareils et aux comptes concernés, plutôt que de l’autoriser largement pour tout le personnel. La mesure n’est pertinente qu’après avoir vérifié les usages existants : la désactivation générale peut gêner certains équipements qui en dépendent.
- Traiter une demande de code inattendue comme une demande de connexion à vérifier, même si la page affichée est officielle.
- Contrôler le nom de l’application et le compte concernés avant de confirmer.
- Réserver le flux par code appareil aux usages identifiés et surveiller les exceptions.
- En cas de doute, signaler le message et prévenir l’administrateur avant de poursuivre.
Ces gestes ne remplacent pas les protections techniques. Microsoft cite aussi les politiques anti-hameçonnage, l’analyse des liens, la détection des créations inhabituelles de règles de boîte aux lettres et la surveillance des connexions à risque. La réponse dépend des services effectivement utilisés et des licences disponibles ; il n’existe pas, dans le dossier consulté, de garantie qu’un réglage unique bloque toutes les variantes de la campagne.
Une authentification plus sûre commence par le contexte
Le hameçonnage par code appareil exploite une confusion simple : l’utilisateur reconnaît l’écran de connexion, mais pas forcément l’origine de la demande. Dans l’analyse de Microsoft, EvilTokens industrialise cette confusion avec des leurres adaptés et des automatismes capables d’examiner les comptes après la compromission.
Pour les organisations qui n’ont pas besoin de ce mode de connexion, le choix le plus clair est donc de le bloquer. Pour les autres, la priorité consiste à réduire son périmètre, à expliquer le geste attendu et à surveiller les signes qui suivent une validation inhabituelle. La double authentification reste utile ; elle doit simplement être accompagnée d’une question supplémentaire : « quel appareil suis-je réellement en train d’autoriser ? »
