APT36 persiste nello spionaggio contro India: Windows e Linux nel mirino, tra GETA RAT, ARES RAT e Desk RAT

APT36, noto anche come Transparent Tribe, non “esplode” in tattiche appariscenti perché non ne ha bisogno. La sua forza, come evidenzia Aryaka Threat Research Labs, sta nella continuità: un ecosistema di spionaggio che opera da oltre un decennio e che continua a produrre accesso e intelligence senza cambiare pelle a ogni ciclo mediatico. L’obiettivo resta stabile e altamente selettivo, con un focus su governo e difesa indiani, ma ciò che cambia è la profondità del tooling, soprattutto quando la stessa mano dimostra di saper ragionare in modo credibile su Windows e Linux. In altre parole: non è una minaccia “nuova”, è una minaccia che non smette mai e che aggiorna la propria cassetta degli attrezzi abbastanza da restare sotto il rumore. Il quadro che emerge è quello di una collaborazione e di una continuità operativa con SideCopy, descritta come parte di un cluster più ampio che punta a intelligence a lungo termine. È una dinamica importante perché spiega la resilienza delle campagne: quando un gruppo non è una singola unità ma un insieme di “capacità” condivise, diventa più semplice mantenere accesso persistente, ruotare infrastrutture, cambiare catene di consegna e ripartire senza ricostruire tutto da zero. Qui l’evoluzione non è “reinvenzione”, è affinamento, e la somma di piccoli miglioramenti produce un grande effetto strategico.

Transparent Tribe e la logica della persistenza: spionaggio senza rumore, ma con attrito per i difensori

Il tratto ricorrente di APT36 è la disciplina del tradecraft: spear-phishing, documenti o contenuti “weaponizzati”, e l’uso di trojan di accesso remoto che non devono necessariamente essere sofisticati in senso assoluto, ma devono essere sufficientemente affidabili da durare. Questa filosofia riduce la necessità di tool “flashy” e aumenta la probabilità di successo contro target che spesso hanno processi rigidi e un perimetro che si difende soprattutto sul piano visibile, cioè su firme e indicatori statici. Quando una catena d’infezione lavora su esecuzione in memoria, su canali C2 covert e su abuso di componenti legittimi, l’attrito passa dal blocco “a priori” alla caccia comportamentale “a posteriori”. È proprio questo che Aryaka mette in evidenza come esigenza di base: visibilità cross-platform. Non perché Linux sia “nuovo” nello spionaggio, ma perché sempre più ambienti governativi e di difesa sono ibridi, e un attore che sa muoversi tra endpoint Windows, sistemi Linux, ambienti di sviluppo e infrastruttura può mantenere sorveglianza continua senza doversi esporre con exploit rumorosi. La maturità si vede quando un gruppo tratta Linux non come un esperimento, ma come una piattaforma su cui costruire persistenza e raccolta dati in modo credibile.

GETA RAT su Windows: LNK e HTA come miccia, mshta.exe e XAML come evasione

Una delle campagne osservate su Windows parte da un pattern che i difensori conoscono bene, ma che continua a funzionare perché è allineato al comportamento umano: phishing con allegati o risorse che includono file LNK e HTA, usati per far partire la catena di esecuzione. Il punto non è il formato in sé, è la capacità di inserirlo in un contesto di fiducia. Da lì, la catena porta a GETA RAT, un RAT in .NET che punta a rimanere “leggero” e a sfruttare strumenti legittimi per evitare controlli file-based. Qui emerge un dettaglio tecnico che merita di essere evidenziato perché racconta un’evoluzione concreta: l’abuso di mshta.exe e l’uso di XAML per un passaggio di evasione che si appoggia alla deserializzazione e che consente payload più difficili da bloccare con controlli statici. Quando un’infezione si sposta verso esecuzione in memoria, la difesa basata su file e hash perde efficacia, e il difensore deve spostarsi su telemetria di processo, relazioni parent-child, pattern di runtime e anomalia di rete. L’altro elemento che rende la campagna coerente con un attore “persistente” è la persistence layered. Non è un singolo meccanismo di startup, è una stratificazione che mira a sopravvivere a riavvii, pulizie parziali e remediation non completa. È la stessa logica dell’APT classico: se perdi un foothold, non vuoi perdere l’operazione. Vuoi rientrare. E vuoi farlo senza dover ripassare dall’intera catena di social engineering.

ARES RAT su Linux: downloader Go, RAT Python e persistenza con systemd

