/00 — boot sequence

Hello.

aiyu
← Back to Blogs

Article

Hermes AI Agent Used in Unattended Post-Exploitation at Thailand Ministry of Finance

August 1, 2026•6 min read
security ai-agent hermes thailand post-exploitation yolo-mode

A threat actor installed the open-source Hermes AI agent on a rented server, disabled its safety confirmation prompt (the "YOLO" mode), and unleashed it inside Thailand's Ministry of Finance network — the agency that runs the country's treasury and tax collection.

The agent then worked autonomously: scanning hosts for privilege escalation paths, crawling file systems, and reading a folder of staff personnel records dating back to 2012. The operator left the agent's own logs sitting on a web server with directory listing enabled, where threat intelligence firm Hunt.io and researcher Bob Diachenko discovered them alongside 585 files and 470 MB of attack tooling.

This is not a vulnerability in Hermes. The tool is a legitimate open-source assistant from Nous Research that people install to manage email, run chores, and take instructions over Telegram or Slack. The mode the operator used — called YOLO — is a documented feature with its own command-line flag (--yolo), a mid-session /yolo command, or a HERMES_YOLO_MODE=1 environment variable.

What makes this case distinct from prior AI-assisted attacks: the operator ran Hermes on their own infrastructure. No vendor was watching, no API account to ban, no safety team to intervene. When Anthropic disclosed a Chinese group using Claude Code for espionage in November 2025, the attackers had to trick the model into cooperating, and Anthropic banned their accounts. Hermes runs locally — the only guardrail is the one the operator chooses to keep.

Attack Chain Details

Initial Access

The operator was already inside the ministry network before Hermes started. Hunt.io recovered:

  • A hidden web shell planted on a ministry web server
  • Scripts targeting named internal Hadoop systems
  • Stolen mailbox passwords hardcoded into a mail-testing script
  • A password list built from the ministry's own department abbreviations (not a generic dictionary)
  • Shellcode carrying hardcoded paths into the ministry intranet

How the operator first gained access remains unknown. Thailand's national CERT and cybersecurity agency were notified on July 15; neither had published findings when The Hacker News checked on July 24.

What the Agent Did

Five log files (call_00_*.txt) hold the agent's autonomous turns:

  1. Kernel vulnerability scanning against a ministry host
  2. A second LinPEAS run (standard Linux privilege escalation hunter)
  3. A sweep for elevated-permission binaries
  4. A filesystem listing
  5. A recursive crawl of the web root belonging to the Office of the Permanent Secretary — containing Office documents, performance evaluations, and personnel records dating to 2012

The logs show the agent reading the directory. None show the files leaving it.

The scan script was not stock LinPEAS. A customized linpeas.sh checked for four 2026 Linux kernel flaws across three families:

  • Copy Fail (CVE-2026-31431)
  • Dirty Frag (CVE-2026-43284 and CVE-2026-43500)
  • DirtyClone (CVE-2026-43503)

Each hands a local user root where prerequisites hold (Dirty Frag and DirtyClone require CAP_NET_ADMIN). All were weeks old when the operator staged them; nothing recovered names a ministry kernel version or confirms any exploit succeeded.

The Hadoop Route

Most custom code targeted the ministry's Hadoop cluster. A script hive_rce_py2.py connected to HiveServer2 (SQL frontend to Hadoop) on an internal machine at port 10000 and sent a password.

Critical detail: Apache Hive's default authentication mode is NONE — it accepts whatever password is given without checking it. Once connected, the script installs a malicious Java add-on (HiveCmd.jar) as a user-defined function, which lets it run OS commands through ordinary database queries and read results back. Cloudera warns that anyone able to install such a function can run arbitrary code as the Hive service account and reach sensitive data.

Also staged on the server: a previously undocumented Go implant called Hades, built for both Windows and Linux in 62 copies. Hardcoded addresses tie the staging server to a second Hong Kong host.

