Phishing su Google Workspace: perché la formazione conta più dei filtri

Chi gestisce Google Workspace o lavora come sistemista sa che, prima o poi, con un attacco di phishing ci si deve scontrare. Non serve chissà quale vulnerabilità complessa: basta una mail di credential harvesting ben impaginata che arriva nel momento sbagliato, aperta dal telefono da una persona che in quel momento è presa da altro. Di recente mi è capitato di gestire proprio una situazione di questo tipo: una mail apparentemente innocua ha superato i controlli di sicurezza, portando alla compromissione temporanea di una casella e all’invio di messaggi verso l’esterno.

Questo articolo racconta l’episodio dal punto di vista operativo: cosa è successo nei log, come ho usato lo strumento di indagine della console e GAM (Google Apps Manager) per ricostruire gli accessi, cosa ha funzionato nei filtri della rete interna e perché, alla fine della giornata, la parte più importante resta sempre la formazione pratica delle persone.

Cosa è successo: dieci minuti per compromettere un account

La sequenza dei fatti è stata molto rapida:

1. Un’utente dell’organizzazione riceve sullo smartphone una mail che sembra una consueta notifica di pagamento in sospeso. Si trova fuori sede, connessa tramite rete dati cellulare.
2. Apre il messaggio dal cellulare, tocca il link e atterra su una pagina fake graficamente identica a quella di Google. Convinta che fosse scaduta la sessione, inserisce indirizzo e password.
3. Circa dieci minuti dopo, qualcuno usa quelle credenziali per accedere da un indirizzo IP negli Stati Uniti.
4. In meno di dieci minuti dall’accesso, dalla casella dell’utente partono quattro mail di phishing, ciascuna con centinaia di destinatari in copia nascosta (CCN): in tutto oltre mille indirizzi, presi dalla sua rubrica.

Ce ne siamo accorti perché un collega ha ricevuto la mail, si è insospettito e me l’ha inoltrata chiedendo se fosse autentica. Da lì ho aperto la console di amministrazione per capire la portata dell’accaduto e intervenire.

Perché nessun filtro antispam l’ha fermata

La prima cosa che ho controllato sono state le intestazioni dell’email esca originale. Mi aspettavo un mittente falsificato o record DNS non allineati. Invece era tutto in regola:

• SPF (Sender Policy Framework): PASS
• DKIM (DomainKeys Identified Mail): PASS
• DMARC (Domain-based Message Authentication): PASS

Il mittente era una casella vera di un dominio registrato pochi mesi prima, con la posta gestita su Microsoft 365 e i parametri configurati correttamente. Anche i controlli in uscita di Microsoft non l’avevano marcata come spam. Per Gmail si trattava di un messaggio legittimo a tutti gli effetti.

Un promemoria utile: SPF, DKIM e DMARC servono a verificare chi spedisce la mail, non se il contenuto è innocuo o malevolo. Un dominio registrato da poco si imposta in pochi minuti, e chi fa phishing usa spesso caselle reali o account di terzi compromessi. Quando una mail passa tutti i filtri, l’ultimo controllo resta sempre chi la legge.

Come ho ricostruito l’accaduto

Per rimettere in fila gli eventi e mettere in sicurezza l’account ho seguito questi passaggi, che sono poi quelli standard per questo tipo di incidenti:

1. Distinguere un account compromesso dallo spoofing

Controllando le intestazioni e usando lo Strumento di indagine sulla sicurezza (Security Investigation Tool) della console, ho verificato subito che i messaggi erano partiti davvero dalla sessione web dell’account, non da un server esterno che usava abusivamente il suo indirizzo.

2. Trovare gli accessi anomali

Nel registro degli accessi (Login Audit Log) comparivano due login eseguiti con la sola password da IP statunitensi, entrambi con il campo is_suspicious impostato a vero.

3. Verificare gli altri account del dominio

Ho cercato quegli IP su tutti i log del dominio (accessi, Gmail, Drive, token OAuth). Comparivano solo su quell’utente, quindi nessun altro account dell’organizzazione era stato toccato.

4. Ricostruire le azioni dell’attaccante e rimuovere l’esca

I log di Gmail filtrati per IP mostravano i passaggi: consultazione della rubrica, creazione delle bozze, invio in pacchetti da 250 in CCN e gestione dei messaggi di mancato recapito per non insospettire l’utente. Risalito al Message-ID della mail iniziale, l’ho rimossa con lo strumento di indagine dalle caselle degli altri colleghi che l’avevano ricevuta.

5. Controllare l’esposizione dati e revocare i token

I log di Google Drive e delle esportazioni dati non mostravano attività sospette. Nei token OAuth però era comparsa un’autorizzazione per Google Chrome subito dopo l’accesso: l’ho revocata subito a mano, per evitare che l’attaccante potesse sincronizzare password, cronologia o segnalibri sul suo browser.

I controlli con GAM da riga di comando

L’interfaccia web della console va benissimo, ma quando serve analizzare volumi consistenti di dati o estrarre rapidamente tabelle per incrociare gli eventi, utilizzare la CLI con GAM fa risparmiare un sacco di tempo. Con pochi comandi si esportano i report direttamente su Google Drive:

# Tutti gli accessi da quell'IP su tutto il dominio negli ultimi 30 giorni
gam report login ip <indirizzo_IP> start -30d todrive

# Attività Gmail registrate per quell'IP nelle 48 ore
gam report gmail ip <indirizzo_IP> start -2d todrive

# Verifica dei token OAuth o browser associati a quell'IP
gam report token ip <indirizzo_IP> start -30d todrive

Un dettaglio a cui fare attenzione: i log di Google Workspace riportano gli orari in formato UTC. Prima di confrontarli con quello che raccontano gli utenti, bisogna ricordarsi di aggiungere l’ora solare o legale italiana, altrimenti i conti non tornano.

Cosa è successo agli altri colleghi (e il ruolo della rete interna)

Un aspetto interessante dell’episodio riguarda quello che è successo subito dopo l’invio delle mail di phishing. Tra i destinatari c’erano anche altri colleghi dell’organizzazione. E come capita spesso quando si lavora di fretta, un paio di persone hanno aperto il messaggio e hanno cliccato sul link senza farsi troppe domande.

È la classica reazione spontanea davanti a una mail apparentemente plausibile, ed è esattamente il motivo per cui l’educazione degli utenti è così importante. In questo caso, però, ci è andata bene per via di come è impostata la nostra rete: chi ha cliccato mentre era connesso alla rete interna dell’ufficio non ha avuto conseguenze, perché il dominio malevolo è stato bloccato direttamente dai filtri DNS e dalle regole del firewall che usiamo per la navigazione. La pagina non si è aperta e il browser ha mostrato direttamente la schermata di blocco.

La differenza sta tutta qui: la prima utente si trovava fuori sede, collegata dal cellulare con la connessione dati mobile, dove ovviamente quel tipo di filtro di rete non era presente. All’interno dell’ufficio invece il blocco perimetrale ha fatto il suo lavoro e ha evitato guai peggiori.

Questo dimostra bene l’utilità delle protezioni a livello di rete, ma fa anche capire che non possono essere l’unica linea di difesa: quando le persone lavorano fuori ufficio, da casa o dallo smartphone, la sicurezza dipende tutta dalla loro capacità di riconoscere una mail sospetta.

I limiti della console Workspace

Dopo l’accaduto ho verificato se fosse possibile impostare un blocco automatico per un utente che comincia a inviare centinaia di mail all’improvviso. Con gli strumenti nativi della console standard ci sono dei limiti:

• I limiti di invio di Gmail sono fissi: circa 2.000 messaggi al giorno e fino a 500 destinatari esterni per invio. Un amministratore non può abbassare queste soglie; quattro invii da qualche centinaio di destinatari ci rientrano tranquillamente.
• Le regole di attività sono cumulative sul dominio: si può creare una regola per contare gli invii, ma la soglia vale per l’intero tenant. Se si attiva l’azione “Sospendi utente”, si rischia di sospendere tutti quelli che hanno inviato una mail in quel lasso di tempo.
• La sospensione per spam di Google: esiste un filtro euristico automatico, ma i tempi di intervento non sono configurabili e su invii concentrati in pochi minuti spesso non fa in tempo a intervenire.

Una regola di attività resta utile come allarme visivo sul traffico complessivo; per un blocco selettivo sul singolo account serve invece uno script esterno tramite API che controlli i log a intervalli regolari.

Cosa ho cambiato dopo l’incidente

