Researchers Found a Botnet That Uses an AI Agent to Operate Inside Compromised Servers

CARBONATO is a botnet that turns Docker servers into footholds for attackers. It places an AI agent inside compromised systems, letting operators send tasks through Telegram and receive results.

The campaign begins with Docker services carelessly exposed to the internet without authentication. Once inside, CARBONATO launches a privileged container, gains access to the host, establishes reboot persistence, and searches nearby networks for vulnerable servers.

ThreatDown researchers identified the operation after finding an unauthenticated Docker registry exposed since May 2026.

In one day, they recovered 59 repositories, 234 image tags, 605 verified blobs, and 4.3 GB of data spanning October 2024 through August 2026.

ThreatDown said in a report shared with Cyber Security News (CSN) that the finding shows how one simple configuration mistake can become a network-wide problem.

CARBONATO spreads without fresh instructions, while its operator-controlled agent can collect sensitive credentials and carry out further actions on systems already compromised.

Researchers Found a Botnet That Uses an AI Agent

CARBONATO installs the open-source Hermes Agent framework without changing its software. Instead, the attackers replace its persona file with 39 lines of instructions that tell it to maintain access, collect secrets, and obey commands arriving through Telegram.

An operator’s task travels with those instructions to the group’s language model gateway. The model interprets the request, writes terminal commands, checks their output, and decides what to try next. The agent runs those commands on the victim server and reports back through Telegram.

Sensitive AI API keys top the agent’s list of targets, ahead of SSH credentials, access tokens, and databases. The focus echoes recent AI ransomware activity, where automated tools used exposed services and available credentials to move rapidly from initial access to damage.

The framework itself remains unchanged; the harmful behavior comes from the instructions imposed at startup. This distinction matters because blocking every installation of a legitimate agent would also disrupt ordinary users.

Researchers also found that the gateway advertised 12 models but served 27 through its interface. Infected hosts could therefore become sources of AI credentials as well as more conventional secrets, a concern also seen in malware targeting developer credentials across build environments.

How the Botnet Spreads

The botnet looks for Docker daemons accepting unauthenticated network connections. It uses the exposed service to start a privileged container with access to the victim’s filesystem, processes, and network, then runs commands on the underlying server.

An entry script opens a reverse SSH tunnel to a relay in Costa Rica, installs an SSH server and attacker key, and sends deployment details to Telegram. The implant also disguises its infected container and processes as Linux activity to make a quick review less revealing.

CARBONATO creates persistence through cron jobs, systemd timers, startup scripts, and OpenRC, then makes related files difficult to change.

Watchdogs can pull the implant again from the same registry if it disappears, reinforcing the risk seen in earlier exposed Docker attacks that gave intruders lasting host access.

Every five minutes, scripts inspect networks attached to the host and Docker bridges, then scan each /24 range for exposed Docker services.

When they find another exposed daemon, they repeat the deployment. The AI agent does not manage this spread; ordinary scripts do the scanning and installation.

The registry also held trojanized cryptocurrency wallet apps alongside botnet components. Its exposed image layers and configurations gave researchers a detailed view of the operation, underscoring the wider security risks of private container image exposure when registries lack proper access controls.

Defenders should keep Docker daemon APIs off public networks, authenticate registries, and check for unexpected privileged containers and Telegram traffic from servers.

They should inspect unusual persistence settings, inventory and rotate AI API keys, and investigate the specific signs of compromise listed below.

ThreatDown cited language, build timestamps, a Telegram handle, and reverse tunnels as clues pointing toward Costa Rica. Those signals support an assessment, not a confirmed identity.

The immediate operational concern for administrators is stopping access through exposed Docker services before the botnet reaches other hosts.

Indicators of Compromise (IoCs):-

Type	Indicator	Description
Network	45[.]79[.]183[.]61	C2 hub (Linode)
Network	91[.]99[.]195[.]164	fsociety-era C2 (Hetzner)
Network	213[.]136[.]79[.]115	Beacon / reverse shell (Contabo, :8080 and :4444)
Network	213[.]136[.]83[.]197	LLM gateway (Contabo), live
Network	190[.]211[.]124[.]187	Reverse-tunnel sink (AS262145, Costa Rica)
Network	carbonato-proxy-{drab,zeta,zeta-2}[.]vercel[.]app	LLM proxies, suspended
Network	Registry fleet on AS40065	Seven endpoints, six live, withheld while live
Container	gh0st/, fsociety/, netd-svc, system/resolved, scrub-empty	Repository names, 59 total
Container	GH0ST_C2, FSOCIETY_DISABLE_TUNNEL, GATEWAY_ALLOW_ALL_USERS	Image environment variables
Container	/opt/gh0st/entry.sh, auto-persist-host.sh, SOUL.md	Implant kit files
Host	/usr/local/bin/.docker-network-monitor	Watchdog binary
Host	/usr/sbin/systemd-logind	Miner disguised as a system service
Host	[kworker/u2:0]	Disguised process arguments
Secret	carbonato125	Shared password across the archive
Secret	CARBONATO_API_KEY	.env variable on infected hosts
Telegram	Chat 750752697	Deployment reports and C2 chat

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC