将网络威胁情报转化为可计算检测模式的结构化工作流程

摘要

在此，我们介绍了一种协议，利用大型语言模型（LLM）和图辅助组件标签的集合提取，将网络威胁情报报告中的文件路径、注册表密钥和命令行指示转换为经过验证的安全信息与事件管理（SIEM）检测规则的正则表达式。

摘要

安全运营中心（SOC）通常将网络威胁情报（CTI）报告转换为操作检测内容。该工作流程中的一个持续瓶颈是将提取的入侵指示（IOC），特别是文件路径、注册表键和命令行字符串转换为可部署的正则表达式（正则表达式），以便嵌入安全信息与事件管理（SIEM）相关规则中。尽管以往工作改进了自动泄露指示（IOC）提取，但将提取字符串转换为经过验证的正则表达式模式仍大多是手动完成，需要专业技能，且容易出错。该协议的目标是提供一个标准化、可重复的IOC到正则表达式转换过程。该工作流程包括五个阶段：（1）将异构的CTI报告解析成统一的Markdown表示;（2）利用多个大型语言模型（LLMs）进行IOC提取，采用共识投票;（3）基于规则的归一化、分类和提取IOC的去重;（4） 对IOC组件进行图辅助标记，标记为保留（捕获组）或丢弃（非捕获组）;以及（5）基于原始IOC字符串进行诊断验证的迭代正则表达式生成。为评估效用，该工作流程应用于3,156个CTI报告，所得正则表达式与来自十个MITRE对抗战术、技术与常识（ATT&CK）评估场景中独立收集的2,400多个真实字符串进行了评估，平均命中率为99.1%，跨IOC平均不匹配率为0.8%。因此，该协议记录了一个可复现的 IOC 转正则表达式转换实现，并明确界定了其当前范围、操作假设及已知的失败案例。

引言

网络犯罪持续给公共和私营部门的组织带来巨大的运营和财务负担。2023年，美国因网络犯罪造成的损失报告超过125^{亿美元1，}凸显了恶意活动的规模和持续性。在此环境中，安全运营中心（SOC）作为主要的运营单位，负责实时检测、分析和响应威胁。
许多SOC工作流中的检测逻辑通过安全信息与事件管理（SIEM）平台内的基于规则的机制实现，这些机制因其可解释性、确定性且与现有SOC工作流兼容而被广泛使用。在不同规则类型中，基于相关性的SIEM规则对于识别跨越多个事件、主机和时间窗口的攻击行为尤为重要。在这些规则中，正则表达式（正则表达式）作为可重用的搜索原语：分析师将它们嵌入更广泛的检测规则中，这些规则增加了字段约束、平台特定过滤器和事件相关逻辑，而非将其部署为自包含的检测器。

在实践中，SOC分析师通常从安全供应商、独立研究人员或公共知识库（如MITRE对抗战术、技术与常识（ATT&^CK）2发布的网络威胁情报（CTI）报告中提取的入侵指标（IOC）开始制定规则。这些IOC字符串可能包括文件路径、命令行片段、注册表键或攻击过程中观察到的其他结构化伪^影。将这些字符串转换为适用于 SIEM 相关规则的正则表达式模式是规则编写工作流程中的一项反复任务。

这一翻译步骤是一个实际操作瓶颈。编写既足够通用以捕捉有意义变化又足够精确以避免意外匹配的正则表达式模式需要专业技能;细微的句法错误或在保留或泛化哪些组件时的错误决策，都可能使本来有用的检测规则失效。由于这项工作是手动、重复且注重细节的，可能会延迟对新兴威胁的检测部署，需要更有经验的分析师审查，并增加SOC4,5的^{操作性工作}量。

IOC转正则表达式转换的核心挑战是确定IOC中哪些部分编码稳定且与攻击者相关的行为，因此应被保留;哪些部分反映了环境或宿主的具体变异，应予以推广。例如，规范注册表根（如 HKEY_CLASSES_ROOT\CLSID）、系统目录（如 System32）以及已知的可执行名（如 rundll32.exe）通常需要保持显式，而用户配置文件路径、主机特定安全标识符（SID）和全球唯一标识符（GUID）通常应被抽象化。在异构IOC类型中持续做到这一点，使得翻译任务变得非简单。在整个协议中，我们称前者为保留或捕获群组件，后者称为抽象或非捕获群组件。

此前的研究曾探索利用自然语言处理和实体^{提取技术，}从非结构化文本中自动提取威胁情报 ^6,7。近年来，多项研究研究利用大型语言模型（LLMs^）直接从CTI报告生成检测规则8。这些方法表明，部分规则编写工作流程可以通过语言模型辅助，但通常不专注于生成既能保留捕获组语义又适合下游SIEM部署的正则表达式模式这一具体操作问题。相关工作线为后续使用提供了结构化的CTI内容，包括TINKER⁹等知识图集表示法，以及基于CTI生成的日志狩猎查询，如ThreatRaptor¹⁰，这些将非结构化CTI转换为结构化知识或领域特定查询语言，而非用于嵌入SIEM相关规则的正则表达式模式。

与此同时，先前的研究也探索了基于实例的方法、神经翻译以及生成与修复方法的自动正则表达式合成，这些方法见11,12,13,14,15,16。然而，这些方法通常针对依赖大量代表性示例或自然语言描述的环境设计，而非IOC驱动的检测上下文。在SOC工作流中，IOC字符串通常稀疏、结构异构，并且与操作语义紧密相关。这种不匹配促使工作流程针对IOC到正则表达式的转换，而非声称现有正则表达式生成方法普遍不足。

这里展示的协议特别关注SOC检测工作流程中的IOC转正则表达式转换阶段。IOC提取被视为上游输入，可能源自人工分析、自动化工具或两者结合;协议不尝试生成完整的 SIEM 规则。相反，它提供了一个系统化的过程，将IOC字符串转换为语法有效、语义上可解释且适合操作部署的正则表达式模式。当前的IOC范围是有意为之：文件路径、注册表键和命令行指示器包含稳定和可变结构组件，受益于正则表达式泛化，而原子指示器如IP地址、域和哈希则更自然地通过精确匹配条件或声誉式查询操作，因此不属于主要范围。在这些范围内，该协议旨在跨SOC环境可移植，这些环境共享相似的输入格式和工具前提条件。

方案

使用以下五阶段工作流程，将CTI报告转换为经过验证的正则表达式模式，并具有可追溯的中间输出（详见 图1 的概述）。

1. 系统搭建

1. 安装先决条件。
   1. 安装 Python 3.8 或更高版本，requirements.txt中列出的所有 Python 依赖，以及 Neo4j 图数据库。
      1. 确认访问所选大型语言模型的一个或多个应用程序接口（API），并确认 Neo4j 服务正在运行且可从本地机器访问。
   2. 确认材料表已完成。
      1. 请确认运行时依赖被列出，包括 Python 解释器版本、流水线依赖、Neo4j 版本以及可移植文档格式（PDF）文本提取后端。
      2. 确认列出了LLM配置选项，包括LLM提供者、型号名称和版本、温度、推理努力选项以及集合投票设置。
      3. 请确认输入和输出格式是否被列出，包括支持的输入文件格式和支持的导出格式。
2. 启动网页用户界面（UI）。
   1. 打开终端，导航到引用实现根目录，并使用文档中的启动命令启动应用程序（参考实现中为 cd langchain_pipeline 跟 streamlit run app_v2.py）。
   2. 确认应用加载时 http://localhost:8501，侧边栏配置面板是否可见。
3. 配置LLM提供者。
   1. 在侧边栏的LLM配置部分，选择LLM提供者，输入型号名称，并提供有效的应用程序编程接口（API）密钥。
   2. 记录材料表的提供者、型号名称、型号版本、温度、推理-工作量选项以及访问日期。
      注意。在参考实现中，单LLM的IOC提取默认使用材料表中列出的主商业LLM，温度=0.0;正则表达式生成默认为温度 = 0.3。
4. 启用集合投票（可选但建议以保证结果可重复）。
   1. 在侧边栏启用集合投票选项，只保留符合最低投票门槛的IOC（建议最低投票数≥2票）。
   2. 通过指定提供者、模型名称、API键以及每个模型的执行重复次数，添加额外的LLM实例。
      1. 记录每个提供者的重复次数和所选的最低投票门槛。
         注意。 集合投票为可选。禁用后，流水线执行单LLM提取，跳过共识过滤器。默认的集合设置为每个配置模型重复次数 = 1，且 min_votes = 2。
5. 连接到Neo4j。
   1. 在侧边栏的 Neo4j 连接部分输入连接 URI（例如 bolt://localhost:7687）、用户名和密码。
   2. 确认接口报告连接成功。没有激活连接不要继续。
6. 确保所有凭证安全。
   1. 把LLM API密钥和Neo4j密码当作敏感凭证。将它们存储在环境变量或秘密管理器中，而不是源文件、导出报告或截图中，如果怀疑有泄密，可以及时更换任何密钥。
      注意。 该软件协议不要求化学烟雾罩、生物安全柜或其他物理安全设备;根据机构数据安全政策处理机密CTI报告和凭证。

2. 第一阶段：文档解析

1. 程序。
   1. 进入主界面的“处理”标签。
   2. 上传支持格式（.pdf、.docx、.md、.txt或.html）的CTI报告。
   3. 点击“运行下一阶段”以执行第一阶段，或点击“运行所有阶段”按顺序执行整个流程。
2. 确认第一阶段检查点。
   1. 确认输入文档的Markdown预览显示。
   2. 确认预览中文件路径、注册表键、命令行片段和分区边界保持完整。
   3. 如果技术字符串被截断或格式被删除，请在重新上传前修正源文件或使用外部转换器预处理文档。

3. 第二阶段：氧气外骨骼提取

1. 程序。
   1. 确认LLM配置（以及如果启用的集合投票）。
   2. 点击“运行下一关”以执行第二阶段。
2. 确认第二阶段检查点。
   1. 确认该界面显示一个包含三个顶层键的 JavaScript 对象符号（JSON）格式的 IOC 集合：文件路径、命令行和注册表键。
   2. 启用集合投票时，请确认每个保留的 IOC 都记录了投票计数和贡献模型元数据。
      注意。 逐字第二阶段系统和人工提示，以及第五阶段生成和优化提示，作为 补充文件1 （Supplemental_File_1_Prompts.txt）发布。

4. 第三阶段：国际空气壳分析与分类

1. 程序。
   1. 点击“运行下一阶段”以执行第三阶段。
2. 确认第三阶段检查点。
   1. 确认每个保留的IOC都标注了标准化类别、源标签以及原始提取密钥（如有）。

5. 第四阶段：Neo4j辅助IOC正常化

