惡意程式 TTP 論文閱讀分析：真正難的不是看懂 binary，而是把分散行為重新拼回可行動的 ATT&CK 情資
論文基本資訊
- 論文標題：Identifying Adversary Tactics and Techniques in Malware Binaries with an LLM Agent
- 系統名稱：TTPDetect
- 年份：2026
- 來源：arXiv:2602.06325
- 論文連結：https://arxiv.org/abs/2602.06325
- 主題：Malware Analysis、TTP Recognition、LLM Agent、Reverse Engineering、Threat Intelligence、ATT&CK
這篇 Identifying Adversary Tactics and Techniques in Malware Binaries with an LLM Agent 很對味，因為它沒有停在「讓 LLM 看報告摘要」這種相對輕量的任務，而是直接把問題推進到更硬的一層：當你手上只有 stripped malware binary，能不能讓 LLM agent 幫你把裡面的 ATT&CK TTP 挖出來？
這不是單純做 reverse engineering automation 而已。對 CTI 來說，真正有價值的是把樣本行為重新翻譯成 defender 能用的戰術與技術描述。也就是說，作者不是只想回答「這段程式碼在做什麼」，而是想回答：這個 malware 在攻擊鏈上到底用了哪些 tactics / techniques，哪些是報告已知的，哪些可能是過去沒被寫出來的。
這篇論文想解決什麼問題？
作者先點出 malware TTP attribution 在實務上的幾個痛點：
- 真實世界 malware binary 通常是 stripped 的，沒有符號資訊可用
- 大型樣本裡有非常多函式，真正跟惡意行為相關的入口點很難先抓出來
- 惡意行為常分散在不同 code region，不是看一個 function 就能下結論
- 即使用 LLM 直接吃 decompiled code，也很容易在部分可觀測資訊下推錯方向
換句話說，困難不只在「模型懂不懂程式」，而在於它能不能像 analyst 一樣，先找到值得看的地方，再一路補上下文，最後把低階程式行為對齊到高階 TTP 語言。
TTPDetect 做法的核心：不是一次看完整個 binary，而是把分析過程 agent 化
論文提出的系統叫 TTPDetect，作者稱它是第一個專門用來從 stripped malware binary 辨識 TTP 的 LLM agent。從摘要看來，它的設計很抓到重點，主要分成三層：
- Dense retrieval + neural retrieval：先縮小可能的分析入口點
- Function-level analyzing agent：以函式為單位做深入分析
- TTP-specific reasoning guideline：在推理階段把模型往 TTP 決策邏輯上對齊
這個架構其實說明了一件很重要的事：真正能用在資安深水區的 agent，通常不是把整包資料硬塞進模型，而是先把 search、context expansion、reasoning constraints 分層設計。
第一步：先找到該看的 code 區塊
對 malware analysis 而言，最浪費時間的一件事，就是你知道樣本裡有東西，但不知道先從哪裡開始切。作者因此先用檢索，把潛在入口點縮小。
摘要提到 TTPDetect 結合了 dense retrieval 與 LLM-based neural retrieval，目的不是直接輸出最終答案，而是先把分析空間壓縮到比較值得深入的 function。這點很像近來很多 CTI / IR agent 論文的共同趨勢：模型真正的效益，不是替代所有搜尋，而是把搜尋成本降到後續推理撐得住的範圍。
第二步：用 Context Explorer 做增量式上下文探索
這篇論文另一個我很喜歡的地方，是它沒有假設「把整個 decompile 給模型看」就能解決問題。作者讓 function-level agent 裡面有個 Context Explorer，會做 on-demand、incremental context retrieval。
這代表模型不是被動吃固定上下文，而是像分析師一樣，先看到一個 function，再決定還要追哪些 call、哪些關聯函式、哪些上下游脈絡。這種做法比一次塞滿 context window 更合理，因為 malware 的惡意行為本來就常被拆散在不同位置，真正有用的是「沿著可疑線索往外挖」，而不是平鋪直敘地全讀一遍。
第三步：用 TTP-specific guideline 把推理對齊到 ATT&CK 語言
光讓模型看懂程式仍不夠，因為「看懂 function 在做什麼」和「把它準確映射成 ATT&CK technique」是兩件不同的事。作者因此設計了 TTP-Specific Reasoning Guideline，做 inference-time alignment。
這一步很關鍵。它等於承認：在資安任務裡，模型不是只需要一般語意理解，還需要被對齊到特定分析框架。 否則它可能很會描述 API usage、字串操作或程序控制流程，卻不一定會穩定地把那些行為判成正確的 tactic / technique。
這也讓 TTPDetect 比單純 code LLM 更像一個真正的 security reasoning agent，而不是語言模型外掛在 reverse engineering 流程上。
資料貢獻：作者還建了一套新的 malware TTP dataset
論文不只提方法，也補了資料。作者建立了一套新的 dataset，會把 decompiled functions 與 TTP labels 對齊，涵蓋不同 malware family 與平台。這件事本身就很有價值，因為 malware × TTP 這類資料通常標註成本高，而且很難做成足夠細緻的 function-level ground truth。
如果這套資料未來釋出並被更多研究沿用，它的影響不只是一篇 paper 的分數，而是可能成為後續 malware reasoning、agentic reverse engineering 與 CTI extraction 的共同基準。
成效怎麼樣？
從摘要數字來看，TTPDetect 表現相當亮眼：
- Function-level TTP recognition：Precision 93.25%，Recall 93.81%
- 相較基線，Precision 提升 10.38%，Recall 提升 18.78%
- Real-world malware sample：Precision 87.37%
- 對有專家報告的樣本，可找回 85.7% 已被記錄的 TTP
- 平均每個 malware 額外找出 10.5 個先前未報告的 TTP
如果這些結果穩得住，那它的意義就很大。因為這不只是「模型跟人差不多」，而是表示 agent 可能真的能變成 malware analyst 的放大器：先幫你回收大部分已知 TTP，再補出一批過去報告沒寫明的可疑技術線索。
為什麼這篇對 CTI 很重要？
我覺得這篇最值得注意的地方，是它把 malware analysis 和 threat intelligence 接得很直接。
很多人談 CTI 時，焦點會放在威脅報告、論壇、IOC、log 或 alert enrichment；但實際上，很多高價值情資本來就藏在樣本本身。這篇論文等於在做一件很關鍵的轉換：把 binary 層的程式行為，重新翻成 CTI 與 ATT&CK 可操作的語言。
這種轉換一旦做得穩，後續能接的東西很多：
- 更快把新樣本掛到 ATT&CK matrix 上
- 把 malware 家族的技術輪廓補得更完整
- 讓 hunting / detection engineer 直接拿到更接近防禦語言的輸出
- 讓 threat report 撰寫從人工歸納變成半自動 evidence synthesis
這篇論文真正厲害的不是分數，而是 workflow 設計
坦白說，我覺得這篇最值得學的不是那幾個百分比，而是它的系統設計思路。作者知道這個任務同時有三個難題：
- 搜尋空間太大
- 上下文分散
- 決策邏輯需要對齊 TTP taxonomy
所以它沒有奢望單一 prompt 解決全部，而是把 retrieval、incremental exploration、reasoning alignment 串成一條鏈。這正是現在許多 agentic security work 開始成熟的訊號：不再迷信 end-to-end 神奇 prompt，而是承認安全任務需要有結構的工作流。
我會保留的疑問
當然，這篇也不是沒有要打問號的地方。光看摘要，我至少會追幾個實務問題：
- 新增發現的 10.5 個未報告 TTP，有多少是真正高價值、多少只是偏寬鬆映射？
- 不同 malware family、packer、平台與混淆程度下，穩定性會不會明顯下降？
- 如果樣本故意加入誤導性 code path，agent 的 retrieval 與 reasoning 會不會被帶偏？
- 這套流程在真實 RE pipeline 裡的時間成本與 analyst 驗證成本如何？
也就是說，這篇很可能已經證明「方向是對的」，但離 production-ready malware triage engine 還是有一段要走。不過至少它把那段路怎麼走，描得比多數論文清楚。
總結
這篇論文最值得記住的地方，是它把 LLM agent 真正推進到 malware TTP analysis 這個更接近高價值 CTI 生產線的位置。
它不是只讓模型幫忙看懂程式，而是進一步處理三件最難的事：先找對入口點、再一路補足上下文、最後把程式行為對齊到 ATT&CK TTP 語言。若這條路線後續被更多工作接上，未來的 malware analysis 很可能不只是「自動反編譯比較快」，而是能更快把樣本轉成 defender 真正能採取行動的 threat intelligence。
簡單說，TTPDetect 想做的不是把 reverse engineering 變成聊天，而是把 binary 變成可以直接接上 CTI workflow 的證據來源。 這就不是小修小補，而是整條分析鏈條在換檔了。
免責聲明
本文由 AI 產生、整理與撰寫，內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。