j-junong/intel-triage
GitHub: j-junong/intel-triage
一款利用 LLM 提取、确定性逻辑验证和评分的网络威胁情报分类工具，可将威胁报告自动转化为经过验证的 STIX 2.1 bundle 和分析师简报。
Stars: 0 | Forks: 0
# AI 辅助的威胁情报分类
一款 AI 辅助的网络威胁情报分类工具，能够摄取威胁报告，提取 IoC 指标和 ATT&CK 技术，通过权威外部来源对其进行验证和富化，使用确定性逻辑对其进行评分，并生成经过验证的 STIX 2.1 bundle 以及人类可读的分析简报。
## 核心设计原则
LLM 负责提取和总结威胁报告。外部 API 提供基础事实依据。模型绝不：
- 判定某个 IoC 指标是否恶意
- 断言某项技术存在
- 引入检索数据中不存在的事实
每一项此类声明都由模型无法影响的检查机制强制执行。
## 示例输出
有关针对 CISA 公告 [AA23-353A (#StopRansomware: ALPHV Blackcat)](https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-353a) 的完整运行结果，请参见 [`output/`](output/)：
- `bundle.json` - 一个经过验证的 STIX 2.1 bundle，可被 TIP 或 SIEM 摄取
- `report.md` - 一份包含已消亡处理（defanged）IoC 指标表的分析师简报
## 架构
```
flowchart TD
A[Report URL or file] --> B[Guarded ingestion]
B --> C[HTML to text]
C --> D[Regex IOC extraction
deterministic baseline] C --> E[LLM extraction
IOCs + ATT&CK techniques] E --> F[Pydantic validation wall] D --> G{Suppression
cross-check} F --> G F --> H[MITRE verification
via TAXII] H --> I[Reputation enrichment
VirusTotal / AbuseIPDB / GreyNoise] I --> J[Deterministic scoring
no LLM] J --> K[Grounded summarisation] K --> L{Grounding check} L --> M[STIX 2.1 bundle] L --> N[Markdown brief] ``` | 阶段 | 模块 | 作用 | |---|---|---| | 摄取 | `ingest.py` | 获取 URL 或文件，包含大小、超时、协议和 Content-Type 防护 | | 基线提取 | `extract.py` | Regex IOC 提取与消亡处理规范化（确定性） | | LLM 提取 | `llm_extract.py` | 提出带上下文的 IOC 以及候选技术 ID | | 验证 | `llm_extract.py` | 使用 Pydantic schema 检查格式错误或超出 schema 的输出 | | 注入触发器 | `llm_extract.py` | 将 LLM 输出与 regex 基线进行对比以检测隐瞒 | | ATT&CK 验证 | `attack.py` | 根据本地缓存，对照 MITRE 的 TAXII server 解析每一个技术 ID | | 富化 | `enrich.py` | 查询信誉 API，而不是查询 IoC 指标本身 | | 评分 | `score.py` | 确定性、可审计的严重程度和置信度（无 LLM 参与） | | 总结 | `summarise.py` | 严格基于计算数据的分析师简报，并带有溯源检查 | | 输出 | `output.py`, `cli.py` | STIX 2.1 bundle 和 markdown 简报 | ## 威胁模型 此工具处理攻击者相关的内容，并生成供他人采取行动的情报。明确针对三类风险进行了设计。 ### 1. 不可信输入 威胁报告是任意的互联网内容。摄取模块假设远程主机可能具有敌意： - 协议白名单（仅限 `http`/`https`） — 阻止 `file://` 及类似协议 - 显式的连接和读取超时 — 恶意服务器无法挂起该工具 - 带有严格大小上限的流式下载 — 在读取正文*之前*而非*之后*防止内存耗尽 - 解析前进行 Content-Type 检查 - `raise_for_status()` 确保错误页面永远不会被静默分析为报告 **绝不触碰 IoC 指标。**该工具获取的是*报告*；它从不解析、连接或请求在报告*内部*发现的任何 IoC 指标。富化是向数据库查询*关于*某个 IoC 指标的信息。联系攻击者基础设施会出现在对手的日志中，并可能向分析师生成恶意软件。 作为本地 CLI，不存在 SSRF 暴露风险，因为由操作者选择 URL。如果部署为服务，则需要在 DNS 解析和重定向跟随*之后*阻止私有和链路本地范围。 ### 2. 提示词注入 报告可能包含旨在劫持 LLM 的文本。例如，指示其隐瞒某个 IoC 指标或篡改摘要。隐瞒是危险的情况，因为被删除的 IoC 指标在模型输出中不会留下任何痕迹。 防御措施，按强度排序： 1. **通道分离。**工具指令位于 System Prompt 中。报告文本仅存在于 user message 中，并被声明为不可信数据，绝不作为指令。 2. **Regex 交叉检查（主要控制）。**确定性提取器在每份报告上运行。提示词注入可以与 LLM 对话；但它无法与 `re.finditer` 对话。任何被 Regex 发现但未在 LLM 输出中出现的 IoC 指标都会引发隐瞒警告。这并不能阻止攻击。它消除了攻击的隐蔽性，而这正是隐瞒危险的原因所在。 3. **`injection_attempts` 字段。**指示模型引用任何试图向其发出指令的文本。这将攻击转化为一种*发现*：正常报告不包含针对机器的指令。**弱点：**它依赖于模型自我报告，因此成功的劫持也可能隐瞒关于劫持的报告。它被视为一种有用的信号，而非一种控制手段。 针对一份专门构建的恶意报告进行了验证（`tests/` 回归覆盖范围）：注入被成功抵御，并在 `injection_attempts` 中被引用，且在模拟隐瞒时，触发器被单独证明会触发。 ### 3. 幻觉 | 失败情况 | 捕获方式 | 残余风险 | |---|---|---| | 响应截断 | `stop_reason == "max_tokens"` 防护 | 无 | | 非 JSON / 带围栏输出 | `json.loads`，加上 assistant prefill 和停止序列 | 无 | | 有效 JSON，无效结构 | Pydantic schema + 字段验证器 | 无 | | 不存在的技术 ID | MITRE TAXII 存在性检查 | 无 | | 过时的技术名称 | 名称取自 MITRE，绝不取自模型 | 无 | | 简报中虚构的 IOC / CVE | 溯源检查（对源数据进行 Regex） | 无 | | **真实技术，映射错误或不完整** | **无自动化措施** | **需要人工审查** | | **过度的散文解释** | **无自动化措施** | **需要人工审查** | 自动化检查验证声明指的是否是*真实*的东西；只有人类才能验证这是否是*正确*的声明。`evidence` 字段是每一项提议技术必须提供的逐字报告引用，其存在旨在通过将声明和来源并列，使这种人工审查成为可能。 ## 评估 ### 技术提取完整性（2 份报告，2 个模型层级） 针对 CISA [ALPHV/BlackCat 公告](https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-353a) 和一份 [DFIR Report](https://thedfirreport.com/) 的入侵文章进行了测试。 **发现：**模型能可靠地提取在其描述点被明确标记的技术，并始终漏掉那些仅作为散文行为描述的*影响/目标*技术。 | 报告 | 标记的技术 | 漏掉的技术 | |---|---|---| | ALPHV 公告（内联 `[T1234]` 标签） | 全部正确提取 | **T1486** Data Encrypted for Impact | | DFIR Report（章节标题中的技术 ID） | 34/34 全部正确提取 | **T1496** Resource Hijacking, **T1041** Exfiltration Over C2, **T1071.001** Web Protocols | 在这两种情况下，确认底层的真实行为已存在于工具提取的输入中（通过 grep 验证），排除了摄取缺口。在 DFIR 案例中，模型*确实*提取了加密货币挖矿行为，但将其映射到了相邻技术 (T1546.004) 而非 T1496。因此，该失败属于完整性和恰当性问题，而非感知问题。 值得注意的是，DFIR 报告在文档底部的摘要表中以纯文本形式列出了 T1041 和 T1496。模型并**没有**从那里提取它们，这表明它是从散文中映射行为而不是抓取标签，并且其行为映射对影响技术存在特定的盲区。 ### 模型对比 ALPHV 样本分别通过 Claude Haiku 4.5 和 Claude Opus 4.8 进行了运行。两者生成了等效的技术映射，并且都漏掉了 T1486。由于完整性缺口在更高能力层级并未缩小，这被视为 LLM 提取的结构性限制，而非模型选择问题。出于成本考虑，**保留 Haiku 作为默认选项**，并且无论使用哪种模型，完整性审查都保留给人类分析师执行。 ## 限制 ### 技术完整性 请参阅上文的评估。在散文中描述但未明确标记的影响技术存在提取不足的情况。需要人工审查。 ### 溯源涵盖事实，而非解释 溯源检查验证简报中的每一个技术 ID、IP 和 CVE 是否出现在源数据中。它无法验证诸如“这表明存在勒索软件活动”之类的散文声明是否恰当，因为这需要理解能力而不是模式匹配。 ### GreyNoise 免费层级不可用 经过身份验证的 Community 层级密钥对 `64.39.104.22`（这是 GreyNoise 自己记录的示例 IP）的 `business_service_intelligence` 和 `internet_scanner_intelligence` 均返回 `found: false`，并且 SDK 报告“Quick Lookup not supported with Community offering”。GreyNoise 的 Community API 指南、v2→v3 迁移矩阵和 v3 API 页面在免费层级访问权限上相互矛盾。该集成已实现，并且在使用付费密钥时可以正常工作。同时，通过 ISP 归属、VirusTotal 无害计数以及评分层中明确的白名单，来近似实现良性基础设施检测。 ### 评分阈值是主观判断 VirusTotal 的检测层级、置信度深度阈值以及双重用途上限都是明确的人工决策，而非经验推导的结果。它们被刻意设计为可见且可测试的，而不是学习得来的。 ### MITRE 缓存永不过期 ATT&CK 数据在首次获取后会被无限期缓存。`load_techniques(refresh=True)` 会强制重新获取。生产环境的部署需要进行陈旧度检查。 ### LLM IOC 提取与 Regex 层冗余 LLM IOC 提取与 Regex 层功能冗余，并且在 IOC 密集的报告中占据输出 token 的主导地位（一份包含 100 多个哈希值的报告超出了 8,000 个 token 的上限）。LLM 阶段合理地可以仅限定于提取技术。 ### 输出大小有上限 非常大的报告可能会被截断，这会被 `stop_reason` 防护机制明确捕获，而不是静默失败。 ### 未经测试的区域 摄取层（特别是大小防护）、TAXII 缓存以及 CLI 的端到端路径没有自动化覆盖。 ## 设置 ``` git clone https://github.com/j-junong/intel-triage.git cd intel-triage python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt cp .env.example .env # Add your keys ``` ### API 密钥 所有密钥都是可选的。该工具会正常运行，并报告哪些来源不可用，而不是直接失败。即使完全没有密钥它也能运行，尽管富化结果将为空。 | 服务 | 环境变量 | 免费层级 | 备注 | |---|---|---|---| | Anthropic | `ANTHROPIC_API_KEY` | 按量付费 | LLM 提取和总结所必需 | | VirusTotal | `VIRUSTOTAL_API_KEY` | 4 次请求/分钟，500 次/天 | 主要富化来源；自带节流 | | AbuseIPDB | `ABUSEIPDB_API_KEY` | 1,000 次/天 | IP 信誉和 ISP 归属 | | GreyNoise | `GREYNOISE_API_KEY` | 见限制 | 可选；免费层级不返回数据 | | MITRE ATT&CK | — | 公开，无密钥 | TAXII 2.1 位于 `attack-taxii.mitre.org` | 密钥通过 `python-dotenv` 从环境中读取。`.env` 被 gitignored，且从未被提交过。 ### 如何运行 ``` python3 -m src.intel_triage.cli --file report.txt -o output python3 -m src.intel_triage.cli --url https://example.com/report -o output ``` 运行时间主要受限于 VirusTotal 的 4 次请求/分钟的速率限制——大约每个唯一的 IoC 指标需要 15 秒。白名单中的 IoC 指标会在任何 API 调用之前短路返回。 ### 测试 ``` python3 -m pytest tests/ -v ``` 19 个测试，完全离线。HTTP 使用 `responses` 进行 Mock，因此不需要 API 密钥，并且测试套件可以在没有密钥的情况下在 CI 中运行。 ## 备注 作为学习项目构建。其目的是理解*为什么*每个设计决策很重要，而不是尽可能快地组装一个可运行的 pipeline，因此在添加 LLM 后仍保留了确定性的 Regex 基线，采用了刻意简单化的评分层，并记录了上述限制。
deterministic baseline] C --> E[LLM extraction
IOCs + ATT&CK techniques] E --> F[Pydantic validation wall] D --> G{Suppression
cross-check} F --> G F --> H[MITRE verification
via TAXII] H --> I[Reputation enrichment
VirusTotal / AbuseIPDB / GreyNoise] I --> J[Deterministic scoring
no LLM] J --> K[Grounded summarisation] K --> L{Grounding check} L --> M[STIX 2.1 bundle] L --> N[Markdown brief] ``` | 阶段 | 模块 | 作用 | |---|---|---| | 摄取 | `ingest.py` | 获取 URL 或文件，包含大小、超时、协议和 Content-Type 防护 | | 基线提取 | `extract.py` | Regex IOC 提取与消亡处理规范化（确定性） | | LLM 提取 | `llm_extract.py` | 提出带上下文的 IOC 以及候选技术 ID | | 验证 | `llm_extract.py` | 使用 Pydantic schema 检查格式错误或超出 schema 的输出 | | 注入触发器 | `llm_extract.py` | 将 LLM 输出与 regex 基线进行对比以检测隐瞒 | | ATT&CK 验证 | `attack.py` | 根据本地缓存，对照 MITRE 的 TAXII server 解析每一个技术 ID | | 富化 | `enrich.py` | 查询信誉 API，而不是查询 IoC 指标本身 | | 评分 | `score.py` | 确定性、可审计的严重程度和置信度（无 LLM 参与） | | 总结 | `summarise.py` | 严格基于计算数据的分析师简报，并带有溯源检查 | | 输出 | `output.py`, `cli.py` | STIX 2.1 bundle 和 markdown 简报 | ## 威胁模型 此工具处理攻击者相关的内容，并生成供他人采取行动的情报。明确针对三类风险进行了设计。 ### 1. 不可信输入 威胁报告是任意的互联网内容。摄取模块假设远程主机可能具有敌意： - 协议白名单（仅限 `http`/`https`） — 阻止 `file://` 及类似协议 - 显式的连接和读取超时 — 恶意服务器无法挂起该工具 - 带有严格大小上限的流式下载 — 在读取正文*之前*而非*之后*防止内存耗尽 - 解析前进行 Content-Type 检查 - `raise_for_status()` 确保错误页面永远不会被静默分析为报告 **绝不触碰 IoC 指标。**该工具获取的是*报告*；它从不解析、连接或请求在报告*内部*发现的任何 IoC 指标。富化是向数据库查询*关于*某个 IoC 指标的信息。联系攻击者基础设施会出现在对手的日志中，并可能向分析师生成恶意软件。 作为本地 CLI，不存在 SSRF 暴露风险，因为由操作者选择 URL。如果部署为服务，则需要在 DNS 解析和重定向跟随*之后*阻止私有和链路本地范围。 ### 2. 提示词注入 报告可能包含旨在劫持 LLM 的文本。例如，指示其隐瞒某个 IoC 指标或篡改摘要。隐瞒是危险的情况，因为被删除的 IoC 指标在模型输出中不会留下任何痕迹。 防御措施，按强度排序： 1. **通道分离。**工具指令位于 System Prompt 中。报告文本仅存在于 user message 中，并被声明为不可信数据，绝不作为指令。 2. **Regex 交叉检查（主要控制）。**确定性提取器在每份报告上运行。提示词注入可以与 LLM 对话；但它无法与 `re.finditer` 对话。任何被 Regex 发现但未在 LLM 输出中出现的 IoC 指标都会引发隐瞒警告。这并不能阻止攻击。它消除了攻击的隐蔽性，而这正是隐瞒危险的原因所在。 3. **`injection_attempts` 字段。**指示模型引用任何试图向其发出指令的文本。这将攻击转化为一种*发现*：正常报告不包含针对机器的指令。**弱点：**它依赖于模型自我报告，因此成功的劫持也可能隐瞒关于劫持的报告。它被视为一种有用的信号，而非一种控制手段。 针对一份专门构建的恶意报告进行了验证（`tests/` 回归覆盖范围）：注入被成功抵御，并在 `injection_attempts` 中被引用，且在模拟隐瞒时，触发器被单独证明会触发。 ### 3. 幻觉 | 失败情况 | 捕获方式 | 残余风险 | |---|---|---| | 响应截断 | `stop_reason == "max_tokens"` 防护 | 无 | | 非 JSON / 带围栏输出 | `json.loads`，加上 assistant prefill 和停止序列 | 无 | | 有效 JSON，无效结构 | Pydantic schema + 字段验证器 | 无 | | 不存在的技术 ID | MITRE TAXII 存在性检查 | 无 | | 过时的技术名称 | 名称取自 MITRE，绝不取自模型 | 无 | | 简报中虚构的 IOC / CVE | 溯源检查（对源数据进行 Regex） | 无 | | **真实技术，映射错误或不完整** | **无自动化措施** | **需要人工审查** | | **过度的散文解释** | **无自动化措施** | **需要人工审查** | 自动化检查验证声明指的是否是*真实*的东西；只有人类才能验证这是否是*正确*的声明。`evidence` 字段是每一项提议技术必须提供的逐字报告引用，其存在旨在通过将声明和来源并列，使这种人工审查成为可能。 ## 评估 ### 技术提取完整性（2 份报告，2 个模型层级） 针对 CISA [ALPHV/BlackCat 公告](https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-353a) 和一份 [DFIR Report](https://thedfirreport.com/) 的入侵文章进行了测试。 **发现：**模型能可靠地提取在其描述点被明确标记的技术，并始终漏掉那些仅作为散文行为描述的*影响/目标*技术。 | 报告 | 标记的技术 | 漏掉的技术 | |---|---|---| | ALPHV 公告（内联 `[T1234]` 标签） | 全部正确提取 | **T1486** Data Encrypted for Impact | | DFIR Report（章节标题中的技术 ID） | 34/34 全部正确提取 | **T1496** Resource Hijacking, **T1041** Exfiltration Over C2, **T1071.001** Web Protocols | 在这两种情况下，确认底层的真实行为已存在于工具提取的输入中（通过 grep 验证），排除了摄取缺口。在 DFIR 案例中，模型*确实*提取了加密货币挖矿行为，但将其映射到了相邻技术 (T1546.004) 而非 T1496。因此，该失败属于完整性和恰当性问题，而非感知问题。 值得注意的是，DFIR 报告在文档底部的摘要表中以纯文本形式列出了 T1041 和 T1496。模型并**没有**从那里提取它们，这表明它是从散文中映射行为而不是抓取标签，并且其行为映射对影响技术存在特定的盲区。 ### 模型对比 ALPHV 样本分别通过 Claude Haiku 4.5 和 Claude Opus 4.8 进行了运行。两者生成了等效的技术映射，并且都漏掉了 T1486。由于完整性缺口在更高能力层级并未缩小，这被视为 LLM 提取的结构性限制，而非模型选择问题。出于成本考虑，**保留 Haiku 作为默认选项**，并且无论使用哪种模型，完整性审查都保留给人类分析师执行。 ## 限制 ### 技术完整性 请参阅上文的评估。在散文中描述但未明确标记的影响技术存在提取不足的情况。需要人工审查。 ### 溯源涵盖事实，而非解释 溯源检查验证简报中的每一个技术 ID、IP 和 CVE 是否出现在源数据中。它无法验证诸如“这表明存在勒索软件活动”之类的散文声明是否恰当，因为这需要理解能力而不是模式匹配。 ### GreyNoise 免费层级不可用 经过身份验证的 Community 层级密钥对 `64.39.104.22`（这是 GreyNoise 自己记录的示例 IP）的 `business_service_intelligence` 和 `internet_scanner_intelligence` 均返回 `found: false`，并且 SDK 报告“Quick Lookup not supported with Community offering”。GreyNoise 的 Community API 指南、v2→v3 迁移矩阵和 v3 API 页面在免费层级访问权限上相互矛盾。该集成已实现，并且在使用付费密钥时可以正常工作。同时，通过 ISP 归属、VirusTotal 无害计数以及评分层中明确的白名单，来近似实现良性基础设施检测。 ### 评分阈值是主观判断 VirusTotal 的检测层级、置信度深度阈值以及双重用途上限都是明确的人工决策，而非经验推导的结果。它们被刻意设计为可见且可测试的，而不是学习得来的。 ### MITRE 缓存永不过期 ATT&CK 数据在首次获取后会被无限期缓存。`load_techniques(refresh=True)` 会强制重新获取。生产环境的部署需要进行陈旧度检查。 ### LLM IOC 提取与 Regex 层冗余 LLM IOC 提取与 Regex 层功能冗余，并且在 IOC 密集的报告中占据输出 token 的主导地位（一份包含 100 多个哈希值的报告超出了 8,000 个 token 的上限）。LLM 阶段合理地可以仅限定于提取技术。 ### 输出大小有上限 非常大的报告可能会被截断，这会被 `stop_reason` 防护机制明确捕获，而不是静默失败。 ### 未经测试的区域 摄取层（特别是大小防护）、TAXII 缓存以及 CLI 的端到端路径没有自动化覆盖。 ## 设置 ``` git clone https://github.com/j-junong/intel-triage.git cd intel-triage python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt cp .env.example .env # Add your keys ``` ### API 密钥 所有密钥都是可选的。该工具会正常运行，并报告哪些来源不可用，而不是直接失败。即使完全没有密钥它也能运行，尽管富化结果将为空。 | 服务 | 环境变量 | 免费层级 | 备注 | |---|---|---|---| | Anthropic | `ANTHROPIC_API_KEY` | 按量付费 | LLM 提取和总结所必需 | | VirusTotal | `VIRUSTOTAL_API_KEY` | 4 次请求/分钟，500 次/天 | 主要富化来源；自带节流 | | AbuseIPDB | `ABUSEIPDB_API_KEY` | 1,000 次/天 | IP 信誉和 ISP 归属 | | GreyNoise | `GREYNOISE_API_KEY` | 见限制 | 可选；免费层级不返回数据 | | MITRE ATT&CK | — | 公开，无密钥 | TAXII 2.1 位于 `attack-taxii.mitre.org` | 密钥通过 `python-dotenv` 从环境中读取。`.env` 被 gitignored，且从未被提交过。 ### 如何运行 ``` python3 -m src.intel_triage.cli --file report.txt -o output python3 -m src.intel_triage.cli --url https://example.com/report -o output ``` 运行时间主要受限于 VirusTotal 的 4 次请求/分钟的速率限制——大约每个唯一的 IoC 指标需要 15 秒。白名单中的 IoC 指标会在任何 API 调用之前短路返回。 ### 测试 ``` python3 -m pytest tests/ -v ``` 19 个测试，完全离线。HTTP 使用 `responses` 进行 Mock，因此不需要 API 密钥，并且测试套件可以在没有密钥的情况下在 CI 中运行。 ## 备注 作为学习项目构建。其目的是理解*为什么*每个设计决策很重要，而不是尽可能快地组装一个可运行的 pipeline，因此在添加 LLM 后仍保留了确定性的 Regex 基线，采用了刻意简单化的评分层，并记录了上述限制。
标签：AI辅助分析, DLL 劫持, Python, STIX, 大语言模型, 威胁情报, 开发者工具, 无后门, 自动化分类, 逆向工具