CARBONATO trasforma gli host Docker esposti in una rete per il furto di credenziali assistita dall’IA

CARBONATO sfrutta Docker esposti su porta 2375 per creare container privilegiati, rubare credenziali e chiavi IA e persistere sugli host.

CARBONATO trasforma gli host Docker esposti in una rete per il furto di credenziali assistita dall’IA
Malware

Immagine illustrativa generata con AI

Le API Docker aperte offrono il punto d’accesso iniziale

CARBONATO è una botnet basata su Docker che combina tecniche convenzionali di compromissione dei server con un agente IA open source. Attiva almeno da ottobre 2024, l’operazione punta a sottrarre credenziali, in particolare chiavi API per piattaforme di IA, per finanziare il gateway per modelli linguistici di grandi dimensioni usato dagli stessi operatori.

La botnet prende di mira i daemon Docker che accettano connessioni non autenticate sulla porta TCP 2375. Invece di sfruttare una vulnerabilità software divulgata, CARBONATO approfitta di configurazioni non sicure che consentono ai client remoti di accedere all’API Docker.

Non sono state indicate specifiche versioni di Docker vulnerabili. Alla campagna non è associato alcun CVE né alcuna voce nel catalogo Known Exploited Vulnerabilities della CISA.

Dopo aver individuato un daemon esposto, gli attaccanti usano l’API per creare un container privilegiato e montare al suo interno il filesystem dell’host. In questo modo, i comandi eseguiti dal container possono modificare il server sottostante: chi controlla Docker finisce così per controllare anche l’host.

I ricercatori che hanno indagato su CARBONATO hanno scoperto l’operazione dopo aver individuato un registro di container accessibile da Internet e privo di autenticazione. Nel corso di una giornata di raccolta passiva e in sola lettura, hanno acquisito 4,3 GB di immagini, distribuite su 59 repository, 234 tag e 605 file verificati.

Il registro non esponeva soltanto immagini malevole. Le cronologie di configurazione delle immagini Docker rivelavano indirizzi di comando e controllo, token dei bot e una password condivisa dagli operatori per accedere al loro gateway di IA.

I container privilegiati garantiscono un accesso persistente agli host

Il componente usato da CARBONATO per l’installazione iniziale è entry.sh versione 5.3, descritto come uno script di primo livello. Una volta avviato, crea un tunnel SSH inverso tra la macchina della vittima e un’infrastruttura di inoltro in Costa Rica.

La porta remota del tunnel non viene scelta a caso: CARBONATO la ricava dall’hash MD5 dell’indirizzo IP della vittima. Gli operatori che conoscono quell’indirizzo possono quindi calcolare la porta prevista per la riconnessione.

Lo script installa anche un server SSH e aggiunge una chiave pubblica controllata dagli operatori. Poi segnala la nuova compromissione tramite Telegram, inviando l’ID del container, il nome host, l’indirizzo IP e il Paese. I messaggi usati durante l’installazione sono in spagnolo con voseo, la forma regionale basata sul pronome «vos».

Diversi meccanismi aiutano il malware a sopravvivere ai riavvii e ai tentativi di rimozione:

  • processi cron;
  • timer systemd;
  • rc.local;
  • OpenRC;
  • attributi di file immutabili, pensati per ostacolarne la cancellazione o la modifica.

Un componente di sorveglianza controlla l’installazione. Se il container malevolo scompare, scarica di nuovo l’impianto dal registro esposto e lo installa nuovamente.

CARBONATO cerca anche di far sembrare ordinari i propri processi. Il container si chiama systemd-resolved e un banner contraffatto imita il resolver di systemd-networkd. Gli argomenti dei processi vengono manipolati per assomigliare a quelli del thread worker del kernel [kworker/u2:0].

Questi camuffamenti possono rendere meno efficaci i controlli sommari sui processi, ma non rendono l’attività indistinguibile da quella dei servizi legittimi del sistema. Un container privilegiato che monta il filesystem dell’host, stabilisce connessioni SSH inverse e contatta Telegram è comunque un chiaro indizio da approfondire.

La propagazione nella rete avviene senza un modello IA

L’IA è centrale nel sistema di comando interattivo di CARBONATO, ma non viene usata per la propagazione automatica della botnet.

Ogni cinque minuti, uno script esamina le reti collegate all’host infetto, comprese quelle bridge di Docker. Scansiona poi gli intervalli di indirizzi /24 vicini alla ricerca di sistemi che espongono un daemon Docker sulla porta 2375.

Quando trova un daemon raggiungibile, CARBONATO verifica che il sistema non sia già infetto. In caso contrario, installa lo stesso ambiente malevolo tramite l’API Docker. La nuova macchina compromessa inizia a sua volta la scansione.

Il risultato è un meccanismo di espansione ripetibile, che non richiede nuovi comandi via Telegram né istruzioni generate dal modello. Una compromissione iniziata su un server esposto può così raggiungere anche i segmenti di rete adiacenti visibili da quell’host.

Le vittime dirette sono amministratori e organizzazioni che espongono API Docker non autenticate. Le conseguenze, però, vanno oltre i carichi di lavoro dei container: il montaggio con privilegi consente infatti di accedere al filesystem dell’host e ai segreti conservati localmente.

Hermes Agent viene riconfigurato tramite il file persona

L’impianto installa Hermes Agent, un framework open source con licenza MIT sviluppato da Nous Research. CARBONATO non modifica il codice sottostante del framework: cambia invece le istruzioni che ne definiscono il comportamento.

