Carbonato malware is not another cookie-cutter cryptomining botnet. It’s one of the first widely documented threats to wire a live AI agent directly into its command-and-control loop, and that changes what a misconfigured Docker host actually is to an attacker: not a machine to script against, but one to converse with in real time.
Security researchers at ThreatDown, Malwarebytes’ threat intelligence arm, uncovered the operation almost by accident, after stumbling onto an unauthenticated container registry that held the attackers’ entire toolchain. What they found reframes a familiar problem: exposed Docker daemon APIs, wrapped around a new and far more capable payload.
For developers, DevOps engineers, cloud teams, and SOC analysts, the takeaway is blunt. Carbonato malware is a clear signal that the old advice about locking down Docker just became urgent again, and that AI agent frameworks are now squarely inside the attacker’s toolkit.
Quick Answer
Carbonato malware is a self-propagating Docker botnet, first reported on September 24, 2026, that scans the internet for hosts with an exposed Docker API on port 2375, hijacks them via a privileged container, and installs the open-source Hermes Agent AI framework, renamed “GH0ST,” to let an operator issue live, AI-interpreted commands over Telegram.
What Is Carbonato Malware?
Carbonato malware is a Linux-targeting botnet that ThreatDown researchers traced back to at least October 2024. The campaign only came to public attention in September 2026, and somewhat ironically, it did so because the operators made the same mistake they’d been exploiting in victims: they left their own container registry exposed without authentication.
Investigators recovered roughly 4.3 GB of image data across 59 repositories, 234 tags, and 605 verified blobs, enough to reconstruct the entire attack chain and its supporting infrastructure, including a related campaign distributing counterfeit cryptocurrency wallet apps.
What sets this Docker malware apart from earlier Docker-targeting botnets like the long-running TeamTNT campaigns is what happens after the initial compromise. Rather than dropping a static cryptominer and moving on, Carbonato installs a functioning AI agent on every host it takes over, giving its operators an interactive, natural-language interface to each victim. ThreatDown could not tie the operation to any previously known threat cluster. Several artifacts, though, point to a Costa Rica-based operator.
How Carbonato Compromises Docker Hosts
The entry point is unglamorous, and entirely preventable: a Docker daemon API exposed to the internet on TCP port 2375 with no authentication in front of it. Port 2375 is Docker’s plaintext REST API. By design it accepts commands with the same privileges as the person running the docker CLI, which on most hosts means root. When that port is reachable and open, no exploit is needed at all.
Carbonato malware’s operators connect directly to the exposed API and instruct the daemon to launch a privileged container with the host filesystem mounted and the host’s process and network namespaces attached. A privileged container configured this way is functionally equivalent to a root shell on the underlying host; the container boundary provides no meaningful isolation once those flags are set. From inside that container, the malware can read or modify any file on the host, including SSH keys, credential stores, and shadow files.
Once it has host-level execution, Carbonato malware opens a reverse SSH tunnel back to attacker-controlled infrastructure, installs its own SSH server seeded with the operators’ key, and reports the new deployment through a Telegram bot. That gives the crew a persistent, low-friction remote-access channel, one that survives a container restart and blends into ordinary outbound traffic.
Inside the Hermes Agent / GH0ST AI Component
The most notable part of the Carbonato malware chain is what it installs once the host is held: Hermes Agent, an MIT-licensed, open-source AI agent framework built by Nous Research. Worth stating plainly, Hermes Agent is legitimate software with ordinary, non-malicious users.
It isn’t malware in itself. It already ships with the ability to accept tasks over Telegram, execute terminal commands, and connect to compatible large language model endpoints, so Carbonato’s operators didn’t need to build any of that tooling themselves. They simply pointed an unmodified copy of the framework at their own infrastructure.
The actual malicious behavior comes from a single configuration change. The entrypoint script overwrites Hermes Agent’s default SOUL.md persona file with a 39-line prompt that renames the agent “GH0ST” and instructs it to maintain persistence, follow instructions received through Telegram, and prioritize stealing AI API keys, SSH credentials, access tokens, and database credentials, in that order, with AI API keys explicitly ranked above the others. When an operator sends a task through Telegram, GH0ST passes that task and its persona instructions to the operation’s LLM gateway.
The model interprets the request, writes the terminal commands needed to carry it out, runs them on the victim, reads the output, and decides what to do next. It’s an interactive loop that reports its results back to the same Telegram chat that receives deployment notices. This is closer to giving an attacker a junior operator embedded on every compromised host than to running a traditional scripted implant, and it’s the clearest example yet of AI agent malware operating outside a lab setting.
Persistence, Propagation, and Command-and-Control
Carbonato malware’s worm-like spread does not depend on the AI component at all; it runs on plain shell scripting. Every five minutes, scripts on an infected host scan its local networks and connected Docker bridges for other systems exposing port 2375, and any newly discovered target receives the same implant and begins scanning in turn. That keeps the botnet growing even if the Telegram-and-LLM control channel is disrupted.
For durability on each infected host, the malware layers in multiple persistence mechanisms simultaneously: cron jobs, systemd timers, rc.local entries, and OpenRC hooks, so that removing any single one doesn’t evict it. Process names are disguised to resemble legitimate kernel worker threads, and a cryptocurrency miner is planted under a path that mimics systemd-logind, a core Linux service most administrators wouldn’t think to inspect closely.
Why Exposed Docker Daemon APIs Are Still a Critical Risk
Carbonato malware is a reminder that this specific misconfiguration, the Docker daemon API left open on the network without TLS or authentication, has been a known, high-severity issue for years and keeps producing new botnets anyway.
Docker’s own documentation has long warned that the daemon socket must be treated as equivalent to root access to the host, and by default the API only listens on a local Unix socket for exactly this reason. Enabling the TCP listener on port 2375 without layering on mutual TLS and an authorization plugin removes that protection entirely.
Attackers don’t need to target a specific organization to find these hosts. Internet-wide scanning services routinely index Docker’s remote API. Campaigns going back to at least 2019, including cryptojacking operations that themselves used Shodan queries to hunt for more victims, have shown that an exposed Docker API is typically found and abused within hours of appearing on the network, not days. Carbonato malware simply raises the ceiling on what happens after that initial discovery.
Hermes Agent’s History of Abuse
Carbonato malware is not the first time Hermes Agent has turned up on the wrong side of an incident. The framework has previously been implicated in an automated attack against a Thai government finance ministry, in autonomous server-compromise activity built around DeepSeek AI, and researchers have separately documented a card-skimming operation that harvested 600,000 credit card records using the same underlying agent architecture.
None of these incidents suggest a flaw in Hermes Agent’s code; in every case, investigators found the framework itself unmodified. The pattern instead reflects how easy it now is to repurpose an accessible, well-documented open-source AI agent as an attacker’s control plane, simply by swapping its persona and pointing it at stolen infrastructure.
CyberInfos Analyst Insight
CyberInfos assesses that Carbonato malware is best understood as a preview of where commodity botnets are heading, not as an unusually sophisticated one-off. The compromise itself is unremarkable: an unauthenticated Docker API is one of the oldest cloud misconfigurations in the book, and nothing about Carbonato’s initial access requires new detection logic beyond what has been recommended since the first Docker cryptojacking waves years ago.
What changes the risk calculus is the operator interface bolted on afterward. A human attacker manually working through hundreds of shells doesn’t scale. An attacker directing an LLM-backed agent that writes and adapts its own commands across hundreds of hosts does.
That difference has a practical consequence for defenders. Post-compromise activity on hosts like these should be expected to look less like a fixed script and more like an improvising human operator, which has implications for behavioral detection tuned to “known bad command” patterns rather than intent.
A common mistake CyberInfos sees in the field is teams treating container escape risk as a Kubernetes-specific concern. Carbonato malware is a plain single-host Docker Engine attack, with no orchestrator involved at all, and the financial and operational fallout from a single compromised host, from stolen AI API keys to a full rebuild, doesn’t require a cluster to be painful.
Carbonato by the Numbers: Key Statistics
- ThreatDown’s recovered evidence spans October 2024 to August 2026, indicating the operation ran for roughly two years before public disclosure on September 24, 2026.
- The exposed registry investigators analyzed contained 59 repositories, 234 tags, and 605 verified blobs, totaling about 4.3 GB of image data, per ThreatDown’s research.
- Carbonato malware’s re-scan interval for finding new victims is every five minutes, per ThreatDown, which is what gives the botnet its rapid, worm-like growth curve.
- Exposed, unauthenticated Docker API endpoints have been a persistent, large-scale problem for years. Internet-scanning services have repeatedly indexed thousands of these hosts since Docker cryptojacking campaigns were first documented publicly around 2018-2019, underscoring that Carbonato malware is exploiting a chronic, not a novel, exposure.
- Hermes Agent, the framework Carbonato malware abuses, has separately been tied to a card-skimming campaign that stole 600,000 credit card details, illustrating the framework’s recurring appeal to threat actors beyond this single operation.
Real-World Examples
The Carbonato malware registry exposure: The clearest case study is Carbonato itself. ThreatDown’s researchers found the operators’ own container registry sitting open on the internet without authentication, in the same class of misconfiguration the malware exploits in its victims. That single mistake handed defenders the Carbonato malware toolchain, command-and-control addresses, bot tokens, and, notably, the shared password protecting the attackers’ own AI gateway.
Hermes Agent misuse against a government target: Separate from Carbonato, security researchers have documented Hermes Agent being used to automate an attack against Thailand’s finance ministry, illustrating that the framework’s abuse is not limited to opportunistic botnets and has also appeared in more targeted operations.
Card-skimming at scale: A distinct campaign using the same agent architecture was linked to the theft of 600,000 credit card records, showing how quickly an accessible open-source AI agent framework can be re-tasked across very different attack types, financial malware, botnets, and e-commerce skimming alike, once its persona file is swapped.
Docker Security Audit Checklist
Use this checklist to assess whether your Docker infrastructure is exposed to Carbonato-style compromise, based on the CIS Docker Benchmark and the specific attack path Carbonato malware relies on.
Daemon exposure
- Confirm the Docker daemon API is not bound to a public or routable interface on port 2375/2376
- If remote API access is genuinely required, enforce mutual TLS (client and server certificates) rather than plaintext HTTP
- Pair TLS with an authorization plugin so authentication alone isn’t the only gate
- Block ports 2375 and 2376 at the network firewall/security group level by default, and route any legitimate remote access through a VPN or bastion host
- Restrict the Unix socket
/var/run/docker.socktoroot:dockerownership with660or more restrictive permissions
Access control
- Audit who is in the local
dockergroup: group membership is equivalent to root on the host - Remove any CI/CD runners, monitoring agents, or third-party containers with unnecessary access to the Docker socket
- Never bind-mount
/var/run/docker.sockinto an application container unless that container is fully trusted
Container privileges
- Confirm no production containers run with
--privilegedunless there is a specific, documented, unavoidable reason - Avoid mounting the host root filesystem (
/) or other sensitive host paths into containers - Run container processes as a non-root user via a dedicated
USERdirective in the Dockerfile - Drop unnecessary Linux capabilities (
--cap-drop=ALL, then add back only what’s required) - Enable user namespace remapping so a container’s root does not map to the host’s root
Monitoring and detection
- Enable Docker daemon audit logging and alert on unexpected
docker execor container-creation events from unfamiliar sources - Monitor for unexplained outbound SSH tunnels, especially reverse tunnels initiated from container hosts
- Watch for unusual scheduled-task creation across cron, systemd timers,
rc.local, and OpenRC in the same window - Baseline and alert on unexpected outbound Telegram API traffic from server infrastructure that has no legitimate reason to contact it
- Run
docker-bench-securityor an equivalent CIS Docker Benchmark scanner on a recurring schedule, not just at initial setup
Registry hygiene
- Require authentication on any private container registry: the Carbonato operators’ own infrastructure was discovered because they made this exact mistake
- Scan images for embedded secrets, API keys, and hardcoded credentials before they’re pushed
Detecting Carbonato on Your Infrastructure
If you manage Docker hosts, especially any with a history of network-exposed daemon access, check for the following indicators that ThreatDown associates directly with this campaign:
- A
SOUL.mdpersona file (commonly under a.hermesdirectory) containing the string “GH0ST” - An environment file (
.env) containing aCARBONATO_API_KEYsetting - Unexpected or unexplained Telegram API traffic originating from server infrastructure
- Reverse SSH tunnels connecting outbound to autonomous system AS262145
- A watchdog-style file at a path such as
/usr/local/bin/.docker-network-monitor - Process listings showing disguised entries mimicking kernel worker threads (for example, arguments styled like
[kworker/u2:0]) or a miner process running under a path resemblingsystemd-logind
The presence of Hermes Agent alone is not proof of compromise, since it’s legitimate, widely used software. It’s the persona file content and the accompanying indicators above that distinguish a Carbonato infection from a benign Hermes Agent deployment. If any of these are found, treat the host as compromised, isolate it from the network, and rotate every credential and AI API key that host could have reached, since credential theft is a stated priority for the GH0ST agent.
FAQ
What is Carbonato malware?
Carbonato malware is a Docker-targeting botnet, publicly disclosed on September 24, 2026, that compromises hosts with an exposed, unauthenticated Docker daemon API and installs an AI agent framework to give its operators live, interactive control over each infected machine.
How does Carbonato malware get into a system?
It connects to a Docker daemon API exposed on port 2375 without authentication, then instructs the daemon to launch a privileged container with host filesystem access, which effectively grants the attacker host-level execution with no exploit required.
What is the Hermes Agent AI framework?
Hermes Agent is a legitimate, MIT-licensed open-source AI agent framework built by Nous Research that accepts tasks over Telegram, executes terminal commands, and connects to large language model endpoints. Carbonato repurposes it, unmodified, by overwriting its persona file.
Who is behind Carbonato malware?
ThreatDown, the research arm of Malwarebytes, has not attributed Carbonato to any known threat cluster, though several artifacts in the recovered infrastructure point toward a Costa Rica-based operator.
Is Docker itself vulnerable to Carbonato?
No. Carbonato does not exploit a vulnerability in Docker’s code. It abuses a common misconfiguration, an administrator exposing the Docker daemon’s remote API to the network without TLS or authentication, which Docker’s own documentation has long warned against.
How can I tell if my Docker host is infected with Carbonato?
Check for a SOUL.md file referencing “GH0ST,” a .env file containing CARBONATO_API_KEY, unexplained outbound Telegram traffic, reverse SSH tunnels toward AS262145, and disguised process names or a miner masquerading as systemd-logind.
Does Carbonato malware spread automatically?
Yes. Infected hosts belonging to the Carbonato malware botnet scan their local networks and Docker bridges every five minutes for other systems with an exposed port 2375, and automatically deploy the implant to any they find, independent of the AI agent component.
What is the fastest fix for exposed Docker API risk?
Ensure the Docker daemon is not listening on a public or routable interface on port 2375. If remote API access is required, enforce mutual TLS with an authorization plugin and restrict access through a firewall, VPN, or bastion host.
Can a non-privileged container still be a risk?
Yes, though the risk is lower. Carbonato specifically relies on a privileged container with host mounts and host namespaces to escalate to full host control. Removing --privileged and host bind-mounts significantly raises the bar even if the API is briefly reachable.
What should I do if I find Carbonato indicators on a host?
Isolate the host from the network immediately, preserve forensic evidence before remediation, rotate every credential and AI API key that host had access to, and rebuild the host from a known-clean image rather than attempting to manually clean an already-privileged compromise.
Has Hermes Agent been abused in other attacks besides Carbonato?
Yes. Researchers have separately linked Hermes Agent to an automated attack on a government finance ministry, autonomous server-compromise activity involving DeepSeek AI, and a card-skimming campaign that stole 600,000 credit card records.
Does using Docker Swarm or Kubernetes protect against Carbonato?
Not inherently. Carbonato malware targets the standalone Docker Engine API directly. Orchestrators don’t eliminate the risk if the underlying daemon’s remote API is still exposed without authentication on any node.
Final Thoughts
Carbonato malware succeeds for an old reason wrapped in a new capability. An exposed, unauthenticated Docker daemon API still hands out root-equivalent access to anyone who finds it, and in 2026 that access now comes with a live AI agent attached rather than a static script. The fix for the entry point hasn’t changed: keep the Docker API off the network, enforce TLS and authorization, and restrict container privileges.
The urgency has changed. Teams should treat any internet-facing Docker Engine as a priority audit item this week, not the next time a compliance cycle comes around, and should check the indicators above against existing infrastructure regardless of whether an incident is suspected.
Longer term, expect more botnets to follow Carbonato’s blueprint of pairing a known, boring misconfiguration with an off-the-shelf AI agent as the payload. That means detection strategies built solely around fixed command signatures will need to evolve toward recognizing adaptive, operator-directed behavior instead.
