The discovery of Carbonato, a newly documented botnet targeting exposed Docker hosts, highlights how traditional infrastructure weaknesses are being combined with AI-driven post-compromise tooling. The campaign does not rely on a sophisticated zero-day or an exotic container escape. Instead, it targets Docker daemons exposed on TCP port 2375 without authentication, uses the Docker API to launch a privileged container, and then converts that access into persistent control of the underlying host. Once established, the attackers install the open-source Hermes Agent framework and configure an agent named GH0ST to handle operator-driven tasks through Telegram.

That distinction matters because the initial compromise is brutally simple. If the Docker API is remotely reachable and unauthenticated, an attacker can instruct Docker itself to launch a container with extensive privileges. Carbonato then uses that privileged container to access the host, install an SSH server containing the attacker's key, establish a reverse SSH tunnel, and report the deployment back through Telegram. The attacker is not breaking Docker security so much as exploiting an environment where the security boundary was never properly configured in the first place.

The malware also establishes several persistence mechanisms, including cron jobs, systemd timers, rc.local, and OpenRC hooks. This redundancy is significant because removing one persistence point does not necessarily eliminate the compromise. An administrator may delete a suspicious cron entry while leaving a systemd timer or startup hook untouched. Carbonato is therefore designed not simply to gain access but to survive incomplete remediation and remain available to the operator.

What makes the campaign particularly interesting is the role of the Hermes Agent AI framework. ThreatDown found that Carbonato installs the open-source framework largely unchanged and then overwrites its SOUL.md persona file with malicious instructions. The resulting GH0ST agent is told to perform tasks received through Telegram, maintain persistence, collect credentials, and report results back to the operator. The AI framework effectively becomes an interactive post-exploitation assistant running directly on the victim host.

This is not a fully autonomous malware system independently deciding whom to attack. The operator still issues tasks through Telegram. The important change is what happens after the instruction arrives. According to ThreatDown, the model interprets the task, generates terminal commands, reads the resulting output, decides what to do next, and continues iterating until it can report a result. That creates an interactive command loop in which the AI agent performs much of the tactical work that a human operator would normally have to execute manually.

That can significantly reduce the amount of attention required per compromised host. A traditional attacker may need to log into each system, inspect the environment, search for credentials, interpret command output, and choose the next command. With an AI agent embedded on the endpoint, many of those steps can be delegated. One human operator could therefore potentially supervise a larger number of compromised systems while the agent performs routine reconnaissance and credential hunting. The technology does not magically create new attack primitives, but it can lower the human workload associated with using them.

The GH0ST instructions specifically prioritize AI API keys, followed by SSH credentials, access tokens, databases, and other secrets. ThreatDown says the prompt names 14 AI providers whose credentials should be collected. This is an interesting indication of how attacker priorities are changing. AI API keys are becoming valuable credentials because they may provide access to paid model services, internal AI workflows, automation agents, or other resources that criminals can abuse.

SSH keys and general access tokens remain equally concerning. A compromised Docker host may belong to a developer, CI/CD system, build server, or cloud workload. Such systems often contain credentials that provide access far beyond the infected machine. If Carbonato steals an SSH private key, cloud token, registry credential, or automation secret, the attacker may be able to move into additional systems without relying on the original Docker exposure. The first compromised host can therefore become a credential-harvesting platform for broader intrusion.

Carbonato also possesses worm-like propagation. Every five minutes, scripts on the infected system scan networks attached to the host for other Docker daemons exposed without authentication. When another vulnerable daemon is discovered, the malware repeats the same process: pull the implant, launch a privileged container, establish persistence, and continue scanning.

This is particularly dangerous in container-heavy environments because Docker hosts often share internal network segments that are not expected to be reachable from the public Internet. An externally exposed Docker daemon can therefore become the first step into a much larger internal cluster of similarly misconfigured systems. Once Carbonato enters that environment, its worm-like scanning can turn a single configuration mistake into a multi-host compromise.

The attack path can be summarized as: exposed Docker API → privileged container → host access → SSH persistence → Hermes/GH0ST installation → Telegram tasking → AI-guided post-exploitation → network scanning → compromise of additional Docker hosts. None of those stages requires a sophisticated memory corruption exploit. The campaign is successful because misconfiguration gives the attacker exactly the execution primitive they need.

The origin of the research is also noteworthy. ThreatDown discovered an unauthenticated Docker registry that had itself been publicly exposed since May 2026. Researchers retrieved 59 repositories, 234 image tags, 605 verified blobs, and approximately 4.3 GB of image data. The archive documented operational activity spanning October 2024 through August 2026 and revealed not only the Carbonato botnet but also a separate operation distributing counterfeit cryptocurrency wallet applications.

That exposed registry provided an unusually detailed view into the operator's tooling, development history, and deployment infrastructure. It also provides a rather fitting irony: an operation built around compromising insecure Docker infrastructure exposed its own Docker registry without authentication. Security misconfiguration, apparently, remains committed to equal-opportunity employment.

The use of Telegram as the operator interface is another important defensive consideration. Telegram provides reliable cloud infrastructure and is used by many legitimate users, making blanket blocking difficult in some environments. Defenders should therefore focus less on the domain itself and more on which process is communicating with Telegram and what happens around that communication. An unfamiliar process communicating with Telegram while also launching shells, inspecting credentials, modifying persistence, or scanning the local network is considerably more interesting than Telegram traffic alone.