La verifica in due passaggi era già in programma, ma come succede spesso nelle organizzazioni si tendeva a rimandare per non creare disagi agli utenti. Questo episodio ha chiuso ogni discussione. Nel configurare le novità ho cercato misure che proteggessero bene senza complicare troppo la vita quotidiana:

1. Verifica in due passaggi (2SV) obbligatoria, con Passkey: le Passkey non si possono inserire su una pagina falsa perché legate crittograficamente al dominio autentico (google.com) e per l’utente sono comode, bastando l’impronta o il PIN del dispositivo. Da sole avrebbero bloccato questo attacco all’origine.
2. Notifiche del Centro Avvisi (Alert Center): avvisi email per accessi insoliti, credenziali compromesse e anomalie di invio.
3. Navigazione sicura e protezione password in Chrome: attivate tramite criteri gestiti dalla console, avvisano l’utente se prova a digitare la password aziendale su siti esterni non Google.
4. DKIM e DMARC: verifica delle firme e passaggio controllato di DMARC verso p=reject, monitorando i report RUA per non bloccare comunicazioni legittime.
5. Integrazione sulle postazioni: gestione dell’accesso ai PC Windows tramite Google Credential Provider for Windows (GCPW), per allineare le credenziali di sistema con quelle di Workspace.

La formazione conta più delle impostazioni

Tutti gli accorgimenti tecnici che ho elencato riducono il rischio, ma non lo azzerano del tutto. In questo caso la mail iniziale era passata perché formalmente corretta, ed è stata una persona — il collega che ha fatto una semplice domanda — a far partire la reazione.

Per questo motivo considero la formazione pratica delle persone la misura più importante, purché sia fatta con buon senso:

• Breve e concreta: dieci minuti passati ad analizzare una vera mail di phishing catturata sul campo insegnano più di due ore di slide teoriche.
• Poche regole pratiche: se clicchi un link e ti viene chiesta la password, fermati un secondo e guarda l’indirizzo della pagina. Se una mail di un collega o fornitore sembra strana, fai una verifica su un altro canale (telefono o messaggio).
• Niente colpevolizzazioni: chi fa un errore deve poterlo dire subito senza timore di essere rimproverato. Più tempo passa in silenzio, più margine ha l’attaccante per muoversi.
• Un canale chiaro di supporto: tutti devono sapere a chi rivolgersi per un controllo o per richiedere assistenza informatica. Un falso allarme gestito rapidamente fa sì che l’utente segnali di nuovo la volta successiva.

Cosa fare se capita a voi: le prime mosse

Se un account del vostro dominio comincia a spedire phishing, l’ordine delle operazioni conta:

1. Bloccare l’account: reimpostate la password, disconnettete tutte le sessioni attive o sospendete temporaneamente l’utente.
2. Revocare i token: revocate token OAuth, password per le app e l’autorizzazione di Chrome se l’attaccante ha associato un browser.
3. Esportare i log prima di toccare altro: accessi, Gmail, Drive e token per almeno 30 giorni.
4. Cercare gli IP su tutto il dominio: per verificare se altri account sono stati coinvolti.
5. Salvare le intestazioni complete della mail esca: prima di cancellarla dalle caselle con lo strumento di indagine (altrimenti l’allegato originale va perso).
6. Avvisare i destinatari esterni: le mail già consegnate all’esterno non si possono richiamare, quindi è corretto informare i destinatari di non aprire link o allegati.
7. Valutare l’aspetto privacy: un accesso non autorizzato a una casella può costituire una violazione di dati personali. Il GDPR dà 72 ore per valutare la situazione con il referente privacy o DPO.

Equilibrio tra sicurezza e lavoro quotidiano

Dopo un incidente la tentazione sarebbe quella di bloccare tutto. Ma ogni misura di sicurezza ha un costo pratico per chi deve lavorare ogni giorno. Se il costo è troppo alto, le persone finiscono per cercare scorciatoie non autorizzate: documenti condivisi su WhatsApp, file inviati alla mail personale, password scritte sui foglietti. A quel punto la sicurezza reale peggiora, anche se sulla carta sembra aumentata.

Il criterio migliore è dare la priorità alle misure che lavorano in silenzio — come le passkey, i filtri di rete ben tarati e le policy DMARC — e spiegare chiaramente il perché di quelle che chiedono un piccolo sforzo in più. Una persona che sa riconoscere una mail sospetta protegge l’organizzazione anche quando la tecnologia non basta.

Domande Frequenti (FAQ)