Gli operatori sostituiscono il contenuto del file persona SOUL.md con un prompt di 39 righe e rinominano l’agente «GH0ST». Le istruzioni gli impongono di agire come strumento di post-exploitation, eseguire le attività ricevute tramite Telegram, mantenere l’accesso e raccogliere credenziali.

Questa strategia rende più difficile rilevare l’infezione basandosi soltanto sull’inventario software. La presenza di hermes-agent non dimostra che un server sia infetto, perché il framework ha anche usi legittimi. I difensori devono esaminare la configurazione, le istruzioni contenute nel file persona, i meccanismi di persistenza circostanti e le comunicazioni.

La persona malevola dà la precedenza alle credenziali dei servizi di IA rispetto a quelle SSH, ai token di accesso generici e ai segreti dei database. Indica esplicitamente 14 provider e tecnologie:

  • OpenAI
  • Anthropic
  • Google
  • Gemini
  • OpenRouter
  • Together
  • Groq
  • Mistral
  • Cohere
  • LocalAI
  • Ollama
  • vLLM
  • LiteLLM
  • One API

Il 3 settembre è stato segnalato online il gateway LLM degli operatori, attivo con un piano gratuito. Pubblicizzava 12 modelli, ma ne rendeva disponibili 27 tramite API.

Nel flusso operativo di CARBONATO, l’attaccante invia un’attività tramite Telegram. Hermes inoltra al gateway la richiesta insieme alla persona malevola SOUL.md. Il modello selezionato genera comandi per il terminale, ne esamina l’output e decide i passaggi successivi. I risultati tornano nella stessa chat Telegram usata per le notifiche di installazione.

Il modello fornisce quindi un’interfaccia di comando adattiva, in grado di reagire alle differenze tra i sistemi compromessi senza che gli operatori debbano creare script distinti per ogni host. È l’operatore umano ad avviare le attività; l’LLM traduce poi gli obiettivi in comandi e azioni successive.

Le chiavi IA rubate finanziano le attività successive

L’interesse di CARBONATO per le credenziali IA dà alla campagna una dimensione di autofinanziamento. Le chiavi API rubate possono addebitare alle vittime i costi di utilizzo dei modelli e, al tempo stesso, garantire alla botnet l’accesso continuativo a servizi di inferenza esterni.

A seconda del servizio e delle autorizzazioni associate alla credenziale, una chiave compromessa può anche esporre i dati di utilizzo dell’account, le quote disponibili o le applicazioni collegate. Non si conosce il numero esatto delle chiavi sottratte né quello delle organizzazioni colpite.

L’operazione comporta diversi rischi concomitanti: accesso remoto persistente, esecuzione di comandi con privilegi, furto di più categorie di credenziali, propagazione automatica nella rete e post-exploitation assistita da modelli. Non è stata assegnata alcuna valutazione formale della gravità.

Il registro esposto svolge due funzioni: distribuisce l’impianto agli host infetti, ma le sue deboli misure di accesso hanno anche rivelato dati operativi che hanno contribuito a portare alla luce la campagna.

Gli elementi raccolti suggeriscono un possibile legame con la Costa Rica, ma non permettono di stabilire dove si trovino fisicamente gli operatori. Quattordici delle 162 configurazioni di immagini esaminate contenevano timestamp UTC-06:00, compatibili con il fuso orario costaricano. L’handle Telegram Carbo506 include il prefisso telefonico internazionale +506 del Paese, mentre le connessioni SSH inverse terminavano nell’AS262145, una rete costaricana.

Anche l’uso dello spagnolo con voseo fornisce un indizio linguistico. Nessuno di questi elementi è conclusivo e un’infrastruttura in Costa Rica potrebbe essere controllata a distanza da un altro Paese.

Cosa controllare e mettere in sicurezza

La principale misura difensiva consiste nell’impedire l’accesso di rete non autenticato all’API del daemon Docker. La porta 2375 non deve essere esposta a reti non attendibili e l’accesso va limitato ai sistemi autorizzati.

Anche i registri di container devono richiedere l’autenticazione e avere un’esposizione di rete limitata. Un registro aperto può rivelare segreti incorporati, cronologie delle immagini, strumenti interni e componenti di malware pronti per la distribuzione.

Chi indaga su possibili infezioni da CARBONATO dovrebbe cercare:

  • /root/.hermes/SOUL.md contenente il nome GH0ST;
  • file .env contenenti CARBONATO_API_KEY;
  • traffico Telegram in uscita dai server non giustificato;
  • container privilegiati chiamati systemd-resolved;
  • connessioni SSH inverse prive di una legittima finalità amministrativa;
  • chiavi SSH, voci cron, timer systemd o modifiche a rc.local e OpenRC inattesi;
  • file contrassegnati come immutabili senza una motivazione operativa documentata;
  • scansioni ricorrenti della porta TCP 2375 sulle reti locali /24.

Gli amministratori non dovrebbero bloccare Hermes Agent solo perché è installato. L’indagine dovrebbe concentrarsi sui contenuti malevoli della persona e sui comportamenti associati.

Le organizzazioni dovrebbero inoltre censire le chiavi API per servizi di IA conservate nella propria infrastruttura, ruotare quelle esposte o di origine incerta e monitorarne l’utilizzo successivo. In questa campagna, le chiavi non sono un reperto secondario: sono un obiettivo primario e una risorsa destinata a sostenere le operazioni della botnet assistite dall’IA.

Leggi anche

Fonti

Questo articolo è una rielaborazione originale basata sulle fonti seguenti.

Argomenti correlatiCARBONATObotnet Dockersicurezza Dockerfurto credenzialichiavi API IAporta 2375Hermes Agent
Torna alla home