1. 程序。
   1. 确认Neo4j连接是否已激活。
   2. 点击“运行下一关”以执行第四阶段。
   3. 检查每个IOC的归一化输出，确认路径和命令行组件的保留/丢弃标签是否存在，注册表键是否产生连续的典范子串。
2. 确认第四阶段检查点。
   1. 确认每种IOC类型（文件路径、注册表键、命令行指示器）都生成了规范化的IOC表。
   2. 确认每个条目是否包含原始值、归一化值，以及标记为保留或丢弃的元素/状态对组成列表。
      注意。 详细的 Neo4j 模式、密码查询、决策规则和注册表密钥规范化过程列于 补充文件 2;代表性结果中提供了工作示例。

6. 第5阶段：正则表达式生成与评分

1. 程序。
   1. 点击“运行下一关”以执行第5关。确认每个归一化的IOC及其禁用令牌列表均提交进行正则表达式生成和确定性验证。
   2. 如果候选表达式验证失败，则允许优化循环对正则表达式进行细化，直到产生符合标准的候选表达式或达到迭代次数上限。
   3. 检查诊断输出、优化历史和迭代计数，针对任何最终正则表达式从合规退回到最高得分部分匹配（记录为 used_fallback = True）的 IOC。
2. 确认第五阶段检查点。
   1. 确认每个保留的IOC都生成一个最终正则表达式。
   2. 确认候选人评分、优化历史、问题列表和迭代次数均被记录。
   3. 确认每个IOC的遥测数据，包括估计的令牌使用量和延迟，是否被记录。
      注意。 详细的正则表达式验证规则、评分公式和迭代控制参数列于 补充文件2中。

7. 分析与验证

1. 打开分析标签页，查看IOC分布、集合投票结果（启用时）、正则表达式质量摘要和优化统计数据。利用这些摘要检测异常，如提取不平衡或反复优化失败。

8. 出口成果

1. 在导出标签中，选择导出格式（纯文本、JSON 或 YAML），并下载正规表达式集。确认导出的正则表达式是否包含相关的分数和分类元数据。
2. 生成并下载包含解析文档、提取IOC、归一化表示、候选正则表达和最终输出的完整JSON报告。请保留此报告作为可重复性记录。

9. 故障排除

1. 如果第一阶段返回截断或空白的 PDF 内容，请在重新上传前使用外部转换器或光学字符识别工具预处理文档，并确认技术瑕疵在 Markdown 预览中依然可见。
2. 如果第二阶段返回的共识IOC过少，在更改阈值前，请先验证提供者、型号、API密钥、重复计数和最小投票数的设置。排除候选人检查以区分幻觉与过于严格的投票。
3. 如果第四阶段将所有组件标记为丢弃，请验证Neo4j的连接性，并确认图中包含所分析IOC类型的相关路径、注册表或命令行界面（CLI）词汇。
4. 如果第5阶段生成了一个正则表达式，但编译失败了匹配或过度泛化，请检查优化历史、诊断失败位置和过度泛化检查后再重新生成候选。

10. 确认最终协议输出。

1. 确认解析后的 Markdown 文件、IOC 集合（启用集合投票时为共识验证，禁用时为单模型）、分类 IOC 表以及图归一化的 IOC 表示是否全部存在。
2. 确认兼容SIEM的正则表达式集、分析摘要和完整的JSON报告都已存在，并将JSON报告作为可重复性记录归档。

结果

本节介绍了IOC转正则表达式协议产生的代表性结果，并总结了用于评估其操作适用性的参考评估。参考评估处理了3,156份与MITRE ATT&CK技术相关的CTI报告，分析了23万多句，提取了63,000多个IOC候选句子，并对来自十个MITRE ATT&CK评估场景中2,400多个独立收集的真实字符串进行了正则表达式的评估。这些实地信息串是专家精心策划的攻击文物，由网络安全厂商在MITRE ATT&CK评估过程中独立报告，因此反映了人工分析师和厂商在实际操作中记录的结构性模式。以下结果聚焦于与操作日志分析和检测工作流相关的工作流行为、结构正确性及评估结果。

图1提供了端到端流水线的概述，总结了捕获群寻找阶段和正则表达式生成阶段，框架了其余代表性结果。

第一阶段：文档解析输出

图2显示了第一阶段的输出，其中输入的CTI报告被解析成统一的Markdown表示。成功执行后，界面会显示文档的结构化预览，包括章节边界和相关性指示符。

正确执行通过连贯的段落分段和技术工件（如文件路径、注册表键和命令行片段）的保存来表示。此阶段过度截断或格式丢失可能影响后续分析，应在继续前处理。

第二阶段：基于共识的IOC提取

图3 展示了第二阶段的输出，其中通过多LLM集合投票提取候选IOCs。由此产生的界面呈现一个带有投票计数和贡献模型注释的 JSON 格式 IOC 集合。

只有符合配置的最低共识阈值的IOC才会被保留。此阶段排除的IOC通常反映模型特有的幻觉或模糊的文本片段。排除这些票是预期且理想的结果，表明集合投票运作正常。

第三阶段：国际奥委会分析与分类

表2 总结了每个协议阶段的预期输出、自动验证步骤及面向分析师的质量控制检查。

图4 显示了在第二阶段集合投票中未达到共识门槛的IOC候选人，并显示界面供分析师检查。此类候选通常反映模型特有的幻觉或模糊的文本片段。因此， 图4 和 图5 对应的是不同的阶段输出——第2阶段丢弃的集合和第3阶段保留的集合——而非同一阶段3过程的不同视图。

