ThreatPilot 論文閱讀分析：當 threat report 真正要進入防守流程，光抽 technique 還遠遠不夠

論文基本資訊

• 論文標題：ThreatPilot: Attack-Driven Threat Intelligence Extraction
• 作者：Ming Xu、Hailong Sun、Runze Chen、Jie Ling、Yeting Li、Wei You
• 來源：arXiv
• 年份：2024 / 2025 v2
• arXiv：https://arxiv.org/abs/2412.10872
• 主題：CTI、Attack-Driven Intelligence、MITRE ATT&CK、Procedure Extraction、Sigma Rule Generation、Detection Engineering

很多 CTI 自動化論文還停在「能不能把 report 對到 technique label」這一層，但 ThreatPilot 想補的洞其實更接近實戰：如果 defender 真正想把 threat report 接進偵測與驗證流程，缺的往往不是再多一個 technique 分類器，而是能把整條攻擊行為翻成 downstream 系統真的吃得下的 intelligence。

作者的野心不小。他們不是只想抽 technique，而是想抽一種更完整的 Attack-driven Threat Intelligence（ATI）：裡面不只包含 tactics / techniques，還包含多步驟 procedures、procedure variants，最後還直接拿這些抽出的 intelligence 去生成 Sigma 規則 與 可重現攻擊指令。這篇真正有意思的地方，也正是它把 CTI extraction 從「標註任務」往「安全工程中介層」推了一步。

本文由 AI 產生、整理與撰寫。

這篇論文在解什麼問題？

作者先點出一個很實際的痛點：現有 CTI extraction 方法大多只抽出零碎 intelligence，像是 technique、IOC 或 entity。這些東西不是沒價值，但一旦你要往下游走，就很容易卡住：

• 只知道 technique，不知道 procedure，很難寫出夠像真實攻擊的 detection logic。
• 只抽 atomic indicator，很難還原 multi-step attack chain。
• 只做 report-to-label mapping，下游 rule generation 常會變得太泛、太脆弱，或根本不夠可執行。

這其實講到 CTI 自動化的一個老問題：很多論文在解 extraction benchmark，卻沒有真的解 operationalization。 也就是說，模型也許能告訴你「這段像 T1566」，但 SIEM、rule engineer、purple team 真正想知道的是：它到底怎麼做、有哪些關鍵步驟、哪些變形行為值得一起防、能不能直接變成偵測規則或模擬命令。

ThreatPilot 的核心主張可以濃縮成一句話：

真正有用的 threat intelligence，不該只停在 technique 名稱，而要能長出 procedure、變體、偵測條件與可驗證的攻擊行為。

ThreatPilot 的方法重點：把 CTI 從 technique label 拉成 attack-driven intelligence

作者提出的 ATI，不是單純把 TTP 寫完整一點而已，而是試圖把 report 裡的攻擊知識重新整理成可接下游安全工作的結構。它至少有三個層次值得注意：

• Tactic / Technique：先把行為放回 ATT&CK 脈絡。
• Procedure：補上具體怎麼做，像是工具、命令、執行流程。
• Procedure Variants：不只停在原文明講的步驟，還嘗試根據外部知識推估合理變體。

這裡最值得注意的是最後那層。很多方法默認「report 裡寫了什麼，系統就抽什麼」，但作者認為這對真實防禦不夠，因為攻擊者常常不會把所有實作細節都寫在公開報告裡。ThreatPilot 因此想做的是：在有外部知識支撐的前提下，把未明說、但高度 plausible 的 procedure variants 一起補起來。

這是一個有風險、但也很有價值的方向。風險是推論可能過頭；價值則是它終於正面承認：真實防禦需要的不是逐字抽取，而是有邊界、有根據的 attack reconstruction。

技術流程：不是直接丟給 LLM，而是拆成多個互補模組

ThreatPilot 的 ATI extractor 不是單一步驟。它刻意把 extraction 拆成幾層，目的就是減少長文資訊流失、降低 hallucination，並補上被漏掉的 techniques。

1. CTI Chunker：先把長報告切成比較像攻擊行為片段的區塊

作者先做 chunking，而且不是普通切段，而是用 IoC presence 當信號，找出比較可能包含惡意行為的區塊，再把前後文一起合併。這個設計的重點很實際：不是每一段 CTI report 都同樣重要，先把 attention 放到「比較像真正攻擊行為」的區域，才比較有機會抽到對的東西。

2. Intention Interpreter：先推 tactic，再縮到 technique

接著模型不是直接猜 technique，而是先做 tactic planning，再在 tactic 約束下產生 technique candidates。這種 top-down 推理很像資安分析師的習慣：先判斷這段行為比較像 initial access、execution 還是 persistence，再往下看更具體的 technique。

作者還加了 rule-based filtering 與 official ATT&CK list 對照，避免模型亂生 technique 名稱。若 LLM 產生的 technique 不在官方清單內，就會做語意相近替換或直接丟掉。這種處理不算花俏，但很重要，因為很多 CTI LLM workflow 最後死的不是大架構，而是 taxonomy discipline 根本沒守住。

3. Knowledge Enhancer：用 MITRE 描述做檢索，把漏掉的 techniques 補回來

ThreatPilot 把 MITRE ATT&CK technique descriptions 做成向量資料庫，用 report chunk 去比相似度，找出可能被前一步漏掉的 techniques。這代表它不是全靠 prompt 理解，而是讓標準知識直接參與候選集合擴充。

