Passkey bypass: tre attacchi demoliscono l'autenticazione…

Tre ricerche indipendenti dimostrano come malware su endpoint Windows aggirino passkey e MFA. Il problema non è la crittografia, ma l'infrastruttura circostante.

Tre ricerche indipendenti pubblicate nell'agosto 2026 hanno dimostrato catene di attacco post-compromise che aggirano l'autenticazione phishing-resistant basata su passkey. SpecterOps, Unit 42 di Palo Alto Networks e il ricercatore Dirk-jan Mollema hanno ciascuno individuato un vettore diverso: il replay di asserzioni WebAuthn esposte dal logging di Windows, il recupero della master key di sincronizzazione di Google Password Manager, e l'abuso di Windows Hello for Business senza richiesta di PIN o biometrico. Tutti e tre gli attacchi richiedono malware già presente sull'endpoint e non necessitano di privilege escalation.

Il nucleo comune è architetturale: nessuno rompe la crittografia FIDO2/WebAuthn, ma tutti sfruttano il presupposto che il dispositivo endpoint sia trusted. Quando questo presupposto fallisce, la catena di fiducia tra utente, dispositivo e cloud collassa.

Punti chiave

CVE-2026-34348, con CVSS 6.5, espone asserzioni WebAuthn firmate in cleartext nel Windows Event Logging Service; Microsoft ha rilasciato patch e mitigazioni
Unit 42 ha isolato la "Golden Pass-ta-key", una master key di 32 byte che protegge le passkey syncate di Google, temporaneamente presente in plaintext nella memoria processo di Chrome
Dirk-jan Mollema ha dimostrato che una challenge WebAuthn di Entra ID valida 5 minuti e non legata a sessione, utente o tenant permette relay e ottenimento di Primary Refresh Token
Tutti e tre gli attacchi operano da processi a basso privilegio su sessioni già compromesse: la distinzione tra passkey "device-bound" e "synced" non protegge da endpoint infetti

Il logging di Windows che parla troppo: CVE-2026-34348

SpecterOps ha dimostrato una catena Windows-to-Entra ID che permette l'impersonazione di utenti privilegiati superando MFA phishing-resistant. Il punto di ingresso è il Windows Event Logging Service, che memorizza in cleartext le firme YubiKey precedenti. Utenti autenticati con privilegi standard, inclusi utenti remoti, possono leggere queste asserzioni.

La vulnerabilità è tracciata come CVE-2026-34348. Secondo il record NVD, il CVSS 3.1 è 6.5 (MEDIUM) con vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N e classificazione CWE-693 Protection Mechanism Failure. Microsoft ha rilasciato aggiornamenti di sicurezza per le edizioni Windows 10, Windows 11 e Server coperte dal CVE.

SpecterOps valuta la catena completa come "rotta" dopo le mitigazioni applicate da Microsoft negli aggiornamenti di luglio 2026. Tuttavia, la ricerca non stabilisce se la catena funzioni identicamente su tutte le release Windows elencate nel CVE. Un portavoce Microsoft, citato da The Hacker News, ha dichiarato: "We appreciate the work of SpecterOps for reporting this through a coordinated vulnerability disclosure. We have applied mitigations for the reported issue involving passkey relay assertions and continue investing in security enhancements across authentication methods."

La chiave d'oro nel browser: quando la sincronizzazione diventa rischio

Unit 42 ha identificato tre varianti di attacco contro Google Password Manager in Chrome su Windows: Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key. La terza è la più grave. Golden Pass-ta-key targets la Security Domain Secret (SDS), una master key di 32 byte che protegge le passkey sincronizzate tra dispositivi.

Secondo Unit 42, la SDS è temporaneamente presente in plaintext nella memoria processo di Chrome durante la re-registrazione. Con questa chiave, un attaccante può recuperare le chiavi private syncate della vittima. Il problema è strutturale: Unit 42 afferma esplicitamente che l'implementazione Google non fornisce alcun modo per ruotare o revocare la SDS.

Google ha rimosso la SDS dai log di Chrome, ma la chiave rimane esposta in memoria processo. Non è chiaro se tutti e tre i percorsi Unit 42 siano stati completamente chiusi. Unit 42 ha sviluppato e validato le dimostrazioni su Chrome 142.

