Account compromesso nonostante l’autenticazione a due fattori (2FA): basta un cookie rubato

L’antivirus segnala il completamento dell’operazione con esito positivo. Malware rilevato, rimosso, tutto pulito. Due giorni dopo, il Suo account Google invia messaggi di spam e l’elenco dei dispositivi mostra un computer che non è il Suo. L’autenticazione a due fattori è rimasta attiva per tutto il tempo.

Ciò che accade in questo caso è denominato «dirottamento di sessione», ovvero la presa di controllo di una sessione già in corso. L’autore dell’attacco non ha bisogno né della Sua password né del Suo secondo fattore di autenticazione. Tutto ciò di cui ha bisogno è il piccolo file che il Suo browser memorizza dopo che ha effettuato l’accesso, in modo che non debba digitare nuovamente nulla alla Sua prossima visita. Quel file è il cookie di sessione.

Google lo descrive apertamente sul proprio blog dedicato a Chromium: il furto avviene dopo l’accesso e quindi aggira l’autenticazione a due fattori. Ed è difficile neutralizzarlo con un software antivirus, poiché i cookie continuano a funzionare anche dopo la rimozione del malware.

Come avviene il furto

All’inizio c’è quasi sempre un infostealer, un programma creato per raccogliere credenziali. Raggiunge il dispositivo tramite software crackato, un programma di installazione manomesso o un allegato. Una volta lì, legge i file in cui il browser memorizza i propri cookie. L’autore dell’attacco importa quindi il cookie nel proprio browser e accede al sito. Il servizio rileva una sessione valida e già autenticata e non richiede ulteriori dati.

L’entità di questo mercato emerge dal Global Threat Intelligence Report pubblicato l’11 marzo 2026 dalla società di sicurezza Flashpoint. Per il 2025, Flashpoint conta oltre 11,1 milioni di computer infettati da infostealer e 3,3 miliardi di credenziali e token cloud sottratti da essi. I cookie di sessione non sono nemmeno inclusi in tale conteggio.

Quanto tutto ciò ci riguardi da vicino è stato dimostrato dall’Operazione Endgame. Il 24 giugno 2026 l’Europol ha riferito di un’operazione contro i gruppi di furti di dati StealC e Amadey e contro la rete di distribuzione SocGholish, con il coinvolgimento della Germania. Sono stati disattivati 326 server e 142 domini e sono state recuperate 27 milioni di coppie di credenziali. Le vittime sono state avvisate tramite Have I Been Pwned, oltre che attraverso altri canali.

Il secondo fattore è collocato in una posizione errata. Un codice SMS, una richiesta dell’app e una chiave di sicurezza verificano chi sta effettuando l’accesso. Il cookie viene creato solo in seguito, a conferma del superamento di tale verifica. Chiunque sia in possesso di tale prova non è tenuto a ripetere il controllo. Nemmeno il Programma di protezione avanzata di Google modifica questa procedura. Secondo Google, a chi rimane connesso potrebbe non essere richiesta nuovamente la chiave di sicurezza. Le modalità per proteggere adeguatamente i propri account sono illustrate nell’articolo «Una password da sola non basta».

Cosa stanno facendo i browser al riguardo

Su Windows, Chrome crittografa i cookie con la tecnologia «App-Bound Encryption» a partire dalla versione 127 del luglio 2024 e associa la chiave all’applicazione. Google stessa ne indica il limite: il malware in esecuzione con privilegi elevati aggira la protezione. Ciò rende il furto più costoso, ma non lo impedisce.

Il vero progresso è rappresentato dalla tecnologia denominata «Device Bound Session Credentials», abbreviata in DBSC. Il browser genera una coppia di chiavi la cui parte privata non lascia mai il dispositivo. Su Windows essa risiede nel TPM, il chip di sicurezza presente sulla scheda madre. Il servizio verifica regolarmente se il browser possiede ancora quella chiave. Un cookie presente sul dispositivo di qualcun altro non supera tale verifica.

Per i siti web questa tecnologia è disponibile a partire da Chrome 145. Google l’ha attivata per i propri servizi il 9 aprile 2026 con Chrome 146 su Windows e ne sta effettuando il lancio dal 25 maggio 2026 per gli account Workspace e gli account Google personali, senza che gli utenti debbano effettuare alcuna configurazione. Permangono due limiti. Secondo le specifiche del W3C, il DBSC non impedisce l’accesso fintanto che l’autore dell’attacco si trova ancora sul dispositivo. Inoltre, ogni sito web deve partecipare attivamente, motivo per cui la protezione viene applicata innanzitutto ai servizi di Google.

Firefox si trova in una posizione peggiore di quanto molti credano. Il suo database dei cookie risiede sul disco senza alcuna crittografia. La segnalazione nel bug tracker di Mozilla, bug 56788, è stata presentata 25 anni fa, chiusa con lo stato «WONTFIX» nel 2000 e riaperta due anni fa. Ha priorità P3 e non è assegnata a nessuno. La funzione «Protezione totale dai cookie» non modifica questa situazione, poiché si tratta di protezione dal tracciamento.

Cosa può fare ora

È l’ordine delle operazioni a fare la differenza. In caso di infezione da malware, l’Ufficio federale tedesco per la sicurezza informatica (BSI) stabilisce la seguente sequenza: reinstallare prima il sistema, modificare le password in un secondo momento. Chiunque proceda al contrario e digiti la nuova password sul computer infetto la consegna direttamente all’aggressore.

Segue poi il passaggio che la maggior parte delle persone tralascia. Una nuova password non esclude necessariamente un malintenzionato in possesso di un cookie valido. È necessario chiudere separatamente le sessioni aperte.

Google: myaccount.google.com, sezione Sicurezza, «Gestisci tutti i dispositivi». Ogni sessione è elencata singolarmente; tocchi il dispositivo e effettui il logout. Google non offre un unico pulsante per tutte le sessioni.

Microsoft: account.microsoft.com, opzioni di sicurezza avanzate, «Effettua il logout ovunque». Secondo Microsoft, il logout può richiedere fino a 24 ore e la Xbox è esclusa.

Apple: account.apple.com, sezione Dispositivi, selezionare il dispositivo, «Rimuovi dall’account». Il dispositivo ricompare se qualcuno è ancora connesso su di esso.

Cosa fanno e cosa non fanno le passkey

Le passkey sono considerate le eredi delle password e il BSI le definisce una forma di autenticazione estremamente sicura. Ciò è vero, ma, ancora una volta, tale sicurezza riguarda esclusivamente l’atto di effettuare l’accesso. Una passkey impedisce a qualcuno di accedere al posto vostro. Non impedisce però a qualcuno di appropriarsi della sessione che avete già aperta. Il fatto che l’accesso stesso rimanga vulnerabile è dimostrato dal fenomeno «Pass-the-Passkey».

Il quadro reale è preoccupante. Nel proprio blog sulla sicurezza del 9 aprile 2026, Google scrive che su nessun sistema operativo esiste un modo affidabile per impedire il furto di cookie utilizzando esclusivamente software, una volta che il malware si è insediato sul dispositivo. Ciò che DBSC modifica è la durata di validità del bottino. Il cookie rubato sarà quindi utilizzabile solo sul computer in cui è stato creato.

Finché ciò non sarà applicabile ovunque, il problema rimarrà a vostro carico. Niente software crackato, download solo dalla fonte originale e, in caso di sospetto, reinstallare prima il sistema e chiudere le sessioni in un secondo momento. In quest’ordine.