Pass-ta-key : trois façons pour un malware Windows de détourner les passkeys synchronisées de Google

Rapport CTI technique du 5 août 2026

Résumé exécutif

Unit 42, l'équipe de recherche de Palo Alto Networks, a publié le 3 août 2026 une étude décrivant trois attaques distinctes contre Google Password Manager dans Chrome sur Windows, baptisées collectivement Pass-ta-key. Les trois techniques, Pass-ta-key, Silver Pass-ta-key et Golden Pass-ta-key, ne cassent pas la cryptographie des passkeys : elles exploitent la façon dont Chrome gère l'identité de l'appareil, le ré-enrôlement après perte d'état local, et la validation de la vérification utilisateur côté service. Toutes nécessitent qu'un malware tourne déjà sur le poste Windows ciblé, avec des privilèges utilisateur standards, sans nécessiter de droits administrateur ni d'interaction de la victime.

La portée pratique varie selon la technique. Pass-ta-key permet de forger une assertion d'authentification sans déverrouillage de l'appareil, mais échoue contre les services qui valident correctement l'indicateur de vérification utilisateur (le cas de GitHub, testé par les chercheurs, contre eBay qui ne le validait pas avant correctif). Golden Pass-ta-key va plus loin : elle extrait de la mémoire du process Chrome le secret de domaine de sécurité (Security Domain Secret) qui chiffre l'ensemble des passkeys synchronisées du compte, un secret que Google ne permet actuellement ni de faire tourner ni de révoquer. Pour un pentester évaluant la posture d'une organisation misant sur les passkeys comme rempart anti-phishing, ce rapport change la donne : la compromission du poste reste le facteur décisif, pas la robustesse du protocole FIDO2/WebAuthn lui-même.

Chronologie

Fiche d'acteur / campagne : recherche offensive Pass-ta-key (Unit 42)

Origine : recherche défensive publiée par Palo Alto Networks Unit 42, pas une campagne malveillante active documentée à ce stade. Cible du mécanisme : Google Password Manager en tant que cloud authenticator FIDO2 dans Chrome sur Windows, sur des postes équipés d'un module TPM.

Description technique. Les trois techniques partagent un prérequis commun : un malware exécuté en tant qu'utilisateur standard sur le poste Windows compromis, sans besoin de privilèges administrateur.

Pass-ta-key abuse la clé d'identité de l'appareil protégée par le TPM que Chrome utilise pour prouver au cloud authenticator de Google qu'une requête provient d'une machine de confiance. Le malware fait signer une requête d'assertion par le TPM via les appels Windows CNG (Cryptography API: Next Generation), sans déverrouillage, sans biométrie, sans PIN. Le cloud authenticator répond par une assertion signée valide, mais celle-ci porte un indicateur User Verified à faux : la technique échoue contre tout service qui vérifie correctement cet indicateur.

Silver Pass-ta-key force Chrome à se ré-enregistrer auprès du cloud authenticator, en invalidant la clé de vérification existante ou en supprimant le fichier local d'état des passkeys. Pendant ce ré-enregistrement, l'attaquant enregistre sa propre clé de vérification utilisateur, que le cloud authenticator accepte sans valider qu'elle provient d'un matériel de confiance. Les requêtes signées par cette clé attaquant sont ensuite acceptées comme preuve légitime de déverrouillage biométrique ou PIN, y compris par des services qui valident correctement l'indicateur.

Golden Pass-ta-key cible le secret de domaine de sécurité (Security Domain Secret, SDS), la clé maîtresse qui chiffre l'ensemble des passkeys synchronisées du compte Google Password Manager. Ce secret transite temporairement vers Chrome lors d'un enregistrement ou d'une récupération de compte. Unit 42 l'a d'abord trouvé en clair dans les logs FIDO internes de Chrome, un défaut corrigé depuis par Google, mais le secret reste accessible en mémoire du process pendant la fenêtre de ré-enregistrement. Un malware qui force ce ré-enregistrement et connaît le motif à rechercher en mémoire peut extraire le SDS et déchiffrer l'ensemble des passkeys du compte, présentes et futures, puisque Google ne propose aujourd'hui aucun mécanisme de rotation de ce secret.

Conditions d'exploitation : exécution de code arbitraire préalable sur le poste Windows ciblé (les trois techniques ne sont pas des vecteurs d'accès initial), présence d'un TPM, navigateur Chrome avec passkeys synchronisées activées. PoC disponible : démonstration décrite par Unit 42 dans son rapport de recherche, pas de code d'exploitation public diffusé au moment de la rédaction. Patch/mitigation : Google a retiré le SDS des logs FIDO, mais n'a pas publié de correctif complet pour l'exposition mémoire ni de mécanisme de rotation du secret au moment de la publication.

