CARBONATO trasforma Docker esposto in una botnet con agente AI controllato via Telegram

🛡️ Executive Summary

• CARBONATO compromette Docker daemon esposti senza autenticazione sulla porta 2375 e si propaga autonomamente nelle reti raggiungibili.
• Hermes Agent entra dopo la compromissione: l’AI interpreta i task inviati via Telegram ed esegue comandi sui sistemi già infetti.
• Le API key dei provider AI vengono indicate come bottino prioritario, davanti a credenziali SSH, token, database e altri segreti.

Una botnet Docker costruita attorno a un agente AI, ma non una botnet che delega all’intelligenza artificiale la compromissione iniziale. CARBONATO sfrutta daemon Docker esposti senza autenticazione sulla porta 2375, installa container privilegiati, crea persistenza, apre tunnel SSH e si propaga autonomamente verso altri sistemi raggiungibili. Solo dopo questa fase entra in gioco Hermes Agent, framework open source trasformato attraverso un file di istruzioni in uno strumento di post-exploitation controllabile da Telegram. La distinzione è fondamentale: l’AI non sostituisce exploit, scanning e persistence, ma diventa il livello che consente all’operatore di interrogare un host compromesso, generare comandi e adattare le azioni alle informazioni raccolte.

Un registry Docker aperto ha esposto quasi tutta l’operazione

La ricostruzione pubblicata da ThreatDown nella ricerca originale su CARBONATO nasce da un errore operativo degli stessi attaccanti. I ricercatori hanno individuato un Docker Registry pubblicamente accessibile senza autenticazione, esposto almeno da maggio 2026, dal quale hanno recuperato 59 repository, 234 image tag, 605 blob verificati e circa 4,3 GB di dati. Le immagini coprono un periodo compreso tra ottobre 2024 e agosto 2026 e documentano due linee criminali collegate: una fabbrica di wallet di criptovalute trojanizzati e la botnet CARBONATO. Il registry non conteneva soltanto immagini, ma anche configurazioni, variabili d’ambiente, command history, indirizzi C2, token Telegram e credenziali utilizzate dal gateway LLM. Lo stesso server funzionava inoltre come infrastruttura di aggiornamento per gli host compromessi, trasformando un singolo errore di esposizione in una fotografia quasi completa della supply chain offensiva. È lo stesso principio di rischio già emerso quando Vite esponeva chiavi AWS, Azure e segreti Terraform attraverso configurazioni accessibili: l’infrastruttura di sviluppo e distribuzione contiene spesso credenziali più preziose del software che dovrebbe ospitare.

Leggi anche: Docker Sandboxes apre il confine tra agenti AI e sistema host

La compromissione avviene attraverso Docker, non attraverso l’AI

CARBONATO cerca daemon Docker che accettano connessioni non autenticate sulla porta TCP 2375. Quando ne individua uno utilizza direttamente l’API Docker per creare un container privilegiato, monta il filesystem root dell’host, condivide namespace PID e rete e usa nsenter per eseguire comandi sul sistema sottostante. Da quel momento il container non è più semplicemente un workload isolato: diventa un ponte verso l’host. Il malware installa un server SSH, aggiunge una chiave degli operatori e apre un reverse tunnel verso un relay in Costa Rica; il numero della porta remota viene derivato deterministicamente dall’MD5 dell’indirizzo IP della vittima, permettendo agli attaccanti di ricostruire il punto di rientro senza mantenere una tabella separata. Per confondersi con normali componenti Linux, CARBONATO utilizza nomi come systemd-resolved, simula banner di servizi legittimi e maschera gli argomenti di processo come [kworker/u2:0].

La persistenza viene realizzata con meccanismi tradizionali: cron, systemd timer, rc.local e OpenRC, file marcati immutable e watchdog che controllano la presenza dei componenti e scaricano nuovamente l’immagine se viene rimossa. Ogni cinque minuti il worm enumera le reti dell’host e i bridge Docker, esegue scansioni sui relativi /24 e tenta di infettare ulteriori daemon esposti sulla stessa porta. In questa fase Hermes Agent non partecipa alla propagazione. Lo scanning, la verifica del servizio, il deployment e la persistenza restano affidati a script deterministici. È una differenza importante rispetto alla crescente tendenza a descrivere ogni malware che incorpora un modello come autonomo: anche RatHat utilizza l’AI per guidare attività su Android, ma i privilegi effettivi continuano a derivare dal runtime e dalle interfacce che l’architettura mette a disposizione.

