Google Calendar usato per rubare account anche con MFA attiva

Un invito su Google Calendar può diventare il punto di partenza per un attacco informatico capace di sottrarre l’accesso a un account Google, anche quando l’utente ha attivato l’autenticazione a più fattori. Non si tratta di una vulnerabilità del calendario o di un difetto che permette di aggirare le protezioni di Google: i criminali sfruttano una tecnica di phishing che intercetta il processo di autenticazione e consente di impossessarsi di una sessione già autorizzata.

La campagna, attiva almeno dalla metà di agosto 2026, ha preso di mira soprattutto utenti aziendali di Google Workspace. A documentarla sono i ricercatori di Material Security, che hanno denominato l’operazione di contrasto Operation CloudFire.

Il caso mostra quanto siano cambiate le tecniche di furto degli account. Il tradizionale phishing, basato sulla creazione di una falsa pagina di accesso per rubare le password, ha lasciato spazio anche a strumenti molto più sofisticati: l’utente interagisce con una schermata di autenticazione apparentemente normale, completa la verifica in due passaggi e, senza accorgersene, permette a un soggetto esterno di ottenere una sessione valida.

Il phishing arriva attraverso gli inviti di Google Calendar

La particolarità della campagna riguarda innanzitutto il canale utilizzato per raggiungere le vittime. Gli aggressori inviano inviti di calendario fraudolenti, spesso provenienti da indirizzi già conosciuti dal destinatario. Non mancano messaggi recapitati tramite copia conoscenza nascosta (BCC), un espediente che complica la ricostruzione dell’elenco dei destinatari.

Gli oggetti degli inviti richiamano situazioni quotidiane: notifiche di messaggi vocali, richieste commerciali, documenti giudiziari o pagamenti non effettuati: il destinatario ha quindi un motivo plausibile per aprire il collegamento inserito nella comunicazione.

Un elemento importante è il ricorso ad account compromessi in precedenza: secondo Material Security, gli indirizzi utilizzati per la distribuzione appartenevano a caselle già sotto il controllo degli aggressori. Gli inviti raggiungevano anche contatti presenti nelle rubriche delle vittime precedenti, aumentando le probabilità che il nuovo destinatario considerasse affidabile il mittente.

Come funziona il furto della sessione Google e perché la MFA non basta

Il componente centrale dell’attacco è un reverse proxy malevolo, collocato tra il browser della vittima e il servizio di autenticazione Google. La tecnica è conosciuta come Adversary-in-the-Middle (AiTM): l’aggressore si interpone nella comunicazione, inoltrando le richieste verso il servizio autentico e restituendo le risposte al browser.

Quando la vittima inserisce nome utente e password, il proxy trasmette le credenziali a Google. Se l’account richiede una verifica aggiuntiva, il processo prosegue normalmente: il sistema può richiedere un codice SMS, un codice generato da un’app di autenticazione oppure una conferma sullo smartphone, compreso il sistema Google con selezione del numero visualizzato. L’aggressore non deve conoscere preventivamente il secondo fattore: lo fa gestire alla vittima e ne inoltra le risposte in tempo reale.

Al termine dell’autenticazione, il proxy può intercettare i dati che identificano la sessione autorizzata, come i cookie di sessione. Se riesce a riutilizzarli, l’aggressore può accedere ai servizi Google senza dover ripetere immediatamente la verifica multifattore.

Nyasher, il framework utilizzato per intercettare gli accessi

L’analisi tecnica attribuisce il funzionamento della piattaforma di phishing a Nyasher, un framework la cui esistenza era già documentata pubblicamente da febbraio 2026, dopo l’individuazione di una chiave incorporata nel codice JavaScript.

Nel white paper tecnico pubblicato da Material Security, i ricercatori descrivono il funzionamento dell’infrastruttura, i componenti utilizzati per distribuire le pagine fraudolente e gli accorgimenti adottati per ostacolare l’analisi automatizzata.

Uno degli espedienti consiste nell’inserimento di una verifica Cloudflare Turnstile prima della pagina che intercetta le credenziali. In alcune implementazioni il controllo è autentico e utilizza l’infrastruttura Cloudflare: proprio questa accortezza, dal punto di vista degli aggressori, contribuisce a rendere meno immediata l’identificazione della truffa.

Gli operatori hanno costruito una rete di domini facilmente sostituibili, registrati presso provider differenti e spesso pochi giorni prima del loro impiego. Gli endpoint destinati a ricevere le informazioni sottratte comparivano da uno a venti giorni prima delle rispettive ondate di attacco.

In un caso, i ricercatori hanno osservato l’emissione di un certificato TLS wildcard, utilizzabile per proteggere più sottodomini dello stesso dominio, appena 46 minuti prima della registrazione del dominio principale. Un dettaglio che suggerisce una preparazione automatizzata e particolarmente rapida dell’infrastruttura malevola.

Cosa rischia chi perde una sessione Google Workspace

Il furto di una sessione autenticata può avere conseguenze più ampie della compromissione della sola posta elettronica. In funzione dei privilegi dell’account e dei controlli applicati, l’aggressore può raggiungere Gmail, consultare file in Drive e tentare di autorizzare applicazioni esterne attraverso OAuth 2.0.

Un’applicazione malevola che ottiene autorizzazioni persistenti potrebbe continuare ad accedere a determinate risorse anche dopo la chiusura della sessione iniziale, finché i relativi permessi rimangono validi.

Per gli amministratori, quindi, modificare la password non rappresenta sempre una risposta sufficiente: vanno verificate le sessioni attive, gli accessi recenti, le applicazioni autorizzate e gli eventi registrati nei log di Google Workspace.

Un account aziendale compromesso può inoltre diventare il punto di partenza per nuovi attacchi verso colleghi e contatti esterni, proprio come dimostra il riutilizzo degli indirizzi già sottratti nella campagna descritta.

Come difendersi: passkey, chiavi FIDO2 e revoca delle sessioni

Le protezioni più efficaci contro il phishing AiTM comprendono i metodi di autenticazione vincolati crittograficamente al sito legittimo. Le passkey basate su FIDO2/WebAuthn e le chiavi di sicurezza compatibili sfruttano la crittografia asimmetrica e verificano l’identità del servizio al quale l’utente si sta autenticando.

Una credenziale registrata per Google non può autenticare l’utente su un dominio fraudolento sotto il controllo di un aggressore. La risposta crittografica non può infatti essere inoltrata dal proxy per completare un accesso su un’origine diversa. Google illustra il meccanismo nella propria documentazione sulle passkey.

Va detto però che una passkey non rende impossibile qualsiasi furto di sessione: malware presenti sul dispositivo, compromissioni del browser o altri metodi per ottenere cookie già validi rappresentano problemi residui.

In ambito aziendale è opportuno affiancare l’autenticazione resistente al phishing a controlli sugli inviti di calendario, all’analisi delle catene di reindirizzamento e al monitoraggio degli accessi sospetti. Le funzioni amministrative di Google Workspace consentono inoltre di intervenire sulle impostazioni di sicurezza degli utenti, compresa la gestione delle sessioni di accesso.

In presenza di una compromissione, il personale IT dovrebbe revocare rapidamente le sessioni interessate, reimpostare le credenziali, esaminare le autorizzazioni OAuth e verificare eventuali modifiche alle impostazioni dell’account.