Spionaggio nel cloud: Google smantella Gridtide, la rete cinese che usava i “fogli di calcolo” per rubare dati di Stato

Quando un attore di cyber spionaggio riesce a trasformare un servizio quotidiano in un canale di comando e controllo, la differenza tra traffico legittimo e traffico ostile smette di essere un problema teorico e diventa una questione di difesa operativa. La campagna Gridtide, attribuita da Google Threat Intelligence Group all’attore Unc2814 collegato alla Repubblica Popolare Cinese, si muove esattamente in questo spazio grigio: sfrutta infrastrutture e Api cloud per confondersi, mantenere persistenza, esfiltrare informazioni e rendere più costoso il rilevamento. L’interruzione annunciata da Google, condotta in collaborazione con Mandiant, punta a tagliare il cuore della catena: progetti cloud controllati dagli aggressori, account Google Workspace usati per operazioni malevole, domini e infrastrutture storiche impiegate per mantenere la campagna viva dal 2023 e, secondo il tracciamento, con un attore attivo almeno dal 2017. Il dato che pesa, oltre la retorica, è il perimetro: telecomunicazioni e organizzazioni governative in 42 paesi confermati, con un numero di vittime osservate che arriva a 53 e il sospetto di estensione in ulteriori aree. Non è un incidente isolato, non è un episodio rumoroso e breve. È una campagna pensata per durare, adattarsi e sfruttare la fiducia implicita che molte reti attribuiscono ai servizi cloud “di tutti i giorni”. Ed è proprio qui che l’operazione di disruption diventa interessante: non si limita a pubblicare indicatori, ma interviene su asset e account per rendere più difficile ripristinare il canale C2 nello stesso modo.

Unc2814 e la logica di Gridtide: spionaggio, telecom e raccolta Pii

La fotografia che emerge è quella di un attore orientato allo spionaggio nazionale, con un interesse ricorrente per il mondo telco. Non è un dettaglio neutro: entrare in una rete di telecomunicazioni significa potenzialmente ottenere visibilità su metadata, flussi, interconnessioni e infrastrutture che sostengono comunicazioni di massa. In questo contesto la raccolta di Pii, cioè dati personali identificativi come nome, numero di telefono e data di nascita, non appare come un “furto” generico, ma come un tassello utile a profilazione, sorveglianza e operazioni mirate, incluse ipotesi di monitoraggio di dissidenti o target specifici.

Google colloca Unc2814 in una traiettoria autonoma, chiarendo che non si tratta di una sovrapposizione con altri cluster come Salt Typhoon. Questa distinzione conta perché sposta l’attenzione dall’etichetta geopolitica alla sostanza operativa: catena d’attacco, infrastrutture, tradecraft, obiettivi, strumenti. In un’epoca in cui molte attribuzioni rischiano di diventare scorciatoie narrative, la differenza la fanno i dettagli di esecuzione e, soprattutto, la ripetibilità della detection.

Il punto di ingresso: exploit su server web e sistemi edge

La campagna descritta si basa su un accesso iniziale ottenuto tramite compromissione di server web e sistemi edge, con riferimento a exploit non identificati nel dettaglio. Anche senza nominare una vulnerabilità specifica, il messaggio è chiaro: la superficie esposta, soprattutto nei perimetri dove convivono appliance, reverse proxy, servizi web e gestione remota, resta il punto dove la sicurezza si gioca in silenzio. Una volta dentro, l’attore riduce al minimo la “firma” usando tecniche living-off-the-land, cioè sfruttando binari e strumenti già presenti per evitare di introdurre payload facilmente classificabili.

È qui che la campagna assume il suo profilo più moderno: non serve saturare la rete di malware rumoroso se puoi muoverti con tool legittimi, script, sessioni Ssh e account di servizio. La conseguenza, per chi difende, è immediata: il confine tra amministrazione e intrusione diventa una questione di contesto, sequenza e anomalia, non di semplice presenza di un eseguibile malevolo.

Gridtide come backdoor: /var/tmp, systemd e persistenza “ordinaria”

