Skip to main content
Return to Blog TrendAI™ Security
AI & emerging technologies Cloud & supply chain

From a Docker Ping to an AI Command Plane: Inside the Hermes Attack Workbench and Carbonato Model Gateway — Part 1: Discovery

Attack attempts against our Docker honeypot led us to uncover AI-assisted attack infrastructure combining AI agents and other offensive tools. We examine its components, security implications, and how organizations can mitigate the risks.

AI General Markets Technology, Media, & Communications Emerging technologies Cloud Software supply chain
November 9th, 2026 4 min read Alfredo Oliveira , Nelson William Gamazo Sanchez
TrendAI
From a Docker Ping to an AI Command Plane: Inside the Hermes Attack Workbench and Carbonato Model Gateway — Part 1: Discovery
Download the PDF

Key Takeaways

  • Our research into an attempted Docker takeover shows how exposed Docker APIs can create opportunities for host compromise.
  • The attacker attempted to access the host filesystem and deploy payloads designed for remote access and persistence. We traced these attempts to the attacker’s malicious scripts, infrastructure, and AI-assisted toolchain.
  • Our analysis of the attacker’s container registries revealed how image names and tags can conceal their functionality. We found 243 tags pointing to seven builds, and seemingly unrelated images shared the same entrypoint scripts, highlighting the need to inspect image contents.
  • Our research revealed how AI agents can be integrated into offensive operations. We uncovered a toolchain combining Hermes, Carbonato, scanners, and other tools, with 29 delegated agents and activity spanning multiple services.

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
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
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
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.

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