Résumé
Depuis avril 2026, un cybercriminel, suivi par la référence O-UNC-066, qui gère un site DLS nommé Pink (signalé comme « CL-CRI-1147 » par Palo Alto Networks Unit 42), a déployé un kit de phishing avec panneau de contrôle visant le processus d’inscription des passkeys pour les clients Microsoft 365.
Okta a constaté que ce groupe d’activité cible des entreprises dans les secteurs de l’alimentaire et des boissons, des technologies, de la santé, de l’automobile, du bâtiment et de l’aéronautique. La principale motivation des cybercriminels est l’extorsion de données.
Le cybercriminel enregistre des noms de domaines intégrant le mot « passkey » (clé d’accès) dans le cadre d’une opération de phishing vocal (« vishing »). Le cybercriminel appelle ensuite les personnes ciblées par téléphone afin de tenter de les convaincre qu’elles doivent inscrire une nouvelle passkey.
Les utilisateurs sont redirigés vers un kit de phishing qui imite de près le processus d’inscription des passkeys de Microsoft. Il semble conçu pour convaincre la personne ciblée qu’elle est en train d’inscrire une passkey auprès de Microsoft, alors que le cybercriminel enregistre simultanément sa propre clé d’accès dans le compte Microsoft de l’utilisateur ciblé.
Ce prétexte arrive à point nommé : depuis mai 2026, les admins Microsoft peuvent créer des campagnes d’inscription de passkeys qui rappellent ou incitent les utilisateurs à s’y inscrire lors de la connexion, et dans certains cas, ces incitations sont activées par défaut.
Des cybercriminels ont utilisé cette mise à niveau de la sécurité, pourtant bien intentionnée, comme prétexte pour détourner le processus d’inscription et servir leurs propres objectifs.
Notre analyse du kit de phishing a révélé qu’il ne tente pas de gérer la fédération vers des fournisseurs d’identité tiers tels qu’Okta. Par la suite, nous n’avons pas constaté de compromission directe des comptes Microsoft.
Nous avons néanmoins publié des conseils dans un article de blog sur la manière d’appliquer la résistance au phishing à l’inscription et à la récupération de l’authentification.
Analyse des menaces
Dans l’activité malveillante que nous avons observée, le cybercriminel crée des sous-domaines spécifiques à chaque cible qui imitent les pages de connexion Microsoft Entra ID. Les pages sont personnalisées à l’aide de l’identité visuelle légitime de chaque entreprise victime. Le style générique de Microsoft est récupéré depuis le réseau de diffusion de contenu de Microsoft, tandis que les éléments d’identité visuelle propres à chaque organisation victime (logo et arrière-plan) sont préparés à l’avance pour chaque sous-domaine pendant la configuration et diffusés depuis le backend du kit de phishing.
Ce kit n’est pas un proxy « adversary-in-the-middle » (AitM) transparent, l’un des types de kits de phishing les plus fréquemment observés, conçu pour collecter des identifiants, des jetons MFA et des tokens de session. Il s’agit d’un panneau PHP contrôlé par un opérateur, dans lequel un cybercriminel guide les personnes ciblées à travers différentes étapes d’authentification, quasiment en temps réel, grâce à un mécanisme d’interrogation heartbeat d’une seconde. L’opérateur peut utiliser le kit pour adapter l’expérience utilisateur aux exigences du MFA propres à chaque victime (TOTP, notification push avec correspondance de numéro, mot de passe à usage unique par SMS) pendant la session. Ce design opérationnel est cohérent avec les méthodes de vishing documentées dans l’article de blog public d’Okta de novembre 2025 : « Les kits de phishing s’adaptent au script des appelants ». L’appelant peut contrôler et modifier en temps réel les pages de phishing et les notifications visibles par l’utilisateur ciblé.
Il est probable que le cybercriminel utilise le kit pour prendre le contrôle du compte utilisateur et inciter l’utilisateur à approuver l’inscription d’une passkey initiée par l’attaquant.
Okta Threat Intelligence a utilisé un code issu du kit de phishing pour reconstituer le flux suivant, qui reprend de près le processus d’inscription de passkeys pour Microsoft Entra.
La première page du kit de phishing (/gate) affiche une icône de chargement pendant que le kit de phishing effectue des vérifications anti-analyse. La deuxième page (/identify) demande un nom d’utilisateur. Le kit de phishing n'a pas redirigé vers un fournisseur d’identité fédéré au moment de notre analyse.
Figure 1. La page de connexion Microsoft O-UNC-066, recréée à partir du code extrait du kit de phishing.
La page suivante (/password) demande à l’utilisateur de saisir un mot de passe. Les identifiants capturés sont envoyés dans une requête POST avec un horodatage et un identifiant vers un panneau d’opérateur à l’adresse /backend.php.
Figure 2. La page de challenge de mot de passe Microsoft O-UNC-066, recréée à partir du code extrait du kit de phishing.
Nous partons du principe qu’un opérateur de kit de phishing (qui peut être une personne différente de celle qui parle au téléphone) capture les identifiants de l’utilisateur ciblé en quelques secondes et les saisit sur la véritable page de connexion Microsoft du tenant visé.
L’utilisateur ciblé voit alors une page (/processing) qui montre un nouvel écran de chargement pendant que le kit de phishing attend la prochaine instruction de l’opérateur. Nous supposons que ce léger délai est nécessaire pour qu’un cybercriminel puisse s’authentifier sur le compte Microsoft légitime de l’utilisateur à l’aide des identifiants volés, observer les challenges MFA proposés et sélectionner la page suivante du kit de phishing à présenter à l’utilisateur.
Page suivante du kit de phishing à présenter à l’utilisateur.
- Si l’opérateur choisit ou est contraint de répondre à un challenge par mot de passe à usage unique (OTP) par SMS, l’utilisateur est dirigé vers une page intitulée /submit-otp. L’OTP capturé est envoyé dans une requête POST au panneau d’opérateur à l’adresse /backend.php.
- Si l’opérateur choisit ou est contraint de répondre à un challenge TOTP, l’utilisateur est dirigé vers une page intitulée /submit-authenticator. L’OTP capturé est envoyé dans une requête POST au panneau d’opérateur à l’adresse /backend.php.
- Si l’opérateur choisit ou est contraint de répondre à un challenge Push MFA, l’utilisateur est redirigé vers une page intitulée /approve-authenticator (voir l’image ci-dessous) et doit saisir le numéro fourni par l’opérateur dans son application d’authentification.
Figure 3. La page de challenge MFA O-UNC-066, recréée à partir du code extrait du kit de phishing.
À ce stade d’une attaque, l’utilisateur a été piégé par téléphone et a approuvé l’accès de l’attaquant à son compte Microsoft 365.
Conformément au prétexte des passkeys, les cybercriminels peuvent alors rediriger les utilisateurs vers la page /passkey/register, qui invite l’utilisateur à créer une passkey.
Figure 4. La page d’enregistrement de la clé d’accès O-UNC-066, recréée à partir du code extrait du kit de phishing.
Le kit de phishing semble exploiter le manque de familiarité des utilisateurs avec l’authentification par passkey. Lors d’une véritable procédure d’inscription de passkey, l’utilisateur peut s’attendre à ce qu’une boîte de dialogue système lui propose d’inscrire une passkey sur son appareil. Les pages de passkey dans ce kit de phishing semblent imiter cette procédure sans inscrire de passkey.
Sur la page /passkey, l’utilisateur ciblé voit s’afficher une page siglée Microsoft qui l’incite à « enregistrer votre clé de récupération » à partir d’une liste de phrases BIP-39 contrôlée par l’attaquant. Cela ressemble fortement aux méthodes utilisées dans certaines applications de cryptomonnaie pour générer des seed phrases faciles à retenir.
Figure 5. La page optionnelle de clé d’accès O-UNC-066, avec du code extrait du kit de phishing.
Ensuite, une page /passkey/check demande à l’utilisateur de vérifier le dernier mot utilisé dans la seed phrase.
Nous n’avons connaissance d’aucune application directe des seed phrases BIP-39 dans Microsoft Entra ni dans son processus d’enregistrement des passkeys. Un attaquant ayant déjà obtenu un accès non autorisé à un compte utilisateur peut générer ses propres codes de récupération en utilisant une méthode qui ne nécessite aucune intervention de la personne titulaire du compte.
Il est probable que ces pages sur le thème des passkeys soient mises à disposition de l’opérateur du kit de phishing pour faire diversion. Cette distraction occupe un utilisateur sur une tâche pendant que le cybercriminel inscrit sa propre passkey sur le compte utilisateur Microsoft légitime.
La page /done confirme que l’inscription d’une passkey a réussi. Un utilisateur non averti qui ne comprend pas entièrement comment une passkey est inscrite peut sincèrement penser avoir inscrit une passkey auprès de Microsoft simplement en accomplissant ces tâches qui, autrement, n’ont pas de réelle signification.
Figure 7. La page de confirmation de la campagne O-UNC-066, avec du code extrait du kit de phishing.
L’opérateur peut choisir quand afficher la page /done à l’utilisateur. Au minimum, cela aide l’opération de phishing à préserver le prétexte initial. Chaque fois qu’un utilisateur inscrit une passkey avec Microsoft, le titulaire du compte compromis reçoit un e-mail authentique de Microsoft l’informant qu’une nouvelle passkey a été inscrite sur son compte. Lors d’une attaque, la passkey a en réalité été enregistrée par le cybercriminel directement auprès de Microsoft, et le cybercriminel peut nommer la passkey de façon à ce que l’utilisateur ciblé la considère comme inoffensive (en reprenant éventuellement une partie de la seed phrase choisie par l’utilisateur ciblé). La configuration d’inscription d’une passkey que l’utilisateur ciblé voit sur le site de phishing, en revanche, existe probablement uniquement pour tromper l’utilisateur et lui faire croire que l’inscription effectuée par l’attaquant était la sienne.
Infrastructure
Des cybercriminels ont été observés en train de créer des sous-domaines pour des entités ciblées données sous les domaines suivants :
- assignpasskey[.]com (2026-06-14, Internet Domain Service BS Corp., DDoS-Guard)
- deploypasskey[.]com (2026-04-21, Tucows, DDoS-Guard)
- passkeydeploy[.]com (2026-04-23, Internet Domain Service BS Corp, DDoS-Guard)
- passkeyadd[.]com (2026-05-08, Tucows, DDoS-Guard)
- setpasskey[.]com (2026-05-23, IQWeb FZ-LLC)
Ainsi, une campagne ciblant « exampleentity » pourrait ressembler à ceci :
exampleentity[.]setpasskey[.]com
L’infrastructure de phishing observée par Okta Threat Intelligence était hébergée sur DDoS-Guard (AS57724, Russie) et IQWeb FZ-LLC (AS59692, États-Unis).
Impact
Depuis avril 2026, un cybercriminel lié à O-UNC-066 exploite un site de fuite de données nommé Pink (signalé sous « CL-CRI-1147 » par Palo Alto Networks Unit 42).
Figure 7. Le site Pink DLS (extorsion de données)
Recommandations
Bien que ce groupe d’activités malveillantes n’ait pas été observé en train d’usurper l’identité d’Okta, des campagnes similaires ont associé du social engineering par téléphone et des kits de phishing contrôlés par des opérateurs :
Article de blog public (accessible au public)
Alerte flash (clients Okta uniquement)
Alerte de menace (clients Okta uniquement)
Les recommandations ci-dessous concernent spécifiquement la défense des clients d’Okta.
ATT&CK
|
Tactique
|
Recommandation de contrôle
|
T1566
|
Phishing
|
Inscrire les utilisateurs sur des authentificateurs robustes tels qu’Okta FastPass, des passkeys ou des cartes à puce et appliquer la résistance au phishing dans la politique.
Établir, communiquer et diffuser des méthodes permettant de vérifier l’identité du personnel de support lorsqu’il contacte les utilisateurs.
|
T1078
|
Phishing
|
Refuser les demandes provenant de lieux où votre entreprise ne propose pas de services. Les zones réseau d’Okta permettent aux administrateurs de définir des politiques qui refusent l’accès aux applications protégées par Okta selon la géolocalisation (pays), l’ASN, l’adresse IP ou d’autres critères.
|
T1078
|
Comptes valides
|
Les politiques d’authentification Okta peuvent être utilisées pour restreindre l’accès aux comptes utilisateurs en fonction d’un ensemble de prérequis configurables par les clients. Nous recommandons aux administrateurs de limiter l’accès aux applications sensibles aux appareils gérés par des outils de gestion des terminaux et protégés par des outils de sécurité des terminaux. |
T1078
|
Comptes valides
|
Informer les utilisateurs de chaque événement du cycle de vie du facteur d’authentification à l’aide des notifications destinées aux utilisateurs finaux.
|
T1098
|
Manipulation de compte (enregistrement d’appareil)
|
Appliquer les politiques de gestion du compte Okta qui limitent la possibilité d’ajouter ou de modifier des authentificateurs en fonction du contexte réseau, de l’état de gestion de l’appareil et des facteurs d’authentification inscrits. Des recommandations spécifiques sont fournies dans l’article de blog suivant : |
