ExCyTIn-Bench 論文閱讀分析：LLM Agent 真的會做 Cyber Threat Investigation 嗎？

論文基本資訊

• 論文標題：ExCyTIn-Bench: Evaluating LLM agents on Cyber Threat Investigation
• 作者：Yiran Wu、Mauricio Velazco、Andrew Zhao、Manuel Raúl Meléndez Luján、Srisuma Movva、Yogesh K Roy、Quang Nguyen、Roberto Rodriguez、Qingyun Wu、Michael Albada、Julia Kiseleva、Anand Mudgerikar
• 年份：2025
• 來源：arXiv:2507.14201
• 論文連結：https://arxiv.org/abs/2507.14201
• 主題：CTI、LLM Agent、Cyber Threat Investigation、SOC、Security Logs、Benchmark、SQL Agent、Reinforcement Learning

如果前一批 CTI / AI 論文像 CTIBench、CTIArena、AthenaBench、AttackSeqBench 比較偏向測模型懂不懂情資知識、會不會做 mapping、能不能理解 attack sequence，那 ExCyTIn-Bench 把問題再往現場推一步：模型能不能真的像 SOC analyst 一樣，進入一堆安全日誌裡查資料、沿著證據鏈一路追，最後回答 investigation 問題？

這篇論文值得看，不是因為它又做了一個新的 benchmark 名字，而是因為它抓到了一個很實際的落差：很多資安 LLM 評測還停留在問答、選擇題、知識對齊或靜態文件理解，但真實的 cyber threat investigation 並不是這樣。實際分析師通常要面對的是：

• 大量而異質的安全日誌
• 跨表格、跨服務的事件關聯
• 從某個 seed alert 一路 pivot 到更多實體與證據
• 最後整理出攻擊脈絡與答案

換句話說，這不是單純的「知不知道」，而是能不能查、能不能連、能不能走完多跳 investigation path。ExCyTIn-Bench 正是在量這件事。

這篇論文想解決什麼？

作者的核心問題可以濃縮成一句話：

如果我們真的想做 LLM-based cyber threat investigation agent，那要怎麼建立一個夠像真實場景、又能自動驗證的 benchmark？

這個問題很重要，因為過去很多安全 benchmark 主要測的是：

• 模型記不記得 CTI 知識
• 能不能做 extraction 或 classification
• 能不能回答某個 security QA

但 investigation agent 面對的是另一種工作型態。它要：

• 先觀察環境
• 決定下一步查哪張表、下什麼 query
• 看回傳結果後修正方向
• 逐步找到答案或中間證據

也就是說，這已經不只是語言理解，而是observation → action → retrieval → reasoning → answer 的序列型任務。作者要補的，就是這一塊評估空白。

ExCyTIn-Bench 做了什麼？

這篇論文提出了一個專門用來評估 LLM agents 在 Cyber Threat Investigation 任務上表現的 benchmark。它的三個核心元件是：

1. 真實感夠高的安全日誌環境
2. 由 investigation graph 自動生成的問題集
3. 可互動、可回饋、可部分給分的執行環境

作者不是只丟一批文本給模型，而是從一個受控 Azure tenant 中，整理出：

• 8 個模擬但貼近真實的 multi-step attacks
• 57 張安全日誌表（來自 Microsoft Sentinel 與相關服務）
• 589 個自動產生的 investigation questions

更重要的是，這 589 題不是憑空問的，而是來自作者建出的 threat investigation graph。每一題都被錨定在圖中的節點與邊，因此答案可驗證，過程也可以給部分獎勵。

為什麼這種 benchmark 比一般 CTI QA 更難？

因為這篇測的不是 closed-book knowledge，也不是單純 RAG 找到一段文件就結束，而是讓 agent 真的去和資料庫互動。

具體來說，模型不是直接看到答案，而是必須：

• 理解目前問題在問什麼實體、事件或關係
• 決定查哪張 log table
• 自己產生 SQL query
• 從查詢結果中找出下一個 pivot 點
• 一路追到最終答案

所以它同時在測：

• security domain understanding
• text-to-SQL / database interaction
• multi-hop reasoning
• tool-use efficiency

這也是為什麼作者特別強調：現有很多安全 benchmark 偏向 knowledge memorization，但 ExCyTIn-Bench 想測的是 investigation ability。

資料從哪裡來？這不是玩具資料集

作者使用的是 Azure tenant “Alpine Ski House”，這是一個用於展示安全產品的虛構 Microsoft 環境。環境中有持續監控的安全產品，例如 Microsoft Sentinel、MS365 Defender 等，因此會產生大量真實格式的安全日誌。

論文整理出的資料特點包括：

• 57 張表
• 每張表欄位數差異很大，約從 8 到 139 欄
• 除了標準欄位，也包含 JSON / nested sub-fields
• 涵蓋 email events、login events、VM activities、security incidents、alerts 等