图5 展示了第三阶段在JSON解析、基于规则的分类和IOC重复删除后产生的保留IOC表。对于每个保留的IOC，阶段记录一个标准化类别、源标签以及原始提取密钥（如有），然后再将IOC传递给下游归一化。

第四阶段：跨IOC类型的图辅助IOC规范化

图6、图7和图8展示了当前研究中涉及的三个IOC类别的代表性归一化结果：文件路径、注册表键和命令行指示符。对于每个类别，图示比较了从CTI报告中提取的原始IOC与通过图辅助分析得出的归一化表示。

在所有IOC类型中，协议将每个IOC分解为语义组件，并通过图数据库中编码的结构化知识解决层级关系。在当前实现中，Neo4j 存储了规范化的路径、注册表和 CLI 节点，并使用邻接关系测试组件是否属于已识别链。这一角色类似于检测工程²中结构化ATT&CK知识的应用。

重要的是，该规范化步骤通过标记为保留或丢弃，记录了IOC组件的明确语义角色，而非默默从分析记录中移除。归一化字符串主要由保留组件重建，而丢弃组件则作为元数据保留，用于下游正则表达式生成和验证。

该阶段的正确执行通过保留有意义结构上下文并在不同IOC类型间表现出一致捕获群标记的归一化IOC来表明。原始表示与归一化表示之间的视觉比较提供了实用的质量控制机制，以验证捕获组分辨率的应用一致且无意外信息丢失。

第五阶段：正则表达式生成，辅以基于约束的选择

图9 展示了第五阶段的输出，该协议通过迭代验证流程从归一化IOC生成结构合规的正则表达式。该实现结合了初始生成提示、候选对象未能匹配IOC时的诊断重启、丢弃感知验证和限制重试循环。

给定归一化的IOC及其相关的保留/丢弃组件规格，工作流程首先生成初始正则表达式候选。候选人随后与 IOC 进行测试，匹配失败时诊断性重新提示，检查禁用丢弃的标记，并利用随机负字符串评估是否过度泛化。

当多个候选项满足基本验证检查时，协议会应用辅助约束选择机制，以保留代表性的正则表达式供下游使用。当前实现对候选人评分为“Score = n_cg - n_wc”，其中“n_cg”是代表的保留组件数量，“n_wc”是正则表达式中丢弃或未映射的标记数。

选择函数定义为：

得分 = n_cg − n_wc

这是更一般形式的等权重专化（α = β = 1），分数 = α·n_cg − β·n_wc。这里，n_cg表示代表的保留成分数量，n_wc表示正则表达式重新引入的丢弃成分或未映射的额外标记数量。实现还记录了每个IOC的迭代次数、问题列表、估计令牌消耗、缓存使用情况和延迟遥测。等权设置被用作参考实现的简单确定性默认;由于它将缺失的保留组件和重新引入的丢弃组件视为同样不理想，在假阴性和假阳性带来不同运营成本的部署环境中，可能会更倾向于采用其他权重。

最终的正则表达式被选为最能满足这些约束的候选表达式。将必需捕获群组件置于可选结构中的正则表达式（例如（ ... ）？，因削弱语义一致性而被排除在选择之外。这一选择步骤是生成过程的辅助步骤，并非作为独立的质量指标。

CTI处理的分析概述

图10 概述了所有处理文件中CTI分析结果。在参考评估中，对3,156份CTI报告的IOC提取产生了超过63,000个IOC候选，包括12,195条文件路径、2,302个注册表键和10,286个命令行指示符，其余候选对象属于非正则表达式目标IOC类型。

这些计数高层次验证了提取的指标集中在当前协议目标的三个IOC类别中，同时也显示许多提取的伪影仍不在正则表达式生成范围内。在重现工作流程时，报告处理的CTI报告数量、总IOC候选报告、类别计数，以及提取过程中使用的提供者、型号、模型版本、温度、重复次数和共识阈值。

在参考评估中，生成的正则表达式与来自十个MITRE AT&CK评估场景中独立收集的2400多个真实字符串进行了比较，平均命中率为99.1%，跨IOC平均不匹配率为0.8%。在本稿中，不匹配率被用作语义特异性度量：当为一个IOC生成的正则表达式与另一个IOC关联的基层字符串匹配时，就会发生不匹配。该数量不应被解读为端到端的操作警报误报率，后者还取决于下游规则逻辑和部署上下文。

该分布反映了CTI语料库的结构性组成，并允许用户验证提取的指标是否与预期的IOC类型相符。与预期比例有较大偏差可能表明上游解析或提取存在问题，应在进行下游归一化和正则表达式生成前进行检查。

正则表达式优化动作分析

图11 总结了正则表达式生成和细化过程中执行的动作。该分布包含三种动作类型：初始正则表达式生成、LLM驱动的优化步骤和基于重试的再生。

LLM驱动的优化占所有观察到的动作的51.7%。这种普遍性表明，仅靠初始生成往往不足以产生满足捕获群约束和排除要求的正则表达式。相反，迭代优化被积极且反复地应用来优化候选正则表达式。

该分布并非反映低效，而是表明优化工作流程是协议在从复杂 IOC 输入生成结构合规正则表达式时必要且不可或缺的组成部分。

