Hermes Agent 在无人值守状态下对泰国财政部持续运行，而其日志被遗留在网上。

2026年7月9日至13日，威胁情报公司Hunt.io与研究员Bob Diachenko在一台属于针对泰国财政部入侵行动的香港暂存服务器上发现了三个开放目录。这585个文件和470 MB的材料中包括Hermes Agent的日志；该框架是Nous Research推出的开源智能体框架，以“YOLO”模式运行，并关闭了人工审批环节。在无人值守状态下，它运行了LinPEAS权限检查、枚举了SUID二进制文件，并递归爬取了财政部常务秘书办公室所属的一个Web根目录，将可追溯至2012年的人事记录编入目录。同一主机上还驻留了一个此前未被报告的Go植入程序，操作者称之为Hades。Hunt.io未发现文件被窃取的证据，也无法确定入侵者最初是如何进入的。这条完整条目日期为2026年7月30日，置信度评级为A，收录在AI事件档案，与本系列其他由智能体驱动的入侵记录并列。

这些目录位于 43.246.208[.]207 上，该主机属于香港的 AS132883（TOPIDC），而 Hunt.io 的 Attack Capture 于 7 月 9 日、10 日和 13 日将其归档：先是 145 个文件，然后是 62 个，再是 378 个，共计 585 个。该 IP 有记录在案的历史，曾作为 ShadowPad 控制器，且 Hunt.io 查看时，其 21083 端口上正运行着一台 VShell 命令与控制服务器。研究人员表示，他们“没有证据证实或否认”VShell 曾被用于针对该部委。该归档将记录日期标为 2026 年 7 月 30 日；其背后的研究时间更早，由 Hunt.io 在七天披露窗口之后于 7 月 23 日发布，并由 The Record 于 7 月 27 日、Dark Reading 于 7 月 28 日报道。

该代理的五个通话记录

7 月 9 日的目录里有一个名为 hermes-results 的文件夹，内含五个文件，每个文件都以 call_00_ 开头，后面接一串随机字符串。Hunt.io 将其描述为该智能体自身调用的记录，并概述了每次调用返回的内容。第一个是针对某部委主机的权限提升评估和内核漏洞扫描。第二个是第二次 LinPEAS 运行，用于枚举服务。第三个用 find 枚举 SUID 和 SGID 二进制文件。第四个列出容器和文件系统，并夹杂着 broken-pipe 错误——Hunt.io 将其解读为智能体产生的输出超出了服务器所能承载的量。第五个最为关键：对连接到常务秘书办公室的 Web 根目录进行递归搜索，其中存有可追溯至 2012 年的标准 Office 文档、绩效评估表和人事档案。

这一切都不需要在键盘前有人操作。Hunt.io 表示，操作员以“无人值守或 YOLO 模式”运行 Hermes Agent，“绕过了针对可能被视为危险的命令的审批提示”。该框架于 2026 年 2 月发布，作为常驻守护进程运行，并跨会话保留记忆；YOLO 是移除这些提示的选项。Hunt.io 报告称，到 2026 年 7 月，该项目在 GitHub 上的星标数已超过 140,000。云安全联盟（Cloud Security Alliance）对日志的分析描述了一个智能体评估每个结果并选择下一步的过程——从外部看，这种工作流程类似于人类分析师会如何推进，只不过是以机器的速度。

Hunt.io对日志所能证明的内容持谨慎态度。对Web根目录的爬取显示，该agent触及了人员档案；但并未显示这些文件被传出。报告称：“没有证据表明这些文件已被窃取外传。”报告对整个服务器的总结是，这些文件“描述了一场仍在进行的入侵：工具已部署到位，内部访问权限不断扩大，且没有迹象表明数据已离开网络，尽管操作者显然正在对Web内容进行编目。”

人类仍然完成的工作

报告中最有用的是分工。智能体负责通用、可重复的侦察——这类工作可以脚本化，且不需要了解目标。操作员则提供了智能体无从知晓的内容：一份密码词表，由该部内设部门和项目的缩写、内部主机名、不可路由地址，以及围绕特定服务编写的脚本构建而成。Cloud Security Alliance 于7月26日发布的研究简报也提出了同样的观点：人类保留了“针对特定目标的技艺”，而智能体负责运行那些可规模化的部分。

最清楚的例子是 Hadoop 攻击链。7 月 13 日的目录中包含十多个针对 Apache HiveServer2 的文件，其中包括 hive_rce_py2.py，该脚本向内部节点的 10000 端口打开原始套接字，并使用 SASL PLAIN 进行身份验证。HiveServer2 的默认身份验证模式为 NONE，会接受任何凭据而不进行验证，而该脚本正是依赖这一点编写的。随后，它注册一个打包为 HiveCmd.jar 的恶意 Java 用户定义函数，并通过 Hive SQL 传递 shell 命令，从另一台内部节点的 50070 端口通过 WebHDFS 获取输出。另一个独立的 Ambari 载荷通过主机名指定了一个内部 HDFS DataNode，攻击的是管理层而非数据。

该工具包的其余部分遵循相同的准备模式。以 gf_ 为前缀的 Node.js 脚本通过 SOCKS5 代理驱动一个无头 Chrome 实例，以访问内部的 GlassFish 管理控制台，使用默认凭据登录并部署 WAR 文件；Hunt.io 无法确认这两个 WAR 文件中是否有任何一个已部署。一个伪装成日志缓存文件的 PHP Web Shell 被放置在部委 Web 服务器的 /storage/Counter/nine/.journald-cache.php 上。一个名为 mail4.pl 的 Perl 脚本使用硬编码的邮箱地址和由提取出的令牌构建的密码，针对部委邮件基础设施测试 SMTP 身份验证；名为 mail_test.py 和 mail3.py 的 Python 脚本也执行相同操作。一个名为 alf_cookie.txt 的文本文件保存了面向某个内部部委地址的 Alfresco 会话材料。两个目录还存有 CVE-2021-3156（sudo 堆溢出）、CVE-2021-4034（PwnKit）和 CVE-2017-7269（IIS 6.0 WebDAV 溢出）的漏洞利用代码，以及 shellcode 和指向该部委内网的路径。

这里没有任何新奇的手法。日志所补充说明的是，这次枚举是持续不断地运行的，没有人类操作员在命令之间通常会留下的停顿——云安全联盟的这份说明指出，围绕键盘敲击节奏构建的检测手段与这种情况并不匹配。

Hades，已暂存但未确认正在运行

7月10日的目录是一台投递服务器：62个编译好的Go二进制文件，格式为Windows PE和Linux ELF，其中许多以合法系统进程命名——Windows上的ctfmon、csrss、conhost和MicrosoftEdgeUpdate；Linux上的kworker、multipathd和accounts-daemon。其中两个带有项目名称：hades_linux_amd64和hades_windows_amd64。Hunt.io分析了每个平台的一个样本，发现它们来自同一代码库；其余60个具有相同的大小范围和构建特征，但未被逐一检查。

静态和动态分析发现，伪装成静态 Web 资源的 HTTPS 命令与控制通道：/assets/app.min.js 用于上线签到，/assets/vendor.js 用于任务下发，/assets/main.js 用于上传。载荷均使用按构建硬编码的密钥通过 AES-256-GCM 加密。环境变量包括终止日期 HADES_KILLDATE，以及工作时间表，使植入体在配置的时间窗口之外休眠。Windows 版本通过注册表 Run 键和计划任务实现持久化，通过反射式加载到被掏空的 svchost.exe 中在内存里执行，通过 GDI 捕获屏幕截图并提供 SOCKS 代理；Linux 版本使用 cron 作业、标准 PTY 和 shellcode 执行。两者均支持分块、可断点续传的文件传输。

这两个被分析的样本指向了不同的控制器：Windows 可执行文件 dwm_33b7.exe 向端口 443 上的暂存服务器发送信标，而 Linux 二进制文件 multipathd_04d0 则指向端口 12443 上的 202.181.27[.]115——该主机是通过共享证书指纹发现的。Hunt.io 指出，这种命名可能是巧合：在希腊神话中，赫尔墨斯引导灵魂前往哈迪斯。

