Come rubano davvero un account Google (anche con 2FA): i miti da sfatare

Quando un account Google viene completamente preso in ostaggio da parte di criminali informatici — fino al punto di consentire la pubblicazione di video su YouTube o la modifica delle impostazioni di sicurezza, come avvenuto a gennaio 2026 nel caso del noto youtuber italiano Andrea Galeazzi — non si tratta quasi mai di un singolo errore. Per rubare account Google nella quasi totalità dei casi si parla di catene di attacco perché, ad esempio, OAuth amplifica l’attacco ma non lo innesca. Più fattori concorrono al superamento delle difese da parte dei criminali informatici. Comprendere questi vettori è essenziale per distinguere tra miti ricorrenti e minacce reali.

Paradossalmente, la rivelazione diretta di username e password, almeno nel caso degli account Google, è una delle modalità oggi meno “gettonate” ed efficaci, se usata da sola, per appropriarsi di un’identità altrui.

Il ruolo della 2FA: barriera efficace, ma non assoluta

La verifica in due fattori rappresenta una difesa fondamentale, ma non deve essere interpretata come una protezione inviolabile. La 2FA (Google la chiama verifica in due fattori ma in generale si parla di autenticazione a due fattori) blocca la maggior parte degli attacchi automatici e rende inefficace la semplice rivelazione delle credenziali, ma introduce un nuovo bersaglio: l’utente stesso.

Tecniche come il phishing interattivo (attacco in cui la vittima è guidata in tempo reale ad approvare un’autenticazione o inserire codici validi, credendo di interagire con un servizio legittimo), la “push fatigue” (tecnica che induce l’utente ad approvare una richiesta di autenticazione a due fattori dopo ripetute notifiche, per stanchezza o distrazione) o l’ingegneria sociale mirata puntano a convincere la vittima ad approvare una richiesta legittima solo in apparenza.

In questi casi la 2FA non è affatto aggirata, ma soddisfatta volontariamente, trasformandosi da difesa tecnica a punto di pressione psicologica.

Furto di sessione e cookie hijacking: quando la password diventa irrilevante

Uno dei vettori più pericolosi oggi è il furto di sessione. Attraverso malware, estensioni malevole o exploit del browser, un attaccante può sottrarre cookie di sessione già validi e impersonare l’utente senza mai conoscere password o codici 2FA.

Questo tipo di attacco è particolarmente insidioso perché sfrutta una sessione in cui l’autenticazione forte è già stata soddisfatta in precedenza. Da quel momento, l’attaccante può accedere ai servizi, modificare impostazioni e, nei casi più gravi, prendere il controllo di canali YouTube o account pubblicitari.

OAuth come fattore abilitante, non come causa

L’accesso OAuth a servizi come Gmail o Drive è spesso descritto come la causa primaria di compromissioni gravi.

Quando parliamo di accesso OAuth non stiamo parlando di una password, né di un login completo all’account. Ci riferiamo a quella richiesta che tutti abbiamo visto decine di volte: “Questa applicazione chiede il permesso di visualizzare e gestire la tua posta”, “leggere i tuoi file”, “accedere alle informazioni di base del profilo”.

In quel momento l’utente non sta comunicando le proprie credenziali, ma sta concedendo a un’applicazione terza un token di autorizzazione limitato a specifici servizi e a specifici ambiti di azione, detti scope. OAuth, infatti, è un protocollo di delegazione dell’accesso, non di autenticazione: consente a un servizio esterno di agire per conto dell’utente su un determinato servizio Google (come Gmail, Drive o Calendar), senza mai conoscere la password e senza ottenere una sessione di login dell’account.

Perché OAuth amplifica l’attacco ma NON lo innesca

Ciò significa che un token OAuth può essere potentissimo sul piano funzionale — ad esempio permettendo di leggere, inviare o cancellare email — ma resta confinato entro i limiti del servizio e degli scope concessi. Non può essere usato per accedere alle impostazioni di sicurezza dell’account, cambiare password, modificare i fattori di autenticazione o “diventare” l’utente.

Il problema nasce quando questa distinzione viene ignorata: l’accesso OAuth è percepito come un login mascherato, mentre in realtà è un permesso granulare, revocabile e isolato, che diventa pericoloso solo se inserito all’interno di una catena di attacco più ampia, come accennato in precedenza.

OAuth rappresenta un moltiplicatore di impatto, non il grilletto iniziale. Un’applicazione malevola autorizzata tramite i permessi OAuth può leggere email di sicurezza, cancellare avvisi e rallentare la reazione della vittima all’attacco, ma non può da sola cambiare password o superare la 2FA. Tuttavia, combinata con altri vettori — ad esempio un furto di sessione o una 2FA già approvata — può rendere l’attacco più silenzioso e difficile da individuare. Andiamo più nel dettaglio.

Se l’aggressore richiede il reset della password, il codice di conferma arriva nella casella Gmail: NON è vero

Anche accordando un accesso completo alla posta a un’applicazione di terze parti via OAuth, il reset password di Google richiede ulteriori verifiche di identità e non può essere completato solo intercettando l’email. In altre parole, un aggressore che avesse guadagnato il controllo di una casella Gmail via OAuth NON può ottenere il cambio password senza un’azione attiva del legittimo proprietario.

Quello che può verosimilmente succedere è che un utente prima accordi il controllo del proprio account Google, via OAuth, a un’applicazione sotto il controllo di terzi. L’errore può essere commesso quando la vittima cade nelle spire di un attacco phishing, presentato come un meccanismo legittimo (quando invece non lo è affatto!…) di verifica account.

Successivamente, a strettissimo giro (perché la velocità dell’operazione è determinante per la riuscita dell’attacco…), gli aggressori inviano una richiesta di cambio password tramite la pagina ufficiale Google. Nel caso in cui la 2FA sia attiva, l’aggressore sceglie Prova un altro metodo, quando disponibile, e conferma l’invio della richiesta alla vittima.

Ecco, qui se la vittima confermasse l’accesso, ritenendo ad esempio che si tratti di un’autorizzazione legata a una verifica legittima dell’account, allora consegna il suo account nelle mani dell’aggressore che può effettivamente modificare le impostazioni di sicurezza.

Il reset della password Google: un processo risk-based, non meccanico

L’errore comune, che ci è capitato di leggere anche in articoli pubblicati da testate che si occupano di tecnologia, è immaginare il reset della password sugli account Google come un’operazione lineare: richiesta, email di conferma, nuova password.

In realtà il recupero dell’account Google è un processo risk-based, che combina più segnali per valutare se l’operazione sia legittima. L’email di reset non contiene un “codice risolutivo” e non autorizza automaticamente il cambio password.

Google valuta il contesto: dispositivo, indirizzo IP, area geografica, storico degli accessi, presenza di sessioni già autenticate, configurazione di sicurezza dell’account. Se il contesto non è coerente con quello del legittimo proprietario, il processo si interrompe o viene trasformato in una procedura di recovery ritardata, che può durare giorni e richiedere verifiche aggiuntive. L’accesso a Gmail, guadagnato ad esempio via OAuth da un’applicazione sviluppata da terze parti, non soddisfa i requisiti di identità necessari per completare il reset della password!

Abbiamo verificato sul campo: cosa succede davvero con OAuth e il recupero dell’account

Per evitare qualunque forma di speculazione teorica, abbiamo riprodotto direttamente gli scenari più citati sviluppando un’applicazione OAuth ad hoc tramite Google Cloud, configurata con gli scope più ampi disponibili per Gmail.

L’app è stata autorizzata su account reali sotto il nostro controllo, verificando che fosse effettivamente in grado di leggere, intercettare ed eliminare qualsiasi messaggio, inclusi quelli relativi alla sicurezza.

A partire da questa configurazione, abbiamo poi avviato più tentativi di recupero password da browser e indirizzi IP completamente nuovi, mai associati in precedenza agli account di test. Il risultato è stato coerente in tutti i casi: Google non ha mai consentito un cambio password diretto basato sulla sola disponibilità dell’email, ma ha attivato una procedura di recupero risk-based,  come spiegato in precedenza, introducendo verifiche aggiuntive, ritardi temporali e richieste di conferma contestuale.

Questo comportamento è emerso non solo su account protetti da 2FA, ma anche su account deliberatamente lasciati senza secondo fattore, a dimostrazione del fatto che l’accesso all’account Google — anche completo e persistente via OAuth — NON è considerato una prova di identità sufficiente.

Addirittura, anche inserendo la password di un account non protetto con autenticazione a due fattori, Google ci ha mostrato la seguente schermata (sempre per via dell’approccio risk-based), invitandoci a confermare in qualche modo la nostra identità:

