論文閱讀分析：A RAG-Based Question-Answering Solution for Cyber-Attack Investigation and Attribution

論文基本資訊

• 論文標題：A RAG-Based Question-Answering Solution for Cyber-Attack Investigation and Attribution
• 作者：Sampath Rajapaksha、Ruby Rani、Erisa Karafili
• 單位：University of Southampton
• 來源：Workshop on Security and Artificial Intelligence 2024, co-located with ESORICS 2024
• 年份：2024
• arXiv：https://arxiv.org/abs/2408.06272
• DOI / 出版頁：https://doi.org/10.1007/978-3-031-82362-6_15
• 主題：RAG、CTI、Cyber-Attack Attribution、Question Answering、Incident Investigation、LLM

A RAG-Based Question-Answering Solution for Cyber-Attack Investigation and Attribution 這篇論文的切入點非常直接：當資安分析師面對大量攻擊報告、部落格、調查文章與威脅研究文件時，能不能把「查資料、比對脈絡、追溯來源」這件事，變成一個可互動的問答系統？

作者提出的是一套以 Retrieval-Augmented Generation（RAG） 為核心的問答系統，目標不是做一般性的資安聊天機器人，而是聚焦在 cyber-attack investigation and attribution。這代表它處理的不只是「某漏洞是什麼」這類靜態知識問題，而是更貼近 CTI 與事件調查現場的問題，例如：

• 某一波攻擊何時開始被利用？
• 兩個惡意家族之間有什麼關聯？
• 某篇報告提到的新能力是什麼？
• 從特定來源文件中，可以支持哪些調查或歸因結論？

這種問題的共同點是：答案必須可追溯，最好能指出來自哪份報告、哪段內容，而不是只靠 LLM 憑語感生成。 這正是這篇論文的核心價值。

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

作者在導論裡先點出一個 CTI 現場很實際的困難：歸因與調查高度依賴非結構化文本。攻擊細節通常散落在 PDF 報告、研究部落格、新聞稿、廠商分析與事件回顧中，而這些資料格式不一致、篇幅長、描述角度不同，導致分析師需要花大量時間查找與交叉比對。

因此，這篇論文要處理的問題可以濃縮成下面這句話：

能不能建立一個以可靠 CTI 報告為知識基底的 RAG 問答系統，讓分析師用自然語言直接詢問與攻擊調查、攻擊歸因相關的問題，並得到附帶來源的答案？

作者之所以不直接信任 GPT 類模型，是因為論文認為現成 LLM 至少有三個限制：

• 容易 hallucination：會生成看似合理、但實際錯誤的敘述
• 知識時間落差：最新攻擊事件常超出模型訓練截點
• 缺乏來源透明性：即使答對，分析師也很難知道答案依據哪份報告

所以這篇論文的方向不是讓 LLM 直接「懂所有攻擊」，而是讓它在一個受控、可檢索、可擴充的知識庫上回答問題。

知識基底：AttackER dataset 是整個系統的核心

這篇研究最重要的基礎設施之一，是作者使用的 AttackER dataset。這不是一般通用語料，而是專門針對 cyber-attack investigation and attribution 蒐集與整理的資料集。

根據論文內容，這個知識庫有幾個重要特徵：

• 資料來自 202 份長篇資安文本
• 內容型態涵蓋 報告、部落格、文章 等多種來源
• 來源包含 Mandiant、Malwarebytes、Talos Intelligence、MITRE、Securelist、Trend Micro 等
• 資料曾由 三位資安專家人工審閱，確保內容適合用於調查與歸因

作者原本建立 AttackER dataset 的目的，是支援與攻擊歸因相關的實體抽取與命名實體辨識；但在這篇論文中，他們把其中與 QA 任務最有關的欄位保留下來，形成新的 RAG 知識庫，包括：

• 網站名稱
• 網站 URL
• 抽取出的長文內容

這個設計的意義在於：系統不是從一開始就假設所有知識都已結構化，而是把高可信的攻擊調查文本，直接作為可檢索的外部記憶。

方法概觀：這套 RAG QA 系統怎麼運作？

作者把系統拆成兩個主要部分：

• Retriever：從向量知識庫找出與問題最相關的文本片段
• Generator：把問題與檢索到的上下文一起交給 LLM 產生答案

整體流程可以整理成下面這樣：

Cyber-attack investigation / attribution question
        ↓
Sentence embedding
        ↓
Vector database retrieval
        ↓
Top-k relevant contexts
        ↓
LLM generator with retrieved context
        ↓
Answer + source information

這個架構本身不是新發明，但它在 CTI 與攻擊歸因場景下的價值很高，因為作者把它用在一個強調最新事件、來源可驗證、答案不可亂猜的任務上。

檢索與生成的數學形式

雖然這篇論文不是以新 loss function 或新架構公式為主要貢獻，但它還是有幾個關鍵的運算步驟，可以用標準 RAG 形式表示。

假設使用同一個 embedding model 把問題 q 與知識庫 chunk d_i 都映射到向量空間：

z_q = Emb(q)
z_i = Emb(d_i)

檢索器用 cosine similarity 做近鄰搜尋：

sim(q, d_i) = (z_q · z_i) / (||z_q|| ||z_i||)

再選出相似度最高的 top-k 片段：

C_top-k = TopK_i sim(q, d_i)

最後生成器根據問題與檢索結果產生答案：

a = LLM(q, C_top-k)

論文同時強調，生成器被要求只根據提供的 context 回答。若沒有足夠證據，系統寧可回覆「Sorry, I don’t know」，也不要憑空生成。這一點在 CTI 情境尤其重要，因為錯誤答案可能直接影響調查方向與歸因判斷。

兩種查詢模式：不只查內建知識庫，還能接外部資料

這篇論文的一個實務亮點，是系統不只支援查詢既有 KB，也支援把外部來源臨時加入檢索流程。作者描述的查詢模式包括：

• Entire KB queries：對整個 AttackER 知識庫提問
• Metadata-based queries：依來源或文件相關資訊查詢
• Specific-document queries：指定某份文件提問
• External-source queries：使用者上傳 PDF 或提供 URL，再由系統建立嵌入後進行查詢

這個設計很像把 RAG 做成一個 investigation workbench。分析師不只能問既有知識庫，也可以把剛收到的新報告丟進去，立刻拿來問答。對 incident response 與歸因實務來說，這種擴充性比單純 benchmark 成績更有價值。

問題設計：不是只有事實題，還包含對比與推論

作者並沒有把 QA 任務侷限在簡單 fact lookup，而是明確區分三類問題：

• Factual questions
• Contrastive questions
• Inferential questions

這代表系統預期處理的不只是「X 是誰」或「Y 發生在何時」這種直接型問題，還包含：

• 比較兩種攻擊或兩個樣本的差異
• 從多段脈絡中做出合理歸納
• 把不同文件裡的資訊拼回一個更有意義的答案

在資料建置上，作者與兩位資深資安專家共同產生了 280 題，最後為了避免評估偏差，挑選其中 170 題 用於主要測試。這些問題同時橫跨不同 query modes，因此評估不是只測單一問法，而是更接近實際使用情境。

Zero-shot 與 Few-shot：論文真正比較的是 prompt 策略

這篇研究另一個值得注意的地方，是作者沒有只測單一 prompt，而是明確比較：

• Zero-shot：不給範例，直接以指令與問題進行作答
• Few-shot：提供少量問答示例，再讓模型回答新問題

這代表論文實際在問的是：當 RAG 已經提供上下文時，few-shot prompting 是否還能進一步提升 CTI QA 的品質？

作者的答案很明確：有，而且幾乎所有核心指標都比 zero-shot 更好。

系統實作：用什麼技術組起來？

從實作細節看，這篇論文比較偏工程型研究，但細節相當完整。作者提到的主要技術元件包括：

