feat(docs): vendor report rules from Kaspersky APT + Huorong malware (#65)
- Add vendor-report-rules.md: 2 flavors only (apt/malware), structure-only - Wire docs-generator SKILL + security-report-templates overlay and IOC gates - Default malware (Huorong-style); apt uses Securelist-style infection chain
This commit is contained in:
yhc
@@ -36,8 +36,22 @@ For writing style, tone, and voice guidance, use `Skill(ce:writer)` with **The E
|
||||
| 渗透测试/漏洞挖掘 | `references/security-report-templates.md` → 渗透测试报告 |
|
||||
| CTF 解题 | `references/security-report-templates.md` → CTF Writeup |
|
||||
| JS/Web 签名逆向 | `references/security-report-templates.md` → 签名逆向报告 |
|
||||
| 恶意软件 / APT / 病毒分析报告 | `references/security-report-templates.md` + **`references/vendor-report-rules.md`** |
|
||||
| 通用技术文档 | `references/templates.md` → README / API 文档 |
|
||||
|
||||
### 厂商报告结构（Issue #65）
|
||||
|
||||
安全类正式报告 **MUST** 叠加 `references/vendor-report-rules.md`（只取结构，不抄厂商原文）：
|
||||
|
||||
| Flavor | 何时用 | 主参考骨架 |
|
||||
|--------|--------|------------|
|
||||
| `malware`（**默认**） | 单样本、木马、白加黑、钓鱼投毒、日常程序分析 | 火绒式：概述→流程→样本分析→应急处置→IOC |
|
||||
| `apt` | APT/战役/团伙/多阶段感染链/行业定向 | 卡巴斯基 Securelist 式：摘要→感染链→调查叙事→Interesting findings→技术分析→检测缓解→IOC |
|
||||
| （无全文 flavor） | 渗透 / CTF / JS 签名 | 原任务模板 + 通用专业元素最小集（摘要、IOC 表可 n/a、建议） |
|
||||
|
||||
原则：**模板在精不在多** —— 仅上述 2 个 flavor，不另建第三套全文模板。
|
||||
与 §0 Evidence→Finding→Path **同时生效**；冲突时 Evidence 契约优先。
|
||||
|
||||
### 输出规范
|
||||
|
||||
- **输出位置**：用户当前项目目录（不是 skill 包目录）
|
||||
@@ -54,6 +68,7 @@ For writing style, tone, and voice guidance, use `Skill(ce:writer)` with **The E
|
||||
- 复现步骤必须让第三方能独立重现
|
||||
- 敏感信息（真实 token、密码、内部 URL）用占位符替代
|
||||
- **MUST** 包含 Evidence → Finding → Path 链（见 `../ops/evidence-finding-path.md` 与模板 §0）
|
||||
- **MUST** 叠加 `references/vendor-report-rules.md`：选定 flavor（默认 `malware`）或任务模板最小集；含概述、IOC 表（可 n/a）、可执行建议
|
||||
- **SHOULD** 引用 case `scope.md` / `timeline.md`（`../scripts/case-init.ps1`）
|
||||
|
||||
### 图表集成
|
||||
@@ -162,6 +177,7 @@ For README, API endpoint, and file organization templates, see [references/templ
|
||||
- `field-journal/` — 报告内容同时作为进化日志的数据来源
|
||||
|
||||
**安全报告模板**: `references/security-report-templates.md`
|
||||
**厂商报告规则**: `references/vendor-report-rules.md`（flavor: malware | apt）
|
||||
**通用文档模板**: `references/templates.md`
|
||||
|
||||
|
||||
|
||||
@@ -29,6 +29,23 @@
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## 0.6 Vendor structure overlay（专业厂商报告结构）
|
||||
|
||||
> 全文规则：`references/vendor-report-rules.md`（Issue #65）
|
||||
> **MUST** 在生成安全类正式报告时读取并选型；**只抽结构，禁止抄录厂商原文/IOC 实例**。
|
||||
|
||||
| Flavor | 场景 | 骨架一句话 |
|
||||
|--------|------|------------|
|
||||
| `malware`（默认） | 普通木马/白加黑/单样本 | 火绒式：概述→流程→样本分析→应急处置→IOC |
|
||||
| `apt` | APT/战役/多阶段链 | 卡巴式：摘要→感染链→调查→Interesting findings→技术分析→检测缓解→IOC |
|
||||
| 无全文 flavor | 渗透/CTF/JS 签名 | 本节任务模板 + 通用元素最小集 |
|
||||
|
||||
**通用元素（G1–G7）摘要**：执行摘要 MUST · Scope MUST · E/F/P MUST · IOC 表 MUST（可 n/a）· 可执行建议 MUST · 附录 SHOULD · ATT&CK SHOULD（apt 建议有表）
|
||||
|
||||
选型与章节顺序以 `vendor-report-rules.md` 为准；与 §0.1–0.5 冲突时 **Evidence 契约优先**。
|
||||
|
||||
## 1. 逆向工程报告模板
|
||||
|
||||
```markdown
|
||||
@@ -58,6 +75,9 @@
|
||||
### 3.1 基本信息
|
||||
<!-- 架构、编译器、保护机制、字符串特征 -->
|
||||
|
||||
### 3.1.1 导入表 / 依赖（二进制 MUST）
|
||||
<!-- 写入 E-imports / E-triage-imports 摘要；失败也要记 Evidence，禁止跳过 -->
|
||||
|
||||
### 3.2 关键函数/类
|
||||
<!-- 列出定位到的关键逻辑，附代码片段 -->
|
||||
|
||||
@@ -99,6 +119,17 @@
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## 1b. 恶意软件 / APT 报告（厂商 flavor）
|
||||
|
||||
当任务为恶意软件分析、病毒报告、APT/战役分析时，**不要**仅用上面「逆向工程」骨架交差：
|
||||
|
||||
1. 读 `vendor-report-rules.md` 选 `malware` 或 `apt`
|
||||
2. 按对应章节顺序输出
|
||||
3. 仍 **MUST** 含 §0 Evidence 链与 IOC 表
|
||||
4. 二进制样本的静态分析 **MUST** 含导入表 Evidence（与 radare2/ida/malware 硬门一致）
|
||||
|
||||
## 2. 渗透测试报告模板
|
||||
|
||||
```markdown
|
||||
|
||||
@@ -0,0 +1,209 @@
|
||||
# Vendor Report Rules（专业厂商报告结构叠加层）
|
||||
|
||||
> Issue #65 问题 2。
|
||||
> **只抽结构与写法规则，禁止抄录任何厂商报告正文、图表、真实 IOC 实例或大段表述。**
|
||||
> 本文件是**叠加层**：不替换 `security-report-templates.md` 的任务模板，也不削弱 §0 Evidence→Finding→Path。
|
||||
|
||||
结构参考（公开样例，仅骨架）：
|
||||
|
||||
| Flavor | 主参考 | 场景 |
|
||||
|--------|--------|------|
|
||||
| `malware`（**默认**） | 火绒安全病毒/技术分析报告 | 普通木马、白加黑、钓鱼投毒、单样本逆向 |
|
||||
| `apt` | 卡巴斯基 Securelist / APT 战役报告（如 MATA） | APT、团伙战役、多阶段感染链、行业定向 |
|
||||
|
||||
原则：**模板在精不在多** —— 仅 2 个 flavor + 1 份通用专业元素，不为第三家厂商再复制全文模板。
|
||||
|
||||
---
|
||||
|
||||
## 0. 何时启用
|
||||
|
||||
在 `docs-generator` 生成**安全类**报告时（逆向 / 恶意软件 / 渗透收尾 / 用户明确要求「专业报告」「厂商风格」）**MUST** 读取本文件并选定 flavor。
|
||||
|
||||
| 信号 | Flavor |
|
||||
|------|--------|
|
||||
| APT / 团伙 / 战役 / 多阶段 C2 / 行业定向 / ICS / spear-phish 战役 | `apt` |
|
||||
| 单样本、木马、窃密、白加黑、仿冒站点、日常程序分析 | `malware`（默认） |
|
||||
| 渗透测试 / CTF / JS 签名 | **不换 flavor 全文骨架**；仍套用下方「通用专业元素」最小集 + 原任务模板 |
|
||||
|
||||
用户显式指定「按卡巴/APT」「按火绒/病毒报告」时，覆盖自动选型。
|
||||
|
||||
---
|
||||
|
||||
## 1. 通用专业元素（所有安全报告）
|
||||
|
||||
下列元素 **SHOULD** 出现；标 **MUST** 的不可省略（可用一行 `n/a` + 原因占位，禁止整节消失）。
|
||||
|
||||
| # | 元素 | 要求 |
|
||||
|---|------|------|
|
||||
| G1 | 执行摘要 / 概述 | **MUST**：3–8 句：分析了什么、最严重结论、影响面、建议动作 |
|
||||
| G2 | 范围与授权 | **MUST**：链到 case `scope.md`（见模板 §0.1） |
|
||||
| G3 | Evidence→Finding→Path | **MUST**：见 `security-report-templates.md` §0 与 `ops/evidence-finding-path.md` |
|
||||
| G4 | IOC 表 | **MUST** 有表头；无指标时一行 `n/a` + 原因（未做流量/无外联等） |
|
||||
| G5 | 建议 / 处置 | **MUST**：至少 1 条可执行建议（检测、缓解或应急步骤） |
|
||||
| G6 | 附录元数据 | **SHOULD**：工具与版本、样本哈希、完整复现命令 |
|
||||
| G7 | ATT&CK 映射 | **SHOULD**（`apt` 下升级为有表可 `n/a` 的硬章节）；技术 ID + 简短证据指针 |
|
||||
|
||||
### 1.1 IOC 表最小列
|
||||
|
||||
```markdown
|
||||
| 类型 | 值 | 上下文 | 置信度 |
|
||||
|------|----|--------|--------|
|
||||
| file_sha256 / file_md5 / domain / ip:port / url / mutex / path / registry | … | 何处发现 | high/med/low |
|
||||
```
|
||||
|
||||
### 1.2 版权与安全边界
|
||||
|
||||
- 不得粘贴厂商 PDF/网页正文段落或图注充作己方分析。
|
||||
- 真实 token、内网 URL、客户标识用占位符。
|
||||
- 未授权目标不得输出可直接利用的攻击步骤细节（遵循 case scope / RULES）。
|
||||
|
||||
---
|
||||
|
||||
## 2. Flavor：`malware`（火绒式 · 默认）
|
||||
|
||||
**叙事目标**：让读者 5 分钟内看懂「是什么 → 怎么来的 → 样本怎么干的 → 怎么处置 → 有哪些 IOC」。
|
||||
|
||||
### 2.1 推荐章节顺序
|
||||
|
||||
```markdown
|
||||
# [标题：一句话威胁定性]
|
||||
|
||||
> 分析日期 / 分析方 / 样本标识（哈希）
|
||||
|
||||
## 1. 概述
|
||||
（G1：发现渠道、伪装手法、核心技术点、产品侧可否查杀——若未知写 n/a）
|
||||
|
||||
## 2. 攻击 / 感染流程
|
||||
（流程图：Mermaid 或分步列表；对应 Path `path_type=attack`）
|
||||
|
||||
## 3. 样本分析
|
||||
### 3.1 样本溯源
|
||||
### 3.2 静态分析
|
||||
（**MUST** 纳入导入表 / 基础身份 Evidence：E-imports 或等价；见 radare2/ida/malware 硬门）
|
||||
### 3.3 动态分析 / 行为
|
||||
（无动态条件则 n/a + 原因）
|
||||
### 3.4 核心发现（Findings 表或编号列表，挂 evidence_ids）
|
||||
|
||||
## 4. 应急处置方式
|
||||
（编号可执行步骤：断网 → 杀进程 → 清文件 → 查 hosts/启动项 → 全盘查杀 → 复核）
|
||||
|
||||
## 5. 总结说明
|
||||
（给普通用户/运维的风险提醒与预防）
|
||||
|
||||
## 6. IOC 信息
|
||||
（G4 表）
|
||||
|
||||
## 7. Evidence 链摘要
|
||||
（§0：E / F / P / Timeline；可与 §3.4 合并但字段不省）
|
||||
|
||||
## 8. 附录
|
||||
（工具版本、复现命令、脚本路径）
|
||||
```
|
||||
|
||||
### 2.2 文风
|
||||
|
||||
- 中文用户默认中文；先结论后细节。
|
||||
- 静态分析按「组件/阶段」分层，避免无结构的长日志粘贴。
|
||||
- 处置步骤必须可独立执行，禁止「加强安全意识」空话充数。
|
||||
|
||||
---
|
||||
|
||||
## 3. Flavor：`apt`（卡巴斯基 Securelist 式）
|
||||
|
||||
**叙事目标**：讲清战役级故事——谁在何时用何链打了谁，调查如何推进，组件如何分工，防守方拿什么去检。
|
||||
|
||||
### 3.1 推荐章节顺序
|
||||
|
||||
```markdown
|
||||
# [战役/集群名称]：[一句话影响]
|
||||
|
||||
> 日期 / 团队 / 行业与地区范围（若可知）
|
||||
|
||||
## 1. Executive summary
|
||||
（G1：时间窗、受害者画像、入口、家族/集群归属、持续时长、最重要结论）
|
||||
|
||||
## 2. The infection chain
|
||||
（分阶段：投递 → exploit/loader → 主马 → 后渗透/窃密；未知段明确 “limited visibility”
|
||||
对应 Path；建议配链图）
|
||||
|
||||
## 3. Incident investigation
|
||||
（调查叙事：关键转折、内网代理/C2 特征、如何扩大范围；挂 Timeline）
|
||||
|
||||
## 4. Interesting findings
|
||||
（3–7 条非显而易见要点，每条尽量挂 E-id / F-id）
|
||||
|
||||
## 5. Technical analysis
|
||||
### 5.1 组件总览表（loader / trojan / stealer / …）
|
||||
### 5.2 分组件行为与配置
|
||||
### 5.3 静态要点（含导入表/加壳/持久化 Evidence）
|
||||
### 5.4 网络与 C2
|
||||
（可附 ATT&CK 表 G7）
|
||||
|
||||
## 6. Detection and mitigation
|
||||
（检测思路 / 狩猎线索 / 缓解优先级；非空泛口号）
|
||||
|
||||
## 7. IOC
|
||||
（G4；按类型分组）
|
||||
|
||||
## 8. Evidence 链摘要
|
||||
（§0 字段）
|
||||
|
||||
## 9. Appendix
|
||||
（样本列表与哈希、工具版本、参考公开编号；不抄外部报告正文）
|
||||
```
|
||||
|
||||
### 3.2 文风
|
||||
|
||||
- 时间线与「可见性限制」要诚实写。
|
||||
- Interesting findings ≠ 重复概述；写调查中真正关键的异常点。
|
||||
- 组件分析用表：角色 / 持久化 / C2 / 依赖，再展开。
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有任务模板的挂接
|
||||
|
||||
| 任务模板（`security-report-templates.md`） | 叠加方式 |
|
||||
|------------------------------------------|----------|
|
||||
| 1. 逆向工程报告 | 默认 `malware`：用 §2 顺序重排；原「静态/动态/复现」并入 §3/附录；**保留**导入表等硬门产出为 Evidence |
|
||||
| 2. 渗透测试报告 | 不套 APT 全文；补 G1（若缺）、G4（若有基础设施 IOC）、G5；攻击路径对齐 §0 Path |
|
||||
| 3. CTF Writeup | 仅 G1 一句概述 + 可复现；不强制 IOC/ATT&CK |
|
||||
| 4. JS/Web 签名逆向 | 默认偏 `malware` 精简：概述 → 定位 → 算法 → 复现 → IOC(n/a 常见) |
|
||||
| 恶意软件 / APT 专项 | 显式选 `malware` 或 `apt` 全文骨架 |
|
||||
|
||||
**冲突解决**：§0 Evidence 链字段与 scope 门禁 **永远优先**；flavor 只改叙事顺序与专业外壳，不得删除 E/F/P。
|
||||
|
||||
---
|
||||
|
||||
## 5. 选型伪代码
|
||||
|
||||
```
|
||||
if user_requests_kaspersky or apt or campaign:
|
||||
flavor = apt
|
||||
elif user_requests_huorong or vir_report or single_malware:
|
||||
flavor = malware
|
||||
elif task in (pentest, ctf, js_sign):
|
||||
flavor = null # 任务模板 + 通用元素最小集
|
||||
else:
|
||||
flavor = malware # 默认
|
||||
emit(report with G1–G7 and flavor outline)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 完成检查清单（写报告末自检）
|
||||
|
||||
- [ ] 已选 flavor 或显式「任务模板 + 最小集」
|
||||
- [ ] G1 概述存在且非空话
|
||||
- [ ] §0 E/F/P 字段完整
|
||||
- [ ] IOC 表存在（或 n/a+原因）
|
||||
- [ ] 有可执行建议/处置
|
||||
- [ ] 无厂商原文粘贴、无 placeholder/TODO
|
||||
- [ ] 导入表等硬门 Evidence 已进入静态/技术分析（若本任务做过二进制分析）
|
||||
|
||||
---
|
||||
|
||||
## 7. 非目标
|
||||
|
||||
- 不维护 Mandiant/CrowdStrike/奇安信等额外全文模板（结构已由双 flavor 覆盖常见需求）。
|
||||
- 不自动爬取厂商站点填报告。
|
||||
- 不因 flavor 降低 Evidence 契约或授权范围。
|
||||
Reference in New Issue
Block a user