Claude读论文系列（九）

精读笔记：IOCRegex-gen

From IOCs to Regex: Automating CTI Operationalization for SOC with LLMs

arXiv: 2604.12228 | cs.CR

机构：Penn State University / Northern Arizona University / WPI

提交日期：2026-04-14

一、TL;DR（一句话）

提出 IOCRegex-gen ：用 LLM 将 CTI 报告中的 IOC 自动转化为可部署的正则表达式，在 3,000+ 真实 CTI 报告上达到 99.1% 命中率 / 0.8% 误报率，比直接 prompt LLM 提升 30% 以上。

二、背景与动机

2.1 SOC 的核心痛点

现代 SOC 分析师每天面对来自 Windows Event Log、Endpoint Log、Linux Journal 等海量日志，核心任务之一是：从 CTI 报告中提取 IOC（失陷指标） ，然后将其转化为 正则表达式，供 SIEM（如 Splunk、Elastic）做日志解析和告警规则。

典型场景：

CTI 报告里描述攻击者用命令 schtasks.exe /create /tn ... 创建计划任务，但真实日志里同一行为可能出现不同路径分隔符、大小写、参数顺序------直接字符串匹配根本行不通，必须用正则。

2.2 现状与缺口

现有工作	做了什么	没做什么
IOC 提取（NER / LLM）	从 CTI 提取 raw IOC 字符串	❌ 没有生成正则
SIEM 规则生成	生成了一些规则	❌ 正则比例极低（135 条规则中仅 7 条含正则，且结构简单）
通用 NLP→Regex	生成通用正则	❌ 不理解安全语境，无法处理攻击者变体

核心缺口：从 IOC → 可部署正则这一步，至今仍靠人工完成。

2.3 三大挑战

编号	挑战	描述
C1	捕获组识别	哪些子串应作为 capture group？错位则影响 SIEM 集成和取证分析
C2	LLM 幻觉	LLM 易生成语法错误或语义偏离的正则
C3	精度与泛化平衡	过窄漏报，过宽误报（含大量通配符无实用价值）

三、系统设计：IOCRegex-gen

3.1 整体架构

复制代码

CTI 报告
   ↓
[IOC 提取（已有工具）]
   ↓
[IOCRegex-gen]
   ├── 组件 1：Group-Aware 机制（解决 C1）
   │      ├── 知识增强框架 + 图数据库
   │      └── 分析 IOC 结构模式，识别 capture/non-capture group
   │
   └── 组件 2：迭代推理 + 多阶段验证（解决 C2 & C3）
          ├── 语法验证（正则编译测试）
          ├── 语义验证（ground-truth 命中测试）
          └── 失败 → 迭代修正 loop
   ↓
可部署正则表达式（SIEM / 取证工具）

3.2 组件一：Group-Aware 机制（核心创新）

问题：正则中 (...) 是捕获组，(?:...) 是非捕获组，错误归类会让 SIEM 提取错误字段。

方案：

用图数据库存储历史 IOC 的结构模式和攻击者行为知识
对新 IOC，检索相似 IOC 的捕获组模式，作为 context 注入 LLM
LLM 在"知情"的情况下判断每个片段应用哪类分组

效果：捕获组与 SIEM 集成需求对齐，下游取证分析可直接提取关键字段。

3.3 组件二：迭代推理 + 多阶段验证（核心创新）

复制代码

LLM 生成候选 regex
       ↓
[Stage 1] 语法检查
  → 失败：重新生成（带错误反馈）
       ↓
[Stage 2] 语义检查
  → 用 MITRE ATT&CK ground-truth 字符串测试命中率
  → 失败：分析具体 miss case，迭代修正
       ↓
[Stage 3] 泛化度检查
  → 拒绝过宽（大量 .* 通配）或过窄（纯 literal）的 regex
       ↓
最终 regex 输出

关键指标：

Grading Score > 3：正则具有实质结构复杂度（不是简单 literal 匹配）
Similarity ≈ 0.4：与原 IOC 有足够相似性（保留关键特征），同时有足够变体空间

四、实验结果

4.1 数据集

数据源	规模	用途
真实 CTI 报告	3,000+ 篇	生成正则的输入
MITRE ATT&CK Evaluation	2,400+ ground-truth 字符串	验证正则效果

MITRE ATT&CK Evaluation 是独立机构（非研究者自己）从真实安全事件采集的，是最可信的 ground-truth。

4.2 主要结果

指标	IOCRegex-gen	直接 Prompt LLM（无组件）
命中率（Hit Rate）	99.1%	~69%（推算，提升 30%+）
误报率（FP Rate）	0.8%	~30%+（推算，降低 30%+）
Grading Score	> 3.0	< 2.0

4.3 消融实验结论

去掉 Group-Aware 机制 → 捕获组错位率显著上升，SIEM 集成失败
去掉迭代验证 → 语法错误率和误报率大幅上升
两个组件缺一不可，协同效果最强

五、深度分析与点评

5.1 为什么 99.1% 命中率很难得？

传统方法：手工写正则，资深分析师需要数小时，且不同人风格不一致。

LLM 直接生成：大量幻觉，语法错误 20-30%，语义错误更多。

IOCRegex-gen 的迭代验证 pipeline 是核心壁垒------它用代码执行来约束 LLM 输出，把"生成正确性"问题转化为"验证通过"问题，工程上非常务实。

5.2 Group-Aware 的深层价值

不只是"生成正确的正则"，而是"生成对 SIEM 工程师有用的正则"。

捕获组的位置决定了 SIEM 能自动提取哪些字段用于关联分析。这一点之前所有工作都忽视了。

5.3 限制与不足

依赖上游 IOC 提取质量：如果 IOC 提取本身有错，下游正则也会偏离
图数据库需要维护：需要持续更新历史 IOC 模式，初期冷启动效果有限
未评估在实际 SIEM 部署中的效果：lab 测试和生产环境的 log 多样性可能有差距
未开源代码：可复现性受限

5.4 延伸思考：落地方向

与 STIX/TAXII 对接：CTI 行业标准格式，自动化 IOC 入库 → 生成正则 → 推送 SIEM 规则，形成完整 pipeline
与 Sigma 规则集成：Sigma 是跨平台 SIEM 规则格式，IOCRegex-gen 可成为 Sigma 规则自动生成器
实时 CTI 流处理：接入 RSS/API CTI feeds，实现"CTI 报告发布 → 正则规则上线"分钟级延迟

六、关键引用追踪

引用	内容	重要性
MITRE ATT&CK Evaluation	ground-truth 数据源	⭐⭐⭐
LLM IOC 提取工作 [18][33]	上游任务，本文衔接	⭐⭐
SIEM 规则生成 [42]	135 条规则仅 7 条含正则，说明问题真实存在	⭐⭐

七、速查卡片

复制代码

论文：IOCRegex-gen
任务：CTI IOC → 正则表达式（自动化）
方法：Group-Aware + 迭代多阶段验证
数据：3,000+ CTI报告 + MITRE ATT&CK GT
结果：命中率99.1% / 误报率0.8% / vs直接LLM提升>30%
开源：未提及
价值：SOC自动化、SIEM规则生成、取证分析