• Streamlit：建立互動式問答介面
• Hugging Face：部署公開應用
• FAISS：向量索引與相似度檢索
• LangChain / HuggingFaceHub：整合 LLM 與 RAG pipeline
• Mistral-7B：作為主要 open-source generator 範例

此外，系統還提供：

• 單題查詢
• CSV 批次查詢
• 問題類型選擇
• 答案、上下文與來源文件顯示

換句話說，這不是只停留在 paper-level concept，而是真正做成一個能讓分析師操作的 QA 工具。

評估指標：作者怎麼量化 RAG QA 的表現？

論文評估採用 RAGAS 類型的多面向指標，而不是只看單一 accuracy。作者列出的主要指標包括：

• Faithfulness：答案是否與上下文一致
• Answer Relevancy：答案是否對題
• Context Precision：被檢回的內容是否把真正有用的段落排在前面
• Context Recall：檢索上下文是否涵蓋 ground truth 所需資訊
• Context Entity Recall：關鍵實體有沒有被檢回
• Context Relevancy：檢回內容本身與問題的相關性
• Answer Similarity：生成答案與標準答案的語意相似度
• Answer Correctness：答案整體正確程度

這組評估方式很適合 CTI 場景，因為在這類任務裡，錯誤可能來自兩個不同環節：

• 檢索錯了
• 生成歪了

如果只看最終答對率，往往很難知道問題是出在 retriever 還是 generator。這篇論文的評估設計，能比較清楚拆出兩者責任。

主要實驗結果：Few-shot 比 Zero-shot 更穩

在整體知識庫查詢場景中，論文給出的平均結果顯示 few-shot 明顯優於 zero-shot。文中最值得記住的幾個數字包括：

• Faithfulness：0.564 → 0.625
• Answer Relevancy：0.859 → 0.917
• Context Precision：0.649 → 0.660
• Context Recall：0.554 → 0.585
• Context Entity Recall：0.331 → 0.347
• Answer Correctness：0.408 → 0.436

如果用論文自己的語言來解讀，few-shot 的價值主要在兩件事：

• 讓模型更遵守回答格式與任務要求
• 讓生成答案更接近 ground truth，且更依附於檢索到的證據

此外，作者也特別提到在 metadata 與 external source 的評估中，模型在 richer data 情境下的 faithfulness 與 context recall 會更好，這說明資料品質與來源完整度對 RAG QA 的效果非常敏感。

案例比較：RAG、GPT-4o、GPT-3.5 誰更可靠？

這篇論文不是只報平均分數，還挑了幾個具代表性的問題，把 RAG 系統與 GPT-4o、GPT-3.5 並列比較。這些例子很適合看出作者強調的「來源可追溯」到底有多重要。

1. CVE-2023-34362 何時開始被利用？

Ground truth 是 2023 年 5 月 27 日。GPT-4o 可回答接近正確日期，但 GPT-3.5 因為訓練資料較舊，一次回答說自己不知道，另一次則出現帶有推測性的 hallucination。RAG 系統雖然加入了額外背景，但至少回答依附於檢索內容，而且分析師可以回頭檢查來源。

2. MagicRAT 與 TigerRAT 的關係是什麼？

Ground truth 指出兩者都與 Lazarus 有關，且共用相同 C2 基礎設施。RAG 系統能抓到「MagicRAT 可投遞 TigerRAT」以及「兩者常在 Lazarus 攻擊中一起出現」這層脈絡；GPT-4o 雖部分正確，但沒有明確說出共享 C2 的要點；GPT-3.5 則直接把樣本錯連到 Dark Caracal，屬於明顯 hallucination。

3. TigerRAT 最新變種的新能力是什麼？

Ground truth 是 USB dump capability，也就是枚舉並竊取特定副檔名檔案。RAG 系統能回到對應脈絡回答這一點；GPT-4o 與 GPT-3.5 則分別生成 screen capture、強化 evasion 等不同答案，反映出如果沒有檢索與來源約束，模型很容易把其他惡意程式常見特徵錯套進來。

這篇論文最值得看的地方，不是它「打贏 GPT」，而是它怎麼打

