On vous appelle pour mettre à jour votre passkey. Pourquoi ce leurre vole la session, pas la Passkey

On présente les passkeys — les clés d’accès — comme « résistantes à l’hameçonnage ». Le 9 septembre 2026, la recherche sécurité de Microsoft a décrit une campagne qui utilise « mettez à jour votre Passkey / MFA / SSO tout de suite » comme excuse. Ce qu’ils veulent n’est que rarement la clé privée sur votre téléphone. C’est la session après la connexion, ou le code d’appareil que vous saisissez sur une page Microsoft authentique pour leur application. L’activité est observée depuis mai 2026. Les appels et les SMS touchent des numéros personnels.

D’abord la conclusion : quand un appelant qui se dit du service informatique vous presse de « mettre à jour votre passkey tout de suite », le danger n’est pas qu’il ait copié la clé privée. C’est que vous lui avez remis une connexion vivante. Les kits d’intermédiaire (AiTM) volent la session. Dans le flux de code d’appareil, la page peut même être un vrai hôte Microsoft. Changer le mot de passe ne couvre que la couche mot de passe. Cela ne retire pas un authentificateur déjà inscrit. Ce que vous pouvez contrôler sur cet appareil : le chemin de l’appel, le nom d’hôte dans la barre d’adresse, et si Informations de sécurité a gagné un appareil que vous n’avez pas ajouté — pas la phrase « j’utilise déjà une Passkey ».

Répondre à l’intention de recherche en une phrase

Une passkey, telle que WebAuthn la définit, garde la clé privée sur cet appareil ou dans un trousseau synchronisé, et la lie à l’origine de la partie de confiance. Un faux hôte de connexion ne peut pas exporter cette clé. C’est le périmètre où « résistant à l’hameçonnage » est vrai. Le périmètre où ça ne l’est pas : on vous presse de terminer une connexion, et le jeton de session atterrit chez eux ; ou vous saisissez un code qu’ils vous ont donné sur une page Microsoft authentique, et le jeton est émis pour un client qu’ils contrôlent.

Cette note s’adresse à celles et ceux qui ont déjà inscrit une passkey et reçoivent encore un appel ou un SMS « mettez-la à jour », et aux développeurs et à l’exploitation qui doivent expliquer pourquoi une Passkey n’est pas un sauf-conduit contre l’hameçonnage vocal. Elle ne remplace pas le compte rendu d’incident de Microsoft, et ce n’est pas un mode d’emploi pour désactiver les passkeys. Ce qu’il faut emporter : quelle couche le scénario couvre, quelle couche la session et le code d’appareil volent chacun, pourquoi changer le mot de passe ne suffit pas, et ce que vous pouvez contrôler sur cet appareil après avoir raccroché.

Ce que cette divulgation a séparé

Le 9 septembre 2026, la recherche sécurité de Microsoft a publié un briefing en anglais. Ils suivent des intrusions d’identité cloud encore en cours : connexions inhabituelles, puis des méthodes d’authentification ajoutées par l’acteur, un trafic Microsoft Graph élevé, des téléchargements SharePoint et OneDrive, et la collecte de boîtes aux lettres via des API REST. Le texte indique que cette activité est observée depuis mai 2026.

Ça ne commence pas par un e-mail d’hameçonnage soigné. Ça commence par un appel ou un SMS vers un mobile personnel. L’appelant se dit du helpdesk de l’entreprise et fabrique l’urgence : la passkey, l’authentification multifacteur ou l’authentification unique doit être mise à jour tout de suite, sinon le compte va casser. Le lien arrive souvent dans un second SMS, sur le même téléphone personnel. Microsoft est net : même si le scénario parle de Passkeys, inscrire une passkey n’est souvent pas le vrai objectif. L’histoire existe pour faire entrer quelqu’un dans l’un des deux chemins techniques — l’hameçonnage par intermédiaire (AiTM), ou l’autorisation par code d’appareil.

Le chemin AiTM capture les identifiants et les jetons de session. Dans le chemin code d’appareil, on convainc la victime de saisir un court code sur la page d’authentification de Microsoft ; le jeton est émis pour un client que l’acteur contrôle, donc il n’a pas besoin d’un cookie de navigateur. L’un ou l’autre chemin peut laisser les accès suivants sauter la MFA. Si le lien s’ouvre sur un téléphone personnel non intégré à Defender, la télémétrie de terminal peut être presque vide. Dans ces cas, le souvenir de l’appel ou du SMS est souvent la première — et parfois la seule — preuve de comment l’intrusion a commencé.

