Leeyoonjoo/Malware_triage
GitHub: Leeyoonjoo/Malware_triage
一个将恶意软件分析流程标准化、可复现化的团队协作学习框架，通过统一的 JSON Schema 和六阶段分析流水线实现从样本输入到自动报告生成的完整闭环。
Stars: 0 | Forks: 0
# Malware_triage
## 项目定义
### 概要
将恶意软件分析从“单独样本解谜”转变为可重现分析流程（pipeline）标准化的项目式学习
### 目的
不仅仅是为了“通过工具得出结果”，而是要同时为团队和成员个人确立以下能力：
- 个人能力
- 能够基于证据通过静态/动态分析判断风险等级。
- 能够将产出物制作成**结构化数据（JSON）**，并以此为依据撰写简明准确的报告。
- 能够提取并规范化 IOC，实现从“分析 -> 响应”的衔接。
- 团队能力
- 任何人都能通过相同的步骤执行，生成相同目录结构的报告。（可重现性）
- 使用统一的 schema 整合静态/动态/IOC，创建可比较、可扩展的数据资产。
- 通过实战型产出物（checklist/README/template）建立可协作、可交接的体系。
### 达成目标
使用相同流程处理 3~5 个样本，自动生成具有相同章节结构的报告。
- input : 样本
- ouput : checklist + 模块化 JSON + 最终报告（基于模板自动生成）
静态/动态/IOC 产出物整合为通用的 JSON schema。
环境、流程通过 README + checklist 文档化，即使团队成员变更也能重现。
💡使用 Schema 的原因
- Schema 是“关于数据存储格式的约定”
- 本项目中的 Schema 用于以下 3 点
1. **整合**：如果静态/动态/IOC 格式不一致，则无法自动生成报告
2. **可重现性**：只有当每个人都在相同的字段中记录相同含义的内容时，才能进行比较和自动化
3. **扩展性**：即使将来工具/日志发生变化，Schema 作为“契约”也能保证整体架构不崩塌
## 2. 整体流程定义
各阶段旨在同时生成**个人学习产出物**和**团队通用产出物**。
### 2.1 Stage 0. Governance（治理/安全/可重现性基础）
- 产出物:
- 样本处理策略（隔离/保管/禁止共享范围）
- 执行环境标准（虚拟环境/快照）
- 版本记录（工具版本、OS、配置）
- 意义：分析质量的 50% 取决于“流程”。
### 2.2 Stage 1. Intake（导入/识别/记录）
- 输入: 样本文件（PE）+ 可选日志/PCAP
- 处理:
- 分配 SHA256/文件元数据/样本 ID
- 分离原始文件与工作副本，自动记录工作日志
- 输出（JSON）:
- `sample` 部分（哈希、大小、类型、提交日期、存储路径等）
### 2.3 Stage 2. Static（静态分析）
- 处理:
- PE 头/节/导入/签名/熵/资源
- 字符串提取及分类（URL/域名/路径/注册表键候选）
- 加壳怀疑（基于证据规则，可进行简单评分）
- 输出（JSON）:
- `static` 部分（节/导入/熵/字符串 artifacts/假设）
### 2.4 Stage 3. Dynamic（动态分析）
- 原则: 禁止环境复杂化，固定最小项目
- 处理:
- 进程树、文件/注册表变更、网络连接
- 执行前后快照对比（以变更点为中心）
- 输出（JSON）:
- `dynamic` 部分（process_tree, file_ops, reg_ops, net_ops, timeline）
### 2.5 Stage 4. IOC/Signature（规范化/提升至检测视角）
- 处理:
- 从静态/动态中提取 IOC → 按类型规范化/去重
- （可选）YARA 草案：以稳定特征为中心 + 简单测试记录
- 输出（JSON）:
- `iocs` 部分（域名/IP/URL/路径/哈希/注册表键等）
- （可选） `signatures` 部分（YARA, 测试结果）
### 2.6 Stage 5. Assessment & Recommendations（判断/处置）
- 处理:
- 风险等级（LOW/MED/HIGH）、置信度、依据
- 建议（Containment/Eradication/Hardening）
- 输出（JSON）:
- `assessment`, `recommendations` 部分
### 2.7 Stage 6. Report（基于模板自动生成）
- 处理:
- 通用 JSON → 模板渲染
- 输出:
- 最终报告 + 附录（日志链接/工具版本/环境）
# 1周
# 2周
1week
## 第1周 ： 团队通用结构达成共识
目标 ： 各自准备 schema 草案材料，在第1周会议上确定 v0.1
### 1) 制作 1 个 Minimal v0.1 虚拟 JSON
目的 ： 让每个人提出能够支撑自动报告的最小结构
方法 ： 无需实际分析，可用虚拟值填充（未知值使用 null/[]）
提交物 ： analysis_result.json 1个（虚拟数据）
#### 我的 Minimal v0.1 的基本原则
1. 仅包含必填字段
2. 最小化嵌套结构
3. 类型明确
4. 看起来像真实值，但示例保持简单
- 字段说明
- schema/version : 确保将来格式变更时的解析/兼容性
- sample_id : 样本识别（内部 ID）
- hashes : 重新识别同一样本的核心
- source : 样本来源（如邮件、EDR、URL、取证等）
- timstamps : 记录何时接收、何时分析
- triage : 当前阶段的结论、优先级、状态
- artifacts : 最基本的 1~2 个 IOC，如文件名路径
### 2) 编写 10 个字段字典
编写 10 个你认为必须的字段
1. `shema_version`(string) → Triage JSON schema 版本，用于将来结构变更时保持兼容性
2. `sample_id`(string) → 内部 Triage 系统中使用的样本唯一标识符
3. `sha256`(string) → 恶意软件样本的 SHA-256 哈希值，用于样本再识别和去重
4. `file_name`(string) → 分析对象的原始文件名
5. `file_path`(string) → 样本在系统中被发现的路径
6. `source`(string) → 样本流入途径
7. `ingested_at`(string) → 样本被收集到 Triage 系统的时间
8. `verdict`(string) → 1 次 Triage 判定结果（benign, suspicious, malicious, unknow）
9. `severity`(string) → 威胁严重程度
10. `analyst_note` → 分析师留下的简要判断依据或备注
# Team Common v0.1
Team Common v0.1
这是第1周时整合各队员 schema 后的版本。
本 schema 并非 DB schema，而是将恶意软件分析结果标准化为 analysis_result.json 格式，
旨在共享和比较团队内结果，自动生成报告，并为后续 v0.2 扩展提供数据契约
### v0.1 的设计目标
- 固定报告不崩溃所需的 10 个最小必填字段
- 区分“分析失败/未确定”与“无结果”，使用 null vs []
- 禁止省略字段以最小化解析器异常
## 1. 数据类型规则
- `string`: UTF-8 字符串
- `number`: 允许整数/实数（分数建议使用整数）
- `array`: JSON 数组
- `null`: 表示未产出/未确定/失败
## 2. 顶层结构（固定）
v0.1 中以下字段必须全部存在！
- `meta`
- `sample`
- `summary`
- `static`
- `dynamic`
- `iocs`
- `assessment`
注意：v0.1 仅强制“必填 10 项”，但这些字段所属的上级对象（如 meta/sample/summary/static/dynamic/iocs/assessment）也必须同时存在，报告才能稳定。
## 3. 必填字段定义
| # | field_path | type | meaning | example | missing_rule |
| --- | --- | --- | --- | --- | --- |
| 1 | meta.schema_version | string | 此 JSON 遵循的 schema 版本 | `"0.1.0"` | 必填，禁止省略，禁止 null |
| 2 | sample.sha256 | string | 样本唯一识别哈希 | `"0123...cdef"` | 必填，禁止省略，禁止 null |
| 3 | sample.filename | string | null | 原始文件名 | `"invoice.exe"` | 如未知则 `null`（禁止省略） |
| 4 | summary.verdict | string | 最终判定（用于标签） | `"unknown"` | 必填，无法产出时为 `"unknown"` |
| 5 | summary.malicious_score | number | null | 风险/恶意分数（区分 0 和 null） | `72` | 未定/未产出则为 `null` |
| 6 | static.imports | array | 静态分析 Import 列表（至少包含 DLL/函数名） | `["kernel32.dll"]` | 无结果则 `[]` |
| 7 | dynamic.process_tree | array | 动态分析进程树 | `[{"pid":1234,"name":"sample.exe"}]` | 无结果则 `[]` |
| 8 | dynamic.network.connections | array | 观察到的网络连接列表 | `[{"dst_ip":"1.2.3.4","dst_port":443,"protocol":"TCP"}]` | 无结果则 `[]` |
| 9 | iocs.domains | array | 域名 IOC 列表 | `["samplesite.com"]` | 无结果则 `[]` |
| 10 | assessment.severity | string | 最终危险等级 | `"HIGH"` | 必填，无法判断时为 `"UNKNOWN"` |
## 4. 缺失规则（团队通用） — 详细版本
### 4.1 使用 null 的情况（unknown / not-yet / failed）
- 字段**必须存在**，但因以下原因值未确定时使用 `null`。
- 未产出（尚未计算/提取）
- 分析失败（工具崩溃、权限不足、超时）
- 环境限制（沙箱未配置、网络阻断等）
- 主要在**标量字段**中使用。
例如： `summary.malicious_score: null`, `sample.filename: null`
### 4.2 使用 [] 的情况
- 分析/收集正常执行，但**确认该事项不存在**时使用空数组 `[]`。
- 例如：未观察到网络通信 → `dynamic.network.connections: []`
### 4.3 省略
- v0.1 中 **10 个必填字段禁止省略**
- 此外，上级块的基本原则也是不省略。
## 5. 推荐枚举/规范化规则
- `summary.verdict`: `malicious | suspicious | benign | unknown`
- `assessment.severity`: `LOW | MEDIUM | HIGH | CRITICAL | UNKNOWN`
## 6. 扩展规则（可选）
为便于 v0.1 后扩展，建议将工具依赖字段或实验性结果按以下形式添加。
- 添加在 `extensions..<...>` 下
- 保持独立命名空间，不破坏 v0.1 必填字段
2week
## 第2周 ： PE 静态分析通用理解 + 基于 v0.1 schema 的 1 次实践
### 1) “PE 静态分析能告诉我们什么” 总结（参考 report/2주차_report.pdf）
以以下 4 个观点为中心，各项目总结 3~6 行左右。
#### ① 节
- 代码/数据如何分布，节名/数量/权限是否正常
- **异常节名、异常多/少的节数量**可能成为信号
#### ② 导入表
- 基于使用的 DLL/API 推测**可能的行为（网络/注册表/进程/加密等）**
- 但导入表与其说是“证据”，不如视为**生成假设的线索**
#### ③ 签名
- 数字签名是判断信任的线索，但**并非绝对标准**
- （有签名 ≠ 一定正常 / 无签名 ≠ 一定恶意）
#### ④ 熵
- 指示压缩/加密/加壳可能性的指标
- **高熵 ≠ 确定加壳，仅作为‘怀疑线索’**使用
### 2) “通过导入表推测功能” 选择整理 10 项（参考 report/2주차_report.pdf）
按以下格式选择整理 10 个导入（或 DLL）
目标 ： 让团队快速共享“看到这个导入表该怀疑什么”
- import(or dll)
- 推测功能
- 为什么这样看（依据）
- 误判可能性/注意事项
### 3) 加壳怀疑规则 v0.1初学者用） - 基于证据的标志提议 （参考 report/2주차_report.pdf）
不使用“结论”，仅使用基于证据的标志。
从以下示例中至少选择 2 个，说明“为什么要怀疑”。
- 存在高熵节
- 节名异常（看起来像无意义字符串/随机数）
- 导入表过于贫乏（几乎没有可分析的 API）
- 字符串过少（显著低于平均值）
### 4) 实践(1) - “填充 static 结果” （参考 report/2주차_report_1.pdf）
对 1 个自选样本（必选）执行 Intake + Static，并按团队通用 v0.1 schema 编写 JSON
（实际值不确定的字段应用 null/[] 规则）
- 提交物： `v0.1_<姓名>_analysis_result.json` （1 个）
#### 推荐检查点
- `meta.schema_version`, `sample.sha256` 必填是否存在
- `static.imports` / `dynamic.*` / `iocs.*` 等处 **[] vs null 规则是否一致**
- 生成报告时是否有会导致解析器崩溃的字段缺失（必填 10 项禁止省略）
### 5) 实践(2) - 填充 static 结果 （参考 report/2주차_report_1.pdf）
对通用样本（`study_sample.exe`）也尽可能执行 Static，并用相同 schema（v0.1）编写 JSON
（目标：对比观察同一样本时，队员们的“基于导入表的假设”和“加壳怀疑标志”有何不同）
- 提交物（可选）： `v0.1_<姓名>_common_sample_analysis_result.json`
标签：Conpot, DAST, HTTPX, IOC提取, JSON Schema, PE文件分析, Windows安全, 云安全监控, 分析报告自动化, 可重现分析, 合规性检查, 威胁情报, 安全团队协作, 安全工作流, 安全数据分析, 库, 应急响应, 开发者工具, 恶意软件分析, 标准化流程, 样本分析, 结构化数据, 网络安全, 自动化分析管道, 逆向工具, 隐私保护, 静态分析