作者從這個 tenant 中辨識出 8 個 distinct、non-repetitive attacks，並根據攻擊時間範圍切出對應日誌片段：從第一個事件前 1 小時，到最後一個事件後 1 小時。單一事件窗長度從 2 小時到 5 天不等。另外，作者也保留了一個 44 天長度的完整連續日誌流，模擬真實 SOC 分析師其實並不知道攻擊開始和結束時間的情況。

這一點很關鍵。因為很多 benchmark 會偷偷把問題切得太乾淨，但真實 investigation 很少有這種福利。

Threat Investigation Graph：這篇論文最漂亮的設計之一

這篇 paper 最值得記住的概念，是它把 investigation 過程抽象成 bipartite threat investigation graph。

作者為每個 incident 建立一個二分圖：

G = (U, V, E)

• U：Alert vertices
• V：Entity vertices
• E：Alert 與 Entity 之間的連結

直覺上，這個圖的意思是：

• 某個 alert 牽涉到哪些實體
• 某個實體又和哪些 alert 有關
• 分析師可以從一個 seed alert 出發，不斷沿著 alert ↔ entity 的關係往外走

作者認為，真實 SOC investigation 很像就是在這張圖上走路。你不是一開始就知道答案，而是從某個可疑 alert 或 entity 開始，一步一步 pivot、找相關事件、再擴展更多 evidence。

這個建模的好處非常大：

• 可以自動產生問題
• 可以自動產生答案
• 可以自動產生一條 solution path
• 也因此可以為 agent 的中途探索給部分分數

問題怎麼生成？不是讓 LLM 隨便出題

作者不是直接把 incident 細節丟給 LLM，叫它隨便寫幾題。因為他們發現這樣生出來的問題很容易變得太泛、太不聚焦，甚至去問一些資料庫裡根本沒有 deterministic answer 的東西。

所以他們改成：

1. 先建 bipartite investigation graph
2. 從圖中選起點 alert 和終點 alert
3. 取起點附近的 entity 當背景 context
4. 取終點附近的 entity 當答案目標
5. 再讓 LLM 只負責把這個結構化資訊轉成自然語言問題

如果寫成簡化版流程，大概像這樣：

Investigation Graph
   ↓
Select start node + context entities
   ↓
Select end node + answer entity
   ↓
Generate question-answer pair with LLM
   ↓
Generate solution path from shortest path in graph

這種做法的價值在於：LLM 不是在瞎編 ground truth，而是在 graph-grounded constraints 下做語言轉換。 這比很多 benchmark 的資料生成方式紮實得多。

這個 benchmark 為什麼能做部分給分？

因為每個問題不只有最終答案，還有一條從起點到答案的 solution path。這意味著如果 agent 雖然沒走到最後，但已經查到中間某些關鍵實體或事件，系統也可以給它部分 reward。

這點很重要，因為 investigation agent 的能力不應只用「最後答對 / 答錯」二分法來看。真實世界裡，一個 agent 如果能：

• 先找到關鍵使用者
• 再找到關聯郵件
• 再找到可疑附件
• 只是最後沒完全追到終點

那它顯然比完全亂查的 agent 更有價值。ExCyTIn-Bench 用 graph path 把這種「部分成功」正式量化了。

環境設計：這其實也是一個 SQL agent benchmark

作者把所有日誌資料放進一個 MySQL Docker 環境，讓 agent 可以透過 SQL 查詢與環境互動。換句話說，這不只是 security benchmark，也是在測 agent 的資料庫交互能力。

整個互動模式接近：

Question → Generate SQL → Execute Query → Observe Result → Reason → Next SQL → ... → Final Answer

這種設定有幾個很實際的意義：

• 比較接近 analyst 實際會做的事情
• 可量化 agent 的工具使用能力
• 未來可自然延伸到 reinforcement learning
• 不只看語言模型本身，也看 system design

也因此，ExCyTIn-Bench 跟 InterCode、Text-to-SQL benchmark、環境互動型 agent benchmark 有血緣關係，但它把這種設計搬到了安全 investigation 場景。

主要結果：這任務真的很難

論文最有說服力的一句話，其實不是哪個模型最好，而是：整體平均 reward 只有 0.249，最佳模型也只有 0.368。

作者評估了多種現代模型，包括 proprietary 和 open-source，也比較了不同 prompting / test-time scaling 策略，如：

• ReAct
• Expel
• Best-of-N
• Self-Reflection

但即使如此，最好的成績也不高。論文中提到，在 base setting 下，o4-mini 的 reward 最高，約為 0.368。這代表什麼？代表目前最強一批模型，到了 investigation-heavy 的安全任務裡，距離真正可靠還有一大段。

這其實很合理。因為這個 benchmark 同時要求：

• 理解問題語意
• 選對表
• 寫對 SQL
• 解讀結果
• 知道下一跳去哪裡
• 最後把整條線串起來

只要其中一段不穩，整個 investigation 就會偏掉。

這篇論文真正揭露的不是「模型不夠大」，而是 workflow 太難

我覺得這篇論文很有價值的一點，是它讓人看到：cyber threat investigation 的困難，不只是 security knowledge 不夠，而是整個 workflow 本身高度複雜。

