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

Introduction

In the first part of our research, we traced a failed attack against our Docker honeypot to an exposed offensive infrastructure combining Hermes, the Carbonato model gateway, and other attack tools.

How did the attacker use this infrastructure to carry out tasks?

Our analysis of the Hermes session database, agent logs, and skill telemetry revealed how a single parent session coordinated 29 delegated workers, executed offensive tasks, and maintained a library of reusable attack methods.

The records provide a closer look at how AI agents can be integrated into threat operations, from receiving instructions to preserving methods and lessons from previous tasks.

For our full analysis, read our technical brief.

One AI agent coordinating multiple tasks

The attacker used Telegram to send instructions to Hermes, which routed them to a persistent parent session. It maintained the conversation context, selected tools, and delegated specific tasks to short-lived workers.

We identified 29 delegated workers launched in 14 waves. Each worker received a bounded assignment, such as examining an exposed database, checking an administrative interface, or gathering information about surrounding infrastructure. Workers returned their findings to the parent session but could not delegate tasks further.

Despite the number of workers, the parent session handled most of the activity. It accounted for approximately 81% of the model requests and performed all recorded execute_code operations. The workers primarily handled narrower searches and probes before returning summaries.

This setup allowed the attacker to manage multiple tasks through one conversation without tracking every command or intermediate result from individual agents.'

AI models and offensive tools operating independently

The attacker separated AI model requests from tool execution. Hermes ran commands and offensive tools on one server, while Carbonato handled model requests through a separate OpenAI-compatible endpoint.

The configuration allowed the attacker to change the model without rebuilding the rest of the environment. Hermes switched from modelo2 to modelo13 during the operation, while the parent session, gateway route, tools, and workbench remained unchanged.

The offensive capabilities did not depend on a single AI model. The same execution environment could continue using its tools and workflows after the model switch.

How Hermes preserved and updated attack methods

We uncovered 19 agent-created skill packages covering reconnaissance and post-exploitation tasks. The library recorded 435 uses and 430 patches, including updates to commands, reference materials, and instructions.

Hermes could initiate background reviews after tasks, using the results to update existing skills. These updates preserved operational knowledge, including methods that worked, corrections, false positives, and approaches that failed.

For example, the Docker exploitation skill retained notes about honeypots, API-version mismatches, and read-only proxies. Other packages recorded information about exposed databases, application services, and infrastructure reconnaissance.

This meant that knowledge did not necessarily disappear when a delegated worker finished its assignment. The parent could retain a worker’s summary, while the skill library preserved the methods for later tasks. These updates also modified skill files rather than retraining the AI models. It is worth noting that these capabilities to update its own methods are a standard feature of Hermes; the attacker did not have to particularly go out of their way to use these capabilities.

Targets beyond Docker

Although a Docker honeypot led us to the operation, the attacker’s activity extended to other exposed services. The retained logs contained evidence of activity involving databases, monitoring platforms, Java applications, message brokers, administrative interfaces, and other services, as shown in Figure 3.

Not every recorded target or available attack method indicated a successful compromise. To assess our evidence, we distinguished four levels of activity:

• Capability: A tool, skill, or probe was available.
• Attempt: Logs recorded an actual request or command.
• Access: Returned data or tool output demonstrated access.
• Persistence or collection: Additional artifacts showed retained access or data collection activity.

These are important when evaluating AI-assisted attacks where numerous requests, tasks, and tools can create an extensive record of activities.

How organizations can mitigate AI-assisted attacks

Organizations should strengthen their defenses by correlating suspicious activity across container, host, network, and application environments:

• Monitor Docker management activity. Restrict unauthorized API access and alert on unusual container creation, execution, deletion, and image pulls, particularly when privileged modes or host filesystem mounts are involved.
• Correlate container and host behavior. Watch out for unexpected Docker socket mounts, host namespace access, nsenter execution, and changes to SSH authorized keys. These behaviors become more significant when associated with privileged containers or host filesystem access.
• Examine suspicious network communications. Monitor unexpected connections to external container registries, private model gateways, and messaging services, particularly when they coincide with unauthorized container or process activity.
• Look for related activity across exposed services. Correlate unusual access to databases, monitoring platforms, management interfaces, and application services. Activity against seemingly unrelated systems might be part of the same operation.

Conclusion

Our research showed how an attacker used AI agents to coordinate conventional offensive tools, delegate tasks, and maintain reusable attack methods. A persistent parent session, short-lived workers, and an evolving skill library allowed the operation to retain context and methods across different tasks and services.

These findings do not establish that AI made the attacks more successful. They do, however, show how AI agent frameworks can organize offensive activity and preserve operational knowledge. Defenders should connect evidence across container, host, network, and application environments to identify coordinated attacks and assess their impact.

For our full analysis, read our technical brief here .