Proactively Detecting Threats 論文閱讀分析：真正拖慢防守的，常常不是黑名單不夠多，而是 threat report 剛出現時根本還沒人先把可用 IOC 撈出來

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

論文基本資訊

• 論文標題：Proactively Detecting Threats: A Novel Approach Using LLMs
• 作者：Aniesh Chawla、Sohan Barua、Ayan Chatterjee、Rakesh Verma
• 年份：2026
• 來源：arXiv:2601.09029 / CyberC 2025
• 論文連結：https://arxiv.org/abs/2601.09029
• DOI：10.48550/arXiv.2601.09029
• 正式出版：https://doi.org/10.1109/CyberC66434.2025.00041
• 主題：CTI、IOC Extraction、Threat Report Mining、LLM Evaluation、Proactive Defense、Web Intelligence

如果最近這波 sectools.tw 的 CTI / AI 論文，已經一路從 threat report extraction、RAG 問答、IOC operationalization 寫到更貼近 analyst workflow 的自動化，那這篇 Proactively Detecting Threats 值得補進來的原因很直接：它處理的不是「某個 IOC 已經整理好了以後，要怎麼分類」，而是更前面那一層——當 threat report 還只是散落在網站上的 HTML 內容時，LLM 能不能直接幫你把真正值得先防的 indicator 撈出來？

這個切點其實很實務。很多企業防線真正慢的地方，不是黑名單系統不會擋，而是新情資剛出現時，根本還沒有人把 report 裡的 IP、domain、hash、TTP 脈絡整理成可用資料。若這一步太慢，你的防禦仍然是被動的：等別人整理、等 feed 更新、等規則進系統，攻擊者早就先一步動手。

這篇論文真正想推進的，就是把防守節奏從「事後收錄」往「報告一出、網頁一抓、IOC 就先被脈絡化地辨認」這個方向挪一步。它不是在做完整 CTI 知識圖譜，也不是在做最終 verdict，而是在測：LLM 能不能從未結構化的 web-based threat intelligence 裡，先把可能的惡意 indicators 辨認出來，讓企業防守更接近 proactive posture。

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

作者點的問題很準：現在很多 malware / threat detection 系統本質上都還是 reactive。它們依賴的通常是：

• 已知惡意樣本
• 既有 signature 或 reputation
• 已被整理過的 threat feeds
• 單一威脅類型的專用分類器

這些東西不是沒用，而是太晚。如果企業想更早採取動作，它需要的是：當 Mandiant、SentinelOne、Sophos、abuse.ch 之類來源剛發布新報告時，就能盡快從裡面找出可疑 IP、domain、URL、hash，並判斷哪些真的值得先進偵測或阻擋清單。

問題在於，真實 threat report 網頁長得非常亂：

• 每家版型不同，沒有統一結構
• IOC 可能在正文、表格、附錄、code block、清單裡
• 同一頁裡既有真正惡意 indicator，也有 benign reference、示意字串、產品名稱或 further reading
• 光抽 regex 不難，難的是看懂脈絡

所以這篇 paper 真正要回答的是：

LLM 能不能在「整頁 threat report 上下文」的條件下，協助區分哪些 IP / domain 真的屬於 malicious IOC，哪些其實只是文章裡順手提到、看起來像指標但不該直接下黑名單的東西？

核心想法：先大量抓 threat report，再讓 LLM 做 context-aware IOC classification

作者的系統其實不花俏，但很務實。整條 pipeline 大致是：

RSS / Atom threat feeds
  ↓
抓取網頁原始內容
  ↓
用 regex 與規則抽出看起來像 IOC 的字串
  ↓
補上整頁 threat report context
  ↓
把「IOC + 全文脈絡」丟給 LLM
  ↓
判斷這個 indicator 是否真的是惡意 IOC

也就是說，作者並沒有直接要求模型從零自己找所有 IOC，而是先用傳統 parser 把候選抓出來，再讓 LLM 做脈絡判別。這個分工很合理：regex 擅長把像 IP、domain、hash 的東西找出來；LLM 真正補上的，是判斷「這個東西在這篇文章裡到底是惡意 indicator，還是只是提到而已」。

這種設計的價值，在於它不是拿 LLM 去取代 parser，而是拿 LLM 去補 parser 最弱的那一塊：context sensitivity。

資料來源：不是 toy dataset，而是 15 個真實 threat intelligence 網站

