Pass-ta-key: l’attacco che copia le passkey di Google

Un attacco alle passkey sincronizzate di Google, documentato dai ricercatori di Unit 42, dimostra che su un computer già infetto le chiavi private possono essere copiate e riutilizzate altrove. La crittografia di WebAuthn resta intatta, mentre cede l’infrastruttura che tiene sincronizzate quelle chiavi.

1. Che cos’è l’attacco alle passkey Pass-ta-key
2. Perché il protocollo WebAuthn resta intatto
3. La parte che non si può revocare
4. Come difendersi dall’attacco alle passkey

La documentazione di Google sugli account contiene una frase che spiega da sola il successo delle passkey: non possono essere condivise, copiate, scritte su un foglio oppure consegnate per errore a qualcun altro. È la promessa che ha reso questo metodo il sostituto naturale delle password, tanto nei consigli delle autorità quanto negli articoli di chi si occupa di sicurezza, compresi i nostri.

Il 3 agosto 2026 Unit 42, la divisione di ricerca di Palo Alto Networks, ha pubblicato uno studio firmato da Arie Olshtein con il titolo “Pass the Passkey: A Novel Attack Surface in Passwordless Authentication“. Il documento descrive tre tecniche che permettono a un malware già presente su un computer Windows di accedere ad account protetti da passkey, senza impronta digitale, senza PIN e senza alcuna richiesta che compaia sullo schermo della vittima.

Ma come sempre, andiamo con ordine e affrontiamo per gradi l’argomento.

Che cos’è l’attacco alle passkey Pass-ta-key

L’attacco alle passkey battezzato Pass-ta-key raccoglie tre tecniche distinte che colpiscono il cloud authenticator di Google Password Manager dentro Chrome, sui computer Windows dotati di TPM. Il nome delle varianti richiama i vecchi attacchi ai ticket Kerberos, quindi Silver e Golden indicano una gravità crescente.

Tutte e tre partono dallo stesso presupposto, ossia un malware già in esecuzione con i normali privilegi dell’utente collegato. Non servono diritti di amministratore. La ricognizione iniziale è banale, poiché Chrome conserva i metadati delle passkey sincronizzate in un database LevelDB dentro la cartella del profilo, leggibile senza alcun privilegio speciale. Da lì l’attaccante ricava quali servizi la vittima protegge con una passkey e con quali nomi utente.

• Pass-ta-key. Chrome mantiene in hardware la chiave di identità del dispositivo, poi la esporta come blob cifrato dentro un file locale chiamato passkey_enclave_state. Il malware legge quel blob e lo rigioca attraverso le normali interfacce crittografiche di Windows, ottenendo un’asserzione di autenticazione valida senza che nulla compaia sullo schermo. Questa prima variante resta bloccata quando il sito richiede la verifica dell’utente e controlla il flag corrispondente nella risposta.
• Silver Pass-ta-key. Il malware invalida la chiave di verifica esistente oppure cancella il file locale che tiene traccia della registrazione, così da forzare una nuova iscrizione del dispositivo. Nella finestra in cui Chrome non ha ancora generato la chiave sostitutiva, l’attaccante registra la propria. Il cloud authenticator non verifica se quella chiave provenga da hardware autentico, quindi le asserzioni firmate con essa portano il flag di verifica utente. Da quel momento l’accesso funziona anche dal computer dell’attaccante, senza più bisogno della macchina della vittima.
• Golden Pass-ta-key. La ri-iscrizione forzata è la stessa, con un passaggio ulteriore. Il malware attende la ricreazione del file di stato, scarica la memoria del processo Chrome ed estrae i 32 byte del Security Domain Secret, la chiave simmetrica che decifra le chiavi private di ogni passkey sincronizzata sull’account. Il segreto arriva dal Google Trusted Vault durante il flusso di recupero e in quel momento transita in chiaro nelle strutture dati del client.

Perché il protocollo WebAuthn resta intatto

Nessuna delle tecniche che compongono questo attacco alle passkey rompe la crittografia a chiave pubblica su cui poggia WebAuthn, lo standard del W3C che definisce l’autenticazione senza password.

La distinzione che conta riguarda il tipo di passkey. Quelle legate all’hardware di un singolo apparecchio, come le chiavi di sicurezza fisiche, restano fuori dal perimetro di questa ricerca, poiché la chiave privata non entra mai nel sistema di sincronizzazione né nella memoria del browser. Quelle sincronizzate su un account cloud scambiano quella garanzia con la comodità di ritrovarsi su tutti i dispositivi. Unit 42 precisa comunque di non aver provato ogni configurazione esistente, quindi una chiave hardware vale come mitigazione forte e non come immunità dimostrata.

La promessa di Google sulle passkey che non si possono copiare regge contro il phishing e contro il riutilizzo delle credenziali. Resta scoperta l’ipotesi che una passkey protegga un account quando il computer che la ospita è già sotto il controllo di qualcun altro.

Nella stessa settimana sono uscite altre due ricerche indipendenti sullo stesso terreno, una di SpecterOps sulle interfacce WebAuthn di Windows e una di Dirk-jan Mollema su Windows Hello for Business, con un CVE Microsoft associato e un aggiornamento già distribuito. Sono lavori distinti, quindi conviene tenerli separati invece di leggerli come un unico problema.

La parte che non si può revocare

Le prime due tecniche hanno un rimedio. Secondo Unit 42 la variante Silver si neutralizza cancellando la registrazione del dispositivo oppure ripetendola da zero. La terza si comporta in modo diverso.

Il Security Domain Secret, nella progettazione attuale, non prevede alcun meccanismo di rotazione o di revoca. Creare una nuova passkey sincronizzata potrebbe quindi non chiudere una compromissione già avvenuta, poiché la stessa chiave continua a decifrare quello che verrà dopo. È una persistenza che sopravvive alla rimozione del malware, quindi il profilo di rischio cambia rispetto al furto di una singola credenziale.

Si aggiunge un secondo problema, meno vistoso. Il contatore di firma previsto da WebAuthn serve a rilevare l’uso di una credenziale clonata. Nelle implementazioni sincronizzate quel contatore restituisce di norma un valore costante, quindi i siti perdono la capacità di accorgersi che la stessa passkey sta lavorando da due posti diversi.

Unit 42 ha aperto tre segnalazioni sul tracker di Chromium. Google ha chiuso quella sul segreto esposto in chiaro nei log FIDO del browser, mentre le altre due restano aperte e riguardano proprio la mancata validazione delle nuove chiavi di verifica e l’assenza del controllo sul contatore. Il segreto continua ad arrivare al processo Chrome durante il recupero e a restare in memoria.

Alla data di pubblicazione di questo articolo non esiste alcun CVE assegnato a queste tre tecniche e nessuno sfruttamento attivo è stato osservato.

Come difendersi dall’attacco alle passkey

La risposta a questo attacco alle passkey non passa dall’abbandono del metodo. Unit 42 stessa indica cinque direzioni di intervento, che si traducono in queste misure per un’azienda.

• Chiavi hardware per i profili più esposti. Per amministratori di sistema, dirigenza e funzioni finance una chiave di sicurezza fisica che non sincronizza la propria chiave privata resta fuori dal perimetro descritto dalla ricerca.
• Verifica reale del flag lato applicazione. Chi sviluppa servizi deve impostare la richiesta di verifica utente come obbligatoria e poi controllare davvero il flag restituito in ogni risposta di autenticazione. Una configurazione che pretende la verifica senza controllarne l’esito non aggiunge nulla.
• Un’infezione da infostealer va trattata come reset totale delle credenziali. Le passkey adesso rientrano in quel conteggio. La macchina si ricostruisce, poi le passkey si registrano di nuovo partendo da un dispositivo pulito.
• Controllo periodico dei dispositivi collegati. La pagina di Google che elenca gli apparecchi con accesso all’account va rivista con regolarità, chiudendo le sessioni che nessuno riconosce.
• Smettere di leggere l’assenza del prompt come una garanzia. Il senso di questa ricerca sta proprio nella comparsa di un’asserzione valida senza che alcuna richiesta raggiunga lo schermo dell’utente.

Una cosa che non conviene fare è cancellare le proprie passkey. Restano più sicure delle password e dei codici via SMS, poiché nessun segreto condiviso viaggia verso il sito. Il presupposto di tutte e tre le tecniche resta un endpoint compromesso, quindi la protezione dei computer aziendali e il passaggio al passwordless sono lo stesso progetto.

In conclusione

La ricerca di Unit 42 non porta argomenti per tornare alle password. Il phishing resta inefficace contro una passkey e nessuna credenziale riutilizzata può essere ritentata altrove. Quello che questo attacco alle passkey ridimensiona è una promessa più specifica, ossia l’idea che la chiave privata resti sempre e comunque sul dispositivo dell’utente.

Per le passkey sincronizzate quella garanzia dipende dallo stato del computer che le ospita. Su una macchina infetta condividono la sorte di tutto il resto. Il caso Golden aggiunge poi una persistenza che sopravvive alla bonifica. Chi ha già letto il nostro pezzo sull’MFA bombing ritrova qui lo stesso schema, dove la tecnologia funziona come previsto mentre l’attacco passa dal contesto in cui la si usa.