Entra ID : le faux enrôlement de passkey qui offre une persistance durable
Par vishing, l'acteur O-UNC-066 enregistre sa propre passkey FIDO2 dans le compte de la victime. Détectez l'ajout de méthode corrélé à une connexion à risque.
Les passkeys sont présentées, à juste titre, comme le moyen le plus solide de se protéger contre le hameçonnage. Une clé FIDO2 ne peut pas être rejouée, ne fuit pas dans une base de données, résiste aux attaques de l'intercepteur. C'est précisément pour cette raison que la campagne décrite par Okta le 10 juillet 2026 est instructive : elle ne casse pas la cryptographie de la passkey, elle attaque le moment où cette clé forte est créée. L'acteur, suivi sous l'identifiant O-UNC-066 et également nommé Pink par l'Unit 42 de Palo Alto Networks, obtient ainsi une persistance qui survit à une réinitialisation de mot de passe.
Le principe est le suivant : par un appel téléphonique, l'attaquant se fait passer pour le support informatique et guide un employé à travers ce qu'il présente comme une procédure d'enrôlement de passkey. Pendant que la victime réalise une cérémonie d'enrôlement factice sur une page de hameçonnage, l'attaquant enregistre sa propre clé FIDO2 dans le compte Microsoft 365 de la victime. Résultat : un identifiant fort, contrôlé par l'attaquant, ancré durablement dans l'annuaire.
Pourquoi cette persistance est si difficile à déloger
Une fois la passkey de l'attaquant enregistrée, changer le mot de passe de la victime ne sert à rien : la clé FIDO2 est une méthode d'authentification indépendante. L'attaquant peut se connecter à volonté, sans mot de passe, en satisfaisant la MFA avec sa propre clé. C'est la technique T1098.005 (Account Manipulation: Device Registration), qui aboutit à un accès persistant à un compte cloud (T1078.004).
La chaîne complète mobilise plusieurs techniques. Le premier contact relève du hameçonnage vocal, T1598.004 (Phishing for Information: Spearphishing Voice). La manipulation de la cérémonie d'authentification pour faire valider l'enrôlement s'apparente à T1621 (Multi-Factor Authentication Request Generation). Okta note que la campagne vise, depuis au moins avril 2026, des organisations dans plusieurs secteurs, et que l'acteur a mis en ligne un site de fuite de données le 31 mai 2026, confirmant une motivation d'extorsion.
Le kit de hameçonnage présente une séquence d'URL reconnaissable, avec des chemins tels que /gate, /identify, /password, /processing et surtout /passkey/register. Ces chemins constituent des indicateurs utiles pour le filtrage web et la détection de proxy.
Le signal de détection : ajout de méthode FIDO2 corrélé à une connexion à risque
Le point de détection le plus fiable ne se trouve pas dans le courriel ou l'appel, invisibles aux journaux, mais dans l'annuaire lui-même. Entra ID journalise chaque ajout de méthode d'authentification dans ses AuditLogs. L'enregistrement d'une nouvelle passkey y apparaît comme un événement d'ajout de méthode FIDO2. Isolé, cet événement est légitime et fréquent. Ce qui le rend suspect, c'est sa corrélation avec une connexion à risque : géographie inhabituelle, appareil inconnu, adresse IP signalée dans les SignInLogs.
Voici une règle Sigma ciblant l'ajout de méthode FIDO2 dans les journaux d'audit Entra ID :
title: Ajout de methode passkey FIDO2 dans Entra ID
id: 4c8e1a90-6d2f-4b73-a1e5-9f0c3d7b2e64
status: experimental
description: >
Detecte l enregistrement d une nouvelle methode d authentification FIDO2 dans
Entra ID, a correler avec une connexion a risque pour reperer un abus O-UNC-066.
references:
- https://www.okta.com/blog/threat-intelligence/vishing-actors-target-microsoft-entra-passkey-enrollment-/
logsource:
product: azure
service: auditlogs
detection:
selection:
properties.category: 'UserManagement'
operationName|contains:
- 'security info'
- 'authentication method'
properties.targetResources|contains: 'FIDO2'
condition: selection
falsepositives:
- Enrolement legitime de passkey par l utilisateur, a correler avec le contexte de connexion
level: medium
tags:
- attack.persistence
- attack.t1098.005
- attack.t1078.004La corrélation qui transforme le signal en alerte
Prise seule, cette règle génère du bruit : les entreprises qui déploient les passkeys enregistrent des méthodes FIDO2 en continu. La valeur vient de la corrélation avec les SignInLogs. Une règle de détection efficace associe l'ajout de méthode FIDO2 à une connexion classée à risque par Entra ID Protection dans une courte fenêtre temporelle, ou à une session initiée depuis un appareil qui n'a jamais servi auparavant pour ce compte. Cette corrélation fait ressortir précisément le schéma de l'attaque : quelqu'un se connecte depuis un contexte inhabituel, puis enrôle immédiatement une nouvelle clé forte.
Les mesures organisationnelles qui coupent la campagne
Deux contrôles préventifs sont décisifs. D'abord, restreindre qui peut enrôler des méthodes d'authentification et depuis quel contexte, via les politiques d'inscription d'Entra ID, en exigeant par exemple une connexion depuis un appareil géré ou un réseau de confiance pour ajouter une passkey. Ensuite, former les utilisateurs à un fait simple : le support informatique ne demande jamais, par téléphone, de dérouler une procédure d'enrôlement de sécurité en suivant un lien reçu. Comme le souligne Okta, il ne s'agit pas d'une faille de la cryptographie des passkeys, mais d'une attaque d'ingénierie sociale visant l'instant de leur création.
Détecter cet abus demande de surveiller l'annuaire d'identité au bon endroit et de corréler les bons signaux. C'est ce que fournit le feed Sigma ThreatClaw : des règles pour Entra ID et les environnements cloud, construites sur les journaux d'audit et de connexion, et pensées pour la corrélation plutôt que pour l'alerte isolée.
Articles liés
ShinyHunters détourne des connexions OAuth de confiance pour exfiltrer le CRM sans déclencher la MFA. Comment détecter les consentements et jetons abusifs.
Nous avons détoné un échantillon Phobos vivant. Voici ce qu'il fait, suppression des clichés instantanés, coupure du pare-feu, et la règle Sigma qui l'attrape, validée sur plusieurs échantillons, zéro faux positif.
Un feed de règles ne vaut pas par son nombre de règles, mais par la preuve qu'elles fonctionnent et par ce que vous en faites quand elles se déclenchent. Testées sur moteur réel, anti-faux-positifs prouvé, signées, et chaque règle porte un playbook d'investigation relié à nos autres moteurs.
Une désérialisation de données non fiables donne une RCE sur SharePoint on-premise. Au KEV, exploitée par Storm-2603. Règle Sigma sur w3wp et détection Nuclei.