Pass-the-Passkey: attacchi alle passkey e difese

Le passkey rappresentano uno dei passaggi più importanti verso un’autenticazione realmente passwordless e resistente al phishing. La ricerca “Pass-the-Passkey Family of Attacks”, presentata da Michael Grafnetter di SpecterOps a Black Hat USA 2026, dimostra però un punto essenziale: una credenziale crittograficamente robusta non rende automaticamente sicuro l’intero processo di autenticazione. Il rischio può spostarsi dalla password alle componenti che circondano WebAuthn: applicazione, browser, sistema operativo, logging, sessione, endpoint e gestione dell’identità.

Il risultato non è che “le passkey sono rotte”. Al contrario, lo stesso whitepaper considera le passkey un miglioramento significativo rispetto alle password. La lezione e più precisa: per ottenere il beneficio atteso da FIDO2 e WebAuthn bisogna proteggere l’intera catena di fiducia, applicare le patch e verificare che relying party, endpoint e processi di identity security implementino correttamente i controlli anti-replay, anti-phishing e anti-tampering.

In ambito Microsoft questo tema riguarda direttamente Windows 11, Windows Hello, chiavi FIDO2 e Microsoft Entra ID, quindi anche le architetture che applicano Identity Security e MFA come controllo di accesso per utenti, amministratori e applicazioni critiche.

Cosa significa Pass-the-Passkey

Il nome richiama volutamente tecniche storiche come Pass-the-Hash. Nel modello WebAuthn la chiave privata della passkey resta nell’autenticatore: TPM/Windows Hello, security key FIDO2 o altro autenticatore compatibile. Il servizio non riceve la chiave privata, ma una assertion firmata costruita per uno specifico contesto di autenticazione.

WebAuthn protegge il flusso principalmente attraverso due proprietà:

• Origin binding: l’assertion è legata all’origine reale della relying party, riducendo il phishing classico basato su domini contraffatti.
• Challenge freshness: ogni autenticazione dovrebbe usare una challenge nuova e monouso, verificata dal server e correttamente associata alla sessione.
• User presence e user verification: l’autenticatore può attestare che l’utente era presente e, quando richiesto, che ha eseguito PIN, biometria o altro meccanismo di verifica.
• Signature counter e metadati dell’autenticatore: quando disponibili e correttamente gestiti, possono contribuire a individuare anomalie o copie di credenziali device-bound.

Il problema emerge quando uno dei livelli attorno alla chiave privata non rispetta queste assunzioni. Il whitepaper mappa una superficie di attacco che va dalla relying party al browser, dal sistema operativo ai password manager, fino agli autenticatori e ai relativi trasporti. In altre parole: la robustezza della firma non compensa una verifica server-side incompleta, un endpoint compromesso o un’interfaccia di autenticazione abusabile.

La vulnerabilità Windows: assertion WebAuthn esposte nei log

Uno dei risultati più rilevanti della ricerca riguarda il logging di Windows. Secondo il paper, Windows registrava nel canale Microsoft-Windows-WebAuthN/Operational assertion WebAuthn complete, includendo materiale sufficiente a tentare un replay contro servizi che non applicavano correttamente le protezioni server-side.

La distinzione tecnica e fondamentale: non veniva estratta o “rubata” la chiave privata della passkey. La chiave privata continuava a rimanere protetta nell’autenticatore. Il rischio derivava dalla disponibilita dell’assertion già firmata, cioe del risultato di una cerimonia WebAuthn valida, combinata con una relying party incapace di riconoscere il riutilizzo.

Microsoft ha associato pubblicamente questo problema a CVE-2026-34348. Il 14 luglio 2026 sono stati rilasciati aggiornamenti di sicurezza. Nel whitepaper viene indicato che sui sistemi completamente aggiornati i campi di firma registrati nel log vengono troncati a 6 byte, rendendo l’assertion inutilizzabile per il replay pur mantenendo informazioni utili al troubleshooting. La scheda NVD riporta per la CVE un punteggio CVSS 3.1 Microsoft di 6,5 (Medium).

Implicazione operativa: la patch di Windows non è un miglioramento opzionale del client; rimuove una sorgente di materiale di autenticazione che, in presenza di altri difetti, poteva diventare un ponte tra compromissione dell’endpoint e compromissione dell’identità cloud.

Il secondo anello: replay delle assertion e Microsoft Entra ID