Il backdoor Gridtide viene descritto come un impianto operativo in grado di eseguire comandi shell, caricare e scaricare file, mantenere un loop di comunicazione con l’esterno e gestire meccanismi di pulizia. L’installazione in percorsi come /var/tmp/xapt e l’esecuzione con comandi del tipo nohup ./xapt indicano un approccio pragmatico: posizionare l’impianto in directory spesso meno monitorate, mantenere processi stabili e ridurre la dipendenza da servizi visibilmente sospetti. La persistenza tramite systemd, con unit file in /etc/systemd/system/xapt.service e binario richiamato da /usr/sbin/xapt, è un passaggio cruciale perché normalizza l’anomalia. Systemd, nelle infrastrutture Linux moderne, è una componente strutturale. Se un servizio malevolo viene registrato in modo credibile e con naming coerente, può restare in esecuzione senza attivare allarmi banali. Il risultato è un’operazione che non punta a “nascondersi” in senso cinematografico, ma a diventare parte dell’ordinario. Ed è questa ordinarietà che, nei SOC, diventa spesso il vero problema.

Il salto di qualità: command-and-control su Google Sheets Api

Il cuore della storia è l’abuso di Google Sheets Api come canale C2. Gridtide usa un modello che, in pratica, converte un foglio in una bacheca di comandi e risposte: polling di una cella per ottenere istruzioni, invio di output ed esfiltrazione in altre celle, e routine di “sanitizzazione” del foglio per ridurre tracce, con cancellazione di grandi porzioni di righe.

Il formato di comando descritto, con struttura -<command_id>-<arg_1>-<arg_2>, e la distinzione tra indicazioni lato client e lato server, racconta un protocollo minimale ma sufficiente per orchestrare operazioni. L’uso di codifiche come Base64 url-safe e la gestione del tempo, con cicli di polling rapidi e successiva randomizzazione tra 5 e 10 minuti dopo un numero elevato di tentativi senza comandi, mostra un’altra priorità: trovare un equilibrio tra reattività e invisibilità. Troppo polling crea rumore. Troppo poco polling riduce l’efficacia. La scelta di adattare i tempi suggerisce che l’attore ha maturato esperienza su cosa “passa” nei controlli di rete e cosa no. L’altro elemento di peso è l’autenticazione via chiave privata di account di servizio. Qui la campagna entra in una dimensione più complessa: non è solo abuso di un endpoint pubblico, è costruzione di un’identità cloud e di un canale che, finché non viene correlato a pattern anomali, può essere scambiato per integrazione legittima. In questo senso, Gridtide non “buca” Google Sheets: lo usa come chiunque potrebbe usarlo, ma con finalità ostili.

SoftEther Vpn Bridge: tunnel outbound e resilienza

Dal luglio 2018 viene citato anche l’uso di SoftEther Vpn Bridge, un componente che permette di creare tunnel outbound cifrati. In una campagna di lunga durata, avere un canale alternativo al C2 primario significa aumentare resilienza e flessibilità. Se il canale su Sheets viene degradato, un tunnel Vpn può mantenere accesso e movimento laterale, soprattutto in ambienti dove l’uscita verso internet è consentita ma la visibilità sui flussi è limitata o non correla correttamente i processi in esecuzione con le destinazioni. Anche qui torna la logica dell’ambiguità: SoftEther è un progetto legittimo. Il problema non è la presenza, ma il contesto, la catena di download, i path di installazione, la configurazione, le connessioni outbound e l’eventuale rinomina di componenti per evasione.

La disruption: cosa significa “interrompere” una campagna cloud-native

L’aspetto più interessante dell’intervento di Google e Mandiant è l’idea di disruption applicata a un avversario che usa il cloud come maschera e come leva. La scelta di terminare progetti Google Cloud controllati dall’attore e disabilitare account Google Workspace colpisce direttamente la capacità di mantenere identità e risorse operative. Il sinkholing di domini attuali e storici interrompe comunicazioni e riduce la possibilità di riattivare rapidamente infrastrutture già “collaudate”. Le notifiche formali alle vittime, se ben orchestrate, accelerano remediation e threat hunting, perché trasformano una minaccia latente in un incidente con una priorità definita. C’è poi un elemento che pesa per la difesa collettiva: l’integrazione di detection in Google SecOps, con firme e regole pensate per scovare pattern come esecuzione sospetta da directory var, creazione di file cfg in percorsi anomali, e traffico Https non-browser verso endpoint di Sheets. È un passaggio che sposta la discussione dal comunicato all’operatività, perché offre un percorso di hunting che può essere tradotto in query e alert reali.