对使用可扩展性测试LLM生成的6,000个IOC随机样本进行的独立可扩展性特性分析（见材料表）报告的中位延迟为每个IOC2.95秒，平均延迟为23.18秒。在同一特性下，语法有效正则表达式编译率达到99.56%，整体生成成功率达到99.4%，平均估计每个IOC约3986个令牌使用，工作流程平均每个IOC约需7.89次LLM调用。匹配-调试循环的首次通过成功率为56.46%，非捕获组验证循环为72.92%。这些测量有助于表征批量使用的计算成本和运营吞吐量。

当前参考特征描述中未使用专家评审样本输出子集进行模型再训练;报告的结果反映了自动流水线执行及上述下游评估数据集。

操作证据和故障处理。图12展示了协议导出的SIEM正则表达式文件结构，以及代表性文件路径、注册表键和命令行模式的规则级验证证据。图13展示了对应的完整JSON报告，该报告暴露所有阶段输出（提取、分析和归一化的IOC，以及生成的正则表达式模式和每个IOC验证标志），是下游工具消耗的主要工件。图14展示了协议对噪声CTI输入的处理：在分析阶段标记一个去牙、带有空白扰动的文件路径，进行校正，归一化为规范的%TEMP%模板，然后转换为编译匹配的正则表达式。该示例补充了图12和图13中的操作证据，记录了当原始IOC文本偏离规范形态时协议的行为。

图1：IOC转正则表达式协议的整体架构。 图中总结了端到端的流程。由上游IOC提取器生成的候选IOC字符串被分解，并与从Windows文档填充的Neo4j图中的参考节点进行比较（步骤1），该图检索已知的路径、注册表和命令行组件（步骤2）。变量或环境特定的片段被标记为丢弃，并从归一化重建中排除，同时保留在组件元数据中，从而产生具有组件级保留和丢弃标签的归一化IOC（步骤3）。这些归一化后的IOC随后被传递到基于LLM的正则表达式生成阶段（步骤4），生成候选正则表达式，这些表达式会被评分并针对捕获群约束和丢弃令牌规则进行迭代优化（步骤5），然后选择最终正则表达式（步骤6）。 请点击此处查看该图的放大版本。

图2：第一阶段文档解析输出。原始CTI报告与解析文档预览的并排对比。左侧面板显示原始CTI报告的PDF格式，右侧面板显示解析器生成的统一Markdown表示。请点击此处查看该图的放大版本。

图3：基于共识的IOC提取，采用多LLM集合投票。 该界面展示了基于集合的 IOC 提取过程及其中间结果。红色框突出显示参与IOC提取的配置LLM实例，包括所选提供者及每个模型执行的重复提取次数。蓝色框表示用户定义的共识阈值，规定保留IOC所需的最少出现次数。在汇总所有模型和重复次数的提取结果后，出现次数少于阈值的候选 IOC 将被丢弃。橙色框显示满足共识标准并进入下游分析阶段的最终保留IOC集合。 请点击此处查看该图的放大版本。

图4：第2阶段集合投票淘汰的IOC。 未达到集合投票中配置最低票数门槛的IOC候选人的并排视图，供分析师检查。被淘汰的候选对象通常反映模型特有的幻觉或模糊的文本片段，不会进入第三阶段的分类步骤。 请点击此处查看该图的放大版本。

图5：保留IOC并采用标准化分类。 在第三阶段处理后保留的IOC候选对象会连同其标准化类别、源标签和原始提取密钥（如有）一同显示。该表提供了归一化阶段使用的结构化IOC输入。请点击此处查看该图的放大版本。

图6：利用图辅助分析进行文件路径IOC归一化。 原始文件路径IOC及其归一化表示的并排比较。基于图的遍历查询通过归一化名称命名路径组件，并将每个组件标记为保留或丢弃。因此，驱动器标识符和变量文件名片段可以在组件记录中标记为丢弃，而归一化的形式主要从保留的结构段重建，这些段用于下游模式构建。 请点击此处查看该图的放大版本。

图7：利用图辅助分析进行注册表密钥IOC归一化。 通过图辅助解析层级注册表结构对注册表密钥IOC进行规范化。简化的根键扩展为规范的注册表蜂巢，分析器提取最长连续的已知注册表子串，同时跳过主机占位符、类似SID的值和类似GUID的标记。输出记录每个保留组件的标签，并生成下游处理的规范注册路径。 请点击此处查看该图的放大版本。

图8：使用图辅助分析的命令行IOC归一化。 原始命令行 IOC 与其归一化表示的比较。该协议在保留引号字符串的同时对命令行进行令牌化，尽可能通过 Neo4j 查找规范化首位命令令牌，并递归分析嵌入的路径类或注册表类片段。稳定的命令相关组件标记为 keep，变量参数标记为 discard，最终规范命令结构则由保留元素重建。 请点击此处查看该图的放大版本。

图9：基于约束的正则表达式候选选择。 每个归一化IOC通过迭代验证流程生成多个正则表达式候选。采用约束驱动的评分机制，选择一个最终正则表达式，既保留指定的捕获组组件，又限制不需要的变量子串。 请点击此处查看该图的放大版本。

图10：提取IOC在CTI报告中的分布。 IOC提取结果摘要，显示CTI报告中识别的指标总数及其在文件路径、注册表键和命令行指示器的分布。该视图提供了CTI内容覆盖率和提取行为的高层验证。 请点击此处查看该图的放大版本。

图11：正则表达式生成过程中优化动作的分布。 正则表达式生成过程中执行的动作分解，包括初始生成、LLM驱动优化和基于重试的再生。LLM驱动的优化占所有动作的51.7%，说明迭代细化是生成满足捕获组约束的正式表达式协议中不可或缺的组成部分。 请点击此处查看该图的放大版本。

