Pass-ta-key: le passkey sincronizzate valgono quanto l'endpoint

Il 3 agosto 2026 Unit 42 ha pubblicato Pass the Passkey: A Novel Attack Surface in Passwordless Authentication, terza parte della serie dedicata al cloud authenticator di Google. Contiene tre tecniche funzionanti che permettono a un malware in esecuzione come utente loggato e non privilegiato su una macchina Windows di produrre asserzioni WebAuthn valide per le passkey di quell'utente — senza biometria, senza sblocco del dispositivo, senza diritti di amministratore — e, nel caso peggiore, di portarsi via la chiave master che decifra tutte le passkey sincronizzate su quell'account Google. Nulla di tutto questo rompe la crittografia di WebAuthn. Tutto quanto rompe la frase che quasi ogni programma di sicurezza ha scritto nel documento di rollout dell'MFA: le passkey sono resistenti al phishing, quindi questo controllo è chiuso.

Che cosa fa davvero Pass-ta-key a una passkey sincronizzata

Il modello mentale diffuso — "la mia passkey sta nel TPM, il TPM chiede la mia impronta" — non descrive il funzionamento di Google Password Manager su Chrome per Windows. In gioco ci sono tre segreti separabili:

• Una device identity key, ancorata al TPM, che dimostra al cloud authenticator di Google che quel dispositivo è arruolato.
• Una chiave di user verification (UV), che firma il singolo bit con cui si dichiara al relying party che un essere umano era presente e verificato.
• Il Security Domain Secret (SDS), chiave master da 32 byte che decifra le chiavi private delle passkey custodite nel sync fabric.

Poiché sono separabili, cadono separatamente. La prima tecnica di Unit 42 estrae la chiave privata di identità in forma wrapped e la fa lavorare attraverso normali chiamate Windows CNG — NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash — per firmare challenge scelte dall'attaccante. Il report attribuisce la raggiungibilità al modo in cui Chrome crea la chiave: "Chrome calls the NcryptCreatePersistedKey function without assigning a key name, making the TPM-backed key ephemeral." Il TPM ha fatto il suo mestiere: ha firmato per un processo che glielo ha chiesto, che è esattamente ciò per cui esiste.

Le tre tecniche, ordinate per durata del danno

Tecnica	Che cosa abusa	Che cosa ottiene l'attaccante	Sopravvive al reimaging dell'endpoint?
Pass-ta-key	Device identity key nel TPM via Windows CNG	Asserzioni valide a richiesta, con il bit UV non impostato	No — serve codice su quell'host
Silver Pass-ta-key	La finestra di ri-arruolamento in cui Chrome rinvia la creazione della chiave UV; il cloud authenticator "does not validate the attestation of newly registered UV keys"	Una chiave UV controllata dall'attaccante, quindi login dalla sua macchina	Sì, finché la chiave ostile non viene rimossa
Golden Pass-ta-key	L'SDS, brevemente in chiaro nella memoria di processo di Chrome durante il re-onboarding	La chiave master di tutte le passkey del security domain, decifrabili ovunque	Sì, finché il security domain non viene ri-chiavato

La nomenclatura Golden/Silver è presa in prestito dagli attacchi ai ticket Kerberos ed è meritata: stessa escalation da posso agire come te, qui, finché ho codice sulla tua macchina a possiedo il materiale crittografico che ti conia, ovunque, a tempo indeterminato. Tutte e tre partono dallo stesso punto: malware già in esecuzione come utente loggato, nessuna elevazione richiesta.

Il flag UV è un contratto da un bit, e solo il relying party può farlo rispettare

Un'asserzione Pass-ta-key è indistinguibile bit per bit da una legittima, tranne che per un flag. La specifica W3C WebAuthn Level 3 non lascia margini su chi debba occuparsene: "If the Relying Party requires user verification for this registration, verify that the UV bit of the flags in authData is set."