Diagramme de la chaîne d'attaque

Reconstitution basée sur le rapport Unit 42 et l'article BleepingComputer du 3 août 2026.

Analyse technique

Étape 1 : compromission préalable du poste Windows

Les trois techniques Pass-ta-key partagent un point de départ identique : elles ne sont pas des vecteurs d'accès initial. Un malware doit déjà s'exécuter sur le poste de la victime, avec des privilèges utilisateur standards. Ce prérequis limite le champ d'application aux scénarios de post-exploitation, mais le rend d'autant plus pertinent pour un red teamer disposant déjà d'un implant sur un poste cible équipé de passkeys d'entreprise.

Étape 2 : abus de la clé d'identité TPM (Pass-ta-key)

Sans privilège administrateur, le malware invoque les API Windows CNG pour faire signer par le TPM une requête d'assertion destinée au cloud authenticator de Google. Le TPM signe sans distinguer si la demande émane du navigateur légitime ou du malware, tant que celui-ci opère dans le contexte utilisateur attendu. Le résultat est une assertion valide, mais avec un indicateur de vérification utilisateur à faux, ce qui limite la portée aux services laxistes sur ce contrôle.

Étape 3 : détournement du ré-enregistrement (Silver Pass-ta-key)

Le malware provoque la perte de l'état local des passkeys, forçant Chrome à engager une procédure de ré-enregistrement auprès du cloud authenticator. Durant cette fenêtre, l'attaquant injecte sa propre clé de vérification, que le service distant accepte sans preuve d'origine matérielle de confiance. Une fois cette clé enregistrée, l'attaquant peut authentifier des requêtes depuis un système totalement différent, sans plus avoir besoin d'accéder à la machine de la victime.

Étape 4 : extraction du secret maître (Golden Pass-ta-key)

Pendant la même fenêtre de ré-enregistrement ou de récupération de compte, le secret de domaine de sécurité transite en clair vers la mémoire du process Chrome. Le malware qui connaît le motif mémoire à rechercher peut l'extraire directement, sans dépendre des logs déjà corrigés par Google. Ce secret déchiffre l'intégralité des passkeys synchronisées, actuelles et futures, tant qu'aucune rotation n'est disponible côté Google.

Étape 5 : exploitation à distance des clés extraites

Les clés privées de passkeys récupérées via Golden Pass-ta-key peuvent être transférées vers un système contrôlé par l'attaquant, situé n'importe où, pour usurper l'identité de la victime sur l'ensemble des services où ces passkeys sont enregistrées. Cette étape rompt la promesse habituelle des passkeys de rester liées au matériel d'origine.

Indicateurs de compromission

Unit 42 n'a pas publié d'indicateurs de compromission réseau ou fichier associés à une exploitation active de ces techniques : il s'agit de recherche défensive démontrant une classe d'attaque, pas d'une campagne suivie sur le terrain au moment de la rédaction.

MITRE ATT&CK

Aucune cartographie officielle Unit 42 ou MITRE n'accompagne ce rapport de recherche à ce stade. Le tableau suivant reflète une lecture technique du déroulé décrit, pas une attribution vendeur.

Remédiation : checklist opérationnelle

1. Exiger et valider strictement l'indicateur User Verified côté serveur pour toute authentification WebAuthn/passkey, plutôt que de se contenter d'accepter une assertion signée.
2. Durcir les processus de récupération et de ré-enregistrement d'appareil des gestionnaires de identifiants pour empêcher l'enregistrement d'une clé de vérification sans preuve d'origine matérielle de confiance.
3. Surveiller les appels applicatifs aux API Windows CNG émis par des processus autres que le navigateur, en particulier sur les postes disposant de passkeys d'entreprise synchronisées.
4. Traiter la compromission d'un poste comme un risque direct sur les comptes protégés par passkeys synchronisées, pas uniquement sur les mots de passe et sessions actives.
5. Prioriser, quand c'est possible, les passkeys liées au matériel (non synchronisées dans le cloud) pour les comptes à privilèges élevés, en attendant un mécanisme de rotation du secret de domaine de sécurité côté Google.
6. Suivre les correctifs et annonces de Google concernant Chrome et Google Password Manager sur ce sujet spécifique, la fenêtre de correction complète n'étant pas close au moment de la rédaction.
7. Sensibiliser les équipes de détection à considérer la présence de malware sur un poste comme suffisante pour justifier une révocation préventive des passkeys associées, sans attendre une preuve d'exfiltration.

Sources

• New Pass-ta-key attacks let malware hijack Google-synced passkeys - BleepingComputer
• Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts - The Hacker News
• Unit 42 - Passwordless Authentication Security Risks