Unit 42, la divisione intelligence di Palo Alto Networks, ha reso pubblica il 3 agosto 2026 una ricerca su tre tecniche di attacco — Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key — che consentono a malware già residente su sistemi Windows di aggirare le protezioni biometriche e i PIN, dirottando i passkey sincronizzati di Google Password Manager in Chrome. La scoperta sposta il focus dalla resistenza al phishing, punto di forza del modello FIDO2, alla vulnerabilità dell'implementazione su endpoint compromessi.
- Le tre tecniche richiedono malware in esecuzione sul dispositivo: sono attacchi post-compromissione, non exploit remoti.
- Pass-ta-key abusa la chiave di identità del dispositito protetta da TPM per firmare richieste di autenticazione senza verifica utente, ottenendo assertion prive del flag UV (User Verified).
- Silver Pass-ta-key sfrutta una window di re-enrollment attacker-controllabile in cui il servizio cloud non attesta l'origine da hardware sicuro.
- Golden Pass-ta-key estrae dalla memoria di Chrome la Security Domain Secret master key di 32 byte, permettendo accesso persistente ai passkey sincronizzati anche da altri sistemi.
Come Pass-ta-key aggira biometrica e PIN senza rompere la crittografia
Il nucleo della prima tecnica risiede nella gestione implementativa della chiave TPM in Chrome su Windows. Secondo quanto documentato da The Hacker News citando Unit 42, il malware estrae la wrapped device identity key e richiede la firma TPM attraverso le Windows Cryptography Next Generation (CNG) API. Chrome crea a quel punto una chiave TPM senza nome — con un riferimento a TODO nel codice sorgente Chromium issue 398125799 — che sopprime il prompt di verifica utente.
Il risultato è un'assertion di autenticazione priva del flag UV (User Verified), che alcuni servizi non validano correttamente. Unit 42 ha testato la tecnica contro GitHub, che l'ha rifiutata per validazione corretta del flag UV, e contro eBay, che l'ha inizialmente accettata e poi corretta dopo la disclosure. La distinzione tra questi comportamenti evidenzia una frammentazione critica nella postura di sicurezza dei relying party.
"Although Google removed this secret from Chrome's logging output following our report, the SDS is still sent to the client and remains accessible in Chrome's process memory" — Unit 42 (Palo Alto Networks), via BleepingComputer
Silver Pass-ta-key: la finestra di re-enrollment senza attestazione hardware
La seconda tecnica, Silver Pass-ta-key, colpisce il momento di ricostituzione delle chiavi su un nuovo dispositito. Secondo Unit 42, Chrome non crea immediatamente una user-verification key durante il re-enrollment, generando una window controllabile dall'attaccante. In questa fase il servizio cloud non verifica l'attestazione hardware di origine della nuova chiave, consentendo al malware di registrarne una controllata.
Il meccanismo non attacca la crittografia asimmetrica FIDO2 sottostante, ma la sua implementazione nell'ecosistema di sincronizzazione. La mancata verifica dell'origine hardware trasforma un'operazione legittima di recovery in un vettore di compromissione.
Golden Pass-ta-key: la master key di 32 byte esposta in memoria
La terza tecnica è la più invasiva. Golden Pass-ta-key estrae la Security Domain Secret (SDS), una chiave master di 32 byte, dalla memoria del processo Chrome durante operazioni di enrollment e recovery. La SDS è inviata al client durante il re-enrollment e risiede in strutture dati accessibili a processi con privilegi sufficienti sul sistema già compromesso.
Secondo BleepingComputer, che cita Unit 42, l'estrazione della SDS permette di decrittare i passkey privati sincronizzati e mantiene accesso persistente anche a passkey futuri sincronizzati sullo stesso account. Google ha rimosso la SDS dai log FIDO di Chrome dopo la segnalazione, ma la chiave continua a essere trasmessa al client e a risiedere nella memoria di Chrome. BleepingComputer riporta inoltre che l'implementazione corrente di Google non fornisce un meccanismo di rotazione o revoca della SDS, con la conseguenza che passkey presenti e futuri restano protetti dalla medesima secret.
Perché è importante
La ricerca ricolloca il passkey nel suo contesto di minaccia corretto. Come documentato da Google e citato da BleepingComputer, i passkey "non possono essere condivisi, copiati, trascritti o accidentalmente consegnati a terzi", il che li rende più sicuri contro il phishing. Unit 42 non contesta questo punto: le sue tecniche dimostrano invece che il passkey è phishing-resistant ma non malware-resistant, una distinzione operativa decisiva per la postura di sicurezza aziendale.
Il dossier non specifica lo stato completo della remediation per tutti e tre i percorsi di attacco, né se il servizio Google abbia implementato la verifica dell'attestazione hardware durante il re-enrollment. Non è documentato se la modifica del PIN di Google Password Manager o la cancellazione dei dati locali invalidi una SDS precedentemente estratta. Nessuna versione specifica di Chrome è indicata come interessata o corretta.
Non emergono evidenze di sfruttamento attivo in-the-wild al momento della pubblicazione. La specifica Web Authentication, come riportato da The Hacker News, prescrive che un relying party che imponga userVerification su required debba fallire la cerimonia quando il bit UV è assente: la discrepanza tra GitHub ed eBay nel rispettare questo requisito segnala che la mitigazione non è uniforme nell'ecosistema.
Domande e risposte
I passkey sono meno sicuri delle password?
No. La ricerca di Unit 42 afferma esplicitamente il contrario. I passkey mantengono la loro resistenza al phishing, che rimane il vettore di attacco predominante. Le tecniche Pass-ta-key richiedono un compromesso preesistente del dispositito, una condizione che non si applica alla maggior parte degli utenti.
Possono queste tecniche funzionare su disposititi senza TPM?
Il dossier non documenta comportamenti su sistemi privi di TPM. Le tecniche descritte si riferiscono esplicitamente all'implementazione di Google Password Manager in Chrome su Windows con TPM.
Esiste un CVE per queste vulnerabilità?
No. Secondo The Hacker News, al 3 agosto 2026 non risulta alcun CVE assegnato alle tecniche Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key. Il CVE-2026-34348 documentato nel dossier si riferisce a una ricerca separata (Pass-the-Passkey/Grafnetter) su Windows 11 e Entra ID, non alle tecniche di Unit 42.
La ricerca di Unit 42 sposta l'attenzione dalla promessa crittografica del passkey alla sua realizzazione implementativa. Il settore deve ora verificare che i propri servizi validino rigorosamente il flag UV e che gli ecosistemi di sincronizzazione includano attestazione hardware e rotazione delle chiavi master. La crittografia FIDO2 resiste; è la catena di implementazione che mostra anelli deboli.
Fonti
- https://techlomedia.in/2026/08/new-passkey-attack-techniques-could-let-malware-bypass-fingerprint-or-pin-on-windows-pcs-125427/amp/
- https://windowsforum.com/windows-news.4/cve-2026-34348-windows-11-fixes-passkey-data-exposure.440578/
- https://thehackernews.com/2026/08/google-password-manager-attacks-could.html
- https://nvd.nist.gov/vuln/detail/CVE-2026-45585
- https://www.bleepingcomputer.com/news/security/new-pass-ta-key-attacks-let-malware-hijack-google-synced-passkeys/
- https://nvd.nist.gov/vuln
- https://nvd.nist.gov/vuln/search
- https://nvd.nist.gov/vuln/categories
- https://nvd.nist.gov/vuln/data-feeds
- https://nvd.nist.gov/vuln/vendor-comments
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.