L’infrastructure est bâtie pour avoir l’air familière. Les hôtes thématiques du briefing incluent passkeyhelpdesk.com, setupmypasskey.com, add-passkey.com et secure-passkey.com, plus des noms d’entreprise glissés dans un sous-domaine, par exemple contoso.add-passkey.com. Le même nom d’entreprise peut aussi siéger sous un hôte à thème SSO comme integratedsso.com. Des domaines peuvent être en ligne quelques heures après l’enregistrement, ce qui laisse une courte fenêtre de blocage. Dans certains cas, l’acteur utilise aussi un compte de collègue déjà compromis pour envoyer le même message « mettez à jour votre passkey » dans Teams, en empilant la confiance interne par-dessus l’appel.

Microsoft rattache l’accès initial à plusieurs grappes, dont Storm-3121 et Storm-3032. Storm-3121 alimente souvent l’extorsion ShinyHunters et Falcon. Storm-3032 est décrit comme une scission de BlackFile qui opère désormais sous la bannière Helix. C’est de l’écologie, pas une preuve que chaque « appel IT » que vous recevez vient de la même équipe. Ce qui appartient à une note de passation, c’est le scénario plus les deux chemins techniques — pas un nom de bande.

Une passkey arrête un faux hôte. Elle n’arrête pas une session que vous remettez

Lire « résistant à l’hameçonnage » comme « on ne peut plus me convaincre » confond la couche identifiant et la couche session. Une passkey est liée à l’origine du site à l’inscription. Une copie de la page de connexion Microsoft sur un autre hôte ne peut toujours pas extraire la clé privée que vous avez stockée pour login.microsoftonline.com. Cet avantage sur la réutilisation de mot de passe est réel. Il n’a pas besoin d’être relativisé.

Une chronologie de l’enquête montre où l’avantage s’arrête. À T+0 minute, un environnement non géré accède à OfficeHome et reçoit l’erreur 50074, qui demande un second facteur. À T+1, la MFA aboutit — le briefing dit intermédiaire plus MFA non résistante à l’hameçonnage — puis 50140 interrompt « rester connecté ». Dans la même minute, l’authentification réussit et une session est établie. Pendant l’heure suivante, cette même session ouvre Mes applications, le profil, la gestion des approbations et Informations de sécurité, puis parcourt SharePoint et Outlook via Graph. Une fois la session là, ils n’ont plus besoin de votre passkey.

Donc « j’utilise déjà une Passkey » ne soutient qu’une affirmation étroite : un faux hôte a peu de chances d’exporter cette clé privée. Elle ne soutient pas : on ne vous pressera pas de retaper un mot de passe ou un code SMS sur une page ressemblante ; un kit d’intermédiaire ne peut pas prendre le jeton que cette connexion vient de créer ; Informations de sécurité ne gagnera pas leur authentificateur. Ces dernières phrases ont besoin d’autres preuves : le nom d’hôte que vous avez ouvert est-il un hôte de connexion officiel, et Informations de sécurité montre-t-elle un appareil que vous n’avez pas ajouté.

N’utilisez pas un vrai compte professionnel pour « tester » le lien ou le code d’appareil de l’appel. Une phrase jetable suffit : raccrochez, puis rappelez par le canal informatique que votre entreprise a publié par écrit. Vous contrôlez le chemin de l’appel et la barre d’adresse — vous ne leur remettez pas une autre connexion vivante.

Pourquoi le code d’appareil peut réussir sur un vrai domaine

L’intermédiaire doit encore monter une page qui ressemble à la connexion. Le code d’appareil retire cette couche. Le flux officiel est : un client affiche un court code ; vous ouvrez la page de connexion d’appareil de Microsoft dans un navigateur ; vous saisissez le code ; cela approuve « ce client-là » pour agir à votre place. La page est vraie. Le certificat est vrai. La barre d’adresse survit à « est-ce Microsoft ». L’astuce se déplace vers une autre question : qui a généré ce code, et quelle application reçoit l’autorisation.

La deuxième séquence d’attaque du briefing est exactement celle-là : après le scénario passkey, la victime saisit un code fourni par l’acteur sur une page d’authentification légitime, et le jeton est émis pour un client qu’ils contrôlent. Ils rejouent ensuite ce jeton, énumèrent l’annuaire et les fichiers, et sautent à la fois le vol de cookie et une autre invite MFA. Pour quiconque a appris à vérifier le cadenas et le nom d’hôte, c’est plus dur à attraper sur le moment — la couche qu’on vous a appris à inspecter est verte.

