Hermes Agent 在無人監管下對泰國財政部執行操作，其日誌被留在線上

2026年7月9日至13日之間，威脅情報公司 Hunt.io 與研究員 Bob Diachenko 在一台香港中繼伺服器上發現三個開放目錄，該伺服器屬於針對泰國財政部的入侵行動。585 個檔案與 470 MB 資料中，包含 Hermes Agent 的日誌；此為 Nous Research 的開源代理框架，以「YOLO」模式運行，並關閉了人工核准步驟。它在無人監督下執行 LinPEAS 權限檢查、列舉 SUID 二進位檔，並遞迴爬取隸屬於財政部常任秘書辦公室的網站根目錄，將可追溯至 2012 年的人事紀錄編目建檔。同一主機還載有操作者稱為 Hades 的前所未報 Go 植入程式。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 將其解讀為代理程式產生的輸出超出伺服器所能承載的量。第五個最為關鍵：對連結到常務次長辦公室的網站根目錄進行遞迴搜尋，該目錄存放著標準 Office 文件、績效評估表，以及可追溯至 2012 年的人事紀錄。

那一切都不需要有人在鍵盤前操作。Hunt.io 表示，操作員以「無人值守或 YOLO 模式」執行 Hermes Agent，「繞過了對可能被視為危險的指令所設的核准提示」。該框架於 2026 年 2 月發布，以常駐守護程序方式運行，並跨工作階段保留記憶；YOLO 是移除提示的選項。Hunt.io 報導，該專案到 2026 年 7 月已突破 140,000 個 GitHub 星標。Cloud Security Alliance 對日誌的分析描述了一個代理評估每項結果並選擇下一步——這種工作流程從外部看來，類似人類分析師會如何進行，但以機器速度。

Hunt.io 對於日誌能確立什麼相當謹慎。網站根目錄的爬取顯示，該行為者已接觸到人事檔案；但並未顯示這些檔案被外傳。報告寫道：「沒有證據顯示這些檔案遭到外洩。」報告對整個伺服器的總結是，這些檔案「描述了一場仍在進行的入侵：工具已部署就位、內部存取持續擴大，且沒有跡象顯示資料已離開網路，儘管操作者顯然正在盤點網站內容。」

人類仍舊所做的工作

報告中最有價值的部分就是這種分工方式。代理程式負責通用、可重複的偵察工作——這類工作可以腳本化，而且不需要對目標有任何了解。操作員則提供了代理程式無從得知的東西：一份密碼字彙表，是由該部會內部各部門與計畫的縮寫、內部主機名稱、非路由位址，以及針對特定服務撰寫的腳本所建構而成。雲端安全聯盟（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 腳本會驅動無頭 Chrome 執行個體，透過 SOCKS5 代理連線至內部 GlassFish 管理主控台，使用預設認證登入並部署 WAR 檔；Hunt.io 無法確認是否有任何 WAR 檔遭到部署。一個偽裝成日誌快取檔案的 PHP 網頁後門被放置於部會網頁伺服器上的 /storage/Counter/nine/.journald-cache.php。Perl 腳本 mail4.pl 會以硬編碼的信箱位址及由擷取到的權杖所構成的密碼，測試部會郵件基礎設施的 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 和指向該部會內網的路徑。

這裡沒有任何新穎的諜報手法。日誌額外揭示的是，列舉持續不間斷地執行，沒有人類操作員在指令之間留下的停頓——Cloud Security Alliance 的說明指出，以鍵盤節奏活動為基礎所建置的偵測方式，與這種情形並不相稱。

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 個具有相同的大小範圍與建置特徵，但並未逐一檢查。

靜態與動態分析發現，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 向暫存伺服器（staging server）的 443 埠發出信標，而 Linux 二進位檔 multipathd_04d0 則指向 202.181.27[.]115 的 12443 埠——該主機是透過共用的憑證指紋所發現。Hunt.io 指出，這些命名可能只是巧合：在希臘神話中，赫米斯引領亡魂前往黑帝斯。

沒有任何來源能證實 Hades 曾在該部會內部運行。Hunt.io 是從操作者自己的伺服器上取回這些二進位檔。Cloud Security Alliance 的說明指出，沒有任何已取回的構件顯示 Hades 曾觸及部會機器；Dark Reading 則報導，該研究並未指明它部署於何處。該植入程式是操作者已建立並預先佈建的能力，並非已確認常駐於部會主機上的程式。

誰是幕後主使者？

Hunt.io 並未指名任何組織。該公司以低至中等信心評估，認為該操作者為中文使用者或對該語言極為熟悉，依據四項指標：該主機曾作為 ShadowPad 控制器的歷史、香港的基礎設施、一個 Hermes 網頁介面密碼中含有中文詞「Leishen」（意為雷神），以及一組中國網際網路資產偵察服務 FOFA 的 API 金鑰。一份環境快照亦記錄到 SSH 用戶端 103.97.0[.]57 位於 AS133073（HK Kwaifong Group Limited），正連線至該中繼伺服器。上述種種皆不構成對某個國家或某個已命名叢集的歸因，Hunt.io 也如此表明。

關於這起入侵事件本身，仍有兩件事未知。其中之一是初始入侵途徑：報告結論指出，「初始入侵的方法仍未知」。另一件是影響範圍。Hunt.io 表示，作用中的 session cookie、已部署的網頁後門及內部網路存取，顯示該操作者「得以入侵 MOF 網路內的多個系統」，但它也警告，單憑 cookie 值無法證明有人登入，因為 Laravel 會向任何訪客核發 session 與 CSRF token。這起入侵是根據數位跡證所作的評估，而非經確認的主機清冊。

泰國接下來做了什麼

Hunt.io 表示，該公司與 Diachenko 於 2026 年 7 月 15 日通知泰國國家 CERT 及國家網路安全局，且兩者已於同日確認收到；隨後在為期七天的窗口期內暫緩發布。在本文所檢視的報導中，未發現任何提及該部會的公開 ThaiCERT 公告。

7月27日，也就是《The Record》報導這起入侵事件的當天，泰國國家網路安全委員會召開了2026年第二次會議，並通過針對AI代理威脅的措施。該機構自家的說法指出，委員會指派ThaiCERT監控、分析與追蹤AI代理威脅，向有風險的機構發出警告，並支援事件應變與數位鑑識；責成分領域CERT加強檢查與通報；並認可主動措施，包括檢查對外網路系統、特權帳號管理、網路分段、備份與復原測試。它還指示制定組織內部安全、透明且可稽核使用AI代理的指引，以及由ThaiCERT與各領域CERT聯合演練、模擬AI代理攻擊。該貼文並未指名Ministry of Finance或Hunt.io，而《The Record》指出，官員「並未直接提及Hunt.io的調查」，同時判斷這些措施顯然是針對該威脅。會議與這起入侵之間的任何因果關聯均屬推論，而非該機構的陳述。

泰國國家網路安全委員會副秘書長 Theerawut Wittayakorn 在會後表示，泰國「必須能夠充分受益於 AI，同時系統性地管理相關風險」，《The Record》報導。財政部本身則保持沉默：《The Record》於7月27日報導，該部尚未公開承認此事件，也未回應置評請求；《Dark Reading》次日報導，政府未發表評論。該檔案庫日期為7月30日的條目，記載了相同內容。

什麼已確立、什麼正被評估、什麼仍然缺失

此檔案將該條目歸類為已實現事件，嚴重程度為重大，信心等級為 A，無爭議，記錄有實際損害，類型標籤為 WEAPON；它未被標記為里程碑。信心等級描述的是文件記錄本身，而這份記錄異常直接：Hunt.io 封存的是操作者的中繼伺服器，而非受害者的日誌。它並不描述獨立驗證，而在這一點上，記錄相當薄弱。