È un passaggio lato server. E qui sta il punto su cui vale la pena fermarsi: eBay accettava queste asserzioni forgiate pur avendo configurato userVerification: "required", finché Unit 42 non ha segnalato il problema. Impostare userVerification: "required" nelle request options esprime una preferenza al client. Verificare il bit UV nella risposta è il controllo. Moltissime integrazioni WebAuthn fanno la prima cosa e saltano la seconda, perché la ceremony va a buon fine in entrambi i casi e nulla, nel percorso felice, ve lo segnala mai.

Lo stesso identico fallimento era già uscito in un password manager tre anni fa

Il Knowledge RAG di Zero Hunt ha fatto emergere dal corpus pre-2026 un precedente a cui il ciclo di notizie non ci avrebbe portati; entrambe le voci sono state ri-verificate su NVD prima di citarle qui:

• CVE-2023-27706 (pubblicata il 9 giugno 2023, CVSS 7.1): "Bitwarden Windows desktop application versions prior to v2023.4.0 store biometric keys in Windows Credential Manager, accessible to other local unprivileged processes."
• CVE-2023-38840 (pubblicata il 15 agosto 2023, CVSS 5.5): "Bitwarden Desktop 2023.7.0 and below allows an attacker with local access to obtain sensitive information via the Bitwarden.exe process."

Sono le due modalità di fallimento che Unit 42 ha appena ri-dimostrato, con tre anni di anticipo e in un altro credential manager: materiale crittografico parcheggiato in uno store di sistema raggiungibile da qualsiasi processo locale non privilegiato, e un segreto residente nella memoria dell'applicazione stessa. Entrambe hanno ricevuto punteggi contenuti — 7.1 e 5.5 — perché AV:L sconta tutto, e il settore le ha archiviate come richiede accesso locale, quindi fuori perimetro. Poi lo stesso settore ha spostato l'autenticazione passwordless dentro la medesima architettura senza rimettere in discussione l'assunto.

La lezione generalizzabile non riguarda Bitwarden né Google. Riguarda il fatto che "richiede esecuzione di codice locale" è uno sconto di severità, non un'esenzione architetturale: nel momento in cui la vostra storia di autenticazione dipende dall'endpoint pulito, l'endpoint è la vostra storia di autenticazione.

Che cosa aveva promesso davvero l'AAL2 sulle passkey sincronizzate

È qui che si smette di leggere un write-up interessante e si comincia a guardare un problema di compliance.

NIST SP 800-63B-4, finalizzato a luglio 2025, è il documento che ha reso le passkey sincronizzate formalmente accettabili ad AAL2, sbloccando buona parte dell'adozione enterprise. Definisce la categoria al §3.1.6.1 — "Some cryptographic authenticators, referred to as syncable authenticators, can manage their authentication keys using a sync fabric (e.g., a cloud provider)" — e una linea l'aveva già tracciata al §2.3.2: "Since syncable authenticators … require the private key to be exportable, syncable authenticators SHALL NOT be used at AAL3."

La benedizione ad AAL2 è condizionata. L'Appendice B.2 stabilisce che cosa il sync fabric deve garantire:

• "Authentication keys stored in the sync fabric SHALL be protected by access control mechanisms such that only the authenticated user can access their authentication keys in the sync fabric."
• "User access to authentication keys in the sync fabric SHALL be protected by AAL2-equivalent MFA to preserve the integrity of the authentication protocols using the synced keys."
• Le chiavi clonate o esportate SHALL essere conservate solo cifrate e SHOULD esserlo "using a method that employs a user-controlled secret."

Ora rileggetele accanto alle tre tecniche. L'SDS è il segreto controllato dall'utente del terzo requisito — e Golden Pass-ta-key lo legge dalla memoria di processo. Il controllo d'accesso del primo requisito è soddisfatto, dal punto di vista del sync fabric, da un dispositivo regolarmente arruolato — che è precisamente ciò che Pass-ta-key impersona. I requisiti non sono sbagliati: sono condizionati allo stato di un client che i requisiti stessi non hanno modo di ispezionare.

