reverse-skills-max: initial public release (restored, redacted, hardened)
This commit is contained in:
baradok609hecl1pq6qi
@@ -0,0 +1,338 @@
|
||||
# 安全/逆向/渗透技术文档模板
|
||||
|
||||
本文件提供逆向工程、渗透测试、漏洞分析等安全类项目的文档模板。任务完成后，AI 应在用户项目目录下新建文档并按对应模板输出。
|
||||
|
||||
---
|
||||
|
||||
## 0. Evidence Chain（所有安全报告 MUST 包含）
|
||||
|
||||
> 契约全文：`skills/ops/evidence-finding-path.md`
|
||||
> Case 目录：`work/<case>/`（`case-init.ps1`）
|
||||
|
||||
报告正文中 **MUST** 含以下章节（可并入「核心发现」但字段不得省略）：
|
||||
|
||||
### 0.1 Scope 摘要
|
||||
- 链到 `scope.md`：`auth` / `in_scope` / `network_profile`
|
||||
- 无 scope → 不得宣称任务完成
|
||||
|
||||
### 0.2 Evidence
|
||||
至少 1 条，字段：`E-id` / `source_ref` / `repro_command` / `content_hash|n/a`
|
||||
|
||||
### 0.3 Findings
|
||||
每条：`F-id` / `severity|n/a_re` / `evidence_ids` / `confidence` / `location` / `status`
|
||||
|
||||
### 0.4 Path
|
||||
至少 1 条 `P-id`：`path_type=attack|callflow|solve`，步骤可挂 E/F
|
||||
|
||||
### 0.5 Timeline 摘要
|
||||
链到 `timeline.md` 或嵌入关键 3–10 条追加记录
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## 0.6 Vendor structure overlay（专业厂商报告结构）
|
||||
|
||||
> 全文规则：`references/vendor-report-rules.md`（Issue #65）
|
||||
> **MUST** 在生成安全类正式报告时读取并选型；**只抽结构，禁止抄录厂商原文/IOC 实例**。
|
||||
|
||||
| Flavor | 场景 | 骨架一句话 |
|
||||
|--------|------|------------|
|
||||
| `malware` | 明确恶意样本/普通木马/白加黑 | 火绒式：概述→流程→样本分析→应急处置→IOC |
|
||||
| `apt` | APT/战役/多阶段链 | 卡巴式：摘要→感染链→调查→Interesting findings→技术分析→检测缓解→IOC |
|
||||
| `flavor = null` | 普通逆向/渗透/CTF/JS 签名 | 本节任务模板 + 适用的 Base 通用元素 |
|
||||
|
||||
**通用元素（G1–G7）摘要**：G1 执行摘要 MUST · G2 Scope MUST · G3 E/F/P MUST · G4 IOC 仅 `malware`/`apt` MUST · G5 建议仅 `malware`/`apt` MUST · G6 附录 SHOULD · G7 ATT&CK 在 `apt` MUST
|
||||
|
||||
选型与章节顺序以 `vendor-report-rules.md` 为准；与 §0.1–0.5 冲突时 **Evidence 契约优先**。
|
||||
|
||||
## 1. 逆向工程报告模板
|
||||
|
||||
```markdown
|
||||
# [目标名称] 逆向分析报告
|
||||
|
||||
> 分析日期：YYYY-MM-DD
|
||||
> 分析人员：[AI / 人工]
|
||||
> 工具链：[jadx / IDA / radare2 / Frida / ...]
|
||||
|
||||
## 1. 目标概述
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|---|
|
||||
| 文件名 | |
|
||||
| 文件类型 | APK / ELF / PE / Mach-O / ... |
|
||||
| 大小 | |
|
||||
| MD5 | |
|
||||
| SHA256 | |
|
||||
| 包名/入口 | |
|
||||
|
||||
## 2. 分析目标
|
||||
|
||||
<!-- 本次逆向要回答的核心问题 -->
|
||||
|
||||
## 3. 静态分析
|
||||
|
||||
### 3.1 基本信息
|
||||
<!-- 架构、编译器、保护机制、字符串特征 -->
|
||||
|
||||
### 3.1.1 导入表 / 依赖（二进制 MUST）
|
||||
<!-- 写入 E-imports / E-triage-imports 摘要；失败也要记 Evidence，禁止跳过 -->
|
||||
|
||||
### 3.2 关键函数/类
|
||||
<!-- 列出定位到的关键逻辑，附代码片段 -->
|
||||
|
||||
### 3.3 加密/签名算法
|
||||
<!-- 如果涉及加密，说明算法、密钥来源、参数构造 -->
|
||||
|
||||
## 4. 动态分析
|
||||
|
||||
### 4.1 Hook 记录
|
||||
<!-- Frida / xposed / 其他 hook 的目标和结果 -->
|
||||
|
||||
### 4.2 运行时行为
|
||||
<!-- 网络请求、文件操作、进程行为 -->
|
||||
|
||||
## 5. 核心发现
|
||||
|
||||
<!-- 用编号列出关键结论 -->
|
||||
|
||||
1. ...
|
||||
2. ...
|
||||
3. ...
|
||||
|
||||
## 6. 复现步骤
|
||||
|
||||
<!-- 让其他人能重现你的分析结果 -->
|
||||
|
||||
```bash
|
||||
# 关键命令
|
||||
```
|
||||
|
||||
## 7. 遗留问题
|
||||
|
||||
<!-- 没有完全解决的点 -->
|
||||
|
||||
## 8. 附件
|
||||
|
||||
<!-- hook 脚本、解密代码、截图等 -->
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## 1b. 恶意软件 / APT 报告（厂商 flavor）
|
||||
|
||||
当任务为恶意软件分析、病毒报告、APT/战役分析时，**不要**仅用上面「逆向工程」骨架交差；普通逆向任务保持原模板，不自动选择 vendor flavor：
|
||||
|
||||
1. 读 `vendor-report-rules.md` 选 `malware` 或 `apt`
|
||||
2. 按对应章节顺序输出
|
||||
3. 仍 **MUST** 含 §0 Evidence 链；`malware` / `apt` flavor 另 **MUST** 含 IOC 表
|
||||
4. 二进制样本的静态分析 **MUST** 含导入表 Evidence（与 radare2/ida/malware 硬门一致）
|
||||
|
||||
## 2. 渗透测试报告模板
|
||||
|
||||
```markdown
|
||||
# [目标] 渗透测试报告
|
||||
|
||||
> 测试日期：YYYY-MM-DD
|
||||
> 测试范围：[URL / IP / 应用名]
|
||||
> 授权状态：[已授权 / CTF / 学习环境]
|
||||
|
||||
## 1. 执行摘要
|
||||
|
||||
<!-- 一段话总结：测试了什么、发现了什么、风险等级 -->
|
||||
|
||||
## 2. 测试范围
|
||||
|
||||
| 项目 | 详情 |
|
||||
|------|------|
|
||||
| 目标 | |
|
||||
| 测试类型 | 黑盒 / 灰盒 / 白盒 |
|
||||
| 测试时间 | |
|
||||
| 工具 | |
|
||||
|
||||
## 3. 发现汇总
|
||||
|
||||
| # | 漏洞名称 | 风险等级 | 状态 |
|
||||
|---|---------|---------|------|
|
||||
| 1 | | 高/中/低/信息 | 已验证/待确认 |
|
||||
|
||||
## 4. 漏洞详情
|
||||
|
||||
### 4.1 [漏洞名称]
|
||||
|
||||
**风险等级**：高 / 中 / 低
|
||||
|
||||
**描述**：
|
||||
|
||||
**影响**：
|
||||
|
||||
**复现步骤**：
|
||||
|
||||
1. ...
|
||||
2. ...
|
||||
3. ...
|
||||
|
||||
**证据**：
|
||||
|
||||
```
|
||||
<!-- 请求/响应/截图/payload -->
|
||||
```
|
||||
|
||||
**修复建议**：
|
||||
|
||||
## 5. 攻击路径
|
||||
|
||||
<!-- 如果有完整攻击链，画出路径 -->
|
||||
|
||||
```
|
||||
入口 → 信息收集 → 漏洞利用 → 权限提升 → 目标达成
|
||||
```
|
||||
|
||||
## 6. 工具与环境
|
||||
|
||||
| 工具 | 版本 | 用途 |
|
||||
|------|------|------|
|
||||
| | | |
|
||||
|
||||
## 7. 修复建议总结
|
||||
|
||||
| 优先级 | 建议 |
|
||||
|--------|------|
|
||||
| P0 | |
|
||||
| P1 | |
|
||||
| P2 | |
|
||||
|
||||
## 8. 附录
|
||||
|
||||
<!-- 完整 payload、脚本、配置文件等 -->
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. CTF Writeup 模板
|
||||
|
||||
```markdown
|
||||
# [比赛名] - [题目名] Writeup
|
||||
|
||||
> 分类：Web / Reverse / Pwn / Crypto / Misc / Forensics
|
||||
> 难度：Easy / Medium / Hard
|
||||
> 分值：N pts
|
||||
> 解题时间：
|
||||
|
||||
## 题目描述
|
||||
|
||||
<!-- 原题描述 -->
|
||||
|
||||
## 解题思路
|
||||
|
||||
### 第一步：信息收集
|
||||
<!-- 观察到了什么 -->
|
||||
|
||||
### 第二步：漏洞/突破口
|
||||
<!-- 找到了什么关键点 -->
|
||||
|
||||
### 第三步：利用
|
||||
<!-- 怎么利用的 -->
|
||||
|
||||
## 关键代码/Payload
|
||||
|
||||
```python
|
||||
# exploit code
|
||||
```
|
||||
|
||||
## Flag
|
||||
|
||||
```
|
||||
flag{...}
|
||||
```
|
||||
|
||||
## 踩坑记录
|
||||
|
||||
<!-- 走过的弯路 -->
|
||||
|
||||
## 知识点
|
||||
|
||||
<!-- 这道题涉及的知识点，方便后续复习 -->
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. JS/Web 签名逆向报告模板
|
||||
|
||||
```markdown
|
||||
# [站点/应用] 签名参数逆向报告
|
||||
|
||||
> 分析日期：YYYY-MM-DD
|
||||
> 目标接口：[URL]
|
||||
> 签名字段：[字段名]
|
||||
|
||||
## 1. 目标请求
|
||||
|
||||
```http
|
||||
POST /api/xxx HTTP/1.1
|
||||
Host: example.com
|
||||
|
||||
param1=xxx&sign=<目标字段>
|
||||
```
|
||||
|
||||
## 2. 定位过程
|
||||
|
||||
### 2.1 断点/Hook 方式
|
||||
<!-- 怎么找到签名生成位置的 -->
|
||||
|
||||
### 2.2 调用栈
|
||||
<!-- 关键调用链 -->
|
||||
|
||||
## 3. 算法还原
|
||||
|
||||
### 3.1 算法类型
|
||||
<!-- HMAC-SHA256 / AES / 自定义 / ... -->
|
||||
|
||||
### 3.2 参数构造
|
||||
<!-- 哪些字段参与签名、排序规则、分隔符 -->
|
||||
|
||||
### 3.3 密钥来源
|
||||
<!-- 硬编码 / 接口返回 / 时间戳派生 / ... -->
|
||||
|
||||
## 4. 本地复现代码
|
||||
|
||||
```javascript
|
||||
// Node.js 复现
|
||||
```
|
||||
|
||||
## 5. 验证结果
|
||||
|
||||
<!-- 用复现代码生成的签名与实际请求对比 -->
|
||||
|
||||
## 6. 反爬/风控注意事项
|
||||
|
||||
<!-- 频率限制、设备指纹、环境检测等 -->
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 文档输出规范
|
||||
|
||||
### 输出位置
|
||||
|
||||
- 文档默认输出到**用户当前项目目录**（不是 skill 包目录）
|
||||
- 文件名格式：`YYYY-MM-DD_[类型]-[目标简称]-report.md`
|
||||
- 如果用户项目有 `docs/` 目录，优先放在 `docs/` 下
|
||||
|
||||
### 输出时机
|
||||
|
||||
AI 在以下时机自动调用本 skill 生成文档：
|
||||
|
||||
1. 逆向任务完成，已产出核心结论
|
||||
2. 渗透测试完成，已发现并验证漏洞
|
||||
3. CTF 题目解出，已拿到 flag
|
||||
4. 用户明确要求"写一份报告/文档"
|
||||
|
||||
### 质量要求
|
||||
|
||||
- 所有代码块必须可直接运行或有明确上下文
|
||||
- 不要有 placeholder/TODO（如果某部分确实未完成，标注"待补充"并说明原因）
|
||||
- 关键发现必须有证据支撑（命令输出、截图描述、代码片段）
|
||||
- 复现步骤必须让第三方能独立重现
|
||||
102
reverse-skill-repo/skills/docs-generator/references/templates.md
Normal file
102
reverse-skill-repo/skills/docs-generator/references/templates.md
Normal file
@@ -0,0 +1,102 @@
|
||||
# Documentation Templates
|
||||
|
||||
## Contents
|
||||
|
||||
- [README.md](#readmemd)
|
||||
- [API Endpoint Documentation](#api-endpoint-documentation)
|
||||
- [File System Organization](#file-system-organization)
|
||||
|
||||
## README.md
|
||||
|
||||
```markdown
|
||||
# Project Name
|
||||
|
||||
One-line description of what this does.
|
||||
|
||||
## Quick Start
|
||||
|
||||
\`\`\`bash
|
||||
yarn install && yarn dev
|
||||
\`\`\`
|
||||
|
||||
## Installation
|
||||
|
||||
Step-by-step setup.
|
||||
|
||||
## Usage
|
||||
|
||||
\`\`\`typescript
|
||||
import { thing } from "package";
|
||||
const result = thing.doSomething();
|
||||
\`\`\`
|
||||
|
||||
## Configuration
|
||||
|
||||
| Variable | Required | Default | Description |
|
||||
| --------- | -------- | ------- | ------------ |
|
||||
| `API_KEY` | Yes | - | Your API key |
|
||||
|
||||
## Documentation
|
||||
|
||||
- [API Reference](./docs/api/README.md)
|
||||
- [Architecture](./docs/architecture/overview.md)
|
||||
```
|
||||
|
||||
## API Endpoint Documentation
|
||||
|
||||
```markdown
|
||||
# Resource Name
|
||||
|
||||
Brief description.
|
||||
|
||||
## GET /resource
|
||||
|
||||
Retrieves resources.
|
||||
|
||||
**Parameters**
|
||||
|
||||
| Name | Type | Required | Description |
|
||||
| ------- | ------ | -------- | ------------------------- |
|
||||
| `limit` | number | No | Max results (default: 20) |
|
||||
|
||||
**Response**
|
||||
|
||||
\`\`\`json
|
||||
{
|
||||
"data": [...],
|
||||
"total": 100
|
||||
}
|
||||
\`\`\`
|
||||
|
||||
**Example**
|
||||
|
||||
\`\`\`typescript
|
||||
const { data } = await api.get("/resource", { limit: 10 });
|
||||
\`\`\`
|
||||
|
||||
**Errors**
|
||||
|
||||
| Status | Code | Description |
|
||||
| ------ | ---------------- | ------------------------ |
|
||||
| 400 | `INVALID_PARAMS` | Invalid query parameters |
|
||||
| 401 | `UNAUTHORIZED` | Missing or invalid auth |
|
||||
```
|
||||
|
||||
## File System Organization
|
||||
|
||||
```
|
||||
/docs
|
||||
├── README.md # Docs index
|
||||
├── /api
|
||||
│ ├── README.md # API overview
|
||||
│ ├── authentication.md
|
||||
│ └── {resource}.md
|
||||
├── /architecture
|
||||
│ ├── overview.md
|
||||
│ └── data-flow.md
|
||||
├── /guides
|
||||
│ ├── getting-started.md
|
||||
│ └── troubleshooting.md
|
||||
└── /features
|
||||
└── {NNN}-{feature}.md
|
||||
```
|
||||
@@ -0,0 +1,218 @@
|
||||
# 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 份通用专业元素；普通逆向、渗透、CTF 和 JS 报告保持任务模板，不默认伪装成恶意软件报告。
|
||||
|
||||
---
|
||||
|
||||
## 0. 何时启用
|
||||
|
||||
在 `docs-generator` 生成**安全类**报告时（逆向 / 恶意软件 / 渗透收尾 / 用户明确要求「专业报告」「厂商风格」）**MUST** 读取本文件。只有任务证据或用户明确要求支持时才选择厂商 flavor；否则使用 `flavor = null`，仅叠加通用专业元素和原任务模板。
|
||||
|
||||
| 信号 | Flavor |
|
||||
|------|--------|
|
||||
| APT / 团伙 / 战役 / 多阶段 C2 / 行业定向 / ICS / spear-phish 战役 | `apt` |
|
||||
| 明确恶意样本、木马、窃密、白加黑、仿冒站点 | `malware` |
|
||||
| 普通 APK/ELF/PE/Mach-O 逆向、算法分析、固件分析、渗透测试、CTF、JS 签名 | `flavor = null`；使用原任务模板和通用专业元素最小集 |
|
||||
|
||||
用户显式指定「按卡巴/APT」「按火绒/病毒报告」时，覆盖自动选型。
|
||||
|
||||
---
|
||||
|
||||
## 1. 通用专业元素（Base）
|
||||
|
||||
下列 Base 元素按报告类型应用。标 **MUST** 的不可省略；与特定 flavor 相关的元素不得为了填模板而出现在无关任务中。没有适用内容时，使用 `n/a` 并说明原因。
|
||||
|
||||
| # | 元素 | 要求 |
|
||||
|---|------|------|
|
||||
| G1 | 执行摘要 / 概述 | **MUST**：3–8 句：分析了什么、最严重结论、影响面、建议动作 |
|
||||
| G2 | 范围与授权 | **MUST**：链到 case `scope.md`（见模板 §0.1） |
|
||||
| G3 | Evidence→Finding→Path | **MUST**：见 `security-report-templates.md` §0 与 `skills/ops/evidence-finding-path.md` |
|
||||
| G4 | IOC 表 | `malware` / `apt` **MUST**；其他任务仅在存在相关指标时出现 |
|
||||
| G5 | 建议 / 处置 | `malware` / `apt` **MUST**：至少 1 条可执行建议；其他任务按原任务模板 |
|
||||
| G6 | 附录元数据 | **SHOULD**：工具与版本、样本哈希、完整复现命令 |
|
||||
| G7 | ATT&CK 映射 | **MUST**（`apt` 下；无适用技术时 `n/a` + 原因）；其他任务 **SHOULD** |
|
||||
|
||||
### 1.1 IOC 表最小列
|
||||
|
||||
```markdown
|
||||
| 类型 | 值 | 上下文 | 首次/最后发现 | 来源证据 | 置信度 |
|
||||
|------|----|--------|---------------|----------|--------|
|
||||
| file_sha256 / file_md5 / domain / ip:port / url / mutex / path / registry | … | 何处发现 | YYYY-MM-DD / n/a | E-id | 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. 应急处置方式
|
||||
（仅在授权范围内执行：先确认 scope 并保全样本、内存、进程树、网络连接和日志等证据，再隔离主机；经负责人批准后再终止进程、隔离/清除文件、检查 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. 逆向工程报告 | 默认 `flavor = null`，保留原「静态/动态/复现」骨架和导入表等硬门 Evidence；只有明确恶意样本才套 §2 |
|
||||
| 2. 渗透测试报告 | `flavor = null`；补 Base 中适用的 G1–G3，攻击路径对齐 §0 Path，不强制 IOC |
|
||||
| 3. CTF Writeup | `flavor = null`；保留原题目、解题思路和复现结构，不强制 IOC/ATT&CK |
|
||||
| 4. JS/Web 签名逆向 | `flavor = null`；使用原概述 → 定位 → 算法 → 复现骨架，不套 malware |
|
||||
| 恶意软件 / APT 专项 | 显式选 `malware` 或 `apt` 全文骨架 |
|
||||
|
||||
**冲突解决**：§0 Evidence 链字段与 scope 门禁 **永远优先**；flavor 只改叙事顺序与专业外壳，不得删除 E/F/P。
|
||||
|
||||
---
|
||||
|
||||
## 5. 选型伪代码
|
||||
|
||||
```
|
||||
if user_requests_kaspersky or apt or threat_campaign:
|
||||
flavor = apt
|
||||
elif user_requests_huorong or vir_report or explicit_malware:
|
||||
flavor = malware
|
||||
else:
|
||||
flavor = null # 原任务模板 + Base 中适用的元素
|
||||
emit(base_report)
|
||||
if flavor in (malware, apt):
|
||||
emit(report with flavor outline)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 完成检查清单（写报告末自检）
|
||||
|
||||
- [ ] 已选 flavor 或显式「任务模板 + 最小集」
|
||||
- [ ] G1 概述存在且非空话
|
||||
- [ ] §0 E/F/P 字段完整
|
||||
- [ ] `malware` / `apt` 报告有 IOC 表（或 n/a+原因）
|
||||
- [ ] `malware` / `apt` 报告有可执行建议/处置
|
||||
- [ ] 无 flavor 的任务没有被套入 malware/APT 专属章节
|
||||
- [ ] 无厂商原文粘贴、无 placeholder/TODO
|
||||
- [ ] 导入表等硬门 Evidence 已进入静态/技术分析（若本任务做过二进制分析）
|
||||
|
||||
---
|
||||
|
||||
## 7. 来源登记
|
||||
|
||||
- Kaspersky Securelist, “Updated MATA attacks industrial companies in Eastern Europe”: <https://securelist.com/updated-mata-attacks-industrial-companies-in-eastern-europe/110829>（结构参考；访问日期：2026-08-11）
|
||||
- 火绒安全公开技术文章入口：<https://www.huorong.cn/>（站点入口；访问日期：2026-08-11。具体文章 URL、标题和访问日期应在实际引用时登记）
|
||||
- ATT&CK 技术编号仅作为规范化映射，必须由本次 Evidence 支撑；不得把外部报告中的 IOC 自动带入当前报告。
|
||||
|
||||
---
|
||||
|
||||
## 8. 非目标
|
||||
|
||||
- 不维护 Mandiant/CrowdStrike/奇安信等额外全文模板（结构已由双 flavor 覆盖常见需求）。
|
||||
- 不自动爬取厂商站点填报告。
|
||||
- 不因 flavor 降低 Evidence 契约或授权范围。
|
||||
Reference in New Issue
Block a user