From IOCs to Regex 論文閱讀分析：真正讓 CTI 卡在落地的，常常不是抽不出 IOC，而是沒人把它翻成 SOC 真的能跑的 pattern
From IOCs to Regex 論文閱讀分析：真正讓 CTI 卡在落地的，常常不是抽不出 IOC，而是沒人把它翻成 SOC 真的能跑的 pattern
如果你一路看過近年很多 CTI × LLM 論文，會很容易發現一個反覆出現的斷點：大家很愛證明模型能從 threat report 裡抽出 IOC、TTP、entity、relationship，甚至能把資訊塞進知識圖譜；但到了 SOC 真正要用的那一步，工作常常還是得回到人身上。
這篇 From IOCs to Regex: Automating CTI Operationalization for SOC with LLMs 補的正是這個很務實、也很少被正面處理的洞：IOC 被抽出來不等於已經可 operationalize。很多時候，真正痛的是 analyst 還得把那些 IOC 手工翻成 regex，才能拿去做 log parsing、digital forensics、SIEM 規則或 hunting。
我會把這篇看成是把 CTI workflow 從「資訊抽取」再往下游推了一步。它不再只問模型會不會讀 threat report，而是直接問：模型能不能把 CTI 轉成防守流程裡真的可執行、可部署、可匹配異質 log 變體的 pattern？
論文基本資訊
- 論文標題：From IOCs to Regex: Automating CTI Operationalization for SOC with LLMs
- 作者：Pei-Yu Tseng、Lan Zhang、ZihDwo Yeh、Xiaoyan Sun、Xushu Dai、Peng Liu
- 單位：The Pennsylvania State University、Northern Arizona University、Worcester Polytechnic Institute
- 年份：2026
- arXiv：https://arxiv.org/abs/2604.12228
- 領域：CTI、SOC、Regex Generation、IOC Operationalization、LLM Security Operations
這篇論文在解什麼問題？
作者抓得很準：CTI report 裡常常有很多對 SOC 很重要的 IOC，像是：
- file path
- registry key
- command-line arguments
問題在於，這些 IOC 在報告裡通常是人類可讀的描述，卻不是機器可直接拿去大規模匹配的 operational artifact。真實環境裡，同一個攻擊行為落到不同主機、不同 log source、不同系統語境之後，會有大小寫、路徑分隔符、參數順序、使用者目錄、時區與主機名稱等差異。你若只拿原始字串去 exact match，常常不是抓不到，就是抓太死。
而 regex 正好是把這段斷層接起來的媒介：它能保留攻擊行為裡真正穩定的骨架，同時允許那些正常又不可避免的變形空間。
所以論文核心問題可以濃縮成一句話：
能不能把 CTI 裡抽出的 IOC，自動翻成既有辨識力、又不會過度寬鬆，還能真的塞進 SOC pipeline 的 regex？
為什麼這題很重要？因為很多 CTI 自動化其實都停在半路
這篇最值得肯定的地方，是它沒有假裝「抽出 IOC」就等於問題解了。作者直接指出，既有工作大多停在兩個層次：
- 從 CTI text 裡抽 IOC / entity / TTP
- 更進一步生成 detection rule，但真正用到複雜 regex 的比例很低
這個批判很中肯。因為在很多真實的藍隊工作裡，光知道某份 report 提到 schtasks.exe /create ...、某個 Run registry key、或某個惡意檔案曾落在 C:\Users\Public\ 底下，其實還遠遠不夠。你真正要做的是把它轉成可以在大量 log 中穩定搜索、又能容忍環境差異的 pattern。
換句話說，這篇論文處理的不是 intelligence extraction，而是 intelligence operationalization。 這個落點很對，因為很多 SOC 現場真正缺的不是更多「看起來懂報告」的 demo，而是能減少 analyst 最耗時、最瑣碎、也最容易出錯的那段轉譯勞動。
作者怎麼定義「適合做 regex 的 IOC」？
論文沒有把所有 IOC 一視同仁，這點很重要。作者明講，像 hash、IP、domain 這種低層、極易輪替、偏 exact-match 的 indicator，並不是這篇的重點。它們更適合 feed lookup、reputation 或直接比對，不一定值得硬做 regex 抽象化。
這篇真正聚焦的是三類更有結構、也更需要 pattern abstraction 的 IOC：
- file paths
- registry keys
- command-line arguments
原因很簡單：這些東西本來就同時包含了穩定部分與可變部分。穩定部分往往反映作業系統內建結構、工具名稱與攻擊技法習慣；可變部分則可能是 payload 名稱、使用者目錄、遠端主機、排程名稱、參數值等等。也正因為它們不是全定值，regex 才有意義。
這篇最關鍵的觀點：Regex 生成不是單純字串改寫，而是在判斷哪裡該固定、哪裡該放鬆
作者把問題拆得很清楚。要讓 LLM 真的做出有用 regex，至少得解三個難題：
- Capture group finding：IOC 裡哪些片段是相對穩定、可當骨架的？哪些是會變的？
- Syntactic validity：regex 本身不能壞掉、漏括號、亂 escape、結構不完整。
- Precision vs. generality：不能窄到只匹配原句，也不能寬到什麼都能匹配。
這三題其實就是人類 analyst 在手工寫 regex 時最常出錯的地方。也因此，論文真正的價值不只是「用 LLM 產 regex」，而是它試圖把 analyst 平常靠經驗做的判斷流程拆成一條可系統化的管線。
IOCRegex-gen 怎麼做？
作者提出的系統叫 IOCRegex-gen。整體上可以分成兩大階段：
- Capture Group Finding phase
- Regex Generation phase
前者負責先判斷 IOC 裡哪些子字串比較像「應被保留的穩定結構」，後者則負責把這些資訊拿去生成、驗證、修正 regex。
第一步：先用 graph database 補 LLM 的結構知識
這篇做法最聰明的一點，是作者沒有假設 LLM 自己就懂 Windows 內建路徑、registry tree 與 command-line parameter hierarchy。他們直接建了一個 graph database，把 Windows 各版本的：
- native file paths
- registry keys
- built-in command / parameter structures
整理成樹狀圖，當成 capture-group 判定時的外部知識底座。
這個設計很實際。因為當 analyst 看到 C:\Users\Public\11.bat，直覺會知道 Users\Public 比較像作業系統慣例或常見目錄骨架，而 11.bat 更可能是攻擊者自選 payload 名稱。但 LLM 如果沒有被明確補這層結構知識，常常就會把該放鬆的地方綁太死，或把該固定的骨架一起放掉。
第二步：做 preprocessing，把 IOC 先正規化
作者也注意到另一個現實問題：CTI report 是人寫的，不會有標準格式。像是：
- 同一個 registry root 可能寫成不同縮寫
- user profile 路徑可能用變數、實名、代稱混寫
- command 可能帶副檔名，也可能不帶
所以系統先做一輪 preprocessing，例如：
- environment variable expansion
- username normalization
- registry root standardization
- command normalization
這看起來像小事，但其實非常重要。沒有這一步，後面很多 grouping 判斷都會因為同義表達而崩掉。
第三步：把 capture group 找出來
對 file path 與 registry key，作者的做法是把 IOC 切成子字串，然後去 graph database 裡找最長、最連續、最像原生結構的那段路徑。這樣可以把攻擊者臨時命名的部分排掉，保留真正穩定的 OS / config 骨架。
對 command-line argument，則改用另一套邏輯：先認主要 command，再沿著圖中的合法 parameter 關係往下找，辨識哪些 flag / option 比較像內建語法骨架，哪些值比較像攻擊者可變內容。
這裡我覺得最值得記的，不是演算法細節，而是它背後那個很對的 intuition：
要產生有用 regex，前提不是先叫模型自由發揮，而是先把 IOC 裡「什麼是環境骨架、什麼是攻擊者自由度」切乾淨。
第四步：不是一次生成，而是 reasoning + validation loop
光知道哪些部分該保留，還不夠。LLM 真正生成 regex 時，還是可能犯兩類錯：
- 語法錯誤：根本不能編譯、括號不平衡、escape 不對
- 語意錯誤：太窄或太寬，失去 detection 價值
所以作者不是一次 prompt 完就收工，而是讓系統進入迭代式 reasoning + 多階段 validation。候選 regex 會被工具檢查，若發現不符 target IOC 或過度寬鬆，就把錯誤訊息回灌進下一輪 prompt，逼模型修。
這個設計跟很多近年的 agentic workflow 脈絡其實是同一路：不要把 LLM 當一次性生成器，而是把它放進「提案 → 驗證 → 修正」的閉環裡。 在這個題目上，這樣做很合理，因為 regex 本來就是一種極度適合被 deterministic checker 審核的 artifact。
這篇論文最實用的一點：它不只追求 match，還在防 useless regex
很多自動 regex 研究容易掉進一個坑：只要能 match 到目標字串，就說自己成功。但對 SOC 來說，這遠遠不夠。因為一個像 .* 這種東西當然超好 match，卻毫無意義。
作者有意識到這點，所以除了 hit rate，也特別處理 overly general regex 的問題。他們用 grading / scoring 機制把過度寬鬆、缺乏鑑別力的 pattern 篩掉，避免系統最後吐出 technically valid、operationally useless 的垃圾 regex。
這一點我很認同。因為在藍隊環境裡，比抓不到更糟的，常常是抓太多，最後讓分析師又回到警報疲勞。
實驗怎麼做？
評估上，作者用了兩塊資料：
- 超過 3,000 份真實 CTI reports
- 超過 2,400 筆來自 MITRE ATT&CK Evaluation 的 ground-truth strings
這個設計很合理，因為它不是只在小型人工題庫上看「像不像」，而是試圖把 generated regex 放回較接近真實攻防演練資料的 context 裡，檢查它能不能在獨立蒐集的 artifact 上真的打中。
結果怎麼看？
論文 headline 很漂亮：
- 平均 hit rate：99.1%
- 平均 false-positive rate：0.8%
而且作者還提到，相較於直接把 IOC 丟給 LLM、讓它裸生成 regex 的 baseline，IOCRegex-gen 在 hit rate 與 false-positive rate 上都有 30% 以上的改善。
我認為這個結果真正有意思的地方，不只是數字高，而是它支持了一個比較大的結論：
在這種 CTI-to-detection 的問題上，LLM 單靠語言能力其實不夠；真正有效的，是把 domain structure、validation loop、以及對「何者該固定、何者該抽象化」的工程約束一起放進來。
我怎麼看這篇論文？
如果把它放回最近 sectools.tw 這條線，我會把這篇看成是補在 CTI extraction → operationalization 中間那塊經常被跳過的轉譯層。
前面很多 paper 在回答的是：
- 能不能抽 ATT&CK technique？
- 能不能抓 entity / relationship？
- 能不能做 STIX 或 knowledge graph？
但這篇問的是另一個更貼近一線藍隊的問題：
- 抽完之後，誰來把它變成能查 log、能寫 rule、能做 forensic search 的東西？
也因此，這篇最大的價值不是模型多炫，而是它把「自動化 CTI」從 paper demo 稍微往 SOC 現場拉近了一點。
它也提醒了什麼限制？
當然，這篇也不是萬靈丹。我覺得至少有幾個限制值得記：
- 平台偏向 Windows：graph database 和很多 structural prior 都建立在 Windows path / registry / command ecology 上，跨到 Linux、macOS、cloud audit trail 時還得重建知識底座。
- IOC 類型有限：它主要處理 file path、registry、command-line；這很合理，但也代表還沒覆蓋更廣的 detection artifact。
- regex 不是終點：在真實 SOC 裡，regex 往往只是更大 detection rule 的一部分，之後還有 correlation、context binding、risk tuning 等問題。
- ground truth 仍偏 artifact matching：它證明了 pattern matching 很強，但還沒完全等於 production detection engineering 全鏈條成熟。
不過我不會因為這些限制就看輕它。相反地，我覺得這篇最好的地方就是它沒有假裝自己解了整個 SOC automation，而是非常具體地把其中一段高摩擦、可驗證、且值得自動化的工作先處理掉。
總結
如果要把這篇濃縮成一句話，我會這樣說：
這篇論文真正補上的，不是「怎麼讓 LLM 多抽幾個 IOC」，而是怎麼把 CTI 裡那些人看得懂、但機器還不能直接用的線索，翻成 SOC 真正跑得動的 detection pattern。
對研究者來說，這篇提醒了一件很重要的事：CTI automation 的價值，不在 extraction 本身，而在 extraction 之後還能不能接上 operational workflow。
對 SOC 團隊來說，這篇也很值得看，因為它讓人更清楚看到：regex authoring 這種過去被視為「理所當然得人工處理」的工作，其實很可能正是最適合被 LLM + validation pipeline 接手的一段。
一句話結論：很多 CTI 論文都停在「看懂報告」，但這篇真正往前走到「把報告變成可執行防守」；而這一步，才是 SOC 會不會真的省下時間的關鍵。
本文由 AI 產生、整理與撰寫。