這些難點包括：

• 資料異質性：不同表結構差很大，欄位命名與語意不一致
• 跨表推理：很多證據藏在不同服務與不同 log source 中
• 多跳搜尋：要先找中間節點，才能找到最終答案
• query precision：SQL 不只是語法對，還要查對東西
• 效率問題：亂查太多次，成本與延遲都會爆

所以這不是簡單的 QA benchmark 換個皮，而是把 agent 推到一個真正需要工具使用與策略規劃的位置。

和其他 CTI benchmark 比，ExCyTIn-Bench 多了什麼？

如果把它放在近期這條 CTI / AI benchmark 脈絡裡，位置大概可以這樣看：

• CTIBench：測知識、漏洞、歸因等基礎 CTI 能力
• CTIArena：測 heterogeneous multi-source CTI knowledge 與 reasoning
• AthenaBench：強調動態 benchmark 與更實務導向的 CTI 任務
• AttackSeqBench：測 attack sequence understanding
• ExCyTIn-Bench：直接測 agent 在日誌環境裡做 investigation 的能力

也就是說，前面幾篇多半在問「模型懂不懂」；這篇更像在問「模型能不能真的去查、去追、去辦案」。

這篇論文最有前景的一點：可自然延伸到 RL 訓練

作者在摘要裡特別提到，由於每個問題都來自圖上的路徑，因此不只可以評估，也可以拿來做 procedural tasks with verifiable rewards，進一步延伸到 reinforcement learning。

這很值得注意。因為很多人都在談 security agent，但真正能拿來做 RL 訓練的 benchmark 不多，尤其是那種：

• 有明確狀態
• 有可執行動作
• 有中途觀察
• 有可驗證 reward

ExCyTIn-Bench 剛好具備這些條件。也就是說，它不只是 evaluation set，也可能是未來 security investigation agent 訓練環境的雛形。

限制在哪裡？

這篇論文當然也有幾個需要一起看的限制。

1. 場景仍然是受控 Azure tenant

雖然資料格式和工具鏈都很真實，但它畢竟仍是 controlled environment。和大型企業、多雲、多 SIEM、多資料源混雜的真實 SOC 比起來，仍然比較乾淨。

2. 問題仍是 graph-anchored QA，而不是完整 incident report writing

這讓 benchmark 很容易自動驗證，但也代表它目前主要在測「沿著圖找對答案」，還不是完整的 analyst narrative synthesis。

3. SQL 交互設計雖好，但仍是單一工具形式

真實 investigation 可能還會涉及時間軸工具、圖視覺化、搜尋介面、腳本、TI feed、case management system 等。ExCyTIn-Bench 現在先把焦點收斂在 SQL-based interaction，優點是可控，缺點是仍有抽象化。

4. reward 高度依賴 graph path 定義

只要圖建得合理，這是優點；但也表示 benchmark 衡量的是一種特定形式的 investigation competency，不一定涵蓋 analyst 所有隱性技能。

不過整體來說，這些限制不太構成致命問題，反而是作者為了讓 benchmark 可擴充、可驗證、可訓練而做的合理取捨。

這篇論文給實務者什麼啟發？

如果你在做 SOC copilot、investigation assistant、security agent orchestration，這篇 paper 的啟示很直接：

• 不要只用靜態 QA benchmark 來判斷 agent 是否能上場
• 真正的 investigation agent 一定要測工具使用與多跳推理
• query generation 能力和 security reasoning 一樣重要
• partial reward / intermediate evidence tracing 很值得做，因為 agent 不該只看 final answer
• 若未來要做 RL security agent，必須先有像這樣可驗證的環境

更白話一點地說，這篇論文是在提醒大家：真正的安全 agent，不會只是會講 ATT&CK 和 CVE 的聊天機器人，而是得能在資料裡動手找證據。

總結

ExCyTIn-Bench 是一篇很關鍵的 security agent benchmark 論文，因為它把問題從「LLM 會不會回答 CTI 題目」推進成「LLM agent 能不能真的做 cyber threat investigation」。

它最值得記住的幾點是：

• 用 57 張安全日誌表 + 8 個 multi-step attacks + 589 題 建出 investigation benchmark
• 用 bipartite threat investigation graph 把問題、答案與 solution path 都 ground 起來
• 讓 agent 在 MySQL 環境 裡實際下 query、看結果、逐步推理
• 結果顯示這任務非常難：平均 reward 0.249，最佳也只有 0.368
• 這說明目前模型距離真正可靠的 investigation agent 還有明顯距離

如果你正在看 security agent、SOC automation、threat hunting assistant 這條線，我認為 ExCyTIn-Bench 比很多只做漂亮 demo 的論文更值得重視。因為它真正問的是：

當模型不再只是回答問題，而是必須進入真實安全資料環境、自己查、自己追、自己找證據時，它到底還剩多少能力？

免責聲明

本文由 AI 產生、整理與撰寫，內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。