En bref

  • Microsoft traque depuis mai 2026 une campagne d'ingénierie sociale exploitant le prétexte des passkeys pour compromettre des comptes Microsoft 365 et piller des données cloud d'entreprise.
  • Les attaquants se font passer pour le support informatique, redirigent les victimes vers des pages de phishing Adversary-in-the-Middle, puis exploitent Graph API pour exfiltrer SharePoint, OneDrive et Exchange Online.
  • Les organisations doivent auditer les méthodes d'authentification enregistrées, activer les politiques d'accès conditionnel et surveiller les accès inhabituels à Graph API.

Une campagne cloud qui abuse de la confiance dans les passkeys

Le 9 septembre 2026, l'équipe Microsoft Security a publié sur son blog officiel un rapport de threat intelligence détaillant une campagne d'intrusion cloud active qu'elle suit depuis mai 2026. La particularité de cette campagne est qu'elle exploite non pas une vulnérabilité technique dans les passkeys — ce standard d'authentification sans mot de passe basé sur la cryptographie à clé publique — mais la confiance que les utilisateurs accordent désormais à ce terme pour les tromper via de l'ingénierie sociale sophistiquée.

Le scénario d'attaque type commence par un contact téléphonique ou par email : un individu se présentant comme un membre de l'équipe IT interne ou du support Microsoft contacte l'employé ciblé et l'informe qu'il doit « mettre à jour » ou « enregistrer » son passkey pour se conformer à une nouvelle politique de sécurité de l'entreprise. Ce prétexte est particulièrement crédible car de nombreuses organisations sont effectivement en train de déployer des passkeys en remplacement des mots de passe traditionnels, dans le cadre de stratégies de sécurisation post-MFA.

L'attaquant envoie ensuite à la victime un lien vers une page web frauduleuse. Ces pages utilisent deux techniques distinctes selon les variantes de la campagne. Dans la première variante, la page implémente une attaque Adversary-in-the-Middle (AiTM) : elle se positionne comme un proxy transparent entre le navigateur de la victime et les serveurs d'authentification Microsoft réels, capturant en temps réel les identifiants saisis et, surtout, le cookie de session généré après une authentification réussie — y compris après validation d'un second facteur. Dans la seconde variante, la page exploite le flux d'authentification par code d'appareil (device code flow) de Microsoft OAuth 2.0, en convainquant la victime d'entrer un code généré par l'attaquant, ce qui lui confère un accès persistant au compte cible.

Une fois l'accès au compte obtenu, les attaquants agissent avec méthode. La première action consiste systématiquement à enregistrer une nouvelle méthode d'authentification sur le compte compromis — un appareil supplémentaire, un token FIDO2, ou une application d'authentification contrôlée par l'attaquant. Cette persistance est critique : même si la victime change son mot de passe, l'attaquant conserve un accès via la méthode d'authentification frauduleusement enregistrée.

La phase d'exploitation s'appuie ensuite sur l'API Microsoft Graph de manière intensive. Graph est l'interface unifiée de Microsoft 365 donnant accès à l'ensemble des ressources cloud d'un tenant : utilisateurs, groupes, rôles, applications, sites SharePoint, espaces OneDrive, boîtes mail Exchange, calendriers. Les attaquants commencent par une phase de reconnaissance via Graph pour cartographier ce à quoi le compte compromis a accès — liste des utilisateurs et de leurs permissions, structure des sites SharePoint, contenu des partages OneDrive. Cette reconnaissance automatisée génère un volume inhabituellement élevé d'appels API, l'un des indicateurs comportementaux identifiés par Microsoft comme signal de détection.

L'exfiltration porte principalement sur SharePoint Online et OneDrive for Business, avec des téléchargements de fichiers en masse. Dans certaines variantes de la campagne, les attaquants étendent leur collecte à Exchange Online via les API REST, récupérant le contenu des boîtes mail, les pièces jointes, et parfois les données de calendrier. Microsoft n'a pas communiqué le nombre d'organisations touchées ni l'identité des victimes confirmées, mais précise que la campagne cible des entreprises dans plusieurs secteurs d'activité, avec une concentration notable dans les services financiers et l'industrie.

L'aspect le plus trompeur de cette campagne réside dans son utilisation du terme « passkey » comme leurre. Contrairement à ce que le nom pourrait suggérer, les attaquants ne cherchent pas à compromettre de vrais passkeys cryptographiques — ce serait techniquement très difficile. Ils exploitent simplement la notoriété croissante du terme pour rendre leurs prétextes d'ingénierie sociale plus crédibles. Comme l'a formalisé l'équipe Microsoft dans son rapport : les leurres passkey ciblent les comptes cloud, pas les passkeys eux-mêmes. C'est une distinction importante que les équipes de sécurité et les utilisateurs finaux doivent avoir à l'esprit.