Donc « la barre d’adresse est Microsoft » ne soutient que : vous n’avez pas tapé un mot de passe dans un sosie tel que add-passkey.com. Elle ne soutient pas : ce code appartient à votre propre ordinateur ; après l’approbation, le jeton restera dans votre navigateur. Un code dicté au téléphone, dans un SMS ou dans un chat doit être traité par défaut comme leur client — pas comme « page officielle, donc sûr ».

Pourquoi changer le mot de passe ne couvre pas un authentificateur qu’ils ont inscrit

Une fois à l’intérieur, le premier geste n’est souvent pas de continuer à feuilleter des fichiers. C’est d’écrire leur propre méthode d’authentification dans votre identité. Le briefing liste un nouveau numéro, une application d’authentification, ou un jeton logiciel à mot de passe à usage unique. Un échantillon d’audit réel du 4 septembre 2026 montre un enregistrement nouvellement ajouté dont le nom d’appareil est NO_DEVICE, dont la balise d’appareil est SoftwareTokenActivated, et dont le champ de fonction de hachage est hmacsha1. Ce n’est pas « ils ont posé un autre mot de passe ». C’est « le prochain second facteur peut être complété par eux ».

La remédiation Microsoft pour un compromis confirmé est une seule séquence : révoquer les sessions actives et les jetons d’actualisation, réinitialiser les identifiants, supprimer les méthodes qu’ils ont inscrites, retirer les règles de boîte aux lettres qu’ils ont ajoutées, et réinscrire avec une méthode résistante à l’hameçonnage. Changer le mot de passe et sauter Informations de sécurité laisse une clé qu’ils ont déjà posée. Une troisième séquence d’enquête montre qu’ils peuvent revenir quelques jours plus tard avec un PhoneAppOTP inscrit plus tôt, puis parcourir Graph avec une automatisation Node.js — mot de passe correct, second facteur « passé », et le facteur est le leur.

Le testeur de mot de passe local compare la chaîne à une liste publique de mots de passe faibles déjà divulgués. Le mot de passe n’est pas envoyé, et le contrôle n’est pas une recherche Have I Been Pwned sur tout le web. Il peut vous dire que la chaîne est trop courante. Il ne peut pas vous dire qu’Informations de sécurité a gagné une ligne NO_DEVICE, et il ne peut pas prouver que l’appel était faux. Un mot de passe faible et une session détournée ne sont pas la même colonne de données. Ne substituez pas l’un à l’autre.

Ce que vous voyez Ce que cela soutient Ce que cela ne soutient pas
J’ai déjà inscrit une passkey Un faux hôte a peu de chances d’exporter cette clé privée Personne ne peut vous presser de remettre une connexion vivante
La barre d’adresse est un hôte Microsoft Vous n’avez pas tapé un mot de passe dans un sosie L’autorisation du code d’appareil est pour votre propre client
L’appelant a nommé l’entreprise et un service Ils ont fait de la reconnaissance en sources ouvertes L’appel a utilisé un numéro de rappel vérifié par votre entreprise
J’ai changé le mot de passe La couche mot de passe a été renouvelée Les authentificateurs étrangers et les sessions non révoquées sont morts
J’ai ouvert le SMS sur mon téléphone ; le PC pro a l’air propre Le journal de terminal de ce poste peut être vide Aucune session d’identité cloud n’a été établie pour eux
Un collègue m’a aussi relancé dans Teams pour mettre à jour la Passkey Le message vient d’un compte interne connecté Ce compte est encore contrôlé par la personne qu’il nomme

Après avoir raccroché, quelles couches contrôler maintenant

Un slogan n’est pas une preuve. Contrôlez seulement ce que vous maîtrisez : l’appel a-t-il emprunté un canal que vous faites déjà confiance, le nom d’hôte que vous allez ouvrir, et si Informations de sécurité a gagné un appareil. N’utilisez pas un compte de production pour ouvrir le lien de l’appel comme expérience.

  1. Raccrochez. Contactez l’informatique par le portail de tickets, le site interne ou le numéro de rappel que votre entreprise a publié par écrit. Ne rappelez pas le numéro qui vient de sonner. Ne touchez pas le lien du SMS. Microsoft dit aux employeurs de donner au personnel un canal vérifié pour signaler les demandes d’authentification non sollicitées.
  2. Si vous avez déjà ouvert le lien : ne regardez que le nom d’hôte. Un nom d’entreprise dans le sous-domaine avec un suffixe tel que add-passkey.com, setupmypasskey.com ou secure-passkey.com n’est pas un hôte de connexion Microsoft. Ne saisissez ni mot de passe, ni code SMS, ni confirmation de passkey sur cette page.
  3. Si quelqu’un vous demande de « saisir un code sur le site officiel » : demandez quelle application et quel appareil l’ont généré. Un code qu’on vous a dicté est leur client. La page officielle de code d’appareil peut rester authentique tandis que l’autorisation atterrit sur leur application.
  4. Après une connexion par un chemin de confiance, ouvrez Informations de sécurité / Mes connexions et lisez chaque méthode. Les numéros, authentificateurs et jetons logiciels en trop — surtout un nom d’appareil qui n’est pas votre téléphone — reçoivent une révocation de session et une suppression par le processus d’administration. Ne vous arrêtez pas à un changement de mot de passe.
  5. Quand vous devez remettre un court secret à usage unique à un collègue déjà vérifié, passez par un chemin de texte chiffré. Ouvrez le lien auto-destructeur et écrivez un canari jetable tel que canary-fp-20260921-passkey-lure. Ouvrez le panneau Network des outils de développement et cochez Preserve log. Après avoir généré le lien, cherchez ce canari : le corps de POST /secrets doit porter le texte chiffré, l’expiration et le nombre de lectures — pas le clair, et pas la clé après #. La forme du lien est s.html?id={id}#{key}. La RFC 9110 dit que l’URI cible de la requête exclut le fragment.

Les quatre premières étapes ferment le canal qui prend l’identité. La cinquième couvre une autre erreur courante : capturer « le code que l’IT a demandé » ou un mot de passe temporaire dans le chat. Les hébergeurs d’images et les albums gardent les pixels et, souvent, de l’OCR. La note précédente a couvert cela. Burn-Link n’envoie que le texte chiffré ; la clé reste après #. Ne mélangez pas les deux canaux — ne capturez pas dans le chat pour ensuite coller l’URL complète de brûlage sur la même image.

Ne mettez pas le lien entier et le clair sur le même chemin. Un code d’appareil dicté au téléphone, une capture dans le chat, et une chaîne complète s.html?id=…#… sont trois surfaces de fuite différentes. Si la clé et le verrou voyagent dans le même message, le dièse ne protège plus personne qui peut voir ce message.

Trois façons de trop lire « j’ai une Passkey »

Première : lire résistant à l’hameçonnage comme résistant à l’ingénierie sociale. Une passkey est liée à l’origine. Cela vise une fausse page de connexion qui tente d’exporter la clé privée. Un appel, un SMS ou un chat interne peut contourner cette couche et vous déposer dans un intermédiaire ou un code d’appareil. La propre liste d’atténuations de Microsoft place la formation contre l’hameçonnage vocal et par e-mail à côté de « imposer une MFA résistante à l’hameçonnage », et dit aussi de bloquer le flux de code d’appareil quand vous n’en avez pas besoin.

Deuxième : lire « la page est officielle » comme « l’autorisation est la mienne ». La page de code d’appareil peut être un vrai hôte. L’icône de cadenas ne dit pas à qui le jeton est émis. La preuve, c’est d’où vient le code : une invite sur votre propre appareil, versus un numéro qu’on vous a dicté, ne sont pas le même événement.

Troisième : lire un changement de mot de passe comme une clôture. Mot de passe, session, authentificateurs qu’ils ont inscrits, et règles de transfert de boîte aux lettres sont des interrupteurs différents. Le briefing veut qu’on les traite ensemble. Générer un nouveau mot de passe en local ne couvre que les services qui utilisent encore un mot de passe : ouvrez le générateur de mot de passe — prêt à l’emploi, longueur 6–128, 16 par défaut, un avertissement en dessous de 8, calculé dans le navigateur, rien n’est envoyé. Cela ne révoque pas les sessions. Cela ne supprime pas une méthode que vous n’avez pas inscrite.

Questions fréquentes

J’ai déjà inscrit une passkey. Cet appel peut-il encore fonctionner ?

