OctLurk e SilkLurk spiano governi e ministeri dell’Asia centrale

🛡️ Executive Summary

• OctLurk e SilkLurk colpiscono dal 2025 governi, ministeri, forze dell’ordine, sanità, ricerca e istruzione nell’Asia centrale.
• I loader usano dati specifici del computer per decifrare backdoor modulari eseguite in memoria, ostacolando analisi e rilevamento automatico.
• La risposta richiede ricerca di servizi e task anomali, controllo delle credenziali, segmentazione e analisi dei movimenti laterali già avvenuti.

Kaspersky GReAT ha identificato due backdoor finora sconosciute, OctLurk e SilkLurk, impiegate dal gennaio 2025 in una campagna di cyber spionaggio contro organizzazioni governative e pubbliche dell’Asia centrale. Le vittime si trovano in Afghanistan, Kirghizistan, Tagikistan, Uzbekistan e Kazakhstan, con ulteriori compromissioni osservate nella Repubblica araba siriana. Gli attaccanti colpiscono ministeri degli Esteri, forze dell’ordine, strutture sanitarie, centri di ricerca, enti logistici, amministrazioni urbane e istituti scolastici. Le due backdoor condividono architettura, infrastrutture e procedure operative, ma Kaspersky attribuisce la campagna soltanto con media confidenza a un attore di lingua cinese non ancora associato a un gruppo APT conosciuto.

OctLurk e SilkLurk colpiscono il settore pubblico

La selezione delle vittime indica un’operazione orientata alla raccolta informativa e alla permanenza di lungo periodo più che alla monetizzazione immediata. I settori osservati comprendono diplomazia, sicurezza pubblica, ricerca, sanità, logistica, pianificazione urbana e amministrazione degli edifici, offrendo agli operatori accesso a comunicazioni istituzionali, credenziali, documenti interni e reti governative. Lo scenario si inserisce in una regione già attraversata da campagne concorrenti, come Double-Tap contro obiettivi diplomatici dell’Asia centrale e BarrelFire contro il settore energetico del Kazakhstan. Kaspersky ha osservato sistemi sui quali SilkLurk e OctLurk erano presenti contemporaneamente, elemento che, insieme alle similitudini del codice e delle procedure, sostiene l’ipotesi di un unico operatore. Non è stato invece ricostruito pubblicamente il vettore di accesso iniziale per tutte le vittime: il rapporto parte da sistemi già compromessi e documenta soprattutto distribuzione, persistenza e attività successive. L’assenza di una catena iniziale completa impone quindi cautela nel descrivere phishing, vulnerabilità o supply chain come origine certa dell’operazione.

I loader si legano al computer della vittima

Entrambe le famiglie utilizzano loader personalizzati che decifrano il payload soltanto sul dispositivo previsto dagli aggressori. OctLurk combina una chiave incorporata nel codice con il numero seriale dell’unità C:, mentre SilkLurk deriva parte del materiale necessario dal nome del computer. Il payload viene sottoposto a una doppia operazione XOR, decompresso con zlib e iniettato riflessivamente nella memoria del processo, lasciando sul disco soprattutto il loader minimale. Una copia prelevata da una macchina compromessa può quindi non funzionare correttamente in un laboratorio che non riproduce gli stessi dati ambientali, rallentando reverse engineering, sandboxing e generazione automatica delle firme. Gli operatori creano servizi Windows e attività pianificate con nomi progettati per confondersi con componenti di sistema, tra cui GoogleUpDate, NgcCIntSvc, Cusrxsrv, PNRPHostSvc e varianti che richiamano Hyper-V o servizi Microsoft. Il modello ricorda altre operazioni cinesi basate su loader personalizzati e componenti in memoria, come GoSerpent contro governi e diplomatici del Sud-est asiatico e il ritorno di Daxin con la backdoor Stupig e persistenza prima del login. La personalizzazione per vittima non rende invisibile l’attacco, ma riduce l’efficacia delle difese che dipendono esclusivamente da hash e campioni eseguibili trasferibili tra ambienti.

OctLurk carica plugin direttamente nella memoria

Dopo l’avvio, OctLurk raccoglie versione del sistema operativo, nome del computer, utente, hostname, indirizzo IP e data locale, quindi comprime e cifra i dati prima di inviarli al server di comando e controllo sulla porta 443. La backdoor riceve comandi o plugin con lo stesso protocollo personalizzato e li carica direttamente in memoria. I moduli individuati includono una shell remota, un file manager e un interaction manager capace di catturare schermate, leggere e modificare gli appunti e simulare movimenti del mouse e pressioni dei tasti. Il file manager consente ricerca, lettura, copia, spostamento, eliminazione e creazione dei file, oltre alla modifica delle relative date per ridurre le tracce temporali. La shell può eseguire comandi attraverso cmd.exe, raccoglierne l’output in file temporanei e cancellarli dopo l’invio. Questa architettura modulare permette agli operatori di mantenere un impianto iniziale relativamente compatto e scaricare soltanto le funzioni necessarie sulla singola vittima. Il comportamento riprende tecniche già osservate in Rainyday e Turian, varianti dell’ecosistema PlugX basate sul DLL search-order hijacking, ma OctLurk utilizza un framework autonomo e non deve essere descritto come una semplice variante di PlugX.

