Spionaggio nelle telecom: come la campagna Poisonous Mars usa finti tool Microsoft per rubare dati

Poisonous Mars è una campagna che mette in scena una verità scomoda della sicurezza moderna: non serve un arsenale “esotico” per fare spionaggio efficace, basta un mix di social engineering, componenti Windows, crittografia leggera e una catena di esecuzione costruita per confondersi con ciò che in azienda è già normale. Secondo l’analisi tecnica, gli attacchi vengono osservati nell’autunno 2025 in Kirghizistan e a gennaio 2026 in Tagikistan, con tracce che coinvolgono anche imprese cinesi. Il bersaglio privilegiato è il settore telecomunicazioni nei paesi CSI, un segmento dove il valore informativo non è solo nei documenti, ma nella rete di relazioni, contratti, apparati, accessi e logistica operativa. Il nome in superficie è LuciDoor, una backdoor caricata in modo riflessivo tramite un loader identificato come LuciLoad, costruito per sembrare un componente legittimo e, soprattutto, per agganciarsi a una semantica familiare: OneDrive, Microsoft, i percorsi “giusti”, i nomi “giusti”. In parallelo compare MarsSnake, un’altra famiglia che entra in gioco con una catena diversa, più legata a DLL side-loading e a tecniche di esecuzione che puntano a sfruttare binari apparentemente affidabili. Il risultato è un quadro a doppia pista: macro e immagini come contenitore di payload da un lato, side-loading e LNK/FTPlnk phishing dall’altro. Due strade che convergono nello stesso obiettivo: ottenere controllo remoto, raccogliere informazioni, esfiltrare e sparire lasciando il meno possibile.

Poisonous Mars nel contesto CSI: perché le telecom diventano terreno di spionaggio “ad alta densità”

Le telecom nei paesi CSI sono un bersaglio naturale per chi fa intelligence o spionaggio industriale: dentro un operatore ci sono mappe di rete, contratti e fornitori, configurazioni di apparati, dati di fatturazione e tariffazione, procedure di provisioning, relazioni con enti pubblici e, spesso, un patrimonio di metadati che racconta abitudini e spostamenti. Anche senza entrare in contenuti “sensibili” in senso stretto, la sola conoscenza di infrastruttura e processi consente a un attaccante di costruire vantaggi strategici, muoversi in modo più preciso, o alimentare campagne successive più mirate. In Poisonous Mars colpisce la scelta di mascherare tutto con un’estetica familiare: email provenienti da servizi Microsoft come Hotmail e Outlook, documenti che mimano software legittimo Microsoft, icone e nomi che richiamano componenti usati ogni giorno. È un disegno che riduce la probabilità che un utente, già immerso nella routine aziendale, si fermi davanti a un allegato. E quando si parla di telecom, spesso si parla di strutture dove l’operatività è continua, le inbox sono piene, e la priorità è “far funzionare” l’azienda. È lì che l’attaccante vince: non con la forza bruta, ma con la normalità apparente.

Un altro elemento che rende questa campagna interessante è l’ibridazione linguistica: documenti in russo con metadati che suggeriscono un contesto cinese, come l’impostazione eastAsia zh-CN, e l’uso di tool come Snipaste per preparare immagini. Questo tipo di dettaglio non è mai una prova definitiva, ma in operazioni di lungo periodo diventa un indicatore di “mano” e abitudine: un modo di lavorare che, ripetuto, finisce per lasciare impronte.

L’ingresso: phishing “Microsoft-like” e documenti con macro come acceleratore di esecuzione

Il punto di partenza è classico, ma curato. Le email di phishing arrivano da infrastrutture che non suonano “strane” a un utente, perché Hotmail e Outlook sono canali che possono comparire in contesti reali, soprattutto quando le organizzazioni dialogano con entità esterne, fornitori, partner o clienti. La lure citata ruota intorno a temi credibili per un operatore: tariffe, piani, pacchetti. Un esempio emblematico è un documento con titolo in russo, “Tарифные пакеты SIM-карт мобильных телефонов”, che simula un contenuto utile ma introduce un passaggio decisivo: spingere l’utente ad abilitare le macro.