這篇研究最值得肯定的一點，是它沒有在封閉小資料集裡自嗨。作者直接從 15 個 web-based threat report sources 自動抓資料，來源包括多家知名資安廠商與威脅情報網站，例如：

• Sophos
• SentinelOne
• CrowdStrike
• Mandiant
• abuse.ch

這很重要，因為真實 CTI web source 最大的麻煩從來不是資料不夠，而是：

• 格式異質
• 欄位不一致
• 很多內容其實根本不是 machine-friendly
• STIX/TAXII 雖然存在，但業界 free-structured report 仍然是主流

作者也明講，STIX 2.0 這類標準在時效性強、需要快速發佈的情資場景中並沒有被普遍採納。換句話說，如果你真的想做 cutting-edge threat ingestion，就不能只等標準化 feed，你得直接吃那些 messy 的網頁。

系統怎麼抽候選 IOC？

在 LLM 判別之前，作者先用 parser 做第一輪抽取，抓出幾類典型 indicator：

• SHA1 / SHA256 / MD5 hashes
• IPv4 addresses
• IPv6 addresses
• domains
• URLs

此外，系統還會用 MITRE ATT&CK Python library 從頁面裡抓出看起來像 tactics、techniques、groups 的片段，讓整體資料不只停在低階 indicator，也帶一點攻擊脈絡標記。

這裡有個重要觀察：論文真正困難的部分，不在「找不像 hash 的 hash」，而在「辨認這個候選值是不是該被視為真正惡意 indicator」。 例如，一個 report 可能提到某 IP 是 C2，也可能在 further reading、示例 URL、下載站說明、registrar 背景資訊裡提到另一個 IP 或 domain。表面上都像 IOC，但 operational value 完全不同。

評估設計：作者其實在測 LLM 的「脈絡判斷力」

作者最後聚焦測兩類最麻煩、也最常出現誤判的指標：

• IP addresses
• domains

原因很合理。Hash 類通常結構穩、誤判空間相對小；但 IP 和 domain 就不同了，它們非常吃上下文。你得知道：

• 這是不是攻擊基礎設施
• 這是惡意主體，還是報告裡提到的合法服務商／註冊商
• 這是實際 IOC，還是只是教學示意或 further reading 裡的例子

作者總共蒐集了：

• 479 個網頁
• 2,658 個 IOC 候選
• 其中包括 711 個 IPv4、502 個 IPv6、1,445 個 domains

真正做模型比較的子集則包含：

• 303 個網頁
• 116 個 IPv4
• 187 個 domains
• 總計 303 個 indicators
• 其中 251 個被標為 malicious

這組設定其實相當貼近 analyst workflow：不是純 benchmark 式的封閉問答，而是把模型放在「整頁 threat report + 候選指標」這個近似真實 ingestion 流程裡。

比較了哪些模型？

作者拿了六個模型做比較，主要來自三個系列：

• Gemini（如 Gemini 1.5 Pro、2.0 Flash-lite）
• Qwen
• Llama

而且是直接用未針對這個任務微調的預訓練模型來做。也就是說，這篇不是在比誰最會 overfit 某個資安資料集，而是在看現成 LLM 對這種 context-heavy IOC classification 到底有多能打。

Prompt 也很簡單粗暴，重點大致是：

• 你是資安專家
• 只能回 true / false
• 根據提供的 threat report context 判斷這個 IOC 是否屬於 compromise

這種設計的好處，是把輸出空間壓得很小，避免模型用長篇解釋掩蓋判斷錯誤；缺點則是它沒辦法完整檢驗模型推理過程。但對第一輪實證來說，這樣反而夠乾淨。

主要結果：Gemini 1.5 Pro 最強，但也不是沒有代價

這篇最值得記的數字，就是摘要裡那組結果：

• Gemini 1.5 Pro precision = 0.958
• specificity = 0.788
• 對真正惡意 IOC 的 recall = 1.0

白話一點說，Gemini 1.5 Pro 在這個任務上的表現，是很少漏掉真正惡意 IOC，而且 precision 也很高。這對 proactive defense 很重要，因為你最怕的是新情資剛出現時，模型把真正該防的 indicator 漏掉。

不過作者也很誠實地指出，這些模型不是完全沒有副作用。整體觀察大致是：

• Gemini 系列在抓惡意 IOC 方面很猛
• 但對 benign / non-malicious indicators 的辨識仍不夠穩
• Qwen3 32B 在這組測試中表現最差，false negative 偏高
• Llama 70B 雖然抓得到很多惡意樣本，但在 precision / 特異性上仍有壓力