Hermes Agent diventa il terminale intelligente della botnet

Una volta consolidato l’accesso, CARBONATO installa Hermes Agent, framework MIT open source sviluppato da Nous Research e lasciato sostanzialmente invariato. Gli operatori ne modificano invece il file SOUL.md, inserendo un prompt di 39 righe che assegna all’agente il nome GH0ST, gli ordina di mantenere la persistenza, rispondere alle istruzioni ricevute attraverso Telegram ed eseguire attività di post-exploitation senza applicare restrizioni. Hermes possiede già le funzionalità necessarie per ricevere task, generare comandi da terminale e comunicare con endpoint LLM compatibili: il malware deve quindi aggiungere soprattutto contesto e obiettivi. Il modello riceve dal bot Telegram il task dell’operatore insieme alla persona malevola, genera comandi, legge l’output del sistema compromesso e decide quali azioni successive proporre o eseguire. L’agente diventa così un’interfaccia interattiva di post-compromise, capace di adattare i passaggi alla risposta dell’host senza obbligare l’operatore a costruire manualmente ogni comando. Questo scenario coincide con il rischio già descritto nell’analisi di 157 skill malevole e tool poisoning contro agenti AI: il problema non è necessariamente il modello, ma ciò che accade quando gli vengono concessi shell, filesystem, credenziali e capacità di eseguire tool reali.

Le API key AI diventano il bottino numero uno

L’aspetto più significativo della configurazione di CARBONATO riguarda la priorità assegnata al furto delle credenziali. Nel SOUL.md gli operatori dichiarano esplicitamente che le API key dei provider AI sono il “loot #1”, superiore a chiavi SSH, access token e database. Il prompt elenca provider come OpenAI, Anthropic, Google, Gemini, OpenRouter, Together, Groq, Mistral, Cohere, LocalAI, Ollama, vLLM e LiteLLM e ordina all’agente di archiviare token e password in chiaro per permetterne il riutilizzo. Il motivo emerge dalla stessa infrastruttura criminale: il gateway utilizzato dalla botnet offriva accesso a decine di modelli e dipendeva quindi direttamente da credenziali e capacità di calcolo che gli operatori potevano sottrarre ad altri. Il valore di una API key AI non è più limitato alla fatturazione. Può consentire accesso a modelli privati, endpoint aziendali, gateway interni e infrastrutture sulle quali transitano prompt e dati sensibili. Il problema è già visibile nella crescente esposizione di credenziali, API e segreti che aprono direttamente database e servizi cloud. CARBONATO aggiunge un passaggio ulteriore: automatizza la ricerca di questi segreti attraverso un agente che comprende l’ambiente già compromesso.

Continua con:

Agenti AI, la nuova kill chain porta skill malevole e tool poisoning dentro i SOC

npm blocca gli install script ma indexed-btree sposta il malware al runtime

CARBONATO mostra dove l’AI cambia davvero il cybercrime

CARBONATO non dimostra che un modello linguistico abbia imparato autonomamente a costruire e propagare una botnet. Dimostra qualcosa di più concreto: un’infrastruttura criminale tradizionale può incorporare un agente AI come livello operativo sopra una compromissione già riuscita. Docker esposto fornisce l’accesso, gli script garantiscono persistenza e propagazione, Telegram offre il canale di comando e Hermes Agent interpreta le richieste dell’operatore sul singolo host. Per difendersi resta quindi prioritario chiudere le API Docker non autenticate, proteggere i registry, controllare container privilegiati e ruotare immediatamente le credenziali esposte. Ma CARBONATO aggiunge una nuova variabile: una volta dentro, l’attaccante può delegare a un agente parte dell’esplorazione e del post-exploitation. L’AI non sostituisce la kill chain: la rende più economica da gestire dopo che il perimetro è già stato violato.