• 已確認：同一台主機上有三個開放目錄（7月9日至13日），共存放585個檔案、470 MB；五份 Hermes 呼叫記錄顯示 LinPEAS、SUID 列舉、容器列表與 web-root 爬取；Hermes Agent 以 YOLO 模式執行；62 個 Go 二進位檔，包括 Hades；HiveServer2 指令碼及其 UDF；web-shell 路徑；憑證與工作階段資料；未發現資料外傳的證據；Hunt.io 於7月15日向 ThaiCERT 與 NCSA 發出通知，同日獲確認。

• 評估結果：該操作者為中文使用者，置信度為低至中等；多個部會系統已遭入侵；國家網路安全局（NCSA）於7月27日採取的措施是對此入侵事件的反應。

• 缺少：初始存取路徑；操作者觸及了多少主機或紀錄；是否有任何檔案流出網路；任何部會確認；任何公開的 ThaiCERT 公告；任何獨立鑑識檢驗。

一則二手報導比原始報告更進一步。iThome 於7月27日的中文資安摘要概述了同一份 Hunt.io 研究，指出入侵者是透過一台可從網際網路存取的部會伺服器上的 PHP Web Shell 進入，且該環境包含至少47台主機、54.9 TB 的政府財務資料、14個 Microsoft SQL 資料庫、生物辨識系統以及一個遠端桌面閘道。這些數字均未出現在 Hunt.io 的報告中；該報告稱初始入侵方式仍未知，而該檔案庫的紀錄依循該報告。看過那些較大數字的讀者應將其視為未獲原始來源支持。

獨立報導確實存在，但獨立證據並不存在。《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 的說明補充了分析，以及一項有用的警示：沒有任何已復原的跡證顯示 Hades 曾出現在部會電腦上。除了這些補充內容之外，報導中的事件事實都可追溯至同一份原始報告。

防守者被告知了什麼

Hunt.io 的建議針對有明確修復方式的部分提出處理。檢視 HiveServer2 驗證模式並強制執行 UDF 封鎖清單；遞迴稽核網站根目錄，找出檔名以點開頭、仿冒系統快取的 PHP 檔案；將 sudo 修補至 1.9.5p2 或更新版本，並對照 CVE-2021-4034 檢查 polkit 版本；停用任何仍存在之 IIS 6.0 執行個體上的 WebDAV，或移轉離開該平台；針對 Web 伺服器程序對內部連接埠（例如 10000 或 50070）開啟對外連線的情況發出警示；以及變更 GlassFish 管理主控台的預設認證，並將存取限制於受信任網路。對於執行代理程式框架的組織，Cloud Security Alliance 新增了一項在此原本會派上用場的控制措施：稽核是否在任何地方啟用了無人值守或等同 YOLO 的模式，除非有記錄在案且已接受風險的理由，否則應將其停用。

Hunt.io 也將這起事件化為找出其他暴露面板的手段。該公司表示，Hermes 網頁介面會回傳一組獨特的 Server 標頭與 Basic-auth realm，而針對 HermesWebUI 的 banner 查詢在過去一個月回傳約 5,900 筆事件；搜尋含有該代理程式 /hermes-results/ 路徑的開放目錄則回傳 575 筆結果。這些數字是發布時單一廠商資料集中的計數，並非受害者的數量，且會隨著面板出現與消失而變動。真正有用的是這項指標：暴露的代理程式面板及其輸出目錄可被發現，而這正是這起行動曝光的原因。

檔案並未將該條目標記為里程碑，技術紀錄也支持這種克制。LinPEAS、Hive UDF 濫用、預設憑證，以及 2017 年的公開漏洞利用程式，都是舊工具；新的是人力安排——一名代理程式持續進行列舉，一名操作員進行針對特定目標的準備。日誌所記錄的正是這種由兩部分組成的安排。它們無法記錄的是影響：操作員深入該部到什麼程度、人事檔案包含哪些內容，或是否有任何東西離開網路。在該部或獨立調查人員回答這些問題之前，這份紀錄描述的是一起有詳盡紀錄的入侵事件，其代價仍然未知。