這背後其實不是單純誰比較聰明，而是這類任務本來就不是一般「看字面像不像惡意字串」的分類題，而是在測模型能不能理解一整頁報告中的 operational role。

這篇論文最有價值的地方：它把 false positive 的來源講得很清楚

我覺得這篇 paper 最有研究味、也最值得現場拿來思考的，不是 leaderboard，而是它對誤判原因的分析。

作者舉了幾種典型失敗案例：

• 模型把 http://<C&C_IP>:<C&C_port>/anydesk.exe 這種帶 placeholder 的示意字串誤判成真正 IOC
• 模型容易被 domain 名稱本身的語意帶偏，例如包含 abuse、Darkside、TrueSightKiller 等詞時，傾向直接判惡意
• 報告中的 further reading、reference link、registrar 或 hosting context，會讓某些其實不是 IOC 的 IP / domain 看起來「很像」惡意

這點很重要，因為它說明：LLM 在這個任務裡學到的，不只是 threat context，也包括表面語意聯想。 換句話說，模型很可能不是在真正理解這個 indicator 的 operational role，而是在做「這個字看起來就很壞」式的 shortcut。

例如 paper 裡就提到，某些 domain 因為和 malware project、abuse list、惡意樣本名稱一起出現，模型就把它直接當 IOC；但對 analyst 來說，這些可能只是描述上下文，不一定該進 blocklist。

這篇研究真正提醒我們什麼？

我認為這篇 paper 最值得記的不是「Gemini 很強」這種短答案，而是三個更長期的訊號。

1. 真正難的不是抽 IOC，而是判斷 IOC 的 operational status

Regex 和 parser 早就能抓出大量像 IOC 的東西，但那不代表這些值都值得直接拿去封鎖。真正昂貴的那一步，是判斷：

• 這是不是活的惡意基礎設施
• 這是不是作者拿來舉例的字串
• 這是不是 legitimate service / registrar / repo link
• 這個 indicator 在該篇報告中的角色到底是 observation、example 還是 actual compromise artifact

這正是 LLM 補上的價值區，但也是它最容易出現認知捷徑的地方。

2. Proactive CTI automation 不該只看 recall，還要看 analyst 可用性

高 recall 很誘人，因為你不想漏報；但如果 false positive 太高，SOC 很快就會被噪音拖垮。這篇 paper 的結果其實剛好把這個 trade-off 擺在檯面上：對 proactive defense 來說，高 recall 幾乎是必要條件，但 precision / specificity 不夠好時，系統仍然很難直接 operationalize。

3. CTI ingestion 的下一步，不只是 web crawling，而是更細的 context segmentation

這篇方法把整頁網頁當 context 丟給模型，已經比孤立字串判斷好多了；但它也暴露了一個限制：當整頁 context 混著正文、附註、示例、download link、further reading 時，模型還是容易把角色混在一起。

所以更成熟的下一步，很可能不是單純換更大的模型，而是把 pipeline 做得更細：

• 先做區塊級內容切分
• 區分正文、附錄、教學示例、外部參考
• 再讓 LLM 根據區塊 provenance 判斷 IOC 身分
• 最後再和 reputation / sandbox / VT 類外部驗證整合

我的看法：這篇不是終點，但它把「更早動手」這件事正式拉進 CTI pipeline

如果要挑毛病，這篇論文當然還有不少空間：

• 評估的 indicator 類型仍偏窄，重點在 IP 與 domain
• 尚未真正走到 PDF、Word、RTF、圖片內嵌 IOC 這些更髒的格式
• 也還沒處理更難的語義型 IOC，例如 malware family、registry key、mutex、file path、campaign alias

但我不會因此低估它。因為它真正補上的，是一個很少被明講、卻很實際的落差：很多企業嘴上說想做 proactive defense，實際上卻還停在等別人把 IOC 整理好。 這篇 paper 至少把流程往前推了一步，讓 threat report 剛出現時，系統就能在原始 web content 上先做 context-aware IOC triage。

所以如果你要我濃縮這篇 paper 的一句主線，我會寫成：

真正拖慢防守節奏的，常常不是模型不會判惡意，而是沒有人在 threat report 還是散亂網頁時，就先把「哪些東西值得立刻防」這件事做掉。

Proactively Detecting Threats 的價值，就在於它把這個前置步驟正式做成一個可以量測、可以比較、也確實開始看到模型差異的問題。它還不是完整答案，但已經把題目問對了。