Dal dispositivo all’account: la vera catena di compromissione nei takeover Google

Nei casi italiani in cui le vittime hanno perso completamente il controllo del proprio account Google, con cambio password riuscito e abuso immediato dei servizi collegati — inclusa la pubblicazione di contenuti su YouTube — la spiegazione tecnica più coerente non è il bypass di OAuth in sé ma una catena di compromissione più profonda che ha avuto origine quasi sempre dai dispositivi delle vittime.

La compromissione iniziale: quando l’attacco parte dal dispositivo

Attraverso malware distribuiti sotto forma di software apparentemente legittimo, file di collaborazione, plugin o strumenti “professionali”, gli attaccanti sono riusciti a sottrarre cookie di sessione già validi, operando quindi all’interno di un contesto in cui password e 2FA erano già state soddisfatte in precedenza.

In questa situazione Google considera l’accesso come legittimo (dal punto di vista della sessione), consentendo operazioni sensibili — incluso il cambio password — senza richiedere una nuova autenticazione forte, perché l’azione avviene da una sessione già fidata.

L’eventuale accesso OAuth a Gmail, spesso citato come causa primaria, ha avuto al massimo un ruolo successivo e accessorio, utile a monitorare o cancellare le email di sicurezza e a rallentare la reazione della vittima, ma non a ottenere l’accesso iniziale.

L’ingegneria sociale finale: rendere credibile la richiesta di 2FA

In alcuni casi, un attaccante può deliberatamente avviare una richiesta di cambio password da una rete e da un’area geografica molto vicina a quella della vittima — stessa città, stesso ISP, a volte persino stesso ASN (Autonomous System Network) — per ridurre l’attrito dei controlli di rischio applicati da Google. Ciò non serve a “bypassare” la 2FA, ma a far sì che la richiesta di verifica a due fattori sia effettivamente presentata, invece di essere bloccata a monte come tentativo palesemente anomalo. In altre parole, l’obiettivo non è evitare la 2FA, ma farla comparire in modo credibile agli occhi dell’utente.

A questo punto entra in gioco il fattore umano. Se la vittima riceve una notifica del tipo “Tentativo di accesso al tuo account” o “Confermi che sei tu?” in un momento di distrazione, stanchezza o confusione — magari mentre sta davvero accedendo a un servizio Google — può approvare la richiesta senza rendersi conto che sta autorizzando l’attaccante. Questo è il classico scenario di push fatigue o di social engineering contestuale: la 2FA non è aggirata tecnicamente, ma soddisfatta volontariamente dall’utente.

Il cambio password riuscito rappresenta quindi l’atto finale di consolidamento, non certo l’inizio dell’attacco, e indica che l’aggressore stava già operando con gli stessi privilegi dell’utente legittimo. In sintesi, questi episodi non dimostrano una debolezza strutturale dei sistemi di Google, ma l’efficacia di attacchi mirati che spostano il punto di rottura dall’account al dispositivo.

Conclusione

I casi che hanno fatto notizia in Italia — fino a episodi eclatanti come quello che ha coinvolto Andrea Galeazzi — non dimostrano che qualunque account Google possa essere preso in ostaggio con facilità, né che i meccanismi di sicurezza di Google siano intrinsecamente deboli. Dimostrano invece qualcosa di più sottile e meno sensazionalistico: gli attacchi che vanno davvero a buon fine sono quasi sempre mirati, costruiti nel tempo e basati su catene di compromissione, non su un singolo errore o su una singola tecnologia “pericolosa”.

Non basta concedere un accesso OAuth, non basta intercettare un’email, non basta nemmeno conoscere una password: perché l’account passi realmente sotto il controllo degli attaccanti serve quasi sempre un punto di rottura più profondo, che passa dal dispositivo della vittima, dal fattore umano o da una sessione già autenticata.

La buona notizia è che questo tipo di scenario non è casuale e non colpisce indiscriminatamente: richiede condizioni precise, spesso evitabili con buone pratiche, consapevolezza e difese adeguate al proprio profilo di rischio.

La cattiva notizia è che nessun meccanismo di autenticazione, da solo, può compensare un endpoint compromesso o una decisione presa nel momento sbagliato. Capire come funzionano davvero questi attacchi — senza miti, senza scorciatoie narrative — è il primo passo per ridurre drasticamente la probabilità di diventarne vittima.