La cosa esce dal perimetro NIST molto in fretta, perché l'articolo 21 della NIS2 indica l'autenticazione a più fattori o continua fra le misure richieste, DORA poggia sulla stessa aspettativa per le entità finanziarie, e l'artefatto che tutti producono per soddisfarle è un report di arruolamento. La pretesa AAL2 che sta sotto quel report dipende dal fatto che l'Appendice B.2 regga su ogni endpoint, ogni giorno. Non abbiamo ancora visto un programma di audit che ponga quella domanda.

Auditor: "Mi dimostri che gli accessi privilegiati usano MFA resistente al phishing." Voi: "Tutte le utenze amministrative sono su passkey. Ecco la policy e il report di copertura degli arruolamenti — 100%." Auditor: "Approvato."

In quello scambio nessuno ha verificato se un'asserzione possa essere prodotta senza l'essere umano. Non era la domanda, perché fino a questa settimana nessuno era obbligato a porla.

La scala non è marginale. Lo State of Passkeys 2026 della FIDO Alliance, pubblicato il 7 maggio 2026, riporta che "5 billion passkeys are now in use worldwide", che "68% of organizations have deployed or are actively deploying passkeys for employee sign-ins" e che il 49% delle persone usa regolarmente le passkey dove disponibili. Questo è il substrato di autenticazione di oggi, non un pilota.

Remediation

1. Sono esposto?

Tre esposizioni distinte, e potete averle in qualunque combinazione:

• Come proprietari di endpoint — host Windows con TPM che eseguono Chrome con le passkey di Google Password Manager attive.
• Come relying party — qualsiasi servizio che gestite e che accetta asserzioni WebAuthn è esposto alla metà "flag UV" della faccenda, indipendentemente dall'authenticator usato dai vostri utenti.
• Come titolari delle identità — utenze aziendali le cui passkey sono sincronizzate anziché device-bound.

Individuate lo stato dell'enclave passkey che le tecniche di Unit 42 manipolano:

where /r "%LOCALAPPDATA%\Google\Chrome\User Data" passkey_enclave_state*

Poi verificate il lato relying party, che è l'esposizione interamente sotto il vostro controllo. Il byte dei flag si trova all'offset 32 di authenticatorData; UV è il bit 2:

UV = 0x04
if not (authenticator_data[32] & UV):
    raise AuthnError("flag UV assente — rifiutare l'asserzione")

Cercate userVerification nel vostro codice e verificate che ogni punto in cui viene impostato "required" sulla richiesta abbia il controllo corrispondente sul flag nella risposta. Se l'integrazione si limita alla request option, avete lo stesso bug che aveva eBay.

2. Patch — versioni corrette esatte

Non ce ne sono, e questa è la risposta onesta, non una lacuna di questo articolo. Il report di Unit 42 non porta identificativi CVE, non indica una versione di Chrome corretta e descrive un comportamento di progetto, non un difetto di memory safety. Ciò che è effettivamente cambiato:

Modifica	Da parte di	Stato al 3 agosto 2026
SDS rimosso dall'output di logging FIDO di Chrome	Google, dopo la segnalazione	Fatto — ma l'SDS continua ad arrivare nella memoria di processo di Chrome durante l'onboarding
Validazione del flag UV sulle asserzioni in ingresso	eBay, dopo la segnalazione	Fatto
Validazione dell'attestation sulle nuove chiavi UV registrate	—	Non affrontato
SDS non più inviato al client	—	Non affrontato

Trattatela come un'esposizione di progetto con finestra aperta a tempo indeterminato, non come un ciclo di patching. I controlli che possedete stanno lato relying party e nella scelta dell'authenticator.

3. Non potete correggere la piattaforma? Controlli compensativi