Le credenziali aprono la rete ai movimenti laterali

L’attività successiva alla compromissione mostra una raccolta sistematica di informazioni e credenziali. Gli operatori interrogano sessioni RDP, processi, software antivirus, configurazioni di rete, cache DNS e connessioni attive, quindi esportano gli eventi di login riusciti per individuare utenti e accessi remoti. Una versione eseguibile di Impacket secretsdump viene utilizzata per estrarre gli hash delle password dai domain controller e identificare ulteriori controller di dominio da raggiungere. Un keylogger mascherato come AnyDesk.exe registra battute e contenuti degli appunti, mentre un decryptor separato tenta di estrarre password da Chrome e Firefox attraverso i database Login Data, Local State e logins.json. Gli attaccanti distribuiscono anche l’agente legittimo Pandora RC come canale remoto alternativo e utilizzano FSCAN per scoprire host, valutare servizi, provare credenziali e cercare sistemi SSH o MySQL. La ridondanza permette di conservare l’accesso anche dopo la rimozione della backdoor iniziale e rende insufficiente la semplice cancellazione del loader. L’uso parallelo di strumenti custom e software amministrativo legittimo compare anche nelle campagne di spionaggio Cina-India contro le forze dell’ordine pakistane, dove PlugX, ShadowPad e strumenti post-exploitation servivano a estendere la presenza dentro reti governative.

LurkProxy crea un canale SOCKS5 cifrato

Accanto a OctLurk, gli aggressori hanno distribuito LurkProxy, componente con un loader fortemente offuscato e un’architettura simile a quella della backdoor, ma dedicato al trasporto del traffico. L’impianto ascolta su tutte le interfacce alla porta 64980 e stabilisce una connessione TLS con il proprio server C2, utilizzando pacchetti compressi con zlib e protetti da una doppia cifratura XOR. Nella configurazione osservata opera come proxy SOCKS5, consentendo agli attaccanti di instradare comunicazioni verso altri sistemi attraverso il dispositivo compromesso. La macchina infetta diventa così un punto di ingresso interno, un relay per nascondere l’origine delle connessioni e un canale per raggiungere segmenti non direttamente esposti su Internet. Una seconda modalità prevista dal codice permette di inoltrare tutto il traffico verso un indirizzo e una porta codificati, senza utilizzare il livello SOCKS5. LurkProxy non svolge quindi le funzioni di comando, furto e controllo tipiche della backdoor, ma amplia la capacità dell’attore di muoversi lateralmente e mantenere percorsi alternativi. La tecnica è coerente con la strategia delle operazioni cinesi che trasformano host compromessi in infrastrutture operative, come avvenuto con LongLeash e le reti ORB costruite attraverso router e dispositivi di frontiera.

SilkLurk consegna PlugX come secondo payload

SilkLurk conserva la struttura modulare di OctLurk, ma utilizza percorsi e nomi differenti, spesso mascherando il loader come vulkan-1.dll dentro directory che richiamano Microsoft, Intel, NVIDIA, Veeam, HP, Realtek e VMware. In almeno un incidente la backdoor ha aperto una shell remota e permesso agli operatori di installare PlugX, configurato con un server C2 separato da quello usato da SilkLurk. La presenza del RAT, attivo almeno dal 2008 e storicamente collegato a più gruppi di lingua cinese, costituisce uno degli elementi che sostengono l’attribuzione linguistica e operativa proposta da Kaspersky. Non consente tuttavia di assegnare automaticamente la campagna a Mustang Panda, APT41 o ad altri cluster noti, perché PlugX è stato condiviso e riutilizzato da numerosi attori. Nel rapporto tecnico di Kaspersky GReAT su OctLurk, SilkLurk e LurkProxy, i ricercatori valutano con media confidenza che le due backdoor siano gestite dallo stesso attore di lingua cinese, ma dichiarano esplicitamente di non poterlo collegare a un gruppo conosciuto. Le organizzazioni interessate devono cercare servizi e task anomali, loader nelle directory indicate, connessioni verso i C2 pubblicati e tracce di secretsdump, FSCAN, Pandora RC e raccolta delle password dei browser. La risposta deve includere rotazione delle credenziali, verifica dei domain controller, analisi dei log RDP e ricostruzione dei movimenti laterali, perché la rimozione di un singolo file non elimina gli accessi secondari già creati.