從 Docker Ping 到 AI 指揮中樞：解析 Hermes 攻擊工作台與 Carbonato 模型閘道（上）

2026 年 7 月，趨勢科技 TrendAI™ 研究團隊在蜜罐（Honeypot）中觀察到針對 Docker API 的攻擊活動。攻擊者從最初簡單的連線測試（Ping），逐步嘗試建立容器、存取主機檔案系統，以及部署惡意指令碼。雖然攻擊者因蜜罐環境的技術限制，未能成功啟動容器，但研究團隊仍循著惡意程式伺服器追查，進一步揭露一套結合 Hermes AI 代理程式框架、Carbonato 私有模型閘道、Telegram 控制介面及多種掃描工具的 AI 輔助攻擊工具鏈。

AI General Markets Technology, Media, & Communications Emerging technologies Cloud Software supply chain

Introduction

In July 2026, we observed an attacker probing the Docker API of one of our honeypots. Over at least seven noncontiguous weeks from early July to October 2026, we observed what began with a simple ping progress into attempts to create containers, access the host filesystem, and deploy malicious scripts.

The attempts failed, but they left behind valuable evidence. Following the attacker’s payload server led us to a much larger operation involving:

Hermes, an AI agent framework.
Carbonato, a private model gateway.
A collection of scanners, scripts, and container images supporting offensive activity across multiple services.

Our research provides a closer look at how the attacker assembled an AI-assisted toolchain around established attack techniques, the infrastructure supporting it, and the risks these capabilities present to organizations.

For our complete findings and analysis, read our technical brief here .

From a Docker probe to a takeover attempt

The attacker initially queried the exposed Docker API on TCP port 2375, listing containers, testing image execution, and gathering information about the host environment.

The attacker then attempted to create a container with the host’s root filesystem mounted read-only and execute a script retrieved from an external server. When the attempt failed, they tried different container configurations, base images, privilege settings, and execution methods.

Figure 1. Initial requests to our Docker honeypot, showing a connectivity check (/_ping), container listing, and attempted Alpine echo test

None of the containers started successfully. The failures were caused by our honeypot’s nested Docker runtime, which prevented runc from accepting the /proc layout. However, the unsuccessful attempts gave us a way to examine the intended payloads. The attacker’s server hosted two scripts:

A script designed to establish a reverse shell
Another script that adds the attacker’s SSH public key to authorized accounts for persistent access

These show how an exposed Docker management interface can provide an opening for attempts to gain host-level access, execute commands, and establish persistence.

Inside the AI-assisted attack workbench

Tracing the payload server led us to an exposed workbench running Hermes, Kali Linux-based tools, scanners, helper containers, and other components. A separate server hosted Carbonato, the attacker’s private OpenAI-compatible model gateway.

Together, these components formed an environment that connected AI agents with conventional offensive tools.

Hermes provided the agent framework, including persistent sessions, delegated sub-agents, and tools for interacting with shells, code, and files. Carbonato handled model requests, while Telegram served as the interface through which the attacker sent instructions and received reports.

The recovered Hermes logs showed a single, long-running parent session spawning 29 short-lived agents across 14 waves. The parent and its workers generated 2,938 model requests.

We found that Docker was not their only focus. The same environment contained scripts and logs associated with activity against Redis, etcd, Spring Cloud Config, Prometheus, Jupyter, Grafana, message brokers, and application login interfaces.

Figure 2. Architecture of the AI-assisted attack infrastructure, showing connections among the attacker’s Telegram channel, Hermes workbench, Carbonato model gateway, Docker registries, and targets

The significance lies in how these capabilities were brought together. Rather than relying only on separate tools and manual processes, the attacker had assembled an environment capable of delegating tasks to AI agents and supporting activity across different services.

However, the presence of this infrastructure and the observed agent activity do not establish whether AI made the attacks more effective or increased their success rate. That distinction is important when assessing the capabilities and potential impact of AI-assisted offensive operations.

Container images that concealed their functionality

Our analysis also uncovered two external Docker registries supplying images used by the attacker’s infrastructure:

The primary registry contained 72 cataloged images and 243 tags. Despite the number of tags, they pointed to only seven distinct builds. In one instance, 161 tags shared the same underlying build.
The secondary registry included images with names resembling ordinary applications and services.

Examining their layers and entrypoint scripts revealed different functionality. For example, an image named apk:latest in the primary registry shared an entrypoint script with android-remote/logger-api:latest in the secondary registry. The script contained functionality associated with Hermes, Telegram, Carbonato, SSH, and Docker. Other sampled images started beacon scripts or contained remote access configuration.

Figure 3. Overview of the two Docker registries, showing their shared and distinct container images and the attacker’s preferred registry order

Conclusion

Our findings reinforce the importance of addressing established security risks, including exposed management interfaces, excessive container privileges, and untrusted images. They also show how attackers can combine familiar techniques with AI agent frameworks to support activity across multiple targets.

For defenders, these findings highlight the importance of restricting access to container management interfaces, inspecting image contents and entrypoint scripts rather than relying on image names, and monitoring for unauthorized SSH keys and suspicious outbound connections.

This first part of our research focuses on our discovery and the infrastructure and tools behind the operation. In the next part, we examine the Hermes session database to understand how the attacker directed the agents and what their recorded activity reveals about the capabilities and limitations of AI-assisted attacks.