图12：代表性导出正则表达式文件。 协议生成的SIEM正则表达式导出（siem_rules.txt）的示例内容。每个条目包含源IOC、推断的类别（文件路径、注册表键或命令行）以及验证后的正则表达式模式。附带的验证表总结了用于确认每种规则类型正确性的预期行为和系统证据。 请点击此处查看该图的放大版本。

图13：代表性完整JSON报告。 在代表性的CTI报告中运行全部五个协议阶段后产生的端到端流水线输出。JSON文档记录源文件、解析后段数、按类别分组的提取IOC、带源标签的第3阶段分类记录、第4阶段规范化差分，以及第5阶段正则表达式模式，并带有每个 IOC 验证标志。报告还揭示了顶层成功和错误元数据，使下游工具能够检测部分失败。 请点击此处查看该图的放大版本。

图14：输入失败或噪声：识别与纠正。 这是协议识别并恢复噪声输入的示例。原始输入 %T E M P%\malware[.]exe 被标记是因为其环境变量令牌包含插入的空格，且文件扩展名已被去牙。修正步骤去除插入的空白并恢复字面点;第四阶段规范化将 %TEMP% 扩展为标准的 Windows 临时目录模板;第五阶段生成一个正则表达式，编译并匹配修正后的归一化 IOC。本例说明了讨论中讨论的噪声输入处理。 请点击此处查看该图的放大版本。

元素	类型	价值 / 模式	示例	注释
节点标签	厂牌	:P	Windows、System32、cmd.exe	存储Windows文件路径组件
节点标签	厂牌	：注册处	软件，Microsoft，Windows NT	将注册密钥组件存储在根蜂箱下方
节点标签	厂牌	：CLI	powershell.exe，-执行策略，绕过	存储命令标记和参数
节点性质	弦	名称	cmd.exe	原装弹壳;用于归一化输出中的显示
节点性质	弦	name_lower	cmd.exe	小写形式;用作所有匹配查询的查找键
关系	定向边	（a）-[：NEXT]->（b）	（Windows）-[：NEXT]->（System32）	两个端点共享相同标签;在Windows系统上编码原生邻接
约束	唯一性	n.name_lower 每个标签的唯一	-	已应用于:P，：Registry，：CLI
数据来源	覆盖范围	Windows 8、10、11	-	客户端操作系统填充到图中
数据来源	覆盖范围	Windows Server 2012， 2016， 2019， 2022	-	服务器操作系统填充到图中

表1：用于IOC规范化的Neo4j图模式（第4阶段）。 列出三个节点标签（路径、注册表、CLI）、它们共享的属性模式（名称、name_lower）、用于原生排序边的有向邻接关系、唯一性约束，以及填充图的 Windows 客户端和服务器版本。

舞台	预期产出	自动验证	面向分析师的质量控制
第一阶段：文档解析	统一的Markdown文本，在LLM处理前分块为4000字符。	—	目视检查Markdown预览，确认文件路径、注册表键、命令行片段和部分边界在解析中依然存在;如果技术字符串被截断，可以切换后端。
第二阶段：卵巢取出	带有三个顶层键（文件路径、命令行、注册表键）的 JSON;启用集合投票时，每个IOC的票数计数和贡献模型元数据。	共识阈值过滤器（min_votes）排除投票数低于配置阈值的国际奥委员。	对被排除的候选人进行检查，以区分幻觉与过于严格的投票，然后再调整min_votes。
第三阶段：IOC分析与分类	分类 IOC 列表：每个 IOC 配对标准化类别、源标签和原始提取密钥（如有）。	通过基于正则表达式的规则和IOC模式启发式进行标准化范畴映射;（IOC，类别）配对重复处理。	对分类输出进行抽查，查找歧义或噪声较大的候选对象（图4A）。
第四阶段：Neo4j辅助正常化	依IOC标准化形式，带有组件级保留/丢弃标签。	对Windows参考图进行密码查询（i）-（iii）;当Neo4j不可用时，确定性预处理的备援。	检查全弃箱以识别图覆盖缺口;在需要时，通过供应商或环境特有的引用扩展图数据。
第五阶段：正则表达式生成与评分	每个IOC的最终正则表达式，包括候选得分、优化历史、迭代次数和每个IOC遥测数据。	匹配测试、静态质量检查、边界感知禁令牌检查、对5个确定性负样本的过度泛化测试;回归得分最高的部分比赛（used_fallback旗）。	备用正则表达式的优化历史回顾;每次故障位置检查后再进行一次故障检查。

表2：阶段输出与验证总结。 将每个协议阶段（1–5）映射到其预期的产物、流水线产生的自动验证证据（正则表达式编译状态、命中率、跨IOC不匹配率、优化迭代次数）以及相应的面向分析师的质量控制检查（视觉比较、淘汰候选物检查和类别审查）。

补充文件1：逐字大语言模型提示。 用于第二阶段IOC提取和第五阶段正则表达式生成与优化的逐字系统和人工提示。请点击这里下载此文件。

补充文件2：第4和第5阶段的实施详情。 支持第四阶段图辅助IOC规范化以及第五阶段正规表达式验证、评分和迭代控制的算法和实现细节。 请点击这里下载此文件。

讨论