La macro è il ponte tra il documento e l’esecuzione. L’analisi descrive macro offuscate che estraggono un payload codificato in esadecimale, quindi non “scaricano” necessariamente tutto in modo esplicito al primo colpo, ma ricostruiscono materiale che è già dentro il file o collegato a esso. Questa scelta ha un valore operativo chiaro: ridurre dipendenza da download evidenti e rendere la prima fase più resiliente contro blocchi di rete o filtri superficiali.

Il passaggio successivo è la scrittura su disco del loader, con un nome che è quasi una provocazione: Perfrom.exe in C:\ProgramData. È una posizione che ha due vantaggi: appare “di sistema” e può essere accessibile senza dover entrare in directory più controllate. In più, l’eseguibile usa un’icona che richiama OneDrive, cioè un brand e un elemento visivo che, nella testa dell’utente, significa “Microsoft, quindi affidabile”. È uno schema ripetuto: la fiducia non è nel codice, è nel contesto.

LuciLoad e la finestra OneDriveLauncher: il loader che prepara la scena per LuciDoor

Il loader, identificato come LuciLoad, introduce una componente quasi teatrale: crea una finestra nascosta chiamata OneDriveLauncher. Questo dettaglio serve a far combaciare l’esecuzione con un’immagine mentale già nota in azienda, ma soprattutto stabilisce una cornice coerente per i passaggi successivi. L’operazione poi entra nel merito tecnico con una sequenza di decifrature e decompressioni che, pur non essendo “innovative”, sono scelte proprio perché affidabili e leggere. La configurazione viene decifrata con RC4, usando una chiave indicata come microsoft. Anche qui il valore simbolico è evidente: la chiave non è solo una stringa, è un richiamo semantico che rafforza l’intero travestimento. Dentro la configurazione compaiono indicatori operativi come un C2 in forma hostname e porta, ad esempio button.gdakdbysw.xyz:443, e un timestamp di campagna come 0926, che suona come un marcatore interno per versioni o ondate. La parte più caratteristica è l’uso di immagini come contenitore. LuciLoad estrae e decripta immagini, poi le decomprime con LZNT1, una scelta coerente con ambienti Windows e con la necessità di restare “compatibili” senza includere dipendenze pesanti. Da quel materiale, il loader ricostruisce un modulo PE che viene caricato in modo riflessivo, cioè senza i passaggi “standard” che alcuni controlli si aspettano. Il PE è LuciDoor, e il loader chiama una funzione esportata passandole la configurazione. In sostanza, la macro non consegna direttamente la backdoor: consegna un loader che costruisce e lancia la backdoor con una sequenza pensata per essere poco rumorosa.

LuciDoor: persistenza leggera, proxy-aware e comandi orientati alla raccolta e all’esfiltrazione

Una volta attivo, LuciDoor mostra un design orientato a operazioni rapide, con un set di capacità che punta a fare il necessario senza diventare “ingombrante”. La persistenza descritta non è una persistenza da manuale APT ultra-complesso, ma è sufficiente per mantenere il controllo: il malware verifica condizioni, può spostarsi in percorsi che imitano componenti Microsoft, come %ProgramData%\Microsoft OneDrive\setup\ e rinominarsi coerentemente, ad esempio come OneDriveLauncher.exe. A quel punto crea un task schedulato con nome coerente, come OneDrive Launcher, in modo da fondersi nel rumore operativo.

Sul piano di rete, LuciDoor è interessante perché è proxy-aware. Prima prova una connessione diretta via TCP, poi valuta l’uso del proxy di sistema o connessioni attive su porte proxy, supportando meccaniche come HTTP CONNECT e anche SOCKS4/SOCKS5. Questo è un punto chiave per ambienti telecom e enterprise: molte reti hanno uscita controllata, e un backdoor che sa adattarsi al proxy aumenta enormemente la probabilità di “parlare” con il C2.

