Sommario
L’infrastruttura Docker torna nel mirino di campagne malware, questa volta con un attacco che impiega il Remote Access Trojan Chaos RAT e una catena di infezione particolarmente insidiosa. Il gruppo responsabile utilizza uno script serverless basato su JavaScript ospitato su Cloudflare Workers, sfruttando container esposti per compromettere sia ambienti Linux che Windows. Il malware Chaos, già osservato in passato in ambienti cloud, viene iniettato tramite un payload offuscato codificato in base64, decifrato da uno script PowerShell oppure Bash, a seconda della macchina bersaglio. La particolarità dell’operazione risiede nell’uso di Cloudflare come vettore di distribuzione, una tecnica che complica il rilevamento e l’attribuzione.
Docker come vettore primario di infezione
Gli attaccanti partono da container Docker pubblicamente accessibili, configurati senza adeguate misure di autenticazione. Una volta identificati, questi vengono compromessi attraverso un semplice comando docker exec, che permette di eseguire codice arbitrario all’interno del contenitore. Il comando lancia uno script PowerShell per ambienti Windows o una shell Bash nei sistemi Linux, entrambi progettati per scaricare ed eseguire il payload. Il malware risiede in uno script ospitato su *.workers.dev, un dominio appartenente a Cloudflare. Il codice recupera il binario di Chaos RAT e lo avvia in memoria, garantendo un’infezione priva di artefatti statici sul disco. La modularità del payload consente all’attaccante di aggiornare in tempo reale il codice malevolo, mantenendo la catena di infezione aggiornata e flessibile. Questo rende le campagne particolarmente pericolose anche per ambienti cloud teoricamente blindati.
Tecniche di evasione e controllo remoto
Una volta eseguito, Chaos RAT stabilisce una connessione al server di comando e controllo, permettendo agli attaccanti di eseguire comandi arbitrari, scaricare file, o installare ulteriori strumenti. Il trojan è scritto in Go e compilato per diverse architetture, inclusi x86, x64 e ARM, rendendolo efficace anche su dispositivi IoT o sistemi embedded. Il canale di controllo è criptato e dinamico, spesso nascosto dietro servizi legittimi per evitare il rilevamento da parte degli strumenti di monitoraggio del traffico. In alcuni casi, Chaos RAT è stato utilizzato anche per stabilire reverse shell persistenti, creando accessi stabili che sfuggono alla revoca degli indirizzi IP.
Ruolo dei Cloudflare Workers
La distribuzione del malware sfrutta l’ambiente serverless offerto da Cloudflare, dove è possibile caricare codice JavaScript che viene eseguito a ogni richiesta HTTP. In questo caso, il Worker funge da intermediario dinamico: riceve le richieste dal container infetto, risponde con il payload base64, e ne logga l’accesso per eventuali analisi post-infezione. Questa scelta architetturale permette agli attaccanti di aggiornare in tempo reale il malware, rimanendo agili nella gestione dell’infrastruttura e sfruttando una rete CDN legittima per mascherare l’attività malevola. L’hosting su Cloudflare, inoltre, ostacola l’attribuzione e rallenta le operazioni di take-down.
Persistenza e impatti trasversali
Chaos RAT non si limita a un’azione una tantum. Dopo l’infezione, il malware implementa tecniche di persistenza diverse in base al sistema operativo. Su Windows, aggiunge una chiave di registro o un servizio, mentre su Linux modifica file come .bashrc o rc.local. Alcuni script rilevati mostrano la capacità di auto-replicazione in ambienti containerizzati, compromettendo più istanze in cascata. Le capacità di esfiltrazione dati, controllo completo e persistenza a lungo termine rendono questa campagna particolarmente adatta a operazioni APT o di cybercriminalità organizzata. Gli ambienti cloud multi-tenant sono tra i più a rischio, data la possibile escalation orizzontale all’interno dello stesso cluster.
Implicazioni per la sicurezza e mitigazioni
Questa campagna evidenzia nuove frontiere nelle minacce contro i container. L’uso di tecniche serverless e legittime infrastrutture CDN rappresenta una sfida per i team di sicurezza. La difficoltà nel rilevamento del traffico e nell’attribuzione rende inefficaci molte delle difese tradizionali. Gli esperti raccomandano di disabilitare l’accesso non autenticato a Docker, monitorare connessioni verso domini *.workers.dev e implementare controlli e logging estesi anche a livello di rete interna. È fondamentale validare ogni processo lanciato all’interno dei container e analizzare periodicamente i log per identificare anomalie anche minime.
