What Hermes Changed in Post-Exploitation—and What It Didn't

The Hermes case matters because the agent did not need to discover a novel exploit or choose a target to change the operation.

The attacker had already supplied access, credentials, and target-specific tooling. Hermes took over the repetitive middle: run the scanner, interpret the output, choose the next check, and keep going without an approval prompt.

For defenders, that leaves the familiar intrusion artifacts plus a new and unusually legible layer: the agent’s runtime, configuration, and call history.

What the recovered evidence proves

On July 23, 2026, Hunt.io and Bob Diachenko published their analysis of attacker infrastructure connected to an intrusion at Thailand’s Ministry of Finance.

The researchers captured three exposed directories from July 9 through July 13. Together, they held 585 files and 470 MB of material:

• exploit code and post-exploitation tooling;
• stolen credentials and session material;
• web shells and HTTP tunnels;
• scripts written for named internal systems;
• Windows and Linux builds of a custom Go implant called Hades;
• environment data from the operator’s staging server;
• five output logs from the Hermes agent.

Those logs show Hermes processing LinPEAS output, assessing kernel vulnerabilities, enumerating services and SUID/SGID binaries, listing containers and filesystems, and recursively inspecting a web root containing Office files and personnel records.

This is evidence of a general-purpose AI agent participating in post-exploitation against a real target. It is more substantial than a demonstration in a lab, but the limits still matter.

The recovered material does not establish that Hermes:

• selected the Ministry of Finance as a target;
• obtained initial access;
• discovered a new vulnerability;
• successfully escalated privileges;
• deployed the Hades implant;
• exfiltrated the documents it enumerated;
• operated without any human direction;
• belonged to a known threat group.

Hunt.io found artifacts consistent with access to several ministry systems, but the researchers could not determine the original entry point. Thailand’s CERT and National Cyber Security Agency were notified on July 15. At the time of the report, neither had published its own account of the incident.

That is enough evidence to study how the agent was used. It is not enough to turn every staged capability into a confirmed action.

The human supplied intent. Hermes supplied the loop.

The operator did the parts that required target knowledge.

Recovered scripts contained ministry hostnames, internal addresses, department abbreviations, hardcoded mailbox credentials, and payload paths into the intranet. Other files targeted Apache HiveServer2, Ambari, GlassFish, IIS WebDAV, mail infrastructure, and an administrative web panel.

That is not generic reconnaissance generated from a blank prompt. Someone had already learned enough about the environment to prepare tools for it.

Hermes appears to have handled a narrower but still valuable job. The five call logs record a sequence of routine post-exploitation tasks:

1. Assess a host for privilege-escalation paths.
2. Run or interpret LinPEAS.
3. Enumerate elevated-permission binaries.
4. Inspect the filesystem and container environment.
5. Recursively examine a directory holding potentially sensitive files.

A human operator could perform every one of those tasks. The change is that the operator could delegate the sequence to a persistent agent running in unattended mode.

Hermes documents several execution backends and warns that its local backend runs commands with the same filesystem access as the user. Its configuration supports more isolated backends, including Docker and cloud sandboxes. In this operation, Hunt.io found the agent running with the approval checks removed.

The agent did not create a new intrusion lifecycle. It compressed the time and attention required to move through an existing one.

There are now two layers of evidence

The conventional intrusion evidence remains the primary layer. Web shells, credentials, exploit staging, network infrastructure, malware, process execution, and persistence still describe the impact.

The agent adds an orchestration layer.

Evidence layer	Examples from the case	What it can answer
Infrastructure	Staging IPs, TLS certificates, exposed directories, open ports	Where the operator staged and controlled the activity
Access	Session cookies, hardcoded credentials, web shells, internal hostnames	Which systems and identities may have been reached
Execution	LinPEAS, SUID/SGID searches, exploit code, Hive and GlassFish tooling	Which post-exploitation actions were attempted
Malware	Hades binaries, C2 paths, persistence methods, file hashes	How access could be maintained and controlled
Agent runtime	HermesWebUI, /hermes-results/, call_*.txt, configuration and environment data	Which work was delegated to an agent and how it was run
Agent trace	Prompts, command output, errors, and sequential calls	What the agent observed, decided, and attempted next

This distinction is important during analysis.

A Hermes log showing that the agent checked for a kernel vulnerability is not proof that exploitation succeeded. A file containing an exploit is not proof that it ran. A directory listing is not proof of collection or exfiltration.

The trace provides intent and sequence. Host and network telemetry still have to establish effect.

Do not invent an AI-specific ATT&CK matrix

Most of the observed behavior already maps cleanly to MITRE ATT&CK.

Hunt.io mapped the operation to techniques including:

• Exploit Public-Facing Application;
• Server Software Component: Web Shell;
• Masquerading;
• Application Layer Protocol: Web Protocols;
• Proxy;
• Command and Scripting Interpreter;
• Exploitation for Privilege Escalation;
• System Information Discovery;
• File and Directory Discovery;
• Steal Web Session Cookie;
• Password Spraying;
• Scheduled Task or Job;
• Process Injection.

Hermes did not make those techniques obsolete. It became part of the procedure.

I would record that relationship in the detection and case data:

behavior: File and Directory Discovery
executor: Hermes agent
approval_mode: unattended
operator_goal: post-exploitation enumeration
input_artifact: agent call and prior command output
observed_effect: recursive directory listing
effect_confirmed_by: agent trace only