没有任何消息来源能够证实的是 Hades 运行在该部委内部。Hunt.io 是从操作者自己的服务器上恢复出这些二进制文件的。云安全联盟（Cloud Security Alliance）的说明指出，没有任何已恢复的样本显示 Hades 曾到达部委的机器；Dark Reading 则报道称，该研究并未说明它被部署在何处。该植入物是操作者已构建并部署到位的一种能力，而非已确认驻留在部委主机上的程序。

幕后是谁？

Hunt.io 并未点名任何组织。它基于四项指标，以低至中等置信度评估该操作者使用中文或对该语言极为熟悉：该主机曾作为 ShadowPad 控制端的历史、香港基础设施、一个包含中文词“Leishen”（意为雷神）的 Hermes Web 界面密码，以及一个用于 FOFA（中国互联网资产侦察服务）的 API 密钥。一份环境快照还记录到 SSH 客户端 103.97.0[.]57（位于 AS133073，HK Kwaifong Group Limited）连接至暂存服务器。这些都不构成对某个国家或某个具名集群的归因，Hunt.io 也明确表示如此。

关于这次入侵本身，仍有两件事尚不清楚。初始访问路径是其中之一：报告得出结论称，"初始访问的方法仍然未知"。另一件是影响范围。Hunt.io 表示，活跃的会话 cookie、已部署的 Web shell 以及内部网络访问表明，该操作者"能够攻陷 MOF 网络内的多个系统"，但它同时警告称，仅凭 cookie 值并不能证明发生过登录，因为 Laravel 会向任何访问者发放会话令牌和 CSRF 令牌。这一入侵判断是基于取证痕迹作出的评估，而非经确认的主机清单。

泰国接下来做了什么

Hunt.io 表示，它和 Diachenko 于 2026 年 7 月 15 日通知了泰国国家 CERT 和国家网络安全局，并且两家机构均在当天确认收到通知；随后发布被搁置了七天。在为本文审查的报道范围内，未发现任何提及该部的 ThaiCERT 公开公告。

7月27日，即The Record报道此次入侵的当天，泰国国家网络安全委员会召开了2026年第二次会议，并批准了针对AI代理威胁的措施。该机构自己的说明称，委员会指派ThaiCERT监测、分析和跟踪AI代理威胁，向面临风险的机构发出警告，并支持事件响应和数字取证；责成各行业CERT加强检查和报告；并认可主动措施，包括检查面向互联网的系统、管理特权账户、网络分段、备份和恢复测试。它还指示制定关于组织内部安全、透明和可审计使用AI代理的指南，并由ThaiCERT和各行业CERT开展模拟AI代理攻击的联合演练。该帖文未点名财政部或Hunt.io，而The Record指出，官员在评判这些显然针对该威胁的措施时“没有直接提及Hunt.io的调查”。会议与此次入侵之间的任何因果联系都是一种推断，而非该机构的声明。

据 The Record 报道，国家网络安全委员会副秘书长 Theerawut Wittayakorn 在会后表示，泰国“必须能够充分受益于人工智能，同时系统性地管理相关风险”。财政部方面则保持沉默：The Record 于7月27日报道称，该部尚未公开承认该事件，也未回应置评请求；Dark Reading 次日报道称，政府未作评论。该档案中日期为7月30日的条目记录了同样的内容。

哪些已确立，哪些已评估，哪些缺失

归档将该条目归类为已发生事件，严重性为危急，置信度为 A，无争议，记录了实际危害，类型标签为 WEAPON；未标记为里程碑。置信度等级描述的是文档情况，而该文档异常直接：Hunt.io 归档的是操作者的暂存服务器，而不是受害者的日志。它并不描述独立验证，而在这一点上，记录很薄弱。

• 已确认：7月9日至13日期间，同一主机上的三个开放目录，包含585个文件和470 MB数据；五份 Hermes 调用日志，显示 LinPEAS、SUID 枚举、容器列举和 Web 根目录爬取；Hermes Agent 以 YOLO 模式运行；包括 Hades 在内的62个 Go 二进制文件；HiveServer2 脚本及其 UDF；Web Shell 路径；凭据与会话材料；无数据外泄证据；Hunt.io 于7月15日向 ThaiCERT 和 NCSA 发出的通知已于同日确认收到。

