# 企业级 Azure SOC：Wazuh SIEM、SOAR 与事件响应实验室
## 关键成果
| 成果 | 有证据支持的结果 |
|---|---|
| Azure 环境 | 3 台虚拟机：Windows Server 2025、Windows 11 Pro 和 Ubuntu Server |
| 监控覆盖范围 | 2 个 Windows Wazuh agent 以及本地 Ubuntu/Wazuh 遥测数据 |
| 告警处理 | 导出 482 条告警：0 条严重、23 条高、260 条中和 199 条低 |
| 检测覆盖范围 | 身份验证、进程、SSH、FIM、漏洞和 CIS 监控 |
| 安全发现 | 捕获 7 个漏洞：5 个高危和 2 个中危 |
| Python 自动化 | 1 个生产级告警报告实用程序，以及 10 个辅助实验室实用程序和原型 |
| SOAR 工作流 | 8 阶段 Shuffle 工作流，集成 VirusTotal、AbuseIPDB、Slack、电子邮件和人工审批 |
| 响应验证 | 安全的 Wazuh Active Response 证明及组件级别的 Windows 防火墙验证 |
## 概述
该项目在 Microsoft Azure 中构建了一个小型企业安全运营中心（SOC）模型。它将 Windows 和 Linux 基础设施连接到一个集中化工作流中，用于日志收集、检测、调查、富化、审批、响应和验证。
该仓库将经过完全验证的控件与组件级别的测试、原型以及未解决的遥测差距区分开来。除非由此产生的安全状态已得到独立验证，否则成功的命令和编排作业不会被视作证明。
## 展现的技能
| 领域 | 技术与能力 |
|---|---|
| 云与网络 | Azure VM、Virtual Network、子网划分、NSG、静态私有寻址、UFW、连通性测试 |
| 身份与系统 | Active Directory Domain Services、DNS、Group Policy、OU、用户、安全组、Windows Server 2025、Windows 11 |
| SIEM 与遥测 | Wazuh Manager、Indexer、Dashboard、Windows Security 日志、Sysmon、PowerShell、Auditd、SSH、FIM |
| 检测与调查 | Wazuh 规则与解码器、事件关联、MITRE ATT&CK 上下文、威胁狩猎、Atomic Red Team、CIS SCA、漏洞审查 |
| SOAR 与响应 | Shuffle webhook、条件路由、VirusTotal、AbuseIPDB、Slack、电子邮件、人工审批、Wazuh Active Response、Azure Automation |
| 自动化与报告 | Python、PowerShell、Bash、JSON、CSV、告警规范化、事件报告、端点侧验证 |
## 端到端 SOC 工作流
```
flowchart TD
A[Azure Infrastructure] --> B[Active Directory]
B --> C[Endpoint Telemetry]
C --> D[Wazuh SIEM]
D --> E[Detection Engineering]
E --> F[Threat Hunting]
F --> G[Shuffle SOAR]
G --> H[Analyst Approval]
H --> I[Automated Response]
I --> J[Endpoint Validation]
```
该实验室遵循防御性操作顺序：构建环境、接入遥测数据、检测并调查活动、富化事件、要求分析师审批、执行受控响应，并在受影响的系统上验证结果。
## 架构
### Azure 基础设施
| 系统 | 平台 | 角色 | 私有 IP |
|---|---|---|---|
| `dc01` | Windows Server 2025 | Active Directory Domain Services、DNS、Group Policy、Wazuh agent | `10.0.0.4` |
| `win11` | Windows 11 Pro | 加入域的 endpoint、Sysmon、PowerShell 日志记录、Wazuh agent | `10.0.0.5` |
| `wazuh01` | Ubuntu Server | Wazuh Manager、Indexer、Dashboard、Linux 遥测、Python 工具 | `10.0.0.6` |
这些系统位于 `enterprise-soc-rg` 资源组和 `enterprise-soc-vnet` (`10.0.0.0/16`) 中。网络安全组 (NSG) 和主机防火墙控制着管理流量和遥测流量。
### Active Directory
`enterprise.local` 域包含部门和资源 OU、基于角色的安全组、域用户、加入域的工作站，以及一个用于响应测试的一次性服务账户。
实施的控件包括密码和锁定策略、部门和特权组、Group Policy、基于 DNS 的域名解析、域身份验证，以及最小权限的远程桌面访问。
从 Windows 验证的有效域密码和账户锁定设置。
### SIEM 与 SOAR 集成
Windows 和 Linux 遥测数据由 Wazuh 收集，通过规则和解码器进行处理，存储在 Indexer 中，在 Dashboard 中进行调查，并转换为结构化事件数据，用于 Shuffle 的富化、通知、审批和响应工作流。
## 实施过程
### 1. Azure 基础设施
该实验室使用三台具有静态私有寻址和内部 DNS 的 Azure 虚拟机。尽管正确配置了 Azure NSG 规则，但 Wazuh Dashboard 和 agent 仍然无法访问，因为 Ubuntu UFW 阻止了所需的流量。我打开了主机防火墙端口，并在继续之前从 Windows 验证了连通性。
```
sudo ufw allow 443/tcp
sudo ufw allow 1514/tcp
sudo ufw allow 1515/tcp
sudo ufw status verbose
```
```
Test-NetConnection 10.0.0.6 -Port 1514
Test-NetConnection 10.0.0.6 -Port 1515
```
### 2. Active Directory 与 Windows 客户端
`dc01` 被提升为 `enterprise.local` 的域控制器。在接入 Windows 11 端点之前，配置了 OU、用户、安全组、密码控制、锁定控制和 Group Policy 设置。
在将端点指向域 DNS 后，我将其加入了 `enterprise.local`，并通过使用域用户账户进行身份验证来验证了结果。
Windows 11 成功加入到企业域。
### 3. 端点与 Linux 遥测
Windows 系统提供了 Security 事件、Sysmon 进程遥测、PowerShell 活动、文件完整性监控 (FIM) 事件和 agent 健康数据。Ubuntu 主机提供了 SSH 身份验证日志、Auditd 事件、本地 Linux FIM 和 Wazuh 服务器日志。
Windows Server 和 Windows 11 agent 的集中可见性。
### 4. 安全监控与态势
#### 文件完整性监控
Wazuh 捕获了受监控系统上的文件添加、文件修改和文件删除活动。
#### 漏洞检测
Windows 漏洞清单显示了受影响的包、CVE 标识符和严重程度。捕获的验证视图显示了七个发现：五个高危和两个中危。
#### 安全配置评估
Wazuh SCA 评估了 Windows 和 Ubuntu 的 CIS 基准控件，并显示了通过、失败和不适用的检查。
## 检测工程
### 身份验证失败关联
受控的身份验证失败活动生成了 Windows 事件 ID `4625` 和 Wazuh 规则 `60122`。重复事件被关联到规则 `60204`，这是一个级别为 10 的 **多次 Windows 登录失败** 告警，与暴力破解行为相关。
单独的失败登录和更高严重级别的关联告警同时显示。
Python 时间线重建了从基础事件到关联规则的演变过程。
### 检测覆盖范围
| 活动 | 主要证据 | 检测上下文 |
|---|---|---|
| Windows 登录失败 | 事件 ID `4625`，规则 `60122` 和 `60204` | 凭据访问和暴力破解调查 |
| Windows 登录成功 | 事件 ID `4624`，规则 `60106` | 身份验证和访问审查 |
| 特权登录 | 事件 ID `4672`，规则 `67028` | 特权会话调查 |
| 可疑的 PowerShell/进程活动 | Sysmon 事件 ID `1`，包括 `92021` 和 `92066` 在内的规则 | 命令执行和进程分析 |
| SSH 暴力破解 | Wazuh 规则 `5712` | MITRE ATT&CK `T1110` |
| 文件添加、更改或删除 | FIM 规则 `550`、`553` 和 `554` | 完整性监控 |
| 易受攻击的软件 | Wazuh 漏洞清单 | CVE 和包审查 |
| CIS 配置发现 | Wazuh SCA | 安全态势和加固 |
### 自定义规则工程
我创建并加载了自定义 PowerShell 规则 `100100`，但它并没有按预期触发。启用 `logall_json` 并检查 `archives.json` 揭示了已索引的 OpenSearch 字段与 Wazuh 规则引擎使用的解码字段之间的差异。
由于在记录的验证窗口期间并未证明该触发器实现了端到端的有效，因此它被记录为检测工程和遥测管道故障排除，而不是一次成功的检测。
## 威胁狩猎与对手模拟
### Sysmon 进程调查
Sysmon 事件 ID `1` 提供了进程映像、命令行、父进程、用户上下文和哈希数据。Wazuh 呈现了可疑的命令外壳、发现和 PowerShell 行为，供分析师审查。
Windows 事件 ID `4672` 作为 **分配给新登录的特殊权限** 被收集。它被视为特权会话遥测数据，而不是特权提升的自动证明。
### Atomic Red Team 验证
我在 `win11` 上安装了 Atomic Red Team 并执行了 PowerShell 命令执行测试 `T1059.001-17`，该测试以退出代码 `0` 完成。然后我在 Wazuh 威胁狩猎中检查了生成的进程映像、命令行、父进程、标识符、哈希和用户上下文。
受控 PowerShell 对手模拟后捕获的详细进程遥测数据。
除非在 Wazuh 规则元数据中可见该映射，否则该事件不会被视为自动映射到 MITRE。
## Python 自动化
主要的 数据驱动实用程序是 [`python/alert_report.py`](python/alert_report.py)。它能够：
```
cd python
python3 alert_report.py \
--input /var/ossec/logs/alerts/alerts.json \
--output-dir reports \
--limit 1000
```
提交的样本报告处理了 **482 条告警**：0 条严重、23 条高、260 条中和 199 条低。
### 辅助实用程序与原型
| 脚本 | 用途 | 当前成熟度 |
|---|---|---|
| [`alert_report.py`](python/alert_report.py) | 解析并导出 Wazuh 告警记录 | 动态、数据驱动 |
| [`daily_health.py`](python/daily_health.py) | 统计可用告警并编写每日摘要 | 动态告警计数 |
| [`log_parser.py`](python/log_parser.py) | 将最近的 Wazuh 日志数据提取到报告中 | 实验室实用程序 |
| [`agent_status.py`](python/agent_status.py) | 生成 agent 状态报告 | 静态状态模板 |
| [`alert_statistics.py`](python/alert_statistics.py) | 生成严重程度分布摘要 | 部分硬编码的样本值 |
| [`soc_health_check.py`](python/soc_health_check.py) | 生成 SOC 健康摘要 | 告警计数加上静态状态字段 |
| [`incident_report.py`](python/incident_report.py) | 生成事件报告模板 | 报告原型 |
| [`dashboard_export.py`](python/dashboard_export.py) | 记录预期的 Dashboard 覆盖范围 | 报告原型 |
| [`ioc_lookup.py`](python/ioc_lookup.py) | 生成 IOC 查找报告 | API 查找未配置 |
| [`threat_client.py`](python/threat_client.py) | 报告威胁情报集成就绪情况 | API 客户端未配置 |
| [`soc_summary.py`](python/soc_summary.py) | 生成合并的 SOC 摘要 | 实验室摘要实用程序 |
Python 威胁情报原型与在 Shuffle 中演示的有效的 VirusTotal 和 AbuseIPDB 富化是分开的。
## Shuffle SOAR 自动化
`Enterprise Wazuh SOC Response` 工作流通过 `Wazuh Alert Ingestion` webhook 接收结构化的事件 JSON。案例 schema 包含严重程度、优先级、端点、目标账户、失败登录次数、源 IP、分配的队列、SLA、评估和分析师操作。
该工作流实施了：
1. Webhook 接入和 JSON 解析
2. SOC 分流和 HIGH/P1 路由
3. VirusTotal 哈希富化
4. AbuseIPDB 源 IP 富化
5. Slack 和电子邮件通知
6. 人工审批
7. Azure Automation 响应实验
8. 响应验证
### 威胁情报富化
在事件富化期间执行的 VirusTotal 和 AbuseIPDB 操作。
### P1 通知
Slack 告警包含案例 ID、事件 ID、严重程度、优先级、端点、目标账户、失败登录次数、分配的队列和 SLA。
## 分析师审批
工作流在可能具有破坏性的响应之前暂停为 WAITING 状态。
该审批门禁防止了将富化或通知的成功自动授权为端点隔离或账户禁用。
## 自动化响应与验证
### Wazuh Active Response
一个安全的服务器端 Wazuh Active Response 命令被附加到规则 `60204` 上。该脚本向 `active-responses.log` 写入了带有时间戳的 `SAFE_ACTIVE_RESPONSE_TRIGGERED` 条目，在隔离测试之前证明了由规则触发的执行路径。
Wazuh Active Response 工作流已执行的非破坏性证明。
### Azure Automation
Azure Automation、Hybrid Runbook Worker 和 PowerShell runbook 被用于测试端点侧的响应执行。在测试期间隔离了 Managed Identity、RBAC、执行上下文和 Worker 部署的限制。
### 端点侧验证
在目标系统上直接检查了最终的 Windows 防火墙状态。该规则已启用，被配置为阻止入站流量，并限定于预期的远程地址。
由于该仓库并未证明一个未中断的事件经历了从攻击产生到最终隔离的每一个阶段，因此这被作为 **组件级别的响应验证** 提出。
### 验证矩阵
| 测试 | 结果 |
|---|---|
| Wazuh Dashboard HTTPS 访问 | 在 UFW 中允许 TCP 443 后恢复 |
| Windows agent 连通性 | 在允许 TCP 1514/1515 后恢复 |
| 域 DNS 解析和加入 | 已验证 |
| Wazuh agent 健康 | 已验证 |
| 失败登录收集和关联到规则 `60204` | 已验证 |
| Sysmon 进程遥测 | 已验证 |
| FIM 添加/修改/删除事件 | 已验证 |
| Windows 和 Ubuntu CIS SCA | 已验证 |
| 漏洞清单 | 已验证 |
| Wazuh Active Response 执行 | 通过非破坏性日志记录验证 |
| Python 告警告警 | 在 TXT、JSON 和 CSV 中验证 |
| Shuffle webhook、富化和 P1 通知 | 已验证 |
| 人工审批 WAITING 状态 | 已验证 |
| Atomic Red Team PowerShell 执行 | 已验证 |
| Windows 防火墙规则配置 | 捕获了组件级别的验证 |
| 自定义规则 `100100` 端到端触发 | 未验证 |
| Wazuh 中的 EICAR 事件 | 未验证；Defender 在本地检测到了它 |
| 一次从攻击到隔离的未中断链条 | 未验证 |
## 故障排除亮点
| 遇到的问题 | 根本原因和解决方法 | 它证明了什么 |
|---|---|---|
| 尽管有正确的 Azure 规则，Wazuh Dashboard 和 agent 仍无法访问 | Ubuntu UFW 仍然阻止 TCP `443`、`1514` 和 `1515`。我打开了端口并使用 `Test-NetConnection` 对其进行了验证。 | 必须独立测试云控件和主机控件。 |
| Windows agent 报告了重复的 Security EventChannel 警告 | 在重启 agent 服务之前删除了重复的 `
` 条目。 | 采集健康度取决于干净的端点配置。 |
| 自定义规则 `100100` 已加载但未触发 | `archives.json` 显示，规则引擎需要解码后的字段（例如 `win.eventdata.image`），而不是已索引的 Dashboard 字段（例如 `data.win.eventdata.image`）。 | 已索引的字段和解码器字段属于不同的 pipeline 阶段。 |
| 内置的 Shuffle 操作失败或请求了不合适的权限 | 将不可靠的连接器步骤替换为直接的 HTTP 操作和 webhook，然后通过返回的执行数据进行验证。 | 当连接器受限时，SOAR 工作流应优雅降级。 |
| Azure Automation 报告成功但未证明端点发生了更改 | 分别测试了执行上下文、Managed Identity、RBAC 和 Hybrid Worker 部署；然后从 Windows 检查了防火墙状态。 | 仅仅是编排状态不能证明控件的有效性。 |
| Defender 在本地检测到了 EICAR，但没有确认匹配的 Wazuh 事件 | 本地控件发挥了作用，但未证实 Defender 到 Wazuh 的遥测路径。 | 必须如实记录可见性差距，而不是夸大其词。 |
## 前置条件
- Microsoft Azure 订阅以及创建网络、VM 和 Automation 资源的权限
- Windows Server 2025、Windows 11 Pro 和 Ubuntu Server 虚拟机
- Wazuh Manager、Indexer、Dashboard 和 agent
- Active Directory 和端点的管理员访问权限
- Python 3、PowerShell、Bash、Sysmon 和 Auditd
- Shuffle 账户
- 可选的 VirusTotal、AbuseIPDB、Slack 和电子邮件凭据
- 用于受控对手模拟的 Atomic Red Team
## 仓库结构
```
enterprise-azure-soc-lab/
├── README.md
├── architecture/
│ └── diagrams/
├── python/
│ ├── lib/
│ ├── reports/
│ └── 11 SOC automation and reporting scripts
└── screenshots/
├── 01-azure/
├── 02-active-directory/
├── 03-windows-client/
├── 04-wazuh/
├── 05-shuffle/
├── 06-python/
├── 07-validation/
└── 08-architecture/
```
## 经验教训
1. **独立验证每一层。** Azure 网络、主机防火墙、服务、agent、事件通道、规则和 Dashboard 都可能单独发生故障。
2. **验证目标状态。** 一个成功的操作或编排作业并不能证明预期的安全控件发生了改变。
3. **首先使用安全的执行证明。** 非破坏性日志记录在隔离测试之前验证了 Active Response 路径。
4. **将遥测与告警分开。** 一个事件可能存在于本地，但并未被收集、解码、匹配或提升为告警。
5. **破坏性操作需要人工审批。** 潜在的隔离操作仍需经过分析师审查。
6. **如实记录差距。** 当声明与证据相符时，不成功的测试和可见性差距反而会增强项目的说服力。
## 未来改进
- 导出经过脱敏处理的 Wazuh 配置、自定义规则、解码器、Active Response 脚本、Azure runbook 和 Shuffle 工作流
- 将 Microsoft Defender Operational 事件接入 Wazuh
- 完成自定义规则 `100100` 的端到端验证
- 将原型状态脚本替换为基于 API 或服务的检查
- 添加单元测试、Wazuh 样本 fixture、CI 检查和密钥扫描
- 使用一次性用户验证 AD 账户禁用操作
- 通过完整的攻击到隔离链条重新运行一次受控事件
- 添加基础设施即代码以实现可重复的 Azure 部署
## 安全与道德
所有攻击活动均在受控实验室环境中进行，以进行防御性安全验证。本项目不授权对非自有或未经明确批准进行评估的系统进行测试。
## 作者
**Uwais Watkins**
GitHub: [`waisyrr`](https://github.com/waisyrr)