Microsoft recommande plusieurs mesures défensives en réponse à cette campagne. En priorité : auditer régulièrement les méthodes d'authentification enregistrées sur tous les comptes du tenant, et mettre en place des politiques d'accès conditionnel (Conditional Access) qui exigent que tout enregistrement d'un nouveau device ou d'une nouvelle méthode d'authentification soit approuvé par un administrateur. L'activation de la protection contre le phishing dans Microsoft Defender for Office 365, et la surveillance des logs d'audit Azure AD pour détecter les enregistrements de méthodes d'authentification inhabituels, font également partie des recommandations.

L'ingénierie sociale, vecteur dominant des compromissions cloud en 2026

Cette campagne illustre une tendance lourde de la menace cybersécurité en 2026 : le déplacement du vecteur d'attaque des vulnérabilités techniques vers l'ingénierie sociale ciblant les identités et les processus organisationnels. À mesure que les entreprises durcissent leurs postures techniques — déploiement du MFA, adoption des passkeys, politiques de Zero Trust — les attaquants s'adaptent et concentrent leurs efforts sur le maillon humain et organisationnel.

Le recours à des techniques AiTM pour contourner le MFA n'est pas nouveau : des frameworks offensifs exploitant ces techniques circulent dans la communauté depuis plusieurs années. Ce qui est notable dans cette campagne, c'est la sophistication du prétexte utilisé — exploiter le déploiement même des nouvelles mesures de sécurité comme vecteur d'ingénierie sociale — et l'automatisation de la phase post-compromission via Graph API. Cette combinaison permet à des acteurs disposant de ressources modestes d'opérer à grande échelle contre des environnements Microsoft 365.

L'abus de Microsoft Graph comme outil de reconnaissance et d'exfiltration constitue un signal fort pour les équipes SOC. Graph est une API extrêmement puissante qui agrège l'accès à l'ensemble des ressources Microsoft 365 d'un tenant sous une interface unifiée. Pour un attaquant disposant d'un token d'accès valide, Graph représente un couteau suisse pour l'énumération et l'exfiltration, sans avoir à compromettre plusieurs systèmes distincts. Les équipes SOC doivent intégrer la surveillance des patterns d'utilisation de Graph API dans leurs règles de détection, en alertant notamment sur les volumes inhabituels d'appels d'énumération en dehors des heures de travail.

Sur le plan des enjeux organisationnels, cette campagne pose la question de la formation des utilisateurs dans un contexte où les procédures légitimes de sécurité ressemblent de plus en plus aux prétextes frauduleux. Quand le vrai support IT demande aux employés d'enregistrer un passkey et que les attaquants utilisent exactement le même discours, la distinction est difficile pour un utilisateur non averti. Les organisations doivent établir des canaux de vérification indépendants — numéros de support internes à rappeler, procédures de validation hors-bande — et former leurs équipes à ne jamais suivre un lien reçu par email ou téléphone pour enregistrer un facteur d'authentification.

Ce qu'il faut retenir

  • La campagne utilise le prétexte de l'enregistrement de passkeys pour piéger les utilisateurs Microsoft 365 via des pages AiTM capturant identifiants et cookies de session.
  • Après compromission, les attaquants enregistrent une méthode d'authentification persistante puis pillent SharePoint, OneDrive et Exchange via Graph API.
  • Les organisations doivent auditer les méthodes d'auth enregistrées, activer l'approbation admin pour tout nouvel enregistrement, et surveiller les pics d'activité anormaux sur Graph API.

Comment distinguer une vraie demande d'enregistrement de passkey d'une tentative de phishing ?

La règle d'or : ne jamais suivre un lien reçu par email ou message pour enregistrer un facteur d'authentification. Les vraies procédures d'enregistrement de passkeys ou de dispositifs MFA se font toujours depuis le portail d'authentification de votre organisation (myaccount.microsoft.com ou l'URL officielle de votre SSO), accessible en tapant l'adresse directement dans le navigateur — jamais via un lien cliqué. Si un membre du support IT vous contacte pour enregistrer un nouvel élément, raccrochez, recherchez le numéro officiel du support IT dans l'annuaire interne de votre entreprise, et rappelez vous-même pour vérifier la demande.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact