IshaanMotwani26/MyFirstHack

# MyFirstHack — 从零开始构建与验证 SIEM 一个实用的家庭实验室项目：构建 Wazuh SIEM，从 Windows 受害者虚拟机发送日志，编写自定义 Sigma 风格的检测规则，并使用 Atomic Red Team 对其进行验证。记录了在此过程中取得的成就**以及遇到的真实世界遥测盲区**。 **作者：** [@IshaanMotwani26](https://github.com/IshaanMotwani26) **日期：** 2026 年 5 月 ## TL;DR 我在 Docker 中部署了 Wazuh 4.7.0 SIEM，构建了配备 Sysmon 和 Wazuh 代理的 Windows 11 受害者虚拟机，编写了三条自定义的 MITRE 对齐检测规则，并使用相应的 Atomic Red Team 攻击逐一进行了验证。在此过程中，我遇到了 Windows 11 上 Sysmon ProcessAccess 的真实遥测盲区，在全链路（Sysmon → Wazuh 代理 → 管理器 → 仪表板）对其进行了诊断，并做出了工程决策：重新设计一条规则，而不是发布一条无法验证的规则。 **三条规则。三次已验证的检测。一份关于失败案例的真实报告。** ## 架构 请参阅 [ARCHITECTURE.md](ARCHITECTURE.md) 获取完整管道的 Mermaid 图表。 **组件：** | 组件 | 位置 | 用途 | |---|---|---| | Wazuh Manager + Indexer + Dashboard | 宿主机 (Docker, 192.168.0.140) | 规则引擎，日志存储，用户界面 | | Wazuh Agent | Win11 虚拟机 (192.168.0.216) | 将 Windows 事件日志发送给管理器 | | Sysmon (SwiftOnSecurity 配置) | Win11 虚拟机 | 端点遥测 — 进程创建，网络等 | | Atomic Red Team | Win11 虚拟机 | MITRE ATT&CK 对手模拟库 | | `local_rules.xml` | 管理器 `/var/ossec/etc/rules/` | 自定义检测规则 | ## 检测规则 这三条规则都是 Sysmon EventID 1 (ProcessCreate) 的子规则。来源：[`local_rules.xml`](local_rules.xml)。 ### 规则 100001 — PowerShell 编码命令 (T1059.001) **级别：** 12 (高) **检测内容：** 使用 `-EncodedCommand`（或任何缩写：`-e`, `-en`, `-enc`, ... `-encodedcommand`）调用 `powershell.exe`。攻击者使用 base64 编码的 payload 来绕过简单的内容过滤器和命令行日志记录。 **验证方式：** 运行了 ``` powershell.exe -EncodedCommand VwByAGkAdABlAC0ASABvAHMAdAAgACcASABlAGwAbABvACAAdABlAHMAdAAnAA== ``` （该命令解码为 `Write-Host 'Hello test'` — 完全无害）。规则按预期触发。Wazuh 内置的规则 92057 也在同一事件上触发，这是实际操作中的真实结果 — 多个重叠检测在生产环境 SOC 中很常见。 ### 规则 100002 — 系统与账户侦察 (T1033, T1087) **级别：** 8 (中) **检测内容：** 进程创建，其中镜像文件为 `whoami.exe`、`net.exe`、`net1.exe`、`quser.exe` 或 `hostname.exe` 之一。捕获几乎每个攻击者在利用后最初运行的命令，以弄清楚他们是谁、存在哪些用户以及他们登录了哪台机器。 **验证方式：** 运行 `whoami` 和 `net user`。规则已触发（参见 `screenshots/01-dashboard-overview.png`）。 ### 规则 100003 — 可疑的 certutil 使用 (T1140, T1105) **级别：** 12 (高) **检测内容：** 使用 `-decode`, `-encode`, `-urlcache`, `-decodehex` 或 `-verifyctl` 中的任何一个调用 `certutil.exe`。`certutil` 是一个内置的 Windows 二进制文件，经常被滥用作 LOLBin 来下载远程 payload 或解码混淆文件。 **验证方式：** 运行了 ``` certutil -encode C:\Windows\System32\drivers\etc\hosts C:\Tools\hosts.b64 ``` 规则已触发（级别 12，MITRE 字段中为 T1140/T1105）。证据见 `screenshots/02-alert-table.png` 和 `screenshots/03-alert-mitre.png`。 ## 验证总结 | 规则 | MITRE | 级别 | Atomic / 测试 | 结果 | |---|---|---|---|---| | 100001 | T1059.001 | 12 | 手动 `-EncodedCommand` PowerShell | ✅ 触发 | | 100002 | T1033, T1087 | 8 | `whoami`, `net user` | ✅ 触发 | | 100003 | T1140, T1105 | 12 | `certutil -encode` | ✅ 触发 | 最终仪表板：3 个警报，其中 2 个为 12 级以上，涵盖 5 个 MITRE 技术。 ## 未起作用的部分：LSASS 调查 最初的计划包括第四条规则，使用 Sysmon EventID 10 (ProcessAccess) 针对 **T1003.001 — OS 凭据转储 (LSASS 内存)**。我编写了规则，然后尝试使用 Atomic Red Team 测试 `T1003.001-2`（通过 `comsvcs.dll` 进行 LSASS 转储）进行验证。但它反复未能触发。诊断此问题花费了数小时的调查，我认为这实际上是本项目中最有价值的部分。 **现象：** Atomic 测试成功运行（`Exit code: 0`），生成了 `lsass-comsvcs.dmp`，但 Windows 事件日志中没有出现 Sysmon EventID 10 事件，Wazuh 也未触发任何警报。 **我的排查顺序：** 1. **Defender 是否在静默重新启用自身？** 是的 — 定期如此。重新禁用 `DisableRealtimeMonitoring`、`DisableBehaviorMonitoring`、`DisableIOAVProtection`、`DisableScriptScanning`。没有变化。 2. **Sysmon 有没有记录任何内容？** 有的 — EventID 1 和 EventID 11 流动正常。 3. **Sysmon 的配置是否在静默过滤 ProcessAccess？** 检查了 SwiftOnSecurity 配置，发现 `` — ProcessAccess 在 SwiftOnSecurity 的配置中**默认是被注释掉的**。添加了一个最小的补丁配置（`sysmon-lsass-patch.xml`），明确启用对 LSASS 目标的 ProcessAccess 监控。 4. **补丁配置是否已加载？** 是的 — 通过 `Sysmon64.exe -c` 验证了配置哈希已更改，并且新的 `` 规则在运行时转储中可见。 5. **配置更改后 EventID 10 是否触发了？** 没有。仍然零事件。 6. **LSA 保护 (PPL) 是否阻止了 Sysmon 驱动程序看到 LSASS 的句柄打开？** 注册表 `RunAsPPL` 未设置，因此理论上不是 — 但 Windows 11 23H2+ 具有未反映在该单一注册表值中的额外保护。 7. **驱动程序是否实际接收了配置更改？** 完全卸载并重新安装 Sysmon，使用 `Sysmon64.exe -u` 和 `Sysmon64.exe -i ...`。仍然没有 EventID 10。 8. **替换配置是否意外禁用了其他事件类型？** 是的 — 我的最小补丁仅声明了 ``，这在某些场景下静默禁用了 EventID 1 日志记录。恢复到 SwiftOnSecurity 配置以还原基线。 **结论：** 在这台 Windows 11 Enterprise Evaluation 主机上，Sysmon 的 ProcessAccess 钩子没有为 `rundll32 → comsvcs.dll → MiniDump → LSASS` 链生成 EventID 10。这与 LSA 保护静默影响较新 Windows 11 版本中驱动程序可见性的情况一致，或者是一个尚未公开记录的 Sysmon 与 Windows 11 交互问题。 **工程决策：** 我没有发布一条无法验证的检测规则，而是放弃了基于 EventID 10 的规则，并将我的检测组合重新调整为我已证明可端到端正常工作的遥测数据——即全部使用 Sysmon EventID 1 的三个规则。这正是工作 SOC 分析师通常做出的决定：无法在您的环境中触发的检测比没有检测更糟，因为它会给防御覆盖带来虚假的信心。 我构建的补丁配置保存在 [`sysmon-lsass-patch.xml`](sysmon-lsass-patch.xml) 中供参考。**任何在 EventID 10 确实有效的 Windows 11 主机上运行此实验室的人**都可以使用该补丁 + 类似以下的规则： ``` 92038 (?i)\\lsass\.exe$ 0x(1010|1410|1438|143a|1fffff) Suspicious access to LSASS process memory (T1003.001) T1003.001 ``` ## 经验教训 1. **遥测可用性是检测的先决条件，而不是假设。** 一条语法完美但依赖于缺失日志源的规则比无用更糟。 2. **SwiftOnSecurity 的 Sysmon 配置默认是保守的。** 几种事件类型（特别是 ProcessAccess 和 PipeCreated）被作为文档注释掉了。在假设已覆盖之前，请先阅读配置。 3. **Windows 11 在重启、快照，有时在 Windows Update 活动后会静默撤销 Defender 禁用设置。** 每次攻击前都要打快照，并重新验证 Defender 状态。 4. **Wazuh 的 `` 链接功能强大但毫不留情。** 如果 Sysmon 没有首先生成父事件，则 `92052` 的子规则将永远不会触发。在调试子规则之前，请务必检查父规则是否已触发。 5. **虚拟机快照是必不可少的。** 我由于 Guest Additions 安装失败导致虚拟机崩溃，但在 30 秒内回滚到了 `Pre-Attack-2-LSASS`，项目方面零数据丢失。 ## 设置（如果您想复现） ### 前置条件 - 配备 16+ GB 内存的 Windows 11 主机 - Docker Desktop - VirtualBox - Windows 11 Enterprise Evaluation ISO ### 部署 Wazuh ``` git clone https://github.com/wazuh/wazuh-docker.git cd wazuh-docker/single-node docker-compose -f generate-indexer-certs.yml run --rm generator docker-compose up -d ``` 仪表板位于 `https://localhost`，默认管理员账号/密码为 admin/SecretPassword。 ### 构建虚拟机 1. 在 VirtualBox 中使用桥接网络安装 Windows 11 Eval 2. 禁用 Defender（关闭篡改保护 → `Set-MpPreference -DisableRealtimeMonitoring $true ...`） 3. 使用 SwiftOnSecurity 配置安装 Sysmon： ``` Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" -OutFile sysmonconfig.xml .\Sysmon64.exe -i sysmonconfig.xml -accepteula ``` 4. 安装 Wazuh 代理，针对管理器 IP 进行注册 5. 安装 Atomic Red Team： ``` IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing); Install-AtomicRedTeam -getAtomics ``` ### 部署规则 ``` docker cp local_rules.xml single-node-wazuh.manager-1:/var/ossec/etc/rules/local_rules.xml docker exec single-node-wazuh.manager-1 chown wazuh:wazuh /var/ossec/etc/rules/local_rules.xml docker exec single-node-wazuh.manager-1 /var/ossec/bin/wazuh-control restart ``` ### 运行验证攻击 ``` # Rule 100001 — encoded PowerShell powershell.exe -EncodedCommand VwByAGkAdABlAC0ASABvAHMAdAAgACcASABlAGwAbABvACAAdABlAHMAdAAnAA== # Rule 100002 — reconnaissance whoami net user # Rule 100003 — certutil LOLBin certutil -encode C:\Windows\System32\drivers\etc\hosts C:\Tools\hosts.b64 ``` 使用查询语句 `rule.id: 100001 or rule.id: 100002 or rule.id: 100003` 检查仪表板。 ## 项目产出物 | 文件 | 用途 | |---|---| | `local_rules.xml` | 这三条自定义检测规则 | | `local_rules.final.xml` | 最终规则集的快照 | | `sysmon-lsass-patch.xml` | LSASS 调查中的 ProcessAccess 配置补丁（参见上文的“未起作用的部分”） | | `evidence-myfirsthack-alerts.json` | 验证期间触发的已过滤 Wazuh 警报 | | `ARCHITECTURE.md` | 管道的 Mermaid 图表 | | `screenshots/` | 仪表板命中和规则详细信息 | ## 未来工作 - **在 Windows Server / 非 Eval 版的 Windows 11 上尝试 LSASS 检测**，以查看 EventID 10 问题是否持续存在，或者是否特定于 Eval 版本 - **添加 T1218.011 (rundll32 LOLBin) 规则**，在 comsvcs.dll 案例能够被可靠触发后，使用更广泛的命令行模式 - **调整侦察规则 (100002)** 以使用频率分析 — 单个 `whoami` 是中等严重性，但一个用户在 30 秒内执行五个侦察命令则是高严重性 - **添加等效的 Sigma 规则** YAML 版本，并使用 [sigma-cli](https://github.com/SigmaHQ/sigma-cli) 转换为 Wazuh 语法以实现可移植性 ## 许可证 本项目发布用于教育目的。代码采用 MIT 许可。SwiftOnSecurity Sysmon 配置和 Atomic Red Team 拥有各自的许可证 — 请参阅它们各自的仓库。

标签：AMSI绕过, Atomic Red Team, Conpot, DevSecOps, Docker, OISF, OpenCanary, PB级数据处理, Sigma规则, Sysmon, URL发现, Wazuh, Windows安全, 上游代理, 威胁检测, 安全基线, 安全实验室, 安全检测, 安全运维, 安全防御评估, 教学环境, 数据泄露检测, 日志管理, 目标导入, 端点安全, 红队模拟, 网络安全, 补丁管理, 请求拦截, 隐私保护