Indicatori, hunting e la parte che interessa davvero ai SOC

Quando una campagna usa servizi cloud diffusi, il problema diventa la “qualità” del segnale. Un IoC isolato può essere utile, ma non basta se l’attore ruota infrastrutture e se i servizi usati sono legittimi. In Gridtide, gli indicatori host-based come binari e file di configurazione, unit systemd e componenti Vpn, assumono valore quando vengono correlati a comportamenti: eseguibili in /var/tmp che spawnano shell, servizi che avviano binari in /usr/sbin non riconducibili a pacchetti attesi, creazione e lettura ripetitiva di config con chiavi di cifratura, pattern di download da Ip e domini non coerenti con la baseline dell’organizzazione. Sul versante network-based, la chiave è evitare di trattare sheets.googleapis.com come “sempre buono” e basta. La detection citata sulla presenza di richieste Https non provenienti da browser, con operazioni Api specifiche come batch update e clear, è un esempio di come si può restringere il campo senza bloccare il servizio per tutti. La stessa logica vale per l’analisi degli user-agent, dei token, delle chiavi di servizio e delle frequenze di polling, soprattutto quando l’accesso alle Api avviene da server che non dovrebbero avere alcun motivo per interagire con Google Sheets. In parallelo, la parte più concreta per chi fa incident response è la mappa dei percorsi e dei processi: alberi di esecuzione che partono da /var/tmp e arrivano a /bin/sh, comandi lanciati con privilegi root, persistenze registrate e servizi creati di recente. È un tipo di telemetria che, se raccolta bene, permette di vedere l’intrusione anche quando l’attore ha poche “firme” statiche.

Cosa cambia per chi gestisce telecom e infrastrutture critiche

La campagna evidenzia un punto che le organizzazioni telco conoscono fin troppo bene: l’attaccante non ha bisogno di colpire il consumatore finale se riesce a ottenere visibilità a monte. Il valore operativo è nella rete, nelle interconnessioni, nei sistemi di gestione, nei server edge e nelle infrastrutture che reggono autenticazione e routing del traffico. La raccolta di Pii, in questo scenario, non è un bottino casuale. È materiale che può alimentare altre operazioni, arricchire profili, supportare campagne successive e rendere più efficace la selezione dei target. Per questo la disruption non va letta come “fine della storia”, ma come una finestra di vantaggio temporaneo. Un attore persistente può ricostruire. La differenza la fa la velocità con cui le vittime integrano IoC, trasformano le regole in monitoraggio continuo e riducono l’esposizione di servizi web ed edge. E la differenza la fa anche una disciplina che spesso manca: correlare identità cloud, chiavi di servizio, accessi Api e processi locali in un’unica narrativa di detection. Se queste dimensioni restano separate, l’attaccante può continuare a muoversi tra i vuoti.

Perché Gridtide è un caso scuola: il cloud come camouflage, non come bersaglio

Gridtide mostra un trend che ormai attraversa molte campagne di spionaggio: il cloud non viene “attaccato” come piattaforma, viene usato come camouflage. Se un’organizzazione si limita a filtrare “domini cattivi”, rischia di restare cieca davanti a un attore che opera dentro domini e servizi legittimi. La risposta non può essere bloccare tutto, perché sarebbe incompatibile con l’operatività moderna. La risposta diventa, inevitabilmente, una strategia basata su contesto, baseline, identità, pattern e telemetria. In questo senso, l’interruzione da parte di Google e Mandiant ha un valore che va oltre il singolo cluster Unc2814: normalizza l’idea che la difesa debba includere interventi su account, progetti, credenziali e risorse cloud usate come asset ostili.

E obbliga chi difende a una domanda scomoda: quanta fiducia automatica stiamo concedendo ai servizi cloud, e quante eccezioni abbiamo inserito nelle policy solo perché “è Google”, “è produttività”, “è traffico comune”?

Gridtide non è solo una backdoor su Linux. È un modello operativo in cui Api legittime, identità cloud e persistenza ordinaria si combinano per produrre spionaggio su scala globale. Ed è esattamente questo mix a renderlo pericoloso: non perché sia invisibile, ma perché sembra normale finché qualcuno non decide di guardare nel punto giusto.