La parte Linux del quadro è quella che, oggi, cambia più rapidamente le priorità operative delle aziende e delle organizzazioni pubbliche, perché molte difese restano sbilanciate su Windows anche quando la superficie reale include server, jump host, ambienti DevOps e toolchain su Linux. In questa campagna, APT36 usa un downloader in Go per installare ARES RAT, un RAT basato su Python che non nasce per “fare scena”, ma per fare lavoro: profilare sistemi, enumerare file e esfiltrare dati. La scelta di un downloader in Go è pragmatica: portabilità, facilità di compilazione statica e buone possibilità di passare in ambienti dove si lavora con binari custom e strumenti interni. A quel punto, il RAT in Python offre flessibilità per operazioni di raccolta, e l’elemento che completa la catena è la persistenza: servizi systemd, spesso in contesto user, che permettono al malware di sopravvivere ai reboot e di integrarsi nella routine del sistema senza necessariamente attirare attenzione immediata. Qui la parola chiave è blend-in: non serve dominare la macchina, serve restare. Questo passaggio è particolarmente rilevante perché sposta l’attenzione dalla “difesa del singolo endpoint” alla difesa di una piattaforma che spesso viene monitorata meno, specialmente quando i log Linux non sono integrati in modo coerente in un SIEM o quando l’osservabilità si ferma a metriche di disponibilità. APT36, in questo quadro, sfrutta una debolezza comune: la fiducia operativa in ambienti Unix, dove molte attività legittime hanno già un profilo “tecnico” e quindi l’anomalia è più difficile da distinguere a colpo d’occhio.

🔴 OSSERVATORIO INTELLIGENCE: LIVE

Annuncio

Desk RAT: add-in PowerPoint come vettore e telemetria real-time via WebSocket

Se la parte Windows mostra un abuso di meccanismi storici (LNK/HTA, mshta.exe), e la parte Linux mostra maturità di persistenza (systemd), Desk RAT aggiunge un tassello che merita attenzione perché porta lo spionaggio dentro un formato che molte organizzazioni trattano come “benigno”: un add-in PowerPoint malevolo. Qui la consegna non è solo una questione di allegato, è una questione di contesto: un add-in si presenta come estensione funzionale e può vivere in ambienti in cui gli utenti si aspettano personalizzazioni. Desk RAT, descritto come basato su Go, enfatizza la raccolta di telemetria host e il monitoraggio in tempo reale. Il dettaglio del C2 via WebSocket è cruciale: un canale persistente e strutturato, con heartbeat e scambi regolari, che abilita una forma di situational awareness più “interattiva” rispetto al C2 tradizionale a polling. Quando l’attaccante può osservare e reagire con maggiore immediatezza, aumenta la capacità di restare invisibile e di modulare le azioni in base a ciò che vede, riducendo il rischio di generare indicatori evidenti. Questo spiega perché Aryaka parla di obiettivi “stealthy”: Desk RAT sembra progettato meno per l’azione distruttiva e più per il controllo continuo, per la raccolta incrementale e per l’adattamento operativo. È un approccio coerente con un attore che punta a governi e difesa: non serve bloccare servizi, serve capire, osservare, copiare, mappare e restare.

SideCopy e l’ecosistema: quando la persistenza è un modello industriale

Il collegamento tra APT36 e SideCopy va letto come capacità di continuità, non come semplice etichetta. Quando un cluster collabora o condivide risorse, la resilienza aumenta perché la campagna non dipende da una singola infrastruttura, da un singolo malware o da un singolo metodo di delivery. Se una catena viene interrotta, l’operazione può proseguire con un vettore alternativo. Se un RAT viene rilevato, un altro può garantire un foothold. Se un canale C2 viene disturbato, un canale covert può prendere il suo posto. Questa struttura “a ecosistema” è la ragione per cui gli APT durano più dei cicli difensivi standard. Un’organizzazione può migliorare un controllo e vedere calare un tipo di evento, ma se non aggiorna anche l’osservabilità, la governance degli endpoint e la risposta incident, l’attore può semplicemente spostarsi su un altro percorso. È il motivo per cui la difesa non può essere solo “bloccare indicatori”: deve essere progettata per riconoscere pattern comportamentali e per ridurre la possibilità di persistenza anche quando l’accesso iniziale avviene.

Perché questo caso conta nel 2026: la lezione cross-platform e la difesa “di contesto”

La conclusione operativa, senza trasformarla in un elenco sterile, è che il caso APT36 dimostra tre priorità che, oggi, separano le organizzazioni resilienti da quelle esposte. La prima è la capacità di leggere catene che abusano di componenti legittimi come mshta.exe, perché l’attaccante si nasconde proprio dove il sistema “si aspetta” attività. La seconda è la capacità di gestire Linux con la stessa serietà con cui si gestisce Windows, perché la persistenza via systemd e i downloader cross-platform mostrano che il perimetro reale non è più monolitico. La terza è riconoscere che l’Office ecosystem può essere vettore, e che un add-in di PowerPoint può diventare una porta di telemetria e controllo, con un C2 moderno come WebSocket. APT36 non ha bisogno di reinventare lo spionaggio. Gli basta farlo bene, a lungo, e su più piattaforme. E quando un attore lavora “below the noise floor”, il difensore deve spostare l’attenzione dal singolo IOC al contesto, dalla firma al comportamento, e dall’endpoint isolato alla visibilità unificata.