La raccolta iniziale include informazioni che sembrano standard ma sono decisive per l’operatore: nome DNS, versione OS, utente, architettura, LCID, e coppie IP:porta, insieme a parametri come timestamp campagna e delay. È la fase di fingerprinting che consente al controller di capire che tipo di macchina ha davanti e come usarla. I comandi descritti indicano una logica di controllo remoto “classica” ma efficiente: esecuzione di shell, input e terminazione, più un canale per trasferimento file e gestione di segmenti. Il dettaglio della console con Lucida Console 11×18 e code page UTF-8 è rivelatore: l’operatore vuole leggere output in modo pulito, con supporto a caratteri, e vuole farlo con un’impostazione prevedibile. Anche qui non c’è glamour, c’è produzione.

La comunicazione è descritta come strutturata, con body XOR-encrypted e marker di messaggio, e controlli di magic value, ad esempio 123. La scelta di un User-Agent che richiama vecchie compatibilità, come un “Mozilla/1.5 compatible Firefox”, è un ulteriore tentativo di restare nel traffico “normale”, riducendo la probabilità di far emergere anomalie troppo moderne o troppo specifiche.

MarsSnake: la seconda pista, tra DLL side-loading e FTPlnk phishing

La campagna non si limita a LuciDoor. Entra in gioco MarsSnake, e lo fa con un meccanismo diverso, spesso più adatto a bypassare controlli applicativi: DLL side-loading. Qui il pattern è quello di sempre, ma ancora una volta la forza è nell’esecuzione pulita: un binario legittimo viene affiancato a una DLL malevola con un nome atteso, così che l’applicazione carichi la DLL senza sospetti. Nell’autunno 2025, ad esempio, viene citato l’uso di un eseguibile legittimo come Plasrv.exe insieme a una PDH.DLL malevola, collocati in un percorso che richiama componenti Microsoft come PlayReady. È un travestimento nel travestimento: non solo “sembra Microsoft”, ma “sembra una parte secondaria di Microsoft” che pochi sanno riconoscere. MarsSnake si carica tramite un loader che decripta con RC4 usando una chiave specifica e poi decomprime con DEFLATE, ricopiando in memoria l’eseguibile e iniettando configurazione, incluso un C2 con più opzioni. La generazione dell’ID di sistema, combinando informazioni come nome macchina, IP locale e username, e poi trasformandole con una logica di hashing e XOR, indica un’attenzione all’identificazione stabile delle vittime, necessaria per gestire infrastruttura e sessioni. La comunicazione C2, in questo caso, adotta un profilo diverso: richieste POST verso un percorso che sembra una risorsa web leggera, come /eg.js?t=unix_time, con body offuscato e cifrato, includendo AES-128 ECB con una chiave definita. Anche qui il punto non è la perfezione crittografica, ma l’operatività: rendere il contenuto non leggibile al volo, mantenendo però un protocollo semplice da implementare e replicare. La variante osservata in contesti legati alla Cina introduce un ulteriore pezzo: FTPlnk phishing con file .lnk che lanciano script BAT. È un ritorno a tecniche “antiche” che funzionano perché l’abitudine vince sulla prudenza. Il BAT crea componenti come help.vbs, copia o ricompone binari in C:\ProgramData, e mima directory e percorsi di installazione che suonano legittimi, come quelli legati a Oracle Java. L’idea è sempre la stessa: far sembrare l’infezione un’operazione di routine, magari un installer, un cache, una dipendenza.

Kirghizistan, Tagikistan, Cina: la campagna che cambia pelle mantenendo la stessa grammatica

Uno dei segnali più importanti di Poisonous Mars è la capacità di variare senza cambiare. In Kirghizistan, nell’autunno 2025, la catena macro-loader-backdoor appare con un set di C2 e indicatori coerenti, e in parallelo si osserva side-loading con MarsSnake. In Tagikistan, a gennaio 2026, la consegna evolve, includendo email con link a risorse di download che portano a documenti aggiornati, con immagini e grafiche rinfrescate. Anche il loader cambia nome, diventando per esempio explorer.exe, un’ulteriore scelta per confondersi nel rumore di sistema. Il C2 può passare da un hostname a un IP, come 93.157.106.75, mantenendo la stessa logica. In Cina la pista si arricchisce con archivi, LNK, e un modo diverso di preparare il pacchetto, con metadati e dettagli che sembrano costruiti per essere credibili in un contesto interno. Anche qui non è necessario ipotizzare un’unica “operazione monolitica”. È più realistico leggere Poisonous Mars come una campagna modulare, con kit e varianti che gli operatori adattano a seconda del bersaglio e delle opportunità.

