Kazuar si Trasforma in Botnet P2P: Turla alza l’asticella dello spionaggio con un backdoor modulare invisibile

Il gruppo di cyber spionaggio Turla ha evoluto il backdoor Kazuar in una botnet P2P modulare progettata per ottenere accesso persistente e difficile da rilevare sui sistemi compromessi. Questa trasformazione segna un cambio di passo importante nel panorama malware, perché non si tratta più di un impianto monolitico ma di un ecosistema a componenti con ruoli separati, capace di adattarsi e resistere meglio alle interruzioni operative e ai tentativi di analisi.

Kazuar, noto come backdoor in ambiente .NET utilizzato in campagne attive da anni, viene ora descritto come una struttura composta da tre tipologie di moduli che cooperano tra loro.

Kernel

Il primo elemento è il Kernel, che agisce come coordinatore centrale della botnet. Il Kernel gestisce la configurazione, assegna compiti, mantiene log e dati raccolti, implementa controlli anti-analisi e anti-sandbox e governa i parametri legati alla comunicazione con il command and control, ai tempi di esfiltrazione, alla gestione dei task e alle attività di raccolta e monitoraggio.

Bridge

Il secondo elemento è il Bridge, che funziona come proxy tra il Kernel leader e l’infrastruttura di command and control. Questo strato intermedio aiuta a ridurre l’esposizione diretta e a rendere più robusta la catena di comunicazione, migliorando la capacità della botnet di continuare a operare anche in presenza di blocchi parziali.

Worker

Il terzo elemento è il Worker, responsabile delle azioni operative sul sistema vittima. Il Worker può registrare digitazioni, intercettare eventi di Windows, raccogliere informazioni di sistema, elenchi di file e dettagli MAPI utili in contesti di raccolta dati e accesso a comunicazioni.

Canali di comunicazione

Un aspetto chiave della nuova architettura è la presenza di più canali di comunicazione sia interni sia esterni. Internamente, i moduli possono scambiarsi messaggi tramite meccanismi di Windows come messaging, mailslot e named pipe. Verso l’esterno, il Kernel può contattare l’infrastruttura degli attaccanti tramite Exchange Web Services, HTTP o WebSockets, aumentando la flessibilità e la probabilità di successo in reti con controlli diversi.

Resilienza ed elezione del Kernel leader

Per rendere il sistema ancora più resiliente, viene eletto un Kernel leader che comunica con il Bridge a nome degli altri moduli Kernel. L’elezione avviene tramite mailslot e tiene conto del tempo di esecuzione e delle interruzioni, come reboot o terminazioni di processo, così da privilegiare istanze più stabili.

Gestione e staging dei dati

I dati raccolti dai Worker vengono aggregati, cifrati e salvati in una directory di lavoro dedicata, usata come area di staging su disco. La separazione tra output di raccolta, log, task e configurazioni consente di mantenere lo stato operativo tra riavvii e di coordinare attività asincrone riducendo i contatti diretti con il C2.