This keeps the stable behavior separate from the implementation.

The same discovery technique might be performed by an interactive shell today, an agent tomorrow, and a purpose-built script next month. The analytic should survive those changes. The executor field helps explain speed, scale, and follow-on behavior without pretending that find becomes a new technique when a model selects it.

This is also where MITRE ATLAS can complement ATT&CK. ATLAS helps describe the AI-enabled system and its autonomous behavior. ATT&CK still describes what happened to the enterprise environment.

Hunt the runtime without losing the intrusion

Hunt.io documented several artifacts that can identify exposed Hermes infrastructure:

• an HTTP Server header containing HermesWebUI;
• a Basic authentication realm of Hermes WebUI;
• a recurring /hermes-results/ directory;
• output files following a call_*.txt pattern.

Those are useful pivots for threat-intelligence collection. They can identify exposed panels, open working directories, and additional operations whose owners left agent output reachable from the Internet.

They are not sufficient as enterprise detections by themselves.

Hermes is legitimate open-source software. A panel banner does not make its operator malicious. The file paths may change. A competent attacker can remove headers, close directory listing, or rename the output. The infrastructure IOC is a lead, not a verdict.

Inside an enterprise, I would focus on relationships that are harder to rename:

1. An agent process or daemon launches a shell or execution tool.
2. The child process performs broad host, permission, service, or filesystem discovery.
3. Command output returns to a persistent agent session.
4. The agent selects another command without a new human approval event.
5. The sequence repeats across hosts or over a longer period than an interactive session.

Useful host and agent telemetry would include:

• process ancestry from the agent runtime to shells and discovery tools;
• command line, working directory, user, container, and destination host;
• tool name, arguments, result, and execution status;
• approval mode and the policy decision for each action;
• the model, provider, session, and agent version;
• the initiating user and the time of the last human instruction;
• files read, credentials accessed, and network destinations reached;
• whether the action matched an approved task and asset scope.

Traditional EDR can see much of the execution. Agent traces can explain why one command followed another. Neither view is complete alone.

Detection has to account for machine-paced tradecraft

Agent-assisted post-exploitation may change the shape of otherwise familiar activity.

An interactive operator pauses to read output, consult notes, switch tools, and decide what to try next. An agent can parse output and continue immediately. It can also keep operating while the human works elsewhere.

That suggests behavioral hypotheses worth testing:

• discovery commands occur in rapid, semantically related sequences;
• large outputs are consumed by the parent process rather than an interactive terminal;
• the same workflow repeats with small changes across multiple systems;
• actions continue outside the operator’s interactive session;
• a general-purpose agent runtime touches credentials, administrative tools, or production hosts;
• approval and prompt logs are absent even though the runtime performs high-impact actions;
• the agent reads sensitive files shortly after privilege or service enumeration.

None of these is malicious in isolation. Internal automation, configuration management, and sanctioned security agents can look similar.

The differentiators are identity, authorization, asset scope, expected runtime, and change control. A detection program therefore needs an inventory of approved agents and their normal capabilities. “AI process observed” is not a useful alert. “Unregistered agent used a local execution backend to run discovery commands on a finance server with no approval record” is much closer.

Preserve the agent evidence during response

Agent state can disappear quickly.

Sessions can be reset. Containers can be destroyed. hosted-model traces may be unavailable to the customer. Context can be compressed. Tool output may exist only in a working directory. An attacker can delete the orchestration layer while leaving conventional malware behind.

An incident-response plan for agent-assisted activity should preserve:

• the full tool-call trace and timestamps;
• prompts and external content supplied to the agent;
• model and runtime versions;
• configuration, environment, skills, and memory;
• approval settings and policy decisions;
• session identifiers and provider request IDs;
• container images, mounts, and network policy;
• generated scripts and downloaded tools;
• child-process telemetry and command output;
• the last known human instruction.

This evidence can answer questions that EDR cannot. Did the human specify the target file, or did the agent select it after reading a directory? Did a tool call fail and cause the agent to choose another route? Was a credential passed in the prompt, read from disk, or inherited from the runtime?

Those questions affect both attribution and containment.

What I would operationalize now

The case suggests a short list of actions for both AISecOps and threat-intelligence teams.

1. Inventory general-purpose agents. Record owners, execution backends, identities, tools, reachable assets, approval modes, and log locations.
2. Ban unattended local execution by default. Make exceptions explicit, narrow, time-bounded, and monitored.
3. Collect the orchestration layer. Preserve tool calls, approvals, session identifiers, and provenance alongside host and network telemetry.
4. Add agent runtimes to threat hunting. Look for unregistered daemons, agent-to-shell ancestry, persistent sessions, and predictable output directories.
5. Track public agent infrastructure. Treat panels, headers, result paths, and exposed traces as pivots that need context and validation.
6. Extend response playbooks. Acquire memory, skills, configuration, and traces before terminating the runtime.
7. Keep claims tied to evidence. Separate attempted action, successful execution, access, collection, and exfiltration.

The most useful part of this case is not a claim that autonomous hacking has arrived fully formed.

It is that a real operator used an agent to perform recognizable post-exploitation work, and then left enough of the orchestration layer exposed for defenders to study it.

The intrusion still produced IOCs. It still mapped to ATT&CK. It still depended on credentials, vulnerable services, web shells, and command execution.

Hermes did not replace that evidence. It added another place to look.