Reverse SSH tunnels are another useful signal. Carbonato establishes outbound SSH connectivity that allows the attacker to reach the compromised host even if inbound access is restricted. Outbound tunnels are attractive because they reverse the usual connection direction: the victim system initiates the connection, potentially bypassing inbound firewall restrictions. Organizations should monitor server environments for unexpected outbound SSH sessions, particularly persistent tunnels to unfamiliar autonomous systems or hosts.

ThreatDown identifies infrastructure associated with AS262145 as relevant to the reverse SSH activity. It also highlights indicators such as the GH0ST persona file and the CARBONATO_API_KEY setting. These provide useful hunting starting points, but organizations should not rely solely on exact filenames, environment variables, or IP addresses. Once publicly documented, attackers can change these quickly.

Behavioral detection is therefore more durable. Security teams should look for combinations such as an exposed Docker daemon launching an unusual privileged container, creation of new SSH server configuration, installation of unauthorized SSH keys, new cron or systemd persistence, outbound Telegram communication, reverse SSH tunnels, and repetitive scanning of internal networks for port 2375.

The most important preventative control is extremely straightforward: do not expose the Docker daemon API without authentication. Port 2375 should not be publicly reachable, and in most environments it should not be broadly accessible internally either. Docker's remote API is effectively an administrative interface. Treating it as an ordinary service port is equivalent to placing a remote root-management interface on the network and hoping nobody notices.

Organizations that genuinely require remote Docker API access should protect it through TLS client authentication, carefully scoped firewall rules, VPN or management-network access, or similarly strong controls. Access should be limited to known administration systems rather than entire network segments. Public exposure should be treated as an emergency configuration issue.

Docker registries also require proper access controls. The Carbonato investigation itself became possible because the attacker's registry was exposed anonymously. Enterprises should ensure private registries require authentication, enforce least privilege, log pulls and pushes, and prevent untrusted users from replacing or introducing images. Container images should also be scanned and signed where possible, especially when deployed into privileged environments.

Privileged containers deserve particular attention. A privileged Docker container can gain extremely broad access to the host. Organizations should restrict privileged mode wherever possible and enforce container-security policies that prevent untrusted workloads from mounting host filesystems or accessing the Docker socket. If an attacker can control the daemon and request privileged workloads, the container boundary effectively stops being much of a boundary.

Carbonato also demonstrates why AI security is becoming part of infrastructure security. The Hermes Agent framework used here is legitimate open-source software. The malware does not exploit a vulnerability in Hermes. The attacker simply installs it and gives it malicious instructions. This is an important distinction because the security issue is not “AI frameworks are malware.” The issue is that general-purpose agents capable of executing terminal commands can become powerful post-exploitation tools when attackers place them inside a compromised environment.

That same capability can be useful to defenders, developers, and system administrators. But once an agent can read command output, reason about the result, and autonomously issue the next command, it becomes a force multiplier for whoever controls it. The framework does not need malicious code if the instructions and environment are malicious.

This creates a broader challenge for endpoint and server monitoring. Organizations may increasingly encounter legitimate AI frameworks running on production or developer systems. Security teams will need to distinguish authorized agents from unauthorized ones and understand which identities, tools, and commands those agents are permitted to use. Merely searching for an AI framework by name will not scale as a defensive strategy.

The campaign also reinforces the importance of credential hygiene on container hosts. Infrastructure systems should not contain more credentials than they need, and secrets should ideally be short-lived and scoped narrowly. A Docker host compromised by Carbonato should not automatically provide access to every cloud account, registry, Git repository, and AI provider used by the organization.

If infection is suspected, defenders should treat the host as fully compromised. Removing one container is not sufficient. Investigators should preserve logs and forensic evidence, identify persistence mechanisms, inspect authorized SSH keys, review outbound tunnels, rotate potentially exposed credentials, and rebuild affected systems from trusted images where practical. Neighboring Docker hosts should also be examined because Carbonato's scanning loop may already have attempted propagation.

The broader cybersecurity lesson is that Carbonato combines three trends that defenders should take seriously: cloud and container misconfiguration, worm-like infrastructure compromise, and AI-assisted post-exploitation. The attack begins with an old and painfully familiar mistake, an unauthenticated administrative service. AI then makes what happens afterward easier to scale.

That distinction is important. Carbonato does not show that AI suddenly made Docker vulnerable. The Docker hosts were already vulnerable because their administrative APIs were exposed without authentication.

What AI changes is the economics of using the access once obtained.

The attacker no longer needs to manually investigate every compromised server. An embedded agent can interpret objectives, run commands, inspect results, and continue working while the operator supervises from Telegram.

For defenders, the practical message is refreshingly unglamorous: secure Docker APIs, restrict privileged containers, control outbound access, protect credentials, and monitor persistence. The AI layer is new. The configuration failure that makes the entire campaign possible is very much not.

A new botnet malware called Carbonato is targeting insecure hosts running Docker daemons to install the Hermes Agent AI framework and take control. [...]

Source: New Carbonato malware uses AI agents to hijack exposed Docker hosts via Bleeping Computer — published 24 Sep 2026.