Le phishing déguisé en passkey vide les comptes Microsoft 365 des entreprises
Microsoft documente des attaques où des gangs liés à ShinyHunters et Helix se font passer pour le help desk afin d’amener des employés vers des sites de phishing passkey, puis exfiltrent les données Microsoft 365. La parade tient moins au passkey lui-même qu’à des méthodes d’authentification résistantes au phishing et à la révocation des sessions compromises.
11 septembre 2026. Microsoft détaille une campagne où des groupes liés à ShinyHunters, Helix et d’autres gangs d’extorsion utilisent l’ingénierie sociale autour des passkeys pour compromettre des comptes d’entreprise et siphonner les données de Microsoft 365. L’activité court depuis mai 2026, et le piège est redoutablement simple : se faire passer pour le help desk interne, puis prétendre qu’un passkey ou une configuration SSO doit être mise à jour d’urgence. Le détournement est d’autant plus pervers qu’il instrumentalise l’outil censé nous protéger du phishing.
Le passkey n’est pas attaqué, il sert d’appât
Le détail qui change tout : les attaquants n’essaient pas d’enrôler un passkey. Microsoft est explicite sur ce point. Le vocabulaire « passkey », « MFA », « SSO » n’est qu’un leurre pour convaincre la cible de cliquer.
La mécanique réelle repose sur deux techniques connues. La première est l’adversary-in-the-middle (AiTM), où un site de phishing relaie en direct la session de la victime vers le vrai portail Microsoft, capturant au passage identifiants et jetons de session. La seconde est le device code phishing : la victime, guidée par téléphone, saisit un code fourni par l’attaquant sur la page d’authentification légitime de Microsoft, ce qui délivre un jeton OAuth à une application contrôlée par l’adversaire.
Microsoft observe que les attaquants investissent lourdement dans la recherche préalable : profils des employés, organigramme, plateformes professionnelles. Les domaines de phishing sont enregistrés en combinant le nom de l’entreprise avec des termes comme passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com ou oktasession[.]com, souvent avec le nom de la victime en sous-domaine (entreprise.secure-passkey[.]com). Le hameçonnage passe par appel téléphonique ou SMS vers le téléphone personnel.
Qui opère, et avec quels liens
Microsoft rattache l’activité à plusieurs acteurs d’un même écosystème d’extorsion : Storm-3121, associé à ShinyHunters et à l’extorsion Falcon, et Storm-3032, lié à d’anciens membres du groupe BlackFile opérant désormais sous la bannière Helix.
Le recoupement avec Google Threat Intelligence est précieux. Google avait déjà documenté le cluster UNC6671, qui combine ingénierie sociale par téléphone et infrastructure de phishing passkey avant de pénétrer des environnements cloud d’entreprise. Google relie UNC6671 aux mêmes gangs : BlackFile, Helix, Falcon, Pink et Redact. Deux équipes de renseignement convergent donc vers le même groupe d’acteurs, avec la même signature technique.
Ce qui se passe une fois la session volée
La partie la plus instructive du rapport est le déroulé post-compromission. Dans un cas, Microsoft voit une connexion suspecte depuis un appareil non géré vers un service Microsoft 365 identifié dans les journaux Entra comme OfficeHome. Après une MFA valide, l’attaquant établit une session légitime et commence, en quelques minutes, à inventorier les ressources accessibles : My Apps, My Profile, les interfaces de gestion des approbations et des connexions.
S’ensuit un accès à SharePoint Online, Outlook Web, aux services de collaboration et de recherche, puis à une application métier interne. La session reste active environ une heure, le temps de lister fichiers sensibles et applications internes.
La persistance est tout aussi méthodique. Les attaquants ajoutent une méthode MFA qu’ils contrôlent : nouveaux numéros de téléphone, applications d’authentification, jetons TOTP logiciels. Cette persistance leur permet de satisfaire les futures demandes MFA sans la victime — même si Microsoft note qu’elle ne survit pas à une réinitialisation complète des identifiants et des sessions.
Vient alors l’énumération par Microsoft Graph : organisations, licences, utilisateurs, groupes, rôles d’annuaire, méthodes d’authentification, applications, service principals, permissions OAuth, sites SharePoint, documents OneDrive, boîtes aux lettres et pièces jointes. Des requêtes comme /users, /groups ou /sites sont courantes en entreprise et ne déclenchent pas d’alerte. Le signal suspect apparaît quand le même compte enchaîne rapidement ressources, privilèges et téléchargements.
La dernière étape est l’exfiltration : accès et téléchargement en volume depuis SharePoint Online et OneDrive for Business, avec des intrusions allant jusqu’à Exchange Online via l’API REST pour lire le contenu des courriels.
Pourquoi le passkey résiste, et où il lâche
Il faut être précis sur ce que cette campagne dit — et ne dit pas — du passkey. Une assertion FIDO2 est liée à l’origine du site : un relais AiTM peut capturer le jeton de session, mais pas rejouer l’assertion sur un autre domaine. C’est cette propriété qui rend le passkey structurellement supérieur au TOTP ou au SMS face au phishing. Aucune de ces attaques ne « casse » le passkey.
Ce qui casse, c’est le parcours d’enrôlement et de récupération, là où l’humain est le maillon faible. L’attaquant ne contourne pas le passkey : il convainc l’employé de s’authentifier par un autre canal — un code device, une session relais — en brandissant précisément le mot « passkey » comme alibi d’urgence. La leçon inverse l’intuition : plus une organisation communique fort sur les passkeys, plus elle doit verrouiller les flux d’authentification faibles qui les entourent.
Concrètement, trois verrous comptent plus que le reste. Premier, restreindre le device code flow aux locataires et applications qui en ont un usage légitime, car c’est le canal préféré de cette campagne. Deuxième, conditionner l’enrôlement de méthodes MFA aux appareils gérés et à une réauthentification forte, pour empêcher l’ajout du « numéro de téléphone de l’attaquant ». Troisième, traiter tout ajout de méthode MFA comme un événement de sécurité à corréler, pas comme une banalité d’annuaire.
Verdict
Le point d’ancrage de cette campagne n’est pas une faille du passkey, mais la friction entre l’humain et l’authentification. Le passkey reste techniquement résistant au phishing — un vrai AiTM ne peut pas rejouer une assertion FIDO2 liée à l’origine. Le problème, c’est que l’employé qui croit « réenregistrer son passkey » finit par saisir un code device ou s’authentifier sur un relais, et là, aucune cryptographie ne le sauve.
Si vous êtes sous Microsoft 365, imposez des méthodes d’authentification résistantes au phishing (passkeys FIDO2, clés de sécurité, certificate-based authentication) et bloquez les flux faibles : interdisez le device code flow aux locataires qui n’en ont pas besoin, restreignez l’enrôlement MFA aux appareils gérés, et surveillez les ajouts de méthodes MFA comme un signal d’alerte de premier rang.
Si vous êtes un RSSI pressé, faites circuler une consigne unique : le help desk ne demandera jamais de réenregistrer un passkey via un lien reçu par SMS. Et préparez la révocation de session comme réflexe — car dans cette campagne, c’est la seule barrière que la persistance ne franchit pas.