這個設計跟近期很多比較成熟的 CTI pipeline 越來越像：不是相信一次生成，而是讓 generation 與 retrieval 互相補洞。

4. Validator：再用獨立 judge 把過度寬鬆的 technique 篩掉

前面兩步會產生比較寬的 candidate set，最後再交給獨立 validator 檢查 technique 描述是否真的跟整份 report 對得上。作者刻意讓 judge 與前面生成步驟隔離，避免整條流程共享同一個幻覺。這不一定能完全解 hallucination，但至少是朝比較像樣的 pipeline discipline 在走。

最關鍵的一步：從 technique extraction 走到 procedure 與 variant generation

如果說前半段還像是進化版 ATT&CK extraction，那真正讓這篇 paper 跳出來的，是它後半段開始做 procedure generation，而且不是只靠一句 prompt 硬生。

作者使用 GraphRAG 思路，把 entity、relationship、community 與 summary 等多種上下文整合起來，試圖讓模型能從 report 內外的知識連結中，補出較完整的程序步驟與 plausible variants。也就是說，它想解的不是「這篇講了 T1059」，而是「這個 technique 在這個 campaign / context 裡，具體可能怎麼被執行」。

這對 Sigma rule generation 很關鍵。因為 rule 真正需要的常常不是 technique 名字，而是：

• 可能的 process image
• command-line pattern
• 執行順序與上下文
• 與 tactic / technique 對應的 detection tags

換句話說，ThreatPilot 的真正目標不是多抽一層資訊，而是把 CTI 裡高層語意與偵測工程裡低層欄位接起來。這點我覺得比單純再做一個 extraction benchmark 有意思得多。

結果怎麼看？重點不是只贏 F1，而是 downstream 真的被拉動

根據論文描述，ThreatPilot 在 1,769 份新抓的報告 加上 16 份人工校正報告 上，technique identification 的 F1 可達到比 AttacKG 高 1.34 倍。單看這個數字已經不差，但更值得看的是它後面的 downstream 效果：

• 在 64,185 筆 honeypot application logs 上，ThreatPilot 產生的 Sigma rules 比 standalone LLM 與既有靜態 ruleset 更能抓到真實惡意事件。
• 它生成的 attack commands 可達到 99.3% execution rate，而若缺少 procedure intelligence，只有 50.3%。

這兩個結果其實比 technique F1 更重要。因為它們在回答的是：抽出來的 intelligence 能不能真的長成可用的 security artifact？ 對 SOC、detection engineering、purple teaming 來說，這種證據比「某 benchmark 上又多幾分」更有 operational 含金量。

我覺得這篇最有價值的地方：它把 CTI extraction 往 security engineering 推進

ThreatPilot 最值得寫的，不只是它做了 ATI、GraphRAG 或 Sigma generation，而是它把一個常被切開看的問題重新接回來：

• CTI extraction 不是獨立任務。
• Detection rule generation 也不是獨立任務。
• Attack reproduction / validation 更不是跟前面完全分開。

作者等於在說：如果中間那層 intelligence 結構做得夠好，這三件事其實可以接成一條線。 這個 framing 很重要，因為它把 CTI 從「報告摘要工作」重新拉回「安全系統的中介知識層」。

這也讓它和近期幾篇值得看的 CTI paper 可以串起來：

• AZERG 強調 threat report 到 STIX entity / relationship 的 operationalization。
• Instantiating Standards 強調 ATT&CK extraction 不能只學資料集，還要對齊標準。
• ThreatPilot 則更往下游推：抽完還不夠，還要長出 rule 與 command。

也就是說，這條線正在從「抽得出來」一路往「接得下去、用得起來」移動。

當然，這篇也有幾個明顯風險

• procedure variants 的推論邊界很敏感：如果 grounding 不夠嚴，variant generation 很容易從補洞變成腦補。
• 下游成功不一定全可泛化：在 honeypot logs 與特定 deployment 成功，不代表所有企業環境都能直接複製。
• Sigma 與 command generation 很吃上下文：環境差異、資料欄位命名、真實資產配置，都可能讓可移植性下降。
• pipeline 很長：chunking、retrieval、judge、GraphRAG、rule generation 每一層都可能引入誤差，實務上要維運並不輕。

不過即便如此，ThreatPilot 至少把問題切到了更對的位置：不是只問模型能不能猜出 ATT&CK label，而是問 threat intelligence 應該長什麼樣，才足以承接 detection 與 validation。

總結

ThreatPilot 真正有價值的地方，不在於它又做出一個新的 extraction pipeline，而在於它提醒我們：CTI 自動化若只停在 technique classification，離真實防禦還差很遠。

它試圖把 report 中的攻擊知識重新整理成 attack-driven intelligence，再往下接到 Sigma 規則 與 可執行 attack command。這條路不完美，推論風險也不小，但方向是對的：真正重要的不是模型又抽出了幾個 label，而是抽出的 intelligence 能不能被防守方拿來行動。

如果你在意的不只是 ATT&CK mapping 本身，而是 CTI operationalization、procedure-level intelligence、detection engineering，那這篇其實很值得看。它比很多只比 extraction 分數的 paper，更接近「情報怎麼變成防禦能力」這個核心問題。