Mboatella25/home-soc-lab-wazuh

# 家庭 SOC 实验室 — 使用 Wazuh + Sysmon 检测 MITRE ATT&CK 技术 ## 项目目标 从零开始搭建并逐步记录一个微型 SOC（安全运营中心），用于模拟真实的攻击技术（映射到 MITRE ATT&CK），并验证开源 SIEM 是否能够检测到它们，遵循检测和响应分析师的工作周期。 - **阶段 0 - 环境**：搭建实验室基础设施（受监控的受害机器 + SIEM）。 - **阶段 1 - 日志接入**：将受害机器连接到 SIEM，并验证安全事件是否正确送达。 - **阶段 2 - 使用 Atomic Red Team 模拟攻击** - **阶段 3 - 检测与规则编写** - **阶段 4 - 钓鱼案例分类与处理** ## 为什么做这个项目 本项目涵盖了防御侧内容，包括使用 SIEM/XDR 设计真实的检测 pipeline，使用系统级传感器 (Sysmon) 生成事件，以及验证接入链。此外还包含告警分析、与 MITRE ATT&CK 的关联，以及安全告警生命周期的管理。 ## 架构 ``` flowchart LR subgraph VM["VM Windows 10 x86_64 (UTM · Emulate)"] A[Sysmon
config SwiftOnSecurity] -->|Event ID 1, 3, 11...| B[Wazuh Agent] end subgraph HOST["Mac host (Apple Silicon M4)"] C[Wazuh Manager] --> D[Wazuh Indexer] C --> E[Wazuh Dashboard] end B -->|puerto 1514/1515
IP LAN del host| C E -->|https://localhost| F([Analista]) ``` **组件及其选择原因：** | 组件 | 选择 | 原因 | |---|---|---| | Hypervisor | UTM (QEMU) | 免费，在 Apple Silicon 上原生运行，同时支持原生虚拟化和 x86 模拟 | | 受害机器 | Windows 10 x86_64 | Endpoint 事件生成器 | | Endpoint 传感器 | Sysmon + SwiftOnSecurity config | 进程、网络和文件遥测的标准；SwiftOnSecurity 的 config 是真实 SOC 实验室中最常用的参考 ruleset | | SIEM/XDR | Wazuh (单节点, Docker) | 开源、免费，原生支持 MITRE ATT&CK 规则 — 与 Microsoft Sentinel/Splunk 属于同类工具 | | SIEM 部署 | Mac 宿主机上的 Docker Desktop | 避免仅为 manager 升起第三台 VM；通过 `docker-compose` 实现可复现的启动 | ## 阶段 0 - 环境 ### Windows 11 ARM64 (虚拟化) 最初的计划是在“Virtualize”模式（Apple Silicon 原生虚拟化，速度更快）下使用 Windows 11 ARM64。但实际上，这种组合在 UTM 中持续失败。 与其继续调试图形驱动程序问题，不如转向 **“Emulate”模式下的 Windows 10 x86_64**。它的 CPU 速度较慢（模拟而非原生虚拟化），但 QEMU 为标准 PC 模拟的硬件（基于 Intel ICH9 的 PC、IDE/SATA 磁盘、VGA 显卡）要成熟得多，并且没有出现任何此类问题。对于实验室的目的（生成 endpoint 事件，而非追求性能），这种速度的损失是无关紧要的。 安装过程中：UEFI 固件无法自动找到启动介质，并进入了 **UEFI Shell**；通过按 `Esc` 键中断启动以访问 **Boot Manager**，并手动选择带有安装程序的 CD-ROM 驱动器解决了该问题。 ### VM 的最终配置 - UTM，**Emulate** 模式，硬件 **基于 Intel ICH9 的 PC (2009, x86_64)** - 8192 MiB RAM，4 个 CPU 核心，64 GB 磁盘 - Windows 10 Pro（在无产品密钥的情况下安装，评估版本） ### 安装 Sysmon 1. 下载 Sysmon (Microsoft Sysinternals) 以及 [SwiftOnSecurity](https://github.com/SwiftOnSecurity/sysmon-config) 的参考配置。 2. 使用以下命令安装： .\Sysmon64.exe -accepteula -i sysmonconfig-export.xml 3. 在事件查看器 (`应用程序和服务 → Microsoft → Windows → Sysmon → Operational`) 中验证：从第一分钟起就确认了进程创建事件 (Event ID 1)、网络连接和文件创建事件。 ## 阶段 1 - 日志接入 ### 部署 SIEM ``` git clone https://github.com/wazuh/wazuh-docker.git -b v4.12.0 cd wazuh-docker/single-node docker compose -f generate-indexer-certs.yml run --rm generator docker compose up -d ``` 部署了三个容器：`wazuh.manager`、`wazuh.indexer`、`wazuh.dashboard`。Dashboard 可在 `https://localhost` 访问。 ### 连接 Agent Windows VM 和 Wazuh manager 运行在不同的机器上（VM 对比 宿主机），因此通信不能使用 `localhost` — 使用了宿主机在局域网中的 IP（macOS 上的 `ipconfig getifaddr en0`）作为 manager 的地址： ``` Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.12.0-1.msi -OutFile $env:tmp\wazuh-agent msiexec.exe /i $env:tmp\wazuh-agent /q WAZUH_MANAGER='' NET START WazuhSvc ``` 在 Dashboard 的 Agent 列表中验证状态为 **Active**。 ### 已解决的障碍：默认未接入 Sysmon 通道 Windows 的 Wazuh Agent 默认配置仅收集标准日志通道 (`Application`, `Security`, `System`) — **而不包括** Sysmon 的特定通道。Agent 的事件能够到达 Dashboard（可通过搜索 `ossec` 进行验证），但没有出现任何 Sysmon 事件。 **解决方案**：手动编辑 `C:\Program Files (x86)\ossec-agent\ossec.conf`，将该通道添加为额外的数据源： ``` Microsoft-Windows-Sysmon/Operational eventchannel ``` 在重启服务（`NET STOP WazuhSvc` / `NET START WazuhSvc`）并生成测试活动后，通过搜索完整的通道名称 (`Microsoft-Windows-Sysmon`)，可以在 Dashboard 中正确看到事件。 ## 阶段 2 - 使用 Atomic Red Team 模拟攻击及检测分析 ### 阶段目标 随着接入 pipeline 已得到验证（阶段 1），*detection engineering* 练习的下一步才是真正重要的环节：仅仅运行命令并计算出现了多少告警是不够的，**必须验证 SIEM 检测到了什么、使用了什么规则以及严重级别如何，调查每一个告警以确认它是真正的攻击还是误报，并记录下剩余的覆盖盲区**。 用于模拟技术的工具：[Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) (Invoke-AtomicRedTeam)，这是 Red Canary 开发的基于 MITRE ATT&CK 的对手模拟框架，每个测试都映射到具体的技术和子技术。 ``` Set-ExecutionPolicy -Scope CurrentUser -Force RemoteSigned IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing) Install-AtomicRedTeam -getAtomics Import-Module "C:\AtomicRedTeam\invoke-atomicredteam\Invoke-AtomicRedTeam.psd1" -Force ``` ### 工作方法论 在执行任何测试之前，都检查了其 YAML 定义 (`Select-String -Pattern "name:|supported_platforms"`) 以确认它具体做什么以及在哪个平台上运行，同一个测试编号在不同技术间并不稳定，也不意味着是一个简单的操作。这种检查避免了盲目执行，例如一个实际上会下载并运行真实 Mimikatz 的测试（见下文）。 对于每项技术，Wazuh 中的分析都是在 *Threat Hunting → Discover* 面板中逐字段进行的，使用 "Available fields" 侧边栏进行过滤（比自由搜索更可靠，在 Wazuh 中自由搜索需要明确的通配符，例如 `*ipconfig*`）来分离出相关的告警，并读取其 `rule.description`、`rule.level` 以及相关的 `data.win.eventdata.*` 字段。 ### 检测覆盖率 — 逐个技术分析 | 技术 (MITRE ATT&CK) | 执行的测试 | 是否检测到？ | Wazuh 规则 (ID / 级别) | 备注 | |---|---|---|---|---| | **T1082** — System Information Discovery | `systeminfo` | 是 | 通用的进程执行规则 (级别 3) | 基础检测，没有针对该技术的特定规则 | | **T1057** — Process Discovery | Test #2, `tasklist` (Windows) | 是 | 通用的进程执行规则 (级别 3) | 原始的 Test #1 (`ps`) 不适用于 Windows；在执行前已在 YAML 中确认 | | **T1016** — System Network Configuration Discovery | 链式命令 `ipconfig /all & netsh interface show interface & arp -a & nbtstat -n & net config` | 部分检测到 | 针对每个独立命令的级别 3-4 规则 | 详见下文描述的关联盲区 | | **T1059.001** — PowerShell (Base64 编码的命令) | 手动构建的 `-EncodedCommand` 命令 | 是，精度极高 | **规则 92057** — "Powershell.exe spawned a powershell process which executed a base64 encoded command" (**级别 12**) | 准确且具体的检测；见下文相关的误报案例研究 | | **T1059.001** — PowerShell (官方测试 #1, "Mimikatz") | Atomic Red Team 的 Test #1 | 执行前被 Windows Defender 拦截 | — | 测试本身试图从 PowerSploit 仓库下载并运行真实的 Mimikatz；Defender 以 "Access is denied" 拦截了它，这也在 `Get-MpThreatDetection` 中得到了证实 | | **T1547.001** — Registry Run Keys / Startup Folder | 在注册表中添加持久化键 | 是 | 规则 92217 "Executable dropped in Windows root folder" (级别 6)，规则 92302 "Registry entry to be executed on next boot" (级别 6) | 正确检测到了该技术；另见与此测试重叠的 "Base64-like pattern" 误报 | | **T1218.005** — Mshta (模拟 FIN7 组织使用的技术) | Test #2 | 被 Windows Defender 拦截 (行为检测) | — | 见下文分析，为什么这种拦截本身就是一个有效的结果 | **关于 Defender 两次拦截的说明**：在这两种情况下，都明确决定不关闭 Windows Defender 也不强制执行。已经配置的文件夹排除项 (`C:\AtomicRedTeam`) 仅能避免因**文件扫描**造成的拦截，而不能避免因**行为检测**造成的拦截，Defender 引擎继续拦截 `mshta → vbscript → PowerShell` 链 (FIN7 模式) 以及 Mimikatz 的下载/执行，因为无论源文件夹是什么，这两者都符合已知的恶意行为。这种拦截被视为一个已记录的发现，defense-in-depth（深度防御）层发挥了作用。 ### Wazuh 中的规则严重性分级 (0-15) 为了能够有评判标准地阅读上表： - **0-3 - 信息/常规**：正常的系统事件，其本身没有安全相关性。 - **4-7 - 低/中度相关**：需要监视但不一定属于恶意的行为（配置更改、系统实用程序的执行）。 - **8-11 - 攻击指标**：与已知技术匹配的模式（侦察命令、可疑的注册表更改等）。 - **12-15 - 高/严重级别**：高可信度的入侵指标（执行混淆代码、已确认的恶意软件等）。 ### 案例研究：误报分析 运行测试并计算告警数量并不是分析，真正的价值在于调查每个告警，直到有证据决定它是真正的攻击还是误报。详细记录了三个案例： **1. `cleanmgr.exe` 和 `GenericProvider.dll` - "Executable dropped" 误报** 在一段不活动期间（没有进行任何测试），Dashboard 显示了 28 条级别 15 的告警，描述为 "Executable file dropped in folder commonly used by malware"，全部集中在同一时间窗口内。对父进程 (`cleanmgr.exe`，Windows 合法的磁盘清理实用程序) 和文件（临时文件夹 `%TEMP%\{GUID}\` 中的 `GenericProvider.dll`）的调查确认，这是 Windows 计划的自动维护，而不是恶意活动。这是一个通用且严重程度高 (级别 15) 的规则示例，需要分析师提供额外的上下文，以免引起告警疲劳。 **2. `__PSScriptPolicyTest_*.ps1` — PowerShell 的内部工件** 在执行测试 T1059.001 的 `-EncodedCommand` 命令时，Temp 文件夹中还出现了一个 `__PSScriptPolicyTest_*.ps1` 文件。这不是攻击工件：它是 PowerShell 在运行命令之前在内部生成的一个临时文件，用于验证脚本执行策略，这是测试本身预期的副作用，而不是独立的发现。 **3. 规则 92041 "Value added to registry key has Base64-like pattern" — 因不精确的启发式算法导致的误报** 在执行持久化测试 T1547.001 时，可执行文件本身的路径 (`C:\AtomicRedTeam.exe`) 仅仅因为字符串的形式触发了规则 92041 (级别 10, "Value added to registry key has Base64-like pattern")，而实际上并没有真实的编码内容。这个案例被刻意用来与前一点中正确检测到真实 Base64 命令的规则 92057 (级别 12) 形成对比：两者之间的比较说明了 detection engineering 中经典的 *precision vs. recall* 权衡 — 宽泛的启发式算法能检测到更多的情况，但也会产生更多的噪音；特定的规则更精确，但可能无法覆盖变体。 ### 识别出的检测盲区：链式侦察命令的关联 当将 T1016 作为单行链式命令 (`ipconfig /all & netsh interface show interface & arp -a & nbtstat -n & net config`) 执行时，每个单独的命令仅触发了级别 3-4 的通用规则，在 Wazuh 的开箱即用配置中，并不存在一种**关联规则**，能够在同一个非交互式父进程 (`PowerShell → cmd.exe`) 于短时间内执行多个不同的侦察命令时，自动提升其严重级别。与任何单独的命令相比，这种行为模式更能存在自动化的侦察，而这正是 DeTT&CT 风格的 *gap analysis* 练习旨在揭示的盲区类型：具备单项技术级别的检测覆盖率，但在行为链 (TTP chaining) 级别却没有。 ## 当前状态 已验证并可运行的端到端 pipeline： **Windows VM (Sysmon) → Wazuh Agent → Manager → Indexer → Dashboard** 真实的进程创建、网络和文件事件能够到达、被索引并可供查询，并且已经对包含 7 种 MITRE ATT&CK 技术的第一轮模拟进行了评估，调查了 3 个误报并记录了 1 个关联盲区。 ## 下一步计划（阶段 3 及以后） - 对于覆盖率部分或完全缺失的技术（链级别的 T1016），在 Wazuh 中编写自定义的关联规则。 - 结合 IOC 和 VirusTotal 进行钓鱼分析实战案例。 - 扩充最终的检测覆盖率表格，添加自定义规则。 ## 证据 | 截图 | 描述 | |---|---| | `screenshots/01-sysmon-event-viewer.png` | Windows 事件查看器显示 Microsoft-Windows-Sysmon/Operational 通道以及捕获的事件 | | `screenshots/02-wazuh-agent-active.png` | Wazuh Dashboard 中的 Agent 列表，显示 Windows VM 已连接并处于活动状态 | | `screenshots/03-wazuh-discover-sysmon.png` | Threat Hunting/Discover 中的搜索结果显示已正确接入 Sysmon 事件 | | `screenshots/04-t1016-discovery-chain-detalle.png` | T1016 事件详情，显示完整的 `parentCommandLine` 以及链式侦察命令 | | `screenshots/05-t1016-net-exe-tabla.png` | 与 T1016 相关的 `net.exe` 事件的表格视图，包含哈希值和二进制文件路径 | | `screenshots/06-falso-positivo-executable-dropped-volumen.png` | 由 `cleanmgr.exe` 误报产生的 28 条 "Executable file dropped" (级别 15) 告警的数量 | | `screenshots/07-t1059-encodedcommand-deteccion.png` | 针对编码后的 PowerShell 命令的规则 92057 (级别 12) 的检测，以及相关的误报噪音 | | `screenshots/08-t1547-base64-pattern-falso-positivo.png` | 在执行持久化测试 T1547.001 期间作为误报触发的规则 92041 "Value added to registry key has Base64-like pattern" (级别 10) |        

标签：Docker, Wazuh, 安全运营, 安全防御评估, 实验室环境, 扫描框架, 端点检测, 请求拦截, 身份验证强制