CARBONATO Botnet Deploys an AI Agent Inside Hacked Docker Servers
Security researchers have uncovered a botnet, tracked as CARBONATO, that hijacks poorly secured Docker hosts and turns a legitimate open-source AI agent framework into an autonomous foothold inside compromised infrastructure.
What Happened
Rather than building custom malware, CARBONATO's operators install an unmodified, open-source AI agent framework and simply swap in a short malicious instruction set that tells it to maintain access, harvest credentials, and take orders over Telegram. A central model gateway routes attacker requests to the on-host agent, which reasons over each task, runs terminal commands, checks the results, and reports back — giving the operators a semi-autonomous presence rather than a fixed script.
The malware spreads by scanning for Docker daemons that accept unauthenticated network connections. Once found, it launches a privileged container with access to the victim's filesystem, processes, and network, then pivots onto the underlying host. An installer script opens a reverse SSH tunnel to infrastructure researchers have linked to Costa Rica, plants a rogue SSH key, and disguises the malicious container and processes as ordinary Linux activity. Persistence is layered across cron jobs, systemd timers, startup scripts, and OpenRC, and a watchdog component can redeploy the agent from the same registry if it is ever removed. Every few minutes, the malware also rescans the local network and Docker bridges for the next exposed daemon and repeats the deployment automatically, independent of the AI agent itself.
Why It Matters
The agent prioritizes AI provider API keys ahead of SSH credentials and database access, and researchers found that the attackers' own model gateway quietly served more models than it advertised — meaning compromised hosts can become a source of AI credentials as well as conventional secrets. Because the underlying agent framework is legitimate, unmodified software, the malicious behavior lives entirely in the instructions it is given at startup, which makes it harder to catch by looking for a known-bad binary. It also reflects a broader shift toward automated tooling that uses exposed services and stolen credentials to move from initial access to impact far faster than a human operator working alone.
What To Do
- Never expose a Docker daemon API to the public network; require authenticated, TLS-secured access for any remote management that is genuinely needed.
- Audit registries and running containers for unexpected privileged containers, unfamiliar persistence entries (cron, systemd, OpenRC), and outbound Telegram traffic from servers.
- Treat AI provider API keys as sensitive credentials — inventory and rotate them, and watch model gateway logs for anomalies such as models being served that were never provisioned.
- Prioritize hardening any internet-facing Docker host now, rather than waiting for a routine patch cycle.