将非结构化CTI报告转换为可执行的检测逻辑仍然是运营安全工作流中耗时且易出错的任务。虽然此前尝试过IOC提取或高级规则生成层面的自动化，但从业者在将提取的IOC字符串转换为结构正确、语义精确且适合下游SIEM使用的正则表达式方面仍面临重大挑战。这里展示的协议通过分阶段工作流程填补这一空白，每个阶段产生明确定义的中间工件，并在传递结果前进行显式验证。 图14 记录了一个案例，即被识别、纠正、归一化并转换为编译正则表达式的文件路径;协议的噪声输入处理及其当前范围与下文列举的限制一同讨论。

该协议的核心贡献之一是其将工作流程明确分解为具有可检查中间输出的阶段。实现现在有了具体描述：文档解析生成Markdown和分块文本用于LLM处理;IOC 提取会为文件路径、注册表键和命令行指示符发送结构化的 JSON 文件;基于规则的IOC分析对提取的值进行标准化和去重;Neo4j辅助归一化将每个IOC组件标记为保留或丢弃;正则表达式生成在候选人选择前应用匹配调试、丢弃验证和过度泛化检查。

该协议将正则表达式生成视为迭代构建任务，而非一次性预测问题。该实现采用初始生成提示、自动匹配诊断、受限细化循环和基于组件的评分函数，以保留结构重要的IOC元素，同时惩罚丢弃或未映射的子串。这种迭代设计，结合在每一步应用的确定性验证器，支持在庞大且异构的评估集中生成结构忠实的正则表达式模式。在参考评估中，该工作流程应用于3,156份CTI报告，并与2,400多个独立的真实字符串进行评估，平均命中率为99.1%，平均跨IOC不匹配率为0.8%。由于这些真实字符串是网络安全厂商在MITRE AT&CK评估过程中报告的专家策划的产物，该评估隐含地将协议输出与人工分析师记录的IOC模式进行比较，而非自动生成的。

正如代表性结果所示，当工作流程处理复杂的IOC结构（如嵌套文件路径或长命令行字符串）时，迭代优化尤为重要。参考评估结果还表明，最常见的不匹配案例发生在攻击者使用图数据库中未显示或源CTI报告未明确说明的自定义可执行文件或参数时。在运行中使用中，这些故障模式应被视为预期的边界条件，而非静默错误，并应触发对图覆盖率、源报告完整性和正则式调试遥测的审查。

该方案可与三类替代方法进行比较。首先，基于实例的正则表达式合成方法，如TransRegex¹¹和Regex+¹²，通过策划的正负字符串样本集学习正则表达式。当有代表性示例集时，这些方法表现良好，但在SOC上下文中应用较少，因为CTI中报告的每个IOC通常只显示为一个代表字符串，且所需的泛化边界由操作语义驱动，而非示例覆盖度。其次，像Bartoli等人提出的遗传编程方法（^13,14）通过进化算符搜索正则表达空间，通常需要一个标记的匹配和非匹配字符串语料库;它们非常适合批量构建提取模式，但不会直接消耗无结构的CTI叙事。第三，最新的神经和基于大型语言模型的方法^15,16将自然语言描述直接翻译为正则表达式字符串;这些方法对于明确指定的提示词非常强大，但在单次使用时，可能产生语法有效的正则表达式，却遗漏了所需的捕获群组件，或在无关的 IOC 变体间过度泛化。当前协议补充了这些方向：（i） 输入非结构化的CTI报告，而非精选的示例集或自然语言查询;（ii）在生成任何正则表达式前，通过图辅助归一化将每个IOC分解为保留和丢弃组件;（iii）在有上限迭代循环内通过确定性匹配、丢弃和过度泛化检查验证每个候选正则表达式。其目标不是在自身基准上超越以往方法，而是提供一个可重复的IOC转正则表达式流程，其中间决策可被SOC分析师检查和审计。

该协议对输入CTI报告的质量做出若干假设。它假设：（i） IOC字符串在文档解析后以可恢复的文本形式出现，即文件路径、注册表键和命令行指示符并非仅嵌入在图片、截图或混淆编码中;（ii） CTI 中报告的 IOC 片段足够完整以保留其结构锚点（例如，注册表键保留蜂巢前缀，文件路径保留至少一个 Windows 文档图中可识别的目录锚点，命令行保留调用的可执行文件或已知模块引用）;以及（iii）报告的IOC不会被截断、遮蔽或重写，以去除协议依赖的捕获组组件。满足这些假设的CTI报告包括大多数MITRE AT&CK技术描述、供应商建议、事件响应报告以及格式良好的威胁公告。主要依赖截图、高度简化且缺乏上下文的IOC列表，或没有明确IOC字符串的自由文本释义的报告，超出了预期的操作范围，应预期导致提取调用减少和规范化不够忠实;此类报告在进入流水线前，可能需要上游图像转文本的预处理或分析师审查。

在应用该协议时应考虑若干限制因素。首先，当前的实现侧重于文件路径、注册表键和命令行指示符，而非更广泛的IOC类别，如域、电子邮件伪影、用户代理字符串或行为序列。这是一个刻意的范围选择，因为原子指示符通常通过精确匹配的工作流程很好地服务，而当前协议针对的是受益于正则表达式泛化的变量结构IOC;但它限制了对当前图中未表示的IOC类型的适用性。其次，当前的失败场景主要分为三类：操作系统图中缺失的非原生路径或命令行参数、相关工具或结构的图覆盖不完整，以及当重要的命令片段或命令小子从未报告时，CTI源本身的不完整。第三，参考评估中使用的跨IOC不匹配指标衡量的是生成正则表达式的语义特异性，而非部署SIEM逻辑下的端到端警报误报。

