Le phishing passkey change la donne : un nouveau kit d’attaque documenté par SecurityWeek n’essaie plus de voler un mot de passe, il fait enregistrer une passkey attaquante sur le compte de la victime. Résultat : la réinitialisation du mot de passe, réflexe numéro un de toute cellule de crise, ne coupe plus l’accès de l’attaquant. Pour une PME-ETI, c’est un angle mort majeur : l’incident est déclaré clos alors que l’intrus dispose toujours d’un authentifiant valide, résistant au phishing, et parfaitement légitime aux yeux du fournisseur d’identité.
Pourquoi le phishing passkey survit au changement de mot de passe
Une passkey est une paire de clés cryptographiques liée au domaine. C’est justement sa force qui devient le problème quand elle est enregistrée par un attaquant : elle est indépendante du mot de passe. Le cycle d’attaque observé est simple.
- La victime arrive sur une page de connexion clonée, relayée en temps réel vers le vrai portail (technique adversary-in-the-middle).
- L’attaquant capture la session authentifiée, MFA comprise.
- Depuis cette session, il déclenche l’enregistrement d’une nouvelle passkey contrôlée par lui, souvent présentée à la victime comme une « vérification de sécurité ».
- La victime change son mot de passe après l’alerte. La passkey attaquante, elle, reste active.
La même logique s’applique aux méthodes MFA ajoutées silencieusement : jeton TOTP, application d’authentification, clé FIDO physique. Le mot de passe n’est plus le pivot de l’identité, donc le réinitialiser ne suffit plus à reprendre le contrôle.
Ce que votre équipe croit faire vs. ce qui se passe vraiment
La procédure classique — « on force le reset du mot de passe et on révoque les sessions » — traite deux artefacts sur trois. Le troisième, la liste des méthodes d’authentification enregistrées, n’est presque jamais auditée. C’est précisément là que se loge la persistance.
Tutoriel : détecter et bloquer le phishing passkey en PME-ETI
Étape 1 — Journaliser l’enregistrement des méthodes d’authentification
Le signal de compromission le plus fiable n’est pas la connexion, c’est l’ajout d’un authentifiant. Activez et centralisez ces événements :
- Microsoft Entra ID : journaux d’audit, catégorie UserManagement, opérations « User registered security info » et « User changed default security info ».
- Google Workspace : rapport Admin / User log events, événements de type « 2-Step Verification enrollment » et ajout de passkey.
- Okta : événements
user.mfa.factor.activateetuser.authenticator.enroll.
Envoyez-les vers votre SIEM. Sur une plateforme comme Wazuh, une règle personnalisée sur ces identifiants d’événement suffit à générer une alerte de niveau 10.
Étape 2 — Alerter sur les enregistrements anormaux
Tous les enregistrements ne sont pas suspects. Concentrez la détection sur les combinaisons à forte valeur :
- Passkey enregistrée depuis une adresse IP ou un pays inhabituel pour l’utilisateur.
- Enregistrement survenant moins de 15 minutes après une première connexion depuis un appareil inconnu.
- Ajout d’une méthode sur un compte à privilèges (administrateur, direction, finance, RH).
- Plusieurs comptes enregistrant une méthode depuis le même ASN dans une fenêtre courte — signature d’une campagne.
Étape 3 — Corriger la procédure de réponse à incident
Réécrivez votre runbook de compromission de compte. L’ordre correct est :
- Révoquer tous les jetons de session et refresh tokens (et non seulement déconnecter).
- Inventorier les méthodes d’authentification du compte et supprimer toute passkey, clé FIDO ou application TOTP non reconnue par l’utilisateur, confirmée hors bande (téléphone, en présentiel).
- Réinitialiser le mot de passe.
- Réenrôler l’utilisateur avec une méthode vérifiée.
- Rechercher les règles de boîte mail, applications OAuth et délégations créées pendant la fenêtre de compromission.
Sans l’étape 2, les trois autres sont cosmétiques. C’est le même raisonnement que pour les attaques par identité qui ouvrent la voie aux ransomwares : l’accès survit à la remédiation partielle.
Étape 4 — Durcir l’enrôlement en amont
- Exiger un appareil conforme ou un réseau de confiance pour enregistrer une nouvelle méthode d’authentification (accès conditionnel Entra ID : action utilisateur « Register security information »).
- Imposer une authentification forte préalable à tout enrôlement — jamais un enrôlement autorisé par une simple session existante.
- Limiter le nombre de passkeys par compte et notifier l’utilisateur par un canal secondaire à chaque ajout.
- Privilégier les passkeys liées à l’appareil (device-bound) plutôt que synchronisées pour les comptes sensibles.
Étape 5 — Auditer l’existant dès aujourd’hui
Ne partez pas du principe que rien n’a été enregistré. Extrayez la liste complète des méthodes d’authentification de vos comptes à privilèges et faites-la valider une par une par leurs titulaires. Sur un parc de PME-ETI, l’opération prend une demi-journée et referme la principale porte dérobée post-phishing.
Ce que le phishing passkey annonce pour 2026
Le phishing passkey confirme un déplacement de fond : les attaquants ne visent plus le secret, ils visent le registre des identités. Les mêmes kits ajoutent déjà des méthodes MFA, des applications OAuth et des règles de transfert automatique — trois formes de persistance invisibles pour un reset de mot de passe. La contre-mesure n’est pas un produit supplémentaire mais un changement d’objet de surveillance : auditer ce qui donne accès, pas seulement ce qui se connecte. Les PME-ETI qui instrumentent dès maintenant les événements d’enrôlement transformeront ce vecteur en détection précoce plutôt qu’en post-mortem, comme pour le phishing par device code sur Microsoft 365.