• 评估：该操作者使用中文，置信度为低至中等；多个部委系统遭到入侵；NCSA于7月27日采取的措施是对此次入侵的回应。

• 缺失：初始访问路径；操作者触及了多少台主机或记录；是否有任何文件离开网络；是否有任何部委确认；是否有任何公开的 ThaiCERT 公告；是否有任何独立取证审查。

一则二手报道比原始报告更进一步。{{1}}iThome 7月27日的中文安全摘要总结了同一项 Hunt.io 研究，称入侵者通过一个面向互联网的部委服务器上的 PHP Web Shell 进入，且该环境中至少有 47 台主机、54.9 TB 政府财务数据、14 个 Microsoft SQL 数据库、生物识别系统和远程桌面网关。{{/1}} {{2}}这些数字均未出现在 Hunt.io 的报告中，该报告称初始访问方法仍然未知，而档案的记录以该报告为准。{{/2}} {{3}}看到这些更大数字的读者应将其视为未得到原始来源支持。{{/3}}

独立的报道确实存在，但独立的证据并不存在。《The Record》（7月27日）、Dark Reading（7月28日）和云安全联盟（Cloud Security Alliance，7月26日）都依赖 Hunt.io 的数据；没有任何一篇描述其自身的取证检查、受害者访问或样本分析。Dark Reading 补充了对 Hunt.io 研究主管 Esteban Borges 的采访，他表示该公司未发现任何数据外泄的证据，并且他所见到的那些高度依赖 AI 的行动留下的痕迹更多，而非更少。《The Record》补充了 NCSA 的声明。CSA 的说明则补充了分析，以及一条有益的提醒：没有任何已恢复的 artefact 显示 Hades 出现在某部委的机器上。除这些补充内容之外，报道中的事件事实均可追溯到同一份原始报告。

防守队员被告知了什么

Hunt.io 的建议针对那些有明确修复方案的部分。审查 HiveServer2 认证模式并强制执行 UDF 黑名单；递归审计 Web 根目录中名称以点开头、模仿系统缓存的 PHP 文件；将 sudo 修补到 1.9.5p2 或更高版本，并对照 CVE-2021-4034 检查 polkit 版本；对任何仍存在的 IIS 6.0 实例禁用 WebDAV，或迁移出该平台；对 Web 服务器进程向 10000 或 50070 等内部端口发起出站连接的情况发出警报；并更改 GlassFish 管理控制台的默认凭据，将访问限制在受信任网络。对于运行代理框架的组织，云安全联盟增加了一项本应在此处至关重要的控制措施：审计是否在任何地方启用了无人值守或等同于 YOLO 的模式，并除非存在已记录且风险已接受的理由，否则禁用该模式。

Hunt.io 还把这起事件变成了一种发现其他暴露面板的方法。该公司称，Hermes 的 Web 界面会返回一个特征鲜明的 Server 头和一个 Basic-auth realm，而对 HermesWebUI 进行 banner 查询，在上个月返回了约 5,900 条事件；搜索包含该 agent 的 /hermes-results/ 路径的开放目录则返回了 575 条命中。这些是发布时来自单一厂商数据集的计数，并非受害者数量，并且会随着面板的出现和消失而变化。真正有用的是其中的指示线索：暴露的 agent 面板及其输出目录是可被发现的，而这正是此次行动得以曝光的方式。

档案并未将该条目标记为 landmark，技术记录也支持这种克制。LinPEAS、Hive UDF 滥用、默认凭据以及 2017 年公开的漏洞利用都是旧工具；新的地方在于人员配置——一名代理持续进行枚举，一名操作员负责针对特定目标的准备工作。日志所记录的正是这种双人分工。它们无法记录的是影响：操作员究竟深入该部委多远、人事档案中包含什么内容，或者是否有任何东西离开了该网络。在部委或独立调查人员回答这些问题之前，这份记录所描述的只是一次有详尽文档记录的入侵，其代价仍然未知。