LLM变量和版本控制下的可重复性。由于IOC提取和正则表达式生成阶段依赖于商业LLM端点，两个变量影响可重复性：提供者端模型随时间更新和每次调用采样随机性。为缓解前者问题，材料表中所有与LLM相关的字段均记录精确模型标识符和参考评估时使用的访问日期，协议建议在提供者暴露特定模型快照时钉顶。为缓解第二种问题，参考实现将IOC提取温度固定在0.0，仅在正则表达生成阶段使用非零温度，此时第2和第5阶段的集合投票和确定性验证器吸收残差变异。在复制这些结果时，用户应记录具体模型版本、访问日期、温度和所用集合投票阈值;在这些轴线上出现实质性偏差，都应预期会改变命中率和不匹配指标。

在产生这些故障的阶段层级，可以处理多种可恢复的失效模式。 第一阶段解析失败 （例如，扫描的PDF产生空或混乱的Markdown）：在重新上传前，先用光学字符识别或外部转换器预处理输入;在继续前，请确认解析段的数量和总字符数是否为零。 第二阶段提取失败 （未返回IOC或出现幻觉条目）：提高集合投票门槛（最小投票数≥2），启用更多模型实例，或降低LLM温度;验证API连接性，并且配置的模型是否接受JSON格式输出。 第四阶段规范化，使用所有丢弃标签 （每个IOC组件标记为丢弃）：扩展Neo4j参考图，加入厂商或环境特定的路径组件和注册表根;Cypher 导入脚本和保留/丢弃决策规则列于 补充文件 2 中。 第五阶段正则表达式失败 （used_fallback = true，或重复丢弃验证拒绝）：检查每个IOC优化历史字段以识别失败验证者;如果IOC确实缺乏稳定的keep组件，可以考虑手动为该IOC进行正则表达式编写，或者将其排除在自动规则生成之外，但保留在分类的IOC表中供分析师审查。

符合上述限制，生成的正则表达式最好被视为更广泛的SOC检测内容中的可复用搜索原语，而非自给自足的检测器。在运营环境中，分析师可以将其与平台特定的字段逻辑、白名单、来源检查或相关条件结合，以抑制来自异常但非恶意路径的良性匹配。

未来工作可能包括系统地与人工正则表达式进行比较、对其他IOC类别进行更广泛的评估、结构化分析师反馈研究、扩展攻击者创建的工具和指令运行工具的图覆盖范围，以及更全面地报告不同部署设置的端到端延迟和成本。尽管如此，当前协议提供了一个可重复且操作上可解释的IOC转正则表达式转换框架，既记录了其优势，也记录了当前的局限。

材料

本文使用的材料清单

姓名	公司	目录编号	评论
计算机（CPU）	—	≥ 推荐 4 核	不需要 GPU
LangChain	LangChain	≥ 0.1.x	LLM 编排框架
LLM（IOC 提取，单模型）	OpenAI	gpt-5.1	用于 IOC 提取（第 2 阶段），当集成投票被禁用时。温度 = 0.0；max_workers = 5。访问日期：2025-12-15。
LLM（正则表达式生成）	OpenAI	gpt-5.1	用于正则表达式生成（第 5 阶段）。在下游验证之前温度 = 0.3。访问日期：2025-12-15。
LLM（可扩展性表征）	OpenAI	gpt-5.1	用于在代表性结果中报告的 6,000-IOC 可扩展性运行。访问日期：2025-12-15。
内存（RAM）	—	≥ 推荐 16 GB	用于文档处理
Neo4j	Neo4j, Inc.	≥ 5.x	用于 IOC 规范化的图形数据库
Neo4j Python 驱动程序	Neo4j, Inc.	≥ 5.x	Neo4j 的 Python 接口
操作系统	Microsoft / Apple / Linux	Windows、macOS 或 Linux	跨平台支持
PDF 解析 — 主要后端	Microsoft	MarkItDown ≥ 0.0.x	第 1 阶段后端；将 PDF/DOCX/HTML/TXT 输入转换为 Markdown。解析输出在 LLM 处理前分块为 4,000 个字符。访问日期：2025-12-15。https://github.com/microsoft/markitdown
管道配置（第 2 阶段 — IOC 提取）	—	参考默认值	单 LLM 模式：温度 = 0.0，max_workers = 5。集成投票模式默认值：每个配置的模型重复 = 1，最小投票数 = 2。
管道配置（第 5 阶段 — 正则表达式生成）	—	参考默认值	生成温度 = 0.3。验证：每个 IOC 的 overgen_random_tests = 5 个确定性负样本。迭代限制：max_iterations = 10，debug_loop_cap = 5，discard_validation_cap = 5。
Python	Python 软件基金会	≥ 3.8	所需运行时环境
正则表达式引擎	Python 标准库	re 模块	用于正则表达式验证和测试
Streamlit	Streamlit Inc.	≥ 1.25	基于 Web 的用户界面
参考实现源代码	作者 / GitHub | GitHub 存储库		Streamlit 接口、LangChain 管道、Neo4j 辅助规范化、正则表达式生成、验证实用工具和示例配置文件的源代码。可在 https://github.com/SOCautomatic/cti-ioc-regex-pipeline 获取。访问日期：2026 年 6 月 11 日。