CARBONATO: A Botnet Built Around an AI Agent via Exposed Docker APIs

1. Basic Information

• Original Title: CARBONATO: a botnet built around an AI agent
• Source: ThreatDown
• Published Date: 2026-09-22
• Updated Date: None
• Collection Date: 2026-09-25T08:28:50+09:00
• Severity: Critical
• Basis of Severity: ThreatDown analyzed recovered containers and scripts, identifying host intrusion, persistence, propagation, mining, and AI agent-driven operational capabilities. Although the exact number of victim hosts and the execution status of each feature have not been publicly disclosed, the severity is rated as critical because exposed Docker APIs can impact entire hosts.
• Original Link: CARBONATO: a botnet built around an AI agent
• Related Sources: BleepingComputer: New Carbonato malware uses AI agents to hijack exposed Docker hosts, Docker: Protect the Docker daemon socket
• CVE: None
• Target Products and Services: Docker Engine API, Hermes Agent, Telegram, OpenRouter

2. Executive Summary

CARBONATO uses Docker APIs exposed without authentication as an entry point, combining host intrusion and script-based propagation with interactive remote control via the Hermes Agent. The propagation itself is not autonomously decided by an LLM.

3. Attack Flow

This mechanism is described based on publicly available information. Distinctions between researcher verification, implementation analysis, and actual exploitation are detailed in the "Attack Success Determination" section.

Intrusion and Propagation from Docker API to Host

1. The attacker scans for Docker APIs accessible without authentication.
2. The attacker uses privileged container creation and access to host resources to execute operations on the host.
3. Scripts deploy persistence and mining capabilities, periodically scanning surrounding Docker APIs to attempt propagation.

Interactive Control Using an AI Agent

1. The Hermes Agent and attack instructions are deployed on the host.
2. Operators issue tasks via Telegram, and the agent uses LLM services to execute commands.
3. Results are returned through the communication channel. Reverse SSH is a separate connection method, and reports do not indicate that all instructions route through SSH.

4. Attacker Positioning and Execution Location

• Attackers reach unauthenticated Docker APIs externally or from a compromised network.
• Processing on the host depends on permissions permitted by the Docker configuration. The analyzed mechanism accesses the host using privileged containers or similar methods.

5. Visibility for Victims and Administrators

Victims

• Resource consumption due to mining or suspicious persistent processes may be visible, though no screen display is required.

Administrators

• Unexpected privileged containers, host mounts, nsenter usage, scheduled jobs, reverse SSH, and communications to Telegram or LLM services serve as investigation clues.

6. Success and Failure Conditions

Success Conditions

• The attacker reaches an unauthenticated Docker API and can perform operations such as container creation.
• Host intrusion requires a configuration that permits privileged settings, host mounts, or namespace access.
• AI control features require communication with an LLM and valid credentials, but initial API exploitation and script-based propagation do not depend on LLM connectivity.

Failure Conditions and Risk Reduction

• Stop unnecessary network exposure of Docker APIs. If remote management is required, use SSH, mutual TLS, source IP restrictions, or appropriate authorization controls.
• Limit privileged containers, host-side mounts, and namespace sharing to necessary operations only.
• During a compromise, do not rely solely on stopping containers; inspect host-side persistence and recover from a trusted state.

7. What Happens Upon Success

• The analyzed implementation includes remote host control, mining, persistence, and propagation to surrounding Docker environments.
• While some configurations instruct credential collection, the instructions in the materials alone do not prove data theft in individual victim environments.

8. Observable Logs

The following section includes perspectives for internal investigation and detection. This does not mean all items were observed in public incidents.

Email

• There are no public reports indicating that email was used for initial access.

Proxy, SWG, and DNS

• Correlate suspicious destination IPs, Telegram, and LLM service connections with host-side processing.

Endpoints and EDR

• Check for privileged containers, nsenter, /root/.hermes/SOUL.md, /usr/local/bin/.docker-network-monitor, and scheduled jobs.

Authentication and IdP

• Verify subsequent usage of SSH keys or cloud credentials that were accessible from the host.

SaaS and Cloud

• Review container creation settings, image pull history, and LLM API usage origins.

Network

• Inspect TCP/2375 connections, surrounding network scans, and reverse SSH. Prioritize correlating these with unusual processes.

9. Attack Success Determination

Scope Confirmable via Public Information

ThreatDown analyzed recovered materials and operation infrastructure, confirming the implementation of each feature. The execution of all features, successful data theft, and the number of victims on individual compromised hosts have not been publicly disclosed.