La ricerca ha spinto eBay a correggere la validazione del flag UV (User Verification) dopo la disclosure; GitHub già enforceava il check. Il numero di relying parties vulnerabili oltre eBay non è stato fornito.

"No CVE was assigned. Google rarely assigns CVEs to issues that require the device to already be compromised by malware." — Arie Olshtein, senior staff security researcher at Palo Alto Networks

Windows Hello for Business: il ticketing che bypassa l'utente

Dirk-jan Mollema ha dimostrato che un processo a basso privilegio in una sessione Windows già compromessa può usare la chiave Windows Hello for Business tramite interfacce crittografiche Windows senza produrre un nuovo PIN o prompt biometrico. La tecnica è conseguenza del funzionamento di Windows Hello for Business, non una vulnerabilità con CVE assegnato.

Mollema ha inoltre trovato che la challenge WebAuthn di Entra ID è valida per 5 minuti e non è legata a sessione, utente o tenant. Questo permette il relay della challenge. Il token risultante può mancare del device ID claim, aprendo la strada alla registrazione di un nuovo device e all'ottenimento di un Primary Refresh Token con durata documentata di 90 giorni.

Non è noto se Microsoft riconoscerà o abbia riconosciuto questa tecnica come vulnerabilità meritante un CVE. SpecterOps non ha sentito della propria ricerca essere utilizzata al di fuori di ambienti di test.

Cosa fare adesso

Le organizzazioni che hanno adottato passkey come autenticazione phishing-resistant devono rivalutare i controlli endpoint. Il compromesso di una macchina Windows con malware standard-user può ora portare a bypass completo dell'MFA, recupero persistente di credenziali syncate, o impersonazione cloud.

Patchare CVE-2026-34348 attraverso gli aggiornamenti di sicurezza Microsoft e verificare l'applicazione delle mitigazioni per passkey relay assertions
I relying party devono validare rigorosamente il flag UV nelle asserzioni WebAuthn, come già enforceato da GitHub e corretto da eBay dopo disclosure
Monitorare le registrazioni device anomale in Entra ID, in particolare token che mancano del device ID claim o che presentano pattern di timing compatibili con relay di challenge a 5 minuti
Preferire passkey hardware-backed per account privilegiati, riducendo la dipendenza da meccanismi di sincronizzazione cloud che centralizzano la fiducia in un singolo punto

Il loop architetturale che l'industria non ha chiuso

L'industria sta replicando con passkey gli stessi errori che hanno reso i password manager un target appetibile: la centralizzazione della fiducia in un singolo punto. Browser, sistema operativo e cloud diventano anelli congiunti di una catena che, se compromesso uno, crolla tutto.

La distinzione tra passkey "device-bound" e "synced" non è più sufficiente a garantire sicurezza se l'infrastruttura circostante è fragile: il logging del sistema operativo, la gestione della memoria del browser, la validazione delle challenge cloud. L'autenticazione phishing-resistant prometteva di spostare il rischio dall'utente al dispositivo, ma il dispositivo rimane attaccabile con tecniche standard.

Ars Technica, citato in aggregazione, ha sintetizzato: "The attacks demonstrated in the post are neither novel nor unique to passkeys." Il punto non è la novità, ma la scala: passkey sta diventando default, e i difetti di infrastruttura si moltiplicano con l'adozione.

Domande frequenti

La crittografia FIDO2/WebAuthn è stata rotta?

No. Nessuna fonte sostiene la rottura della crittografia. Gli attacchi mirano all'infrastruttura di supporto: logging del sistema operativo, memoria processo browser, validazione challenge cloud.

Perché Google non ha assegnato un CVE per Pass-ta-key?

Secondo Arie Olshtein di Palo Alto Networks, Google assegna raramente CVE a issue che richiedono compromissione preesistente del dispositivo da malware. Questo non diminuisce l'impatto per endpoint enterprise già infetti.

Le tecniche di Mollema sono patchabili?

Il dossier non specifica misure correttive da parte di Microsoft per la tecnica Windows Hello for Business. Microsoft ha applicato mitigazioni specifiche per la catena SpecterOps/CVE-2026-34348, ma non è chiaro se riconoscerà la ricerca Mollema come vulnerabilità.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti