論文閱讀分析：揭露 LLM 輔助 Cyber Threat Intelligence 的脆弱性

論文基本資訊

• 論文標題：Uncovering Vulnerabilities of LLM-Assisted Cyber Threat Intelligence
• 作者：Yuqiao Meng、Luoxi Tang、Feiyang Yu、Jinyuan Jia、Guanhua Yan、Ping Yang、Zhaohan Xi
• 年份：2025 / 2026（arXiv v3 於 2026-02 更新）
• 來源：arXiv:2509.23573v3
• 論文連結：https://arxiv.org/abs/2509.23573
• 主題：CTI、LLM Evaluation、Threat Reasoning、Failure Analysis、RAG、Security Benchmark

這篇論文的重點，不是再展示一個新的 CTI agent 多會做事，而是反過來問：為什麼 LLM 一旦進入真實的 cyber threat intelligence workflow，明明看起來很懂，卻還是常常在關鍵地方失手？

作者的核心論點很清楚：LLM 在 CTI 的問題，不只是一般人熟悉的 hallucination 或 prompt sensitivity，而是 CTI 本身就是一個高度異質、快速變動、來源彼此衝突的知識環境。如果不把這個 threat landscape 的特性放進分析框架裡，就很容易低估模型在實務中的失敗模式。

這篇論文想解決什麼問題？

作者要回答的其實是三個層次的問題：

• LLM 在 CTI workflow 中，究竟會怎麼失敗？
• 這些失敗是模型本身的通用缺陷，還是 CTI 場景特有的結構性問題？
• 如果知道失敗的根因，能不能設計出有針對性的 defense，而不是只靠更大的模型或更長的 prompt？

為了回答這些問題，論文不是只跑一兩個 demo，而是沿著整個 CTI lifecycle 去做系統性分析，並把失敗模式整理成一套 taxonomy，再進一步做 causal intervention 與 mitigation evaluation。

作者怎麼定義 CTI 的四個階段？

論文把 CTI 任務拆成四個階段，這個切法很重要，因為後面所有 failure analysis 都是沿著這條 pipeline 展開：

1. Contextualization：把零散的 IOC、alert、log 與 CVE / ATT&CK / malware family 等知識連起來
2. Attribution：根據 TTP、基礎設施重用、語言風格與行為模式，推斷背後 threat actor 或 campaign
3. Prediction：預測 exploit likelihood、影響範圍、target sector 與 campaign escalation
4. Mitigation：把情報轉成 patch recommendation、YARA / playbook / response summary 等可執行輸出

這個切法的價值在於：它不把 CTI 簡化成單一 QA task，而是把 analyst 真正在做的事情拆成不同 reasoning stage。這使得作者能更精準地回答「模型在哪一段 workflow 出問題、又是怎麼壞掉的」。

資料與評估規模

論文使用的資料不是單一 benchmark，而是把多套資料源整合起來，包括：

• CTIBench：一般 CTI 任務
• SevenLLM-Bench：威脅報告理解
• SWE-Bench：軟體修補與程式分析
• CyberTeam：blue-team threat hunting
• NVD、CVE、CISA KEV 等真實漏洞與威脅資料來源

其中 Appendix 提供的原始 benchmark 規模也很值得記一下：

• CTIBench：5,610 筆
• SevenLLM-Bench：92,701 筆
• SWE-Bench：2,294 筆
• CyberTeam：452,293 筆

也就是說，這不是小樣本印象式研究，而是把 CTI 各階段任務放到相對大規模的評估框架裡觀察失敗分布。

模型比較：不是只有 general LLM，也看 cyber-specialized model

作者同時評估兩條模型路線：

• General-purpose LLMs：例如 GPT-5、Claude、Gemini 這類通用大模型
• Cybersecurity-specialized models / agents：經過資安領域資料調整或專門訓練的模型

這點很關鍵，因為它讓論文能比較兩種常見假設：

• 是不是只要用最強通用模型就夠？
• 還是 cyber 專用模型在某些 task 上真的比較可靠？

結果顯示，通用模型通常在理解、長文本整合、source reliability scoring、threat actor linking、exploit likelihood 等任務上較強；但 cyber-specialized agent 在某些比較 operational 的輸出，例如 infrastructure reuse、countermeasure ranking 等項目，會有局部優勢。

換句話說，這篇論文沒有得到「一種模型統治全部 CTI 任務」的結論，反而更清楚地呈現出不同模型能力的分工與侷限。

整體觀察：所有模型都有 universal gap

作者特別強調一件事：即使最強模型，也沒有真正跨過 CTI 的幾個核心門檻。論文觀察到的共通弱點包括：

• 在 obfuscation 情境下，IOC normalization 與 CVE linking 仍不穩
• TTP extraction 在 retrieval-augmented reasoning 中容易不一致
• 對 timeline、campaign escalation 這類時間性推理缺乏穩定性
• 在 threat report alignment、ticket / playbook generation 上，常出現對真實證據依賴不足與格式錯誤

這些問題同時出現在 general model 與 cyber model 上，說明問題不只是模型大小或 domain tuning，而是 CTI 本身對證據一致性、時間敏感性、來源衝突與脈絡理解的要求，比一般文本任務高得多。

論文最重要的貢獻：提出三大類 CTI 專屬脆弱性

這篇論文最值得記住的，是它把 LLM 在 CTI 的脆弱性整理成三大類：

1. Spurious Correlation
2. Contradictory Knowledge
3. Constrained Generalization

一、Spurious Correlation：模型把表面共現誤認成因果線索

這一類問題的核心是：模型看到某些 metadata、工具名稱、地理標記、共現欄位時，會過度放大它們的意義，進而做出錯誤推理。

作者進一步拆成幾個 subtype：

• Co-mention bias：同一份報告裡一起出現的漏洞、IOC、mitigation 被錯誤視為彼此相關
• Exploitation bias：重複出現的 IOC 被誤認為持續活動或 actor reuse 的強證據
• Confounding factors：地理區域、組織標記等非因果特徵，被錯當成 exploit likelihood 或 attribution 依據
• Skewed source：過度依賴某些 vendor feed，導致 patch prioritization 偏斜
• Hierarchical metadata：把 ATT&CK chain 或 taxonomy 結構誤讀成因果順序

這很像 analyst 最怕的那種「看起來很合理，但實際上只是一起出現」的錯誤。對 CTI 而言，這種錯不是語法錯，而是 evidence weighting 錯。

二、Contradictory Knowledge：不同情報來源彼此打架

第二大類是 CTI 世界非常典型的問題：不同來源的說法本來就可能互相矛盾。像是 vendor advisory、community report、NVD、EPSS、社群討論與 exploit feed，不一定同步，也不一定一致。

作者整理出的 subtype 包括：

• Temporal contradiction：舊 advisory 與新證據互相衝突
• Conflicting reports：不同報告對 actor、攻擊脈絡、依賴條件的描述不一致
• Semantic conflict：同一威脅家族有不同命名，例如 PlugX / Korplug
• Divergent structures：JSON feed 與非結構化 PDF 難以一致對齊
• Misaligned standards：CVSS、vendor rating、其他 scoring framework 給出不同風險訊號
• Counteracting generation：推理與生成流程彼此干擾，導致輸出不穩

這裡的重點是：模型不是單純「不知道答案」，而是面對本來就彼此衝突的 evidence 時，無法穩定地做 source-aware reasoning。

三、Constrained Generalization：對新型威脅與新環境不夠能泛化

第三類問題是 CTI 最現實的一面：威脅會變，攻擊路徑會變，組織環境也會變。模型若只是背熟歷史樣式，遇到新 threat surface 就會開始失準。

作者將這類問題拆成：

• Distributional bias：訓練資料過度集中在特定語言、地區或 threat corpus
• Unseen patterns：面對 zero-day 或新型攻擊模式時推理失效
• Overfitted reasoning：過度依賴記住的 CVE–TTP 或 actor–TTP 關聯
• Environmental unawareness：忽略本地系統、產業別、依賴關係等現場條件

這些問題在 prediction 與 mitigation 階段尤其危險，因為模型可能看似給出完整答案，但其實沒有真正理解「這個環境跟它訓練時見過的環境不一樣」。

方法論亮點：不用脆弱的 LLM-as-a-judge，而是人機協作分類

這篇論文的方法論設計也值得注意。作者明確不信任單純的 LLM-as-a-judge，因為模型容易替自己的輸出合理化，也不擅長穩定辨識矛盾。因此他們設計了三步驟流程：

1. Stratified failure sampling：先用 similarity score 把輸出分層，再抽樣人工檢查 anchor sample，推定哪些區間屬於 failure
2. Iterative taxonomy refinement：先由人工建立初始 failure taxonomy，再讓模型分類，最後由人工檢查「other」或不穩定案例
3. Human-in-the-loop multi-agent decision：讓多個模型兩輪判斷，再由人工處理 vote disagreement 與跨輪波動案例

論文聲稱，這種方法把人工檢查量壓到很低：在 failure set 建立時，人工檢查少於 1.5%；在最後的人類驗證階段，少於 1.8% 的案例需要人工介入。對大規模 CTI 評估來說，這個設計很實用，因為它不是全手工，也不是完全把判斷外包給 LLM。

這個方法真的有效嗎？

作者把自己的方法和幾種基線比較：

• Clustering
• Topic modeling
• GPT judge
• Gemini judge
• Multi-agent debate

結果顯示，單純的 clustering / topic modeling 很難抓到細粒度 vulnerability subtype；單一 LLM judge 雖然比統計方法好，但在複雜、多步驟判斷類別上仍有偏移；作者提出的人機協作方法，其 subtype distribution 最接近 human annotation。

這裡的訊息很明確：要研究 CTI 裡的 LLM failure mode，不能只靠模型自己當法官。

因果干預與防禦策略

論文不只停在 taxonomy，還進一步把 taxonomy 轉成 defense 設計。作者把 mitigation 分成兩大方向：

• Retrieval-based defense：在檢索階段就做時間、來源、證據粒度與對齊方式的過濾
• Inference-time constraints：在推理時明確限制模型如何使用證據、如何處理不確定性

針對 Spurious Correlation 的做法

• 在 retrieval 階段去除粗糙共現造成的雜訊，把證據切成更細粒度片段
• 對高頻但低區辨度的 artifact 降權，不讓模型把常見工具名誤當 actor 證據
• 在 inference 階段要求模型區分「共現」與「因果」，沒有直接證據就不能推成高信心結論

針對 Contradictory Knowledge 的做法

• 加入 time-aware reranking，優先使用較新且被多方佐證的情報
• 把證據按時間順序包裝，附上 clearly tagged as-of 時間
• 讓模型顯式標示 source conflict 與 uncertainty，而不是硬輸出單一肯定答案

針對 Constrained Generalization 的做法

• 在 retrieval 階段補充與新威脅或新環境更接近的 supporting evidence
• 在 inference 階段限制模型不要把訓練中熟悉的 pattern 硬套到新案例
• 面對 kill-chain、sector-specific 與 local environment 類問題時，要求模型把推斷降成「soft hint」而不是事實

防禦效果：full-fledged mitigation 最有效

論文的 Table 7 顯示，若只做 retrieval-only 或 inference-only 改善，確實能降低部分 vulnerability ratio；但 把 retrieval 與 inference 兩段一起做的 full-fledged mitigation，效果最穩定，也最接近真正可用的系統設計。

例如在 general model 設定下，spurious correlation、contradictory knowledge、constrained generalization 多個 subtype 都能明顯下降；在 agent 設定下，full-fledged 方案同樣比單段式方案更能壓低 failure ratio。這代表作者的主張成立：CTI 裡的 LLM 風險不是單點修補能解決，而是需要沿著 retrieval → reasoning → generation 整條鏈條一起治理。

這篇論文的重要性在哪裡？

如果把它放進最近這批 sectools.tw 的 CTI / AI 論文脈絡，它的位置非常清楚：

• 像 AURA、CyLens、Autonomous IR 這類論文，重點是「怎麼把 LLM / agent 用進 CTI workflow」
• 像 CTIBench，重點是「怎麼評估 LLM 在 CTI 到底行不行」
• 而這篇則更往前一步，回答「就算模型表現不差，它究竟會在哪些 CTI 特有條件下系統性失敗？」

因此它的價值不只是 benchmark，也不只是 failure list，而是替未來的 CTI agent / RAG / cyber reasoning 系統提供一套更接近實戰的風險地圖。

論文限制

這篇論文當然也有幾個需要保留的地方：

• 雖然資料很多，但仍主要圍繞英文與公開可得 CTI 資源
• 部分模型名稱在主文以縮寫呈現，實驗重現性仍需搭配附錄與釋出的 code
• 很多指標仍仰賴 reference-based metric，例如 BLEU / F1 / AUC，與真正 analyst team 的 operational value 之間還有距離
• mitigation 結果顯示可以減少 failure，但還沒等同於 production-ready autonomous CTI system

總結

這篇論文最重要的貢獻，是把「LLM 在 CTI 中為什麼不可靠」這件事，從泛泛而談的 hallucination 問題，往前推進成一套可分類、可驗證、可對應防禦策略的實證框架。

作者指出，CTI 的困難不在於知識量大而已，而在於它的知識本身就充滿異質性、時間漂移、來源衝突與環境依賴。只要這些條件存在，LLM 即使在 benchmark 上看起來不錯，仍然可能在 attribution、prediction、mitigation 等實務任務上出現高代價錯誤。

對 sectools.tw 的讀者來說，這篇論文提供的訊息非常務實：未來真正能落地的 CTI AI 系統，不會只是把更大的模型接上資料庫，而是必須把 evidence hygiene、source conflict handling、time awareness、uncertainty control 與 human oversight 一起設計進去。