Digho007/soc-detection-response-pipeline
GitHub: Digho007/soc-detection-response-pipeline
基于 Wazuh 和 TheHive 构建的端到端 SOC 检测与事件响应流水线，通过 Atomic Red Team 对手模拟验证了五条映射 MITRE ATT&CK 的自定义检测规则。
Stars: 0 | Forks: 0
# SOC 检测与事件响应流水线
### Wazuh SIEM + TheHive 案例管理 + Atomic Red Team 对手模拟
[](https://wazuh.com)
[](https://strangebee.com)
[](https://atomicredteam.io)
[](https://attack.mitre.org)
[]()
[](LICENSE)
一个双节点、云端部署的 SOC 流水线，可检测映射到 MITRE ATT&CK 的对手技术，并将其升级为分析师可直接处理的案例 —— 实现从攻击者技术执行到案例管理平台中经过分拣告警的端到端流程。
本项目作为在 Digiss 安全实习期间的动手工程项目构建，该仓库记录了完整的部署过程：架构决策、自定义检测规则工程、自定义 Wazuh 到 TheHive 的集成，以及跨 5 个 ATT&CK 映射用例的验证测试（全部 5/5 通过）。
## 为什么做这个项目
大多数“SIEM 教程”项目仅仅停留在安装仪表板。本项目更进一步：它构建了完整的检测**流水线** —— 遥测生成 → 收集 → 关联 → 告警 → 案例升级 —— 这与托管安全服务提供商（MSSP）使用的工作流相同，并记录了沿途遇到的每一个非平凡的工程决策和失败（在 8GB 主机上跨 3 个并发 JVM 的资源争用、静默的集成失败、HOCON 配置怪癖、已弃用的 Ubuntu 包签名方法等等）。
## 架构
```
┌─────────────────────┐ Atomic Red Team executes ┌──────────────────────────────┐
│ attack-range │ an ATT&CK technique │ soc-core │
│ (monitored endpoint)│──────────────────────────────────────▶ │ (SIEM + IR platform) │
│ │ auditd/Sysmon → Wazuh Agent │ │
│ • Wazuh Agent │ ships log over TCP 1514/1515 │ • Wazuh Manager │
│ • auditd │──────────────────────────────────────▶ │ • Wazuh Indexer │
│ • Atomic Red Team │ │ • Wazuh Dashboard │
└─────────────────────┘ │ • custom-w2thive integration │
│ • TheHive + Cassandra + │
Wazuh rule fires (level ≥ 10) │ dedicated Elasticsearch │
─────────────────────────────────────▶ │ • TheHive Alert Queue │
└──────────────────────────────┘
```
**数据流：** ART 技术执行 → 原始 auditd/Sysmon 事件 → Wazuh Agent → Wazuh Manager（规则评估）→ Wazuh 告警（level ≥ 10）→ `custom-w2thive` 集成脚本 → TheHive 告警。
关于双节点拆分、端口选择和安全组设计的完整理由，请参阅[工程报告的架构部分](docs/ENGINEERING_REPORT.md#2-architecture-overview)。
## 检测用例（5/5 已验证）
| # | 技术 | ATT&CK ID | 检测方式 | 规则 ID |
|---|---|---|---|---|
| 1 | 发现 / 枚举 | T1082 / T1087 | 匹配枚举二进制文件的 `audit.command` | 100010 |
| 2 | 可疑的编码执行 | T1059 | 匹配 base64/`-enc` 模式的 `audit.command` | 100011 |
| 3 | 凭据转储尝试 | T1003 | 针对 `/etc/passwd`、`/etc/shadow` 的 `audit.key = identity` 文件监控 | 100012 |
| 4 | 计划任务 / 持久化 | T1053 | 匹配 `crontab`/`schtasks` 的 `audit.command` | 100013 |
| 5 | C2 式出站连接 | T1071 | 匹配 `nc`/`curl`/`wget` 的 `audit.command` | 100014 |
每种技术均使用 Atomic Red Team 执行，并在 `audit.log` 中确认，在 Wazuh 中确认为已触发的告警，并在 TheHive 中确认为已升级的告警。完整的验证方法和证据：[`docs/VALIDATION.md`](docs/VALIDATION.md)。
## 仓库结构
```
.
├── README.md this file
├── docs/
│ ├── ENGINEERING_REPORT.md full write-up: design rationale, build phases, challenges
│ ├── VALIDATION.md per-technique validation methodology & results table
│ └── TROUBLESHOOTING.md symptom-based runbook
├── rules/
│ └── local_rules.xml custom Wazuh detection rules (5 ATT&CK-mapped)
├── integrations/
│ ├── custom-w2thive.py Wazuh → TheHive alert bridge (Python, thehive4py)
│ └── custom-w2thive shell wrapper Wazuh invokes to run the script
├── screenshots/ placeholders — see below
└── LICENSE
```
## 快速开始（复现此构建）
1. 准备两台 Ubuntu 22.04 主机（`soc-core`、`attack-range`）—— 规格特点和安全组规则详见 [docs/ENGINEERING_REPORT.md § 阶段 0](docs/ENGINEERING_REPORT.md#3-phase-0---pre-flight-preparation)。
2. 在 `soc-core` 上安装 Wazuh（Manager + Indexer + Dashboard）—— [阶段 1](docs/ENGINEERING_REPORT.md#4-phase-1---wazuh-installation-soc-core)。
3. 在 `attack-range` 上安装 Wazuh Agent + auditd + Atomic Red Team —— [阶段 2](docs/ENGINEERING_REPORT.md#5-phase-2---agent-and-telemetry-setup-attack-range)。
4. 在 `soc-core` 上安装 TheHive（+ Cassandra + 专用 Elasticsearch）—— [阶段 3](docs/ENGINEERING_REPORT.md#6-phase-3---thehive-deployment-soc-core)。
5. 将 [`rules/local_rules.xml`](rules/local_rules.xml) 放入 `/var/ossec/etc/rules/`，并将 [`integrations/`](integrations) 中的集成脚本放入 `/var/ossec/integrations/` —— [阶段 4](docs/ENGINEERING_REPORT.md#7-phase-4---detection-use-cases-rule-engineering-and-integration)。
6. 运行五种 Atomic Red Team 技术并进行端到端验证 —— [阶段 5](docs/ENGINEERING_REPORT.md#8-phase-5---validation-and-testing-attack-range)。
## 解决的关键工程挑战
- **在 8GB 主机上跨 3 个并发 JVM 服务的资源争用** —— 通过分配 swap + 限制堆内存（Indexer 1GB，Cassandra 512MB，TheHive 及其 Elasticsearch 各 512MB）解决。
- **文件名/配置不匹配导致的静默集成失败** —— 构建过程中最耗时的 bug：`ossec.conf` 中的 `` 与集成脚本文件名不匹配，导致 Wazuh 在*完全没有报错的情况下*丢弃了 TheHive 移交。
- **TheHive 中的 HOCON 配置合并行为** —— `application.conf` 中重复的顶层块会静默应用失败，导致 JanusGraph 回退到错误的 Elasticsearch 端口。
- **Ubuntu 弃用了 `apt-key`** —— 每个第三方仓库（Wazuh、Cassandra、Elasticsearch）都需要使用现代的 `gpg --keyring` + `signed-by` 模式。
- **Wazuh 自带 Python 中损坏的 `pip` 垫片** —— 通过将 `pip` 作为模块调用（`python3 -m pip`）而不是使用损坏的脚本来解决。
有关上述各项的详细信息，包括根因推理：[docs/ENGINEERING_REPORT.md § 10](docs/ENGINEERING_REPORT.md#10-challenges--engineering-decisions---summary)。
## 截图
原始构建的截图占位符在 [`docs/ENGINEERING_REPORT.md`](docs/ENGINEERING_REPORT.md) 中有说明，并在 [`screenshots/`](screenshots) 中被引用。请在发布前将导出的 PNG 图片添加到那里，并使用匹配的文件名。
## 关于
由 **Jeremiah Dighomanor** 在 2026 年第二季度 Digiss 实习期间作为工程项目构建。
如果您是招聘人员或招聘经理：此仓库旨在展示动手实践的 SOC 工程 —— SIEM 部署、自定义关联规则编写、跨平台集成工程以及由对手模拟驱动的验证 —— 而不仅仅是工具安装。[工程报告](docs/ENGINEERING_REPORT.md) 记录了每个决策背后的*理由*，而这正是截图无法体现的部分。
欢迎联系：[LinkedIn](https://www.linkedin.com/in/jeremiahdighomanor) · [Email](mailto:jeremiahdighomanor@gmail.com)
## 许可证
本项目的文档和自定义脚本在 [MIT License](LICENSE) 下发布。Wazuh、TheHive 和 Atomic Red Team 是拥有各自许可证的第三方工具 —— 请参阅它们各自的仓库。
标签：Atomic Red Team, CIDR查询, PB级数据处理, TheHive, Wazuh, 安全事件响应, 安全运维, 数据泄露检测, 逆向工具