Attribution Indicators

  • Operator's SSH session came from 103.97.0[.]57 in Hong Kong
  • Agent's web interface password contains the Chinese word Leishen (thunder god)
  • A key for FOFA (a Chinese asset-search service) sits alongside it
  • The same server previously hosted a ShadowPad controller and now runs a VShell command-and-control listener
  • Hunt.io assesses with low-to-medium confidence that the operator is Chinese-speaking; names no specific group

Impact Assessment

The Hermes agent itself did not discover novel vulnerabilities or choose the target. The human did the target-specific work: password lists from internal abbreviations, shellcode with hardcoded ministry paths, Hadoop exploit scripts. The agent handled the repetitive part: run scan, read output, decide next check, run another.

No recovered material shows data exfiltration or that any of the four kernel exploits succeeded. The intrusion appears focused on reconnaissance and establishing persistent access via Hadoop.

Detection & Mitigation

Immediate Checks

  1. Check HiveServer2 authentication mode — if set to NONE, restrict who can install user-defined functions. This default is what the operator's script relied on.
  2. Alert on web server connections to internal Hadoop ports (10000, 50070). A web server reaching a Hadoop node is inherently suspicious.
  3. Search web roots recursively for PHP files with leading-dot names that imitate system caches (e.g., /storage/Counter/nine/.journald-cache.php). These don't appear in normal directory listings.
  4. Patch kernels against all four 2026 flaws above, plus sudo to 1.9.5p2+, polkit for CVE-2021-4034, and any remaining IIS 6.0 WebDAV.

Hermes-Specific Detection

The agent leaves its own trail:

  • Hermes's web panel returns a HermesWebUI server header — ~5,900 scan events over a month (Hunt.io, July 23)
  • Results written to a consistent /hermes-results/ folder with predictable filenames — 575 exposed directory hits in Hunt.io's index

No safety control exposed this operator. A directory listing did. The endpoint sees the same shell commands and tools either way; nothing in an ordinary command line announces that nobody is at the keyboard.

Key Takeaways

  1. AI agents running locally with YOLO mode are force multipliers for attackers — they automate the repetitive post-exploitation grind without vendor oversight
  2. The vulnerability is not in the AI tool — it's in the default configurations the tool interacts with (HiveServer2 NONE auth, unpatched kernels, exposed web roots)
  3. Directory listing + predictable output paths = instant detection — the operator's OPSEC failed on basics, not AI sophistication
  4. Attribution follows human artifacts — password dictionaries, hardcoded paths, language in passwords, C2 infrastructure — not the agent's autonomous behavior
  5. Defenders should audit for exposed Hermes instances — the HermesWebUI header and /hermes-results/ folder are reliable indicators

Frequently Asked Questions

Is Hermes vulnerable?

No. Hermes is a legitimate open-source AI assistant. The YOLO mode is a documented feature explicitly warned against for production use: the configuration guide states to "only use this in trusted, sandboxed environments."

Did the AI discover new exploits?

No. The operator provided a customized LinPEAS script checking for four known 2026 kernel CVEs. The agent automated the scanning; it did not find novel vulnerabilities.

Was data stolen?

Hunt.io's analysis of 585 files and 470 MB of tooling found no evidence of data exfiltration. The agent crawled a personnel records directory but logs don't show files leaving it.

How did the attacker get in initially?

Unknown. A hidden web shell was found on a ministry web server, but the initial access vector wasn't in the recovered artifacts.

Can cloud-hosted AI agents be used this way?

Yes. Any AI agent that can execute shell commands autonomously (YOLO/auto-approve mode) and has network access to target infrastructure can be used this way. The difference with local agents like Hermes: no vendor oversight, no API account to ban.

What should Hermes users do?

  • Never use YOLO mode on systems with access to sensitive infrastructure
  • Treat the agent's credentials as highly privileged — scope them minimally
  • Monitor for HermesWebUI headers and /hermes-results/ directories in your environment
  • The hardline blocklist still refuses machine-wiping commands even in YOLO mode

Sources:

Automated Transmission

This entry was synthesized and populated dynamically using native API integrations.

Resources & Links