Internal Determination Criteria

• Initial Execution Criteria: Correlate unauthorized container creation with subsequent host-side processes or file creation. Public documentation reflects implementation analysis of recovered materials and does not indicate execution of all features in a victim environment. (Scope: Internal containers and hosts.)
• Data Theft or Session Compromise Criteria: Confirm access to credentials and external transmission using separate evidence. (Scope: Success or failure of individual host theft.)

10. Investigation Playbook

The following are proposals for investigation and countermeasures based on public information.

Starting Point for Investigation

• Start with unauthorized Docker operations, privileged containers, or host-side files matching public IoCs.

Initial Verification

• Verify Docker API authentication, connection sources, container privileges, host mounts, and creation timestamps.

Endpoints and Servers

• Preserve container configurations, images, host processes, scheduled jobs, agent settings, and logs.

Authentication and Cloud

• Inspect credentials exposed on hosts and review audit logs for their subsequent use.

Subsequent Operations

• Check for connections to other Docker hosts, mining, access to sensitive information, and additional remote control activities.

Containment

• Isolate the host, stop API exposure, and investigate persistence. If host compromise is confirmed, recover from a trusted state and rotate exposed credentials.

Decision Categories

• Evaluate API access, container creation, host execution, AI control, propagation, and data theft separately.

11. Defense and Detection Ideas

The following are proposals for investigation and countermeasures based on public information.

Single Events

• Detect unauthorized privileged container creation or suspicious host-side scheduled jobs.

Time-Series Correlation

• Correlate Docker operations with host execution, persistence, network scanning, and outbound communications.

Threat Hunting

• Search using public IoCs and SOUL.md files containing GH0ST indicators. The mere presence of Hermes Agent does not inherently indicate maliciousness.

Limitations of Logs

• Implementation materials within registries alone do not prove execution in a victim environment. Records from both containers and hosts are required.

Priority Countermeasures

• Prioritize stopping public API exposure, securing and restricting management paths, minimizing host privileges, and removing host-side persistence.

12. Facts / Inference / Hypothesis

Facts

• ThreatDown analyzed 59 repositories, 234 tags, and 605 verified blobs from public container registry materials obtained in August 2026. This figure does not represent the number of victim hosts.
• The entry point is the Docker API exposed without authentication. Mechanisms using privileged containers, host-side mounts, and namespaces to proceed to host execution have been confirmed.
• The Hermes Agent code itself is unmodified; SOUL.md instructions impart malicious behaviors associated with GH0ST. The inclusion of credential collection in instructions is distinct from actual successful theft in individual cases.
• The architecture uses Telegram to instruct the agent and perform operations via LLMs. A reverse SSH connection path is also implemented separately.
• Periodic scanning and propagation to surrounding networks are implemented via scripts and do not require LLM decision-making.
• Based on infrastructure clues, ThreatDown assesses that the operators are located in Costa Rica. This is the vendor's attribution assessment.

Inference

• Because public exposure of the Docker API and high host privileges create the entry point, while interactive AI control and routine script propagation operate independently, blocking AI communication alone cannot be considered complete containment.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unknowns and Additional Investigation."

13. MITRE ATT&CK Mapping

• T1610 Deploy Container (Confidence: High): Implementation creating containers via exposed Docker APIs has been confirmed.
• T1611 Escape to Host (Confidence: High): Implementation executing tasks on the host using privileged settings and host resource access has been confirmed.
• T1059.004 Command and Scripting Interpreter: Unix Shell (Confidence: High): Shell scripts performing propagation and persistence have been analyzed.

14. Unknowns and Additional Investigation

• Number of victim hosts, distribution by country and industry, and execution frequency of each feature.
• Information actually retrieved and transmitted by the AI agent, along with individual operator instructions.
• Additional operational infrastructure or associates not captured in public data.

15. Impact on SOCs and Organizations

Prioritize checking Docker public exposure settings and host privileges. Do not assume communications with AI services are inherently malicious; investigate by combining unauthorized container creation, host-side persistence, and periodic scanning.

16. Summary by Target Audience

• SOC: Correlate Docker APIs, privileged containers, host-side processes, reverse SSH, and AI communications.
• Administrators: Stop unauthenticated API exposure, restrict management paths, and limit container host privileges.
• Users: Since general users cannot mitigate this, report suspicious resource consumption or processes to Docker administrators.