# Il malware iAuthFlow registra una passkey Google che il reset password non cancella URL: https://menteinformatica.it/sicurezza-privacy/iauthflow-malware-passkey-google/ Autore: Giorgio Perillo Aggiornato: 2026-10-01 Categoria: Sicurezza e Privacy --- Prima il limite, poi il perché conta comunque. L’analisi che circola dal **20 agosto 2026** su iAuthFlow v2 non nasce da un test diretto: i ricercatori di **Abnormal AI**, Callie Baron e Piotr Wojtyla, dichiarano esplicitamente di non aver eseguito il toolkit né di aver effettuato l’accesso a un account tramite esso. La loro ricostruzione si basa sui post del venditore su un forum, su un [canale Telegram](https://menteinformatica.it/sicurezza-privacy/teleshim-telegram-attacchi-governi-medio/) e su video dimostrativi. È una postulazione, non una prova di laboratorio, e SecurityWeek lo ribadisce: di iAuthFlow v2 è pubblicamente noto molto poco. Detto questo, il meccanismo descritto merita attenzione anche solo come ipotesi documentata: sposta la logica dell’incident response su un punto che finora nessuno considerava critico. ## Il toolkit costa 10.000 dollari e vende un salto di qualità **iAuthFlow v2** è venduto su un forum russo di cybercrime a un prezzo base di 10.000 dollari, con moduli aggiuntivi acquistabili separatamente. Non è un kit di phishing generico: usa un’architettura **browser-in-the-middle** (BitM) con due ambienti browser distinti. La vittima interagisce con una pagina di phishing convincente, mentre un browser sul server dell’attaccante ottiene in parallelo la sessione autenticata reale. Fin qui, niente di radicalmente nuovo: il BitM è una tecnica nota. Il salto arriva dopo. ## Non ruba la passkey, ne registra una nuova Una volta che la vittima completa un login Google vulnerabile al phishing, il toolkit usa quella sessione autenticata per **registrare una passkey controllata dall’operatore** sull’account compromesso. Qui va precisato con esattezza cosa succede, perché è facile fraintenderlo: non viene sottratta una passkey esistente della vittima, ne viene creata una nuova, che l’attaccante controlla da subito. Nella dimostrazione registrata dal venditore, il proprietario dell’account cambia la password e invalida la sessione attiva. L’operatore, però, si autentica con la passkey appena registrata e rientra nella casella di posta. Né il reset della password né la revoca della sessione rimuovono una passkey registrata dall’attaccante: restano lì, valide, finché qualcuno non le elimina esplicitamente. Il reset della password, per anni la prima mossa di ogni contenimento, smette di essere sufficiente da solo. **Attenzione:** secondo TechRadar, nella dimostrazione del venditore la passkey viene creata sei secondi dopo l’autenticazione. È possibile che Google richieda un’ulteriore verifica dell’identità prima di consentire la registrazione, ma la dimostrazione non lo esclude. ## Il come resta un’ipotesi, non una certezza Abnormal ipotizza che il toolkit usi un virtual authenticator software-based integrato in Chromium, il browser open source alla base di Chrome, per simulare la registrazione WebAuthn. È una spiegazione tecnicamente plausibile per quanto mostrato nel video, ma i ricercatori stessi la presentano come tale: non stabilisce che iAuthFlow v2 funzioni davvero così. Le fonti divergono anche su un altro punto. TechRadar scrive che Abnormal avrebbe ottenuto una copia del toolkit per l’analisi, ma questa versione contraddice quanto Abnormal dichiara di persona, e SecurityWeek conferma che il lavoro si basa sui materiali online del venditore, non sull’uso reale del malware. Non ci sono elementi per scegliere tra le due versioni: meglio saperlo, senza far finta che il dubbio non esista. ## Chi rischia, oggi e domani Il build analizzato prende di mira gli account **Google**, quindi [Gmail e Workspace](https://menteinformatica.it/sicurezza-privacy/google-workspace-token-oauth-agenti/). Il venditore pubblicizza però anche versioni per Microsoft, iCloud e LinkedIn: se il meccanismo funziona come descritto, il problema non resta confinato a un solo ecosistema. Riguarda soprattutto chi gestisce la risposta a un incidente in azienda, dove le procedure di contenimento spesso si fermano al reset delle credenziali. **Cosa cambia:** dopo una compromissione sospetta non basta più cambiare la password e revocare le sessioni attive. Serve controllare ed eliminare esplicitamente passkey e chiavi di sicurezza non riconosciute, filtri Gmail e regole di inoltro sospette, accessi delegati e permessi OAuth concessi ad app terze. Per gli utenti Workspace, Google mette a disposizione il Security Investigation Tool proprio per questo tipo di verifica puntuale sull’account. ## Il limite che conta più del dettaglio tecnico Secondo me il punto debole di questa storia non è il toolkit in sé, ma quanto poco lo si conosca davvero: nessuna esecuzione diretta, nessuna conferma sul meccanismo interno, nessuna prova di utilizzo reale contro vittime. Ho notato che ogni fonte secondaria ripete la stessa cautela di Abnormal, e questo È già un segnale: quando persino chi scrive il report invita a leggerlo come ipotesi e non come verifica tecnica, il lettore deve trattarlo di conseguenza. Non cambia però la sostanza pratica: anche se iAuthFlow v2 restasse un prodotto da forum criminale mai realmente dispiegato su larga scala, il principio che descrive è solido e replicabile da chiunque abbia le competenze per farlo. La difesa basata solo su reset password ha un buco concettuale reale, a prescindere da questo singolo toolkit. **Perché conta:** le passkey sono presentate come lo standard più resistente al phishing disponibile oggi, e in gran parte lo sono per il furto di credenziali. Questo caso sposta però l’attenzione sulla fase successiva a una compromissione già avvenuta: se un attaccante ottiene una sessione attiva, può usarla per piantare una propria chiave d’accesso permanente, ed è lì che le procedure standard di incident response mostrano il limite. Chi sospetta un accesso non autorizzato sul proprio account Google farebbe bene a controllare la lista delle passkey registrate, non solo la password. È un controllo che richiede due minuti e che oggi, semplicemente, quasi nessuno fa. Fonte: [abnormal.ai](https://abnormal.ai/blog/iauthflow-v2-phishing-google-passkeys).