如果只看摘要，可能會以為這篇論文的主張是「RAG 打贏 GPT-3.5 / GPT-4o」。但更重要的其實是：作者不是用更強的生成能力取勝，而是用更可驗證的檢索流程與來源透明性取勝。

在 CTI、事件調查、歸因這些場景裡，這個差異很大。因為分析師真正需要的不是一個「看起來很像專家」的答案，而是：

• 答案來自哪份報告
• 是否能回頭驗證
• 是不是根據最新文本，而不是模型腦補

從這個角度看，這篇論文其實是在回答一個比 benchmark 更本質的問題：面對高風險資安決策，可信度要怎麼落地？

限制與失敗模式

作者並沒有把系統描述成萬能。論文明確指出幾個限制：

• 檢索錯誤會直接拖垮答案：如果 top-1 context 相似但不含真正答案，生成器還是可能跟著答錯
• 知識庫覆蓋率有限：KB 不可能囊括所有重要報告，因此對新事件與冷門樣本仍可能有盲區
• 沒有連續對話能力：系統偏向單輪查詢，不是完整 investigation copilot
• 延遲問題：採用 open-source 組件與外部部署時，回應速度仍可能偏慢

其中最有意思的是第一點。作者提到一個案例：當問題問到 Who is linked to the Sharpshooter campaign? 時，系統雖然檢回了一段和 Sharpshooter 高度相似的文本，但那段並沒有真正包含目標答案；正確上下文其實排在第二順位。這說明這類系統的瓶頸往往不是生成器不夠聰明，而是 retrieval ranking 還不夠準。

未來工作：從單輪 QA 走向更動態的 CTI assistant

作者在結論裡提出幾個下一步方向，這些方向與 2025–2026 的 agentic security / advanced RAG 脈絡也相當一致：

• 用 AI agents 自動持續爬取可靠的最新資安報告
• 導入 contextual chunking 改善文本切分
• 加入 reranking 提升檢索排序
• 使用 query transformation 改善查詢表達
• 進一步降低延遲並提高答案精度

換句話說，這篇論文雖然是 2024 年的工作，但它已經把後面兩年的 CTI+RAG 發展主軸講得很清楚了：更好的資料更新、更好的 chunking、更好的 reranker、更好的 query planning。

重點整理

• 這篇論文提出一套專門用於 cyber-attack investigation and attribution 的 RAG 問答系統。
• 知識基底來自 AttackER dataset，包含 202 份 經專家審閱的攻擊調查相關文本。
• 系統支援 整體 KB、metadata、特定文件、外部 PDF/URL 等多種查詢模式。
• 問題設計包含 factual、contrastive、inferential 三大類，而不只是簡單 fact lookup。
• 檢索流程採用 embedding + FAISS + cosine similarity，再把 top-k context 送給 LLM 生成答案。
• Few-shot prompting 在 faithfulness、answer relevancy、context recall、answer correctness 等多項指標上都優於 zero-shot。
• 與 GPT-3.5 / GPT-4o 相比，這套系統最大的優勢不是語言更華麗，而是 答案附帶來源、較少 hallucination、較適合高風險調查工作。
• 主要限制在於 retrieval ranking、KB 覆蓋率、缺乏多輪互動，以及回應延遲。

Takeaway

這篇論文最值得記住的一點，是它把 CTI 與攻擊歸因中的「讀報告找答案」這件事，從人工搜尋推進到可追溯的 RAG 問答。它沒有試圖把 LLM 神化成全知分析師，而是把模型放在一個更合理的位置：先檢索可信來源，再根據證據回答。

對 2024–2026 這一波 CTI × LLM × RAG 研究脈絡來說，這篇論文的重要性在於它把很多後續工作會談到的關鍵點——來源透明性、知識更新、外部文件接入、retrieval quality、few-shot prompt engineering——都提前放進了同一個調查型問答框架裡。若從 incident response、attack investigation、threat attribution 的角度來看，這是一篇很適合直接拿來當 early CTI-RAG archetype 的論文。

免責聲明

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