suepercrab/wazuh-soc-lab

# Wazuh SOC 检测与响应家庭实验室 一个基于 Wazuh 构建的 SOC 检测实验室。我对 Windows 和 Linux 端点发起了真实攻击，在 Wazuh 中检测到了它们，并自动封锁了其中一个端点，同时记录了我将如何对每个警报进行分类处理的过程。 - 由 Hooper 构建 **目录：** [环境](#environment) · [端点可见性](#endpoint-visibility) · [SCA 安全态势扫描](#sca-posture-scan) · [自定义规则 + 主动响应](#custom-rule--active-response) · [检测到的攻击](#attacks-detected) · [警报分类](#triage) · [我的收获](#what-i-learned-and-whats-next) ## 包含的内容 - Wazuh SIEM，已注册一个 Windows 和一个 Linux agent - 来自 Sysmon (Windows) 和 auditd (Linux) 的端点遥测数据 - 包含补救前后对比的 SCA (CIS 基准) 安全态势扫描 - 我为该环境编写并调优的自定义关联规则 - 在多次认证尝试后自动封锁攻击者 IP 的主动响应 - 已运行并检测到的攻击，映射至 MITRE ATT&CK - 警报分类记录，将每个警报判定为真实警报或误报，并附有相应理由 ## 环境 | 主机 | 角色 | IP | |------|------|-----| | Wazuh SIEM | 管理器 + dashboard (Amazon Linux 2023 OVA) | 10.0.40.60 | | Ubuntu-Endpoint | Linux 端点，agent 001 | 10.0.40.61 | | WIN11 | Windows 11 端点，agent 002 | 10.0.40.20 | | Kali | 攻击者 | 10.0.40.50 | | DC01 | 域控制器（来自我的 [AD 实验室](https://github.com/suepercrab/ActiveDirectory-Security-Lab)） | 10.0.40.10 | 宿主机是运行 VirtualBox 的 Linux Mint 机器。所有设备都在没有互联网接入的隔离内部网络（`labnet`，10.0.40.0/24）上运行 ## Wazuh 上线 部署了 Wazuh OVA 并在 10.0.40.60 上启动了 dashboard。  ## 已注册的 Agent 两个端点均已注册并处于活跃状态 — Ubuntu-Endpoint 作为 agent 001，WIN11 作为 agent 002。  ## 端点可见性 在 WIN11 上安装了 Sysmon，并将其 `localfile` 块添加到 `ossec.conf` 中，以便进程和网络遥测数据能传输到 Wazuh。在 Ubuntu 上配置了 auditd，以便记录每一条运行的命令。  这是 Linux 端的工作情况 — sudo 到 root 被捕获并触发警报：   ## SCA 安全态势扫描 针对 Ubuntu 运行了安全配置评估 (CIS 基准)。提取了基线，修复了两个集群 — sysctl 网络加固和 cron 权限，然后我再次扫描了 Ubuntu 端点 补救前：  补救后：  得分从 44% 上升到了 51%。 ## 自定义规则 + 主动响应 编写了规则 100100。当在 60 秒内来自同一源 IP 发生 8 次以上的 SSH 认证失败时，它就会触发。我使用 `` 对其进行了限定，使其仅在单一源疯狂攻击该主机时触发，而不是网络上散布的多个不相关的失败尝试。我将其级别设置为 12，并打上了 T1110 标签。 ``` 5760 Possible SSH brute force: 8+ failed logons in 60s from same source T1110 ```  然后将具有 120 秒超时的 firewall drop 主动响应绑定到它。当规则触发时，Wazuh 会在端点防火墙上自行封锁源 IP。 ## 检测到的攻击 每次攻击都在隔离实验室中运行，在 Wazuh 中被捕获，并映射到 MITRE 技术。 ### T1110 — SSH 暴力破解（检测并响应） 从 Kali 对 Ubuntu 运行了 hydra： ``` hydra -l wazuh -P /usr/share/wordlists/rockyou.txt ssh://10.0.40.61 -t 4 ``` 在大约 16 次尝试后，它停止了。规则 100100 捕获了失败爆发，主动响应在攻击中途封锁了 Kali 的 IP，导致剩余的任务卡在死连接上。攻击被切断是响应起作用的证明。  规则 100100（级别 12）被触发，规则 651 确认 firewall-drop 已启动：   `active-responses.log` 记录了整个过程 — 添加了攻击者 IP，然后在 120 秒超时结束后将其删除：  ### T1059.001 — 编码的 PowerShell 在 WIN11 上运行了混淆的 PowerShell 命令 — base64 载荷，隐藏窗口，无配置文件。与真实恶意软件隐藏其运行内容的模式相同 ``` powershell.exe -NoProfile -WindowStyle Hidden -EncodedCommand ```  载荷是无害的（只是一个 `Write-Host` 测试字符串）。被捕获的是命令行模式。Sysmon 在进程创建时记录了完整的命令行，普通的 Windows 日志记录根本不会显示 `-EncodedCommand` 参数。  规则 92057（级别 12）对其进行了标记。展开的警报包含了一切；完整的命令行、父进程（作为 `WIN11\vboxuser` 的 `powershell.exe`）、文件哈希和完整性级别：  ### T1046 — 网络扫描（Wazuh 看不到的内容） 从 Kali 发起了隐蔽扫描： ``` nmap -sS 10.0.40.61 ``` 在 Wazuh Dashboard 中没有看到警报，这是预料之中的。Wazuh 是基于主机的；它依赖日志工作。SYN 扫描永远不会完成握手，因此没有服务接受连接，也没有任何内容被记录。我在我的 [AD 安全实验室](https://github.com/suepercrab/ActiveDirectory-Security-Lab) 中遇到了同样的盲点 — 由于相同的原因，Splunk 也看不到扫描。两个不同的 SIEM，相同的盲点，因为两者都在使用主机日志而不是监控网络流量。 ### 总结 | 技术 | MITRE | 工具 | 捕获方式 | |-----------|-------|------|-----------| | SSH 暴力破解 | T1110 | hydra | 规则 100100 + 主动响应 (651) | | 编码的 PowerShell | T1059.001 | powershell.exe | Sysmon → 规则 92057 | | 网络扫描 | T1046 | nmap `-sS` | 未检测到，由于 SIEM 盲点 | ## 分类 描述了我发现的每个警报，它是否需要引起关注，以及我将如何响应。 ### 事件 1 — 真实警报：SSH 暴力破解 - 警报：规则 100100，级别 12 — “可能的 SSH 暴力破解：60 秒内来自同一源的 8 次以上登录失败” - 调查：`data.srcip` 显示每次失败都来自同一台主机，即 Kali 攻击者 (10.0.40.50)。`rule.frequency` 确认在 60 秒窗口内有 8 次失败。像这样单一源攻击单一服务是有针对性的暴力破解，而不是单纯输错密码的人。 - 结论：真实警报。 - 响应：触发主动响应（规则 651）并将该 IP 封锁了 120 秒 — 已在 `active-responses.log` 中确认。攻击停滞。 - 在生产环境中：使封锁永久化，调查源主机，并检查该账户是否应该被访问。 ### 事件 2 — 真实警报：编码的 PowerShell - 警报：规则 92057，级别 12 — “Powershell.exe 生成了一个 powershell 进程，该进程执行了一条 base64 编码的命令” - 调查：从命令行中提取出 base64 并解码 — `Write-Host "T1059 encoded command test - lab only"`。这些标志（`-EncodedCommand -WindowStyle Hidden -NoProfile`）是恶意软件隐藏其运行内容的常用方式。 - 结论：真实警报（实验室测试）。在现实世界中，无论它解码出什么，这种命令行模式都会引起关注。 - 在生产环境中：隔离主机，找到启动 PowerShell 的父进程，并在其他机器上搜寻相同的模式。 - 注意：解码载荷而不是仅仅阅读警报标题，这一步骤能告诉你隐藏的命令是否安全。 ### 事件 3 — 误报：PowerShell 策略测试 - 警报：规则 92205，级别 9 — WIN11 上的 PowerShell 活动 - 调查：触发它的内容是 `__PSScriptPolicyTest_`，这是 Windows 为检查自身执行策略而编写的一个临时脚本。这是正常的操作系统行为，而不是攻击者。  - 结论：误报。 - 在生产环境中：调优或抑制它，使其不再占用分析师的精力。 ### 事件 4 — 误报：“在恶意软件文件夹中释放了可执行文件” - 警报：规则 92213，级别 15 — “在恶意软件常用的文件夹中释放了可执行文件” - 背景：它与上述编码的 PowerShell 测试在同一时间戳不断触发。 - 调查：展开事件后发现，被标记的可执行文件是 `powershell.exe` 本身，从 `C:\Windows\System32\WindowsPowerShell\v1.0\` 运行。规则集将该路径中的 PowerShell 视为恶意软件文件夹的命中。父进程和哈希与真实的 Microsoft 签名二进制文件匹配 — 这是由我的 T1059 测试发起的操作系统运行其自身已签名的可执行文件。  - 结论：误报，是我自己测试的副作用。 - 在生产环境中：将其与已知活动（这里是我的测试）相关联，并调优规则以排除已签名的系统二进制文件。 - 注意：这个警报在级别 15（面板上的最高严重级别）触发，结果却是良性的。严重性数字告诉你应该去查看，而不是答案本身。如果不进行分类就盲目追逐每一个最高严重级别的警报，可能会导致倦怠，并可能导致真实警报被忽略 ## 我的收获与下一步计划 这个实验室教会我的内容： - 基于主机的检测在端点层面上非常深入。它可以详细查看进程创建、命令行和文件更改，但隐蔽的网络扫描对它是不可见的。真正的覆盖范围需要同时部署 HIDS 和网络传感器。 - 严重性是分类的起点，而不是可靠的结论。我的四个警报中有两个是误报，其中一个是级别 15。在升级每个威胁之前，你必须对其进行调查。 - 命令行就是证据。编码的 PowerShell 检测完全依赖于 Sysmon 捕获的完整命令行，如果没有它，该警报将几乎毫无用处。 - 编写自己的规则比任何内置规则教会我的都多。Wazuh 已经内置了针对暴力破解的标记，但亲自构建 100100 帮助我理解了设计未来规则所需的语法，以及如何将语法转换为纯文本推理。 我接下来要添加的内容： - 一个网络传感器（Zeek 或 Suricata），以填补 T1046 的空白，并捕获 Wazuh 和其他 SIEM 无法检测到的侦察活动。 - 随着时间的推移增加更多的检测 — 凭证转储、计划任务持久化、横向移动 — 作为单独的提交添加到此仓库中。 - 执行调优以抑制我在这里发现的误报，从而使信噪比不断提高。 我计划随着时间的推移，随着我在这方面的知识和经验的增长，继续改进并详细记录这个仓库。 ## 展示的技能 - SIEM 部署与管理 — Wazuh 管理器、agent 注册、端点配置 - 检测工程 — 编写并调优了具有环境特定范围的自定义关联规则 - 自动化响应 — 主动响应防火墙封锁，已进行端到验证 - 端点遥测 — Sysmon 和 auditd - 安全态势评估 — SCA (CIS) 扫描，具有可衡量的补救措施 - 攻击模拟 — 运行并检测到了 T1110 和 T1059.001，映射至 MITRE ATT&CK - 分类 — 四个事件结论（两个真实警报，两个误报），包括排除了一个级别 15 的误报 - 了解局限性 — 记录了为什么 Wazuh 会有盲点，以及为什么必须将 Wazuh 与其他服务结合使用 ## MITRE ATT&CK 覆盖范围 | 战术 | 技术 | ID | |--------|-----------|-----| | 凭证访问 | 暴力破解 | T1110 | | 执行 | 命令和脚本解释器：PowerShell | T1059.001 | | 发现 | 网络服务发现 | T1046 *(盲点)* |

标签：Wazuh, 安全实验环境, 安全运营, 扫描框架, 自动化响应