Il replay diventa realmente utile solo se il servizio destinatario accetta una assertion già utilizzata o insufficientemente legata al contesto originale. Nella ricerca SpecterOps le condizioni critiche sono tre: mancato controllo del riuso della challenge, challenge non associata alla sessione dell’utente e mancata gestione efficace dei signature counter.

Il whitepaper descrive una vulnerabilità Entra ID tracciata internamente da MSRC come VULN-171325, classificata dai ricercatori con CVSS 3.1 pari a 7,8 (High). La timeline della ricerca indica una correzione parziale nel maggio 2026 per chiavi FIDO2 e Windows Hello basato su VBS. Poiché il documento stesso avverte che Microsoft può aver distribuito ulteriori mitigazioni dopo i test, questa informazione va letta come fotografia della versione 1.0 del paper, non come affermazione sullo stato corrente di ogni flusso Entra ID.

Per un’organizzazione il punto non e inseguire il singolo exploit, ma verificare che la strategià “phishing-resistant MFA” non sia l’unico controllo posto a protezione degli account ad alto valore. Conditional Access, device trust, gestione dei privilegi, session controls, application control e telemetria endpoint rimangono livelli indipendenti e necessari.

Le principali famiglie di attacco individuate dalla ricerca

Il paper descrive più di venti tecniche. Per una lettura difensiva, possono essere aggregate in sei famiglie:

1. Assertion capture, mining, replay e relay - L’attaccante tenta di ottenere una assertion valida da log, memoria o intercettazione del flusso e di riutilizzarla o inoltrarla. Il successo dipende soprattutto dalla qualità dei controlli server-side e dalla protezione dell’endpoint.
2. Malware-initiated passkey phishing - Un malware già in esecuzione sul PC può invocare le API WebAuthn di Windows e generare un prompt di autenticazione. La chiave privata non viene esportata: è l’utente che, approvando una richiesta non iniziata consapevolmente, può produrre una assertion utilizzabile dall’attaccante.
3. Prompt flooding e spoofing dell’interfaccia - Ripetizione di prompt, overlay e manipolazione di metadati possono ridurre la capacità dell’utente di distinguere una richiesta legittima da una richiesta generata da software malevolo.
4. Hooking e detour del percorso WebAuthn - Codice presente sul client può tentare di intercettare le chiamate alle API WebAuthn nel browser o nel sistema operativo, osservando o alterando challenge e response senza dover attaccare direttamente il secure element.
5. Rischi di synced passkey e software authenticator - Quando una passkey è sincronizzata attraverso un password manager o un account cloud, parte del modello di fiducia si sposta verso il vault, il processo di recovery e la sicurezza del dispositivo/account che gestisce la sincronizzazione.
6. Tampering e user-verification bypass lato relying party - Un’applicazione che non valida correttamente challenge, origin, flags UP/UV, contatori o firma può trasformare un flusso crittograficamente solido in una autenticazione accettata con garanzie inferiori a quelle attese.

Passkey phishing: perché “phishing-resistant” non significa “impossibile da abusare”

La proprietà phishing-resistant di WebAuthn rimane valida contro il phishing web tradizionale: un sito contraffatto non può normalmente ottenere una assertion valida per il dominio legittimo, perché l’origine entra nel materiale verificato crittograficamente.

La ricerca sposta però l’attaccante sul client. Se un malware e già presente sulla workstation, può tentare di utilizzare il percorso WebAuthn locale per indurre l’utente ad approvare una richiesta. Questo scenario non dimostra una debolezza della crittografia FIDO2: dimostra che l’endpoint e l’interfaccia utente diventano parte del perimetro di autenticazione.

Per questo la formazione dell’utente deve cambiare: con le passkey non basta insegnare a non digitare la password su un sito sospetto. Un prompt passkey inatteso, comparso senza un’azione volontaria di login, deve essere considerato un evento da rifiutare e investigare.

La stessa logica giustifica l’integrazione fra identità ed endpoint: Endpoint Protection, application control e telemetria EDR/XDR diventano complementari alla MFA resistente al phishing.

Device-bound o synced passkey: cosa cambia per gli account privilegiàti

Il whitepaper distingue chiaramente il profilo di rischio delle passkey legate a un dispositivo da quello delle passkey sincronizzate. Le synced passkey aumentano usabilita e recuperabilità, ma introducono nel trust model il provider di sincronizzazione, il vault e i relativi processi di account recovery.

Per gli account ad alto valore la raccomandazione dei ricercatori è esplicita: preferire passkey device-bound e applicare attestation per consentire solo autenticatori genuini e approvati. In un ambiente Microsoft questo approccio va integrato con ruoli privilegiàti separati, dispositivi amministrativi gestiti e policy Conditional Access dedicate.

Per l’architettura passwordless e la relazione tra FIDO2, Windows Hello for Business ed Entra ID, il riferimento interno da mantenere separato da questo articolo e FIDO2 e Cloud Kerberos Trust: accesso passwordless. Questo articolo resta focalizzato sul threat model e sulle misure di difesa.

Tabella: attacchi, prerequisiti e controlli difensivi

Cosa deve fare un’azienda: checklist di hardening

Le indicazioni del whitepaper, tradotte in controlli operativi, portano a questa priorità:

1. Aggiornare Windows e verificare la copertura delle patch. CVE-2026-34348 è stata corretta attraverso gli aggiornamenti Microsoft del 14 luglio 2026. Gli endpoint che usano passkey devono essere inclusi nel processo di patch compliance, con evidenza delle build effettivamente protette.
2. Non usare la sola “phishing-resistant MFA” come barriera per identità critiche. Per amministratori e applicazioni sensibili servono controlli indipendenti: device compliance, accesso da workstation gestite, ruoli JIT/PIM dove applicabile, restrizioni di sessione e separazione degli account amministrativi.
3. Preferire passkey device-bound e attestation per gli utenti ad alto valore. Security key approvate o autenticatori gestiti riducono la dipendenza da vault sincronizzati e recovery consumer. L’attestation consente di limitare quali autenticatori sono accettabili.
4. Bloccare applicazioni e browser extension non autorizzate. Una parte significativa delle tecniche richiede codice già presente sul client. Application control, privilegi minimi e governance delle estensioni riducono la superficie da cui invocare o intercettare WebAuthn.
5. Portare WebAuthn nel perimetro del penetration test. Una implementazione deve validare challenge, session binding, origin/RP ID, firma, user presence, user verification e contatori secondo specifica. Il test deve includere replay e tampering, non soltanto il happy path.
6. Evitare dati sensibili di autenticazione nei log. Log applicativi e diagnostici devono essere progettati per il troubleshooting senza conservare materiale riutilizzabile. Authentication logging e data minimization devono essere parte del secure design.
7. Creare detection specifiche sull’endpoint. WebAuthn invocato da processi non-browser, accesso anomalo al log Microsoft-Windows-WebAuthN/Operational, injection/hooking di processi browser e caricamenti inattesi attorno a webauthn.dll sono segnali da correlare in EDR/XDR.
8. Monitorare registrazioni e modifiche delle passkey. Per identità privilegiàte, la registrazione di nuovi metodi di autenticazione deve generare telemetria e, dove possibile, alert. Il whitepaper raccomanda il monitoraggio delle registrazioni via API Microsoft Graph/IdP.
9. Trattare un prompt passkey inatteso come segnale di sicurezza. L’utente non deve approvare richieste non originate da una propria azione. Su account privilegiàti l’evento va correlato con processi, sign-in e telemetria dell’endpoint.

Nel caso di ambienti ibridi, la verifica deve includere anche la relazione tra privilegi on-premises e cloud. Un Assessment & Hardening Active Directory consente di estendere l’analisi a tiering amministrativo, lateral movement, identità ibride e configurazioni che possono trasformare una compromissione endpoint in escalation verso Entra ID.

Detection: indicatori utili per SOC ed EDR

La sezione OPSEC del paper è particolarmente utile dal punto di vista difensivo. Fra i segnali indicati dai ricercatori:

• uso delle API WebAuthn da applicazioni che non sono browser o componenti attesi;
• accesso al canale Microsoft-Windows-WebAuthN/Operational da processi insoliti;
• enumerazione anomala delle window handle dei processi;
• pattern di DLL injection verso processi browser;
• named pipe e artefatti di comunicazione associati a tooling di hook;
• hooking inatteso di WebAuthNAuthenticatorGetAssertion e delle funzioni di caricamento librerie;
• registrazioni passkey inattese per identità privilegiàte.

Questi indicatori non devono essere trasformati in regole isolate. La correlazione con identità, processo, parent process, integrità del device e sign-in cloud è molto più significativa di una singola stringa o di un singolo event ID, soprattutto perché un attaccante può modificare nomi, pipe e tecniche di injection.

Cosa cambia per CISO e IT manager

• Passwordless non significa endpoint-less: il trust del dispositivo diventa parte del controllo di autenticazione.
• La classificazione “phishing-resistant” descrive una proprietà del protocollo, non una garanzia assoluta dell’intero stack.
• Gli account amministrativi richiedono un profilo di passkey più restrittivo rispetto agli utenti standard: device-bound, attestation, device management e access paths controllati.
• Le applicazioni che implementano WebAuthn devono essere testate come codice di autenticazione critico, non considerate sicure perché usano uno standard FIDO.
• Identity telemetry ed endpoint telemetry devono convergere: un prompt WebAuthn generato da un processo inatteso è un evento sia di endpoint security sia di identity security.

Le passkey vanno quindi adottate o fermate?

Vanno adottate, ma con un modello di sicurezza completo. La ricerca non ribalta il vantaggio di FIDO2 rispetto a password, SMS OTP o TOTP. Mostra invece che, quando le password scompaiono, l’attaccante si sposta verso gli strati che producono, trasportano e verificano la prova crittografica.

La strategià corretta è quindi duplice: ridurre il rischio credenziale con passkey e, contemporaneamente, elevare il livello di hardening di endpoint, relying party e identità privilegiàte. Per i servizi sviluppati internamente, questo significa testare WebAuthn in modo esplicito; per Microsoft 365 ed Entra ID, significa mantenere Windows aggiornato, governare gli autenticatori e non affidare tutto a una singola policy di MFA resistente al phishing.

Per approfondire la terminologià tecnica puòi consultare il Glossario Cybersecurity Nexsys; per capire come inserire questi test in un’attività offensiva controllata, vedi anche Penetration test: come funziona e a cosa serve

FAQ - Pass-the-Passkey e sicurezza delle passkey

Le passkey sono ancora sicure dopo la ricerca Pass-the-Passkey?

Si. Il whitepaper considera le passkey un miglioramento significativo rispetto alle password. Le tecniche descritte mostrano soprattutto vulnerabilità o abusi negli strati che circondano WebAuthn: relying party, endpoint, browser, sistema operativo, logging e software authenticator. La sicurezza dipende quindi dalla corretta implementazione dell’intera catena.

CVE-2026-34348 permette di rubare la chiave privata di una passkey?

No. Il problema descritto dalla ricerca riguarda l’esposizione nei log Windows di assertion WebAuthn e del relativo materiale di firma, non l’estrazione della chiave privata dall’autenticatore. Microsoft ha rilasciato aggiornamenti il 14 luglio 2026; il whitepaper indica che i sistemi aggiornati troncano i campi di firma registrati nei log, impedendone il replay.

Un attaccante può fare phishing anche se usiamo passkey?

Il phishing web tradizionale è fortemente limitato dall’origin binding di WebAuthn. Se però un malware e già presente sull’endpoint, può tentare di generare un prompt WebAuthn locale e indurre l’utente ad approvare una richiesta non iniziata consapevolmente. Per questo un prompt passkey inatteso deve essere rifiutato e investigato.

Una chiave FIDO2 elimina tutti i rischi descritti?

No. Una security key protegge molto bene la chiave privata e offre forti garanzie di presenza e verifica utente, ma non corregge una relying party che accetta challenge riutilizzate, un endpoint compromesso o un flusso applicativo WebAuthn implementato in modo non conforme.

Quali account dovrebbero usare passkey device-bound?

Il whitepaper raccomanda le passkey device-bound per gli account ad alto valore e suggerisce l’attestation per limitare l’uso ad autenticatori genuini e approvati. In azienda la priorità riguarda amministratori, ruoli privilegiàti e accessi ad applicazioni o dati critici.

Come si verifica la sicurezza di una implementazione WebAuthn?

Occorre verificare almeno unicità della challenge, binding alla sessione, origin e RP ID, firma, user presence, user verification, signature counter dove applicabile, gestione degli errori, logging e resistenza a replay e tampering. La verifica deve includere test applicativi e penetration test, non soltanto vulnerability scanning.

Cosa conviene monitorare su Windows ed Entra ID?

Sono rilevanti l’uso delle API WebAuthn da processi non attesi, l’accesso anomalo ai log WebAuthn, injection o hooking nei processi browser e la registrazione di nuove passkey per account privilegiàti. La telemetria endpoint deve essere correlata con sign-in, identità, privilegi e stato del dispositivo.