• Imponete UV lato server, ovunque. Non la request option: il flag nella risposta. Questo singolo controllo neutralizza la prima tecnica contro i vostri servizi.
• Richiedete l'attestation sulle chiavi di nuova registrazione. È ciò che chiude Silver Pass-ta-key: una chiave UV che compare senza attestation accettabile non è un ri-arruolamento, è un'iniezione.
• Portate il Tier-0 su authenticator device-bound. NIST vi ha già detto che le chiavi sincronizzate non arrivano ad AAL3. Domain admin, utenze break-glass, amministrazione dell'IdP, root cloud: security key hardware o passkey vincolate alla piattaforma, non sincronizzate. È il controllo con il rapporto valore/sforzo più alto della lista e non richiede che nessun fornitore rilasci nulla.
• Non contate su signCount. Gli authenticator sincronizzati riportano un contatore di firma costante, quindi il classico rilevatore di clonazione qui non scatta. Scrivetelo esplicitamente nel runbook, invece di lasciare che qualcuno creda di avere un allarme che non ha.
• Trattate il re-onboarding come evento di sicurezza. Sia Silver sia Golden richiedono di forzare un ri-arruolamento. Un prompt inatteso del PIN di recupero, o una ri-registrazione del dispositivo nel mezzo di un login ordinario, è l'osservabile visibile all'utente: spiegate al service desk che cosa significa.
• Step-up sulla conseguenza, non sul login. Un'asserzione passkey è un segnale su un dispositivo. Le azioni ad alto impatto — rilascio di pagamenti, assegnazione di privilegi, export massivi — devono richiedere un fattore ancorato dove il malware sull'endpoint non arriva.
• Policy del browser: verificate, non date per scontato. Alla data di pubblicazione non siamo riusciti a identificare una policy Chrome Enterprise circoscritta specificamente all'enclave delle passkey; PasswordManagerEnabled e SyncTypesListDisabled governano il salvataggio delle password e i tipi di dato sincronizzati. Controllate l'elenco policy aggiornato prima di scrivere un controllo dentro uno standard.

4. Caccia alla compromissione

Segnale	Dove guardare	ATT&CK
Processo diverso da Chrome che apre i file credenziali in User Data	Telemetria di accesso ai file / Sysmon	T1555.003
Cancellazione di passkey_enclave_state	Telemetria di cancellazione file	T1556
Handle su chrome.exe con PROCESS_VM_READ da immagine non firmata Google	Sysmon Event ID 10	T1555
ncrypt.dll caricata, più chiamate di firma CNG, in un processo senza ruolo crittografico	Sysmon Event ID 7 + telemetria API	T1552.004
Nuovo dispositivo arruolato nel security domain Google	Audit log amministrativo di Google Workspace	T1556
Asserzione accettata con UV assente dove la policy richiede verifica	Log di autenticazione del relying party	T1606
Asserzione valida da ASN inconsueto, con signCount costante	Log di autenticazione del relying party	T1550

Partite dalla regola SigmaHQ Access To Browser Credential Files By Uncommon Applications (id 91cb43db-302a-47e3-b3c8-7ede481e27bf, tag attack.t1003, richiede il provider ETW Microsoft-Windows-Kernel-File). Poi leggete che cosa copre davvero: \User Data\Default\Login Data e \User Data\Local State. Non copre lo stato dell'enclave passkey. Aggiungetelo. La caccia standard al furto di credenziali dal browser, quella che quasi ogni SOC già esegue, non vedrà questa classe di attività — ed è esattamente il tipo di lacuna che su una dashboard si legge come copertura.

Sulla finestra di look-back: Unit 42 ha pubblicato il 3 agosto 2026, ma le tecniche colpiscono comportamenti di progetto esistenti da quando esiste l'enclave. Dimensionate la caccia sullo storico dei vostri incidenti da infostealer, non su questa settimana. Ogni stealer commodity che ha girato su un host con passkey sincronizzate si trovava accanto a tutto questo.

5. Bonifica e verifica

L'ordine conta, e sbagliarlo manda sprecata la rotazione:

1. Contenete l'endpoint prima di toccare l'account. Ruotare mentre il malware è vivo significa semplicemente consegnargli il materiale sostitutivo.
2. Date per bruciato l'intero insieme sincronizzato, non solo la passkey che avete visto usare. Se Golden rientra nello scenario, l'SDS decifra ogni passkey di quel security domain.
3. Ri-chiavate il security domain, non limitatevi a ri-registrare una passkey. Cancellare una credenziale presso un relying party lascia la chiave master valida per tutti gli altri. Rimuovete il dispositivo dall'account Google, cambiate la password dell'account, chiudete tutte le sessioni, resettate il PIN di recupero, poi ri-registrate presso ciascun relying party.
4. Ruotate tutto il resto che quell'endpoint deteneva. Lo stesso malware aveva i cookie di sessione, i refresh token OAuth e gli artefatti SSO. Una rotazione delle passkey che lascia in piedi le sessioni vive è teatro — è la stessa lezione delle machine key SharePoint sottratte, dove il materiale crittografico è sopravvissuto alla patch.
5. Ricostruite l'host. Un impianto di furto credenziali arrivato a CNG e alla memoria di un altro processo non è qualcosa che si rimuove in modo selettivo.
6. Verificate lato relying party, non lato endpoint. Rigiocate un'asserzione con UV assente contro il vostro servizio in un ambiente di test e confermate che venga rifiutata. È l'unica prova che il controllo esista. Il report di arruolamento è la prova che è stato acquistato.

Un orologio da tenere d'occhio: sotto NIS2 e GDPR la finestra di notifica decorre dalla consapevolezza, non dalla conferma. Se passkey sincronizzate che coprono identità aziendali sono state esposte su un host compromesso, la qualità delle evidenze di caccia è essa stessa il deliverable — la stessa dinamica che ha reso così difficile perimetrare a posteriori il materiale di firma dei token forgiato a livello ADFS.

Dove si colloca Zero Hunt

La lacuna che questa ricerca mette in luce non è un prodotto mancante: è che "MFA resistente al phishing implementata" è un'affermazione, e quasi nessuno produce evidenze che quell'affermazione regga ancora. Zero Hunt mappa in continuo ogni finding, scansione e remediation su 32 framework — NIS2 incluso il Titolo 13, DORA incluso l'RTS TLPT 2025, ISO 27001, SOC 2, NIST CSF — con scoring pesato per severità e mappatura incrociata dei controlli, così che un singolo controllo di autenticazione testato ricada su tutti i framework che lo richiedono invece di essere ri-evidenziato in tre esercizi di audit separati. I finding sono firmati ECDSA al momento della scrittura, con catena di custodia per costruzione, e il Trust Center esporta il pacchetto che un auditor o un assicuratore accetteranno davvero. È la differenza di cui parla questo articolo: un report di arruolamento dice che un controllo è stato implementato, un finding firmato dice che è stato testato — in una data, su un host, con un esito.

Produrre quelle evidenze richiede qualcosa che percorra la catena, non che ci ragioni sopra. Lo swarm a 10 agenti di Zero Hunt — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic e Report sotto un AI Controller — è organizzato esattamente sulla sequenza che Unit 42 descrive: codice su un host, poi materiale credenziale, poi identità, poi movimento. Gli agenti Credential e Post-Exploit lavorano la domanda che l'audit non pone mai — data l'esecuzione a livello utente su questo endpoint, quale materiale di identità è raggiungibile e a che cosa autentica — e gli exploit vengono generati per singolo target da un LLM locale anziché prelevati da un database pubblico, con ogni nuova skill sottoposta a backtest nell'AI Gym prima di toccare una campagna di produzione. L'intera appliance gira on-prem in container effimeri senza callback cloud, il che pesa più del solito quando gli asset sotto test sono i sistemi di identità stessi. Se volete vederlo all'opera sul vostro perimetro di autenticazione, parliamone.