Attribuzione e sovrapposizioni: UnsolicitedBooker, tracce eastAsia zh-CN e l’ombra di Space Pirates

L’attribuzione tecnica, quando si parla di campagne così, è sempre un gioco di probabilità, non un timbro notarile. In questo caso viene indicata una possibile connessione con un gruppo attribuito come UnsolicitedBooker, con sovrapposizioni a TTP osservate in altri scenari e richiami a cluster come Space Pirates. I segnali che vengono descritti includono documenti in russo con metadati cinesi, l’uso di strumenti come Snipaste, e la presenza di tool rari di origine cinese. Sono elementi che, presi singolarmente, possono avere spiegazioni alternative. Presi insieme, suggeriscono un’impronta operativa che merita attenzione, soprattutto perché la campagna tocca contemporaneamente paesi CSI e aziende cinesi, cioè un perimetro geografico che raramente è casuale. Anche l’uso di infrastrutture “intermedie”, come router compromessi e componenti TLS su porta 443, rientra nel modello moderno di C2: ridurre esposizione, non ospitare tutto su server facilmente attribuibili, sfruttare nodi terzi e far sembrare il traffico un normale HTTPS. In un settore come le telecom, dove i flussi sono enormi e la complessità è alta, la mimetizzazione è più facile.

Cosa rende Poisonous Mars pericolosa: l’illusione del “troppo semplice per essere APT”

Il rischio più grande di campagne come Poisonous Mars è psicologico: sembrano “banali”, quindi vengono sottovalutate. Macro, RC4, LNK, side-loading, sono tecniche note. Ma proprio perché note, spesso convivono con procedure aziendali che non riescono a eliminarle del tutto. Le macro continuano a riemergere in mille forme, perché l’ecosistema documentale è vasto e perché la pressione operativa porta a cliccare. Il side-loading continua a funzionare, perché molte applicazioni e componenti Windows mantengono comportamenti di caricamento che possono essere sfruttati se l’attaccante controlla la directory di esecuzione. I LNK continuano a ingannare, perché un collegamento “sembra” un file innocuo e spesso viene trattato come tale. In più, Poisonous Mars insiste su una strategia che funziona bene contro difese disallineate: costruire un mondo coerente di segnali “Microsoft”. Nomi, icone, percorsi, attività schedulate, tutto converge sulla stessa narrativa. L’utente non deve credere al contenuto del documento, deve credere al contesto. E in aziende dove Microsoft è l’ossatura dell’operatività, il contesto è già una garanzia emotiva.

Implicazioni operative per aziende telecom: perché questa campagna parla di processi, non solo di malware

Per le telecom, il punto non è solo “bloccare un hash” o “segnare un dominio”. Il punto è riconoscere che Poisonous Mars sfrutta processi: come vengono gestiti allegati e link, come vengono autorizzate macro, come vengono trattati eseguibili in ProgramData, come viene controllata la creazione di task schedulati con nomi plausibili. La campagna suggerisce anche una lezione sulla telemetria: se un endpoint esegue un binario con icona OneDrive da C:\ProgramData e crea un task “OneDrive Launcher”, il problema non è solo che quel binario è malevolo, ma che quel comportamento può passare come “normale” se non esiste un baseline ben definito. La presenza di proxy-aware C2 indica inoltre che la semplice restrizione dell’uscita Internet non basta se il malware sa usare proxy di sistema e tunnel come HTTP CONNECT. Serve osservare le correlazioni: processi che avviano Edge in modalità anomala, script che creano file VBS e BAT in percorsi di sistema, side-loading in directory legate a componenti secondari. Poisonous Mars non richiede exploit sofisticati: richiede che una singola persona abiliti una macro o apra un contenuto nel modo sbagliato.