Oui, et souvent sans que la Passkey ait été copiée. Le scénario s’en sert comme prétexte. Ce qu’ils veulent, c’est la session qu’un kit d’intermédiaire capture, ou le code d’appareil que vous saisissez sur un vrai hôte Microsoft pour leur client. Une passkey est liée à l’origine de la partie de confiance. Cela empêche une fausse page de connexion d’exporter la clé privée. Cela ne vous empêche pas d’autoriser leur application.

Si la barre d’adresse ressemble à Microsoft, puis-je saisir un code d’appareil ?

La page de connexion du flux de code d’appareil est censée être un hôte Microsoft authentique. Le risque n’est pas « est-ce un faux site ». C’est « qui a généré ce code, et quelle application reçoit l’autorisation ». Un code dicté au téléphone ou dans un SMS autorise leur client, pas votre propre session de navigateur.

Si je change le mot de passe, l’incident est-il clos ?

Non. Microsoft a écrit qu’une fois à l’intérieur, ils inscrivent leur propre numéro, authentificateur ou jeton logiciel. Changer le mot de passe sans révoquer les sessions ni supprimer ces méthodes laisse un facteur qu’ils contrôlent déjà. Les appareils en trop sur la page Informations de sécurité doivent partir par les étapes officielles de remédiation.

Un collègue demande un code à usage unique dans le chat. Puis-je envoyer une capture ?

N’envoyez pas un OTP vivant ni un code d’appareil dans un album de discussion. Chiffrez une courte chaîne dans cet onglet avec AES-256-GCM et passez par Burn-Link, avec la clé après #. La forme est s.html?id={id}#{key}. Créer et lire sont prêts à l’emploi ; aucun compte. Confirmez la personne par un canal que votre entreprise a déjà publié — pas l’appel qui vient de se prétendre le service informatique. Au-delà de 32 Ko, le matériau appartient au chiffrement de fichier : un fichier jusqu’à 5 Go, sortie .lock / .enc.

Déplacer un court secret vers un chemin prêt à l’emploi

Si vous voulez une page qui écrit la frontière de calcul à découvert, pour vous exercer à « rendre un mot de passe, sauter la capture », ouvrez Burn-Link de FastPwd. Aucune inscription. Écrivez le canari ci-dessus, laissez le nombre de lectures à 1, générez le lien, puis comparez Network comme à la cinquième étape : le corps doit porter le texte chiffré seulement — pas le clair, et pas la clé après le dièse. N’empruntez ce chemin qu’après vérification du collègue. Ne capturez pas d’abord. Ne dictez pas un code d’appareil à un inconnu au téléphone.

Si un journal de chat ou un ticket empile encore des numéros de téléphone et des numéros de pièce, faites un masquage par règles dans le nettoyage de confidentialité avant de décider d’envoyer. Le nettoyage reste sur cet appareil. Le texte source n’est pas envoyé comme donnée métier et n’est pas écrit dans analytics. Pour les sites qui utilisent encore un mot de passe, générez-en un unique en local. Ne réutilisez pas la chaîne que l’appelant vous a pressé de taper. Le testeur de mot de passe ne répond qu’à « est-ce un mot de passe faible publiquement courant ». Il ne répond pas à « cet appel était-il faux ».

La prochaine fois qu’un appelant dit « mettez à jour votre passkey maintenant », gardez trois phrases. Première : Passkey dans le scénario n’est souvent que le prétexte ; ils veulent une session ou une autorisation par code d’appareil. Deuxième : un vrai hôte ne vous empêche pas d’émettre un jeton pour l’application de quelqu’un d’autre. Troisième : la clôture, c’est Informations de sécurité plus la révocation de session — pas un changement de mot de passe seul. Ces trois phrases peuvent entrer dans une note de passation. « J’ai activé les passkeys, donc je peux ignorer l’appel » ne le peut pas.

Pour aller plus loin

Après qu’un mot de passe a été recadré dans un hébergeur d’images, un hash de connexion ne couvre ni le clair OCR ni une Image ID — voir Pourquoi le texte OCR et les Image ID d’un hébergeur de captures sont plus dangereux qu’un hash de mot de passe. Un lien auto-destructeur peut prouver que le serveur a supprimé le texte chiffré ; il ne peut pas prouver que le destinataire a sauté la capture — voir Pourquoi un lien auto-destructeur peut prouver que le serveur a supprimé le texte chiffré, mais pas que le destinataire n’a pas fait de capture d’écran. Pourquoi le segment après # reste hors de HTTP — voir Pourquoi un fragment d’URL peut porter une clé, et quand cette protection lâche.