Zeltoc/wazuh-brute-force-detection-lab

# Wazuh SIEM 实验环境 - 暴力破解与凭证访问检测 **工具：** Wazuh 4.x, Sysmon (SwiftOnSecurity 配置), NetExec (nxc), Hydra **平台：** Proxmox 家庭实验室 - Ubuntu 22.04 (Wazuh 管理端), Windows 11 (受监控终端) **MITRE ATT&CK：** T1110.001, T1550.002, T1531, T1078 ## 目标 搭建 SIEM 环境以检测针对 Windows 终端的暴力破解攻击，确认内置检测规则能正确触发，然后编写自定义规则以减少噪音并提高默认设置的准确度。记录从攻击者的首次 NTLM 握手到账户锁定的完整检测链。 ## 环境 | VM | OS | 角色 | IP | |---|---|---|---| | wazuh-manager | Ubuntu 22.04 | Wazuh 服务器 + 仪表盘 | 192.168.1.x | | DESKTOP-72VLLG0 | Windows 11 | 受监控终端 (Wazuh agent + Sysmon) | 192.168.1.162 | | kali | Kali Linux | 攻击者 | 192.168.1.36 | Windows 虚拟机上使用 [SwiftOnSecurity 配置](https://github.com/SwiftOnSecurity/sysmon-config)部署了 Sysmon。Wazuh agent 配置为同时收集 Security 事件通道和 Sysmon Operational 通道的数据。 ## 攻击模拟 ### 场景 1 - 通过 SMB 进行 NTLM 暴力破解 (T1110.001) ``` nxc smb 192.168.1.162 -u Administrator -p ~/big-list.txt ``` NetExec 在尝试凭证之前会执行 NTLM 认证握手。这在记录任何失败尝试*之前*表现为一次匿名 NTLM 登录（事件 ID 4624，登录类型 3，目标：ANONYMOUS LOGON）——这一特征本身就是非常有用的检测信号（见下文规则 100004）。 握手完成后，每次密码尝试都会生成一个 4625（登录失败）事件，包含： - `logonType: 3` - 网络登录，非交互式 - `authenticationPackageName: NTLM` - `subStatus: 0xc000006a` - 账户存在，密码错误 - `ipAddress: 192.168.1.36` - 攻击者来源 `subStatus` 的区分非常重要。`0xc000006a` 表示账户存在但密码错误。`0xc0000064` 表示账户根本不存在。攻击者利用这一点在发起全面暴力破解之前确认有效的用户名。在真实环境中，如果在密集的失败尝试中持续观察到 `0xc000006a`，说明攻击者已经知道该账户是有效的。 最终该账户被锁定，生成一个 4740 事件。 ## 检测结果 - 内置规则 以下 Wazuh 内置规则在没有任何自定义配置的情况下被触发： | 规则 ID | 级别 | 描述 | 事件 | |---|---|---|---| | 60122 | 5 | 登录失败 - 未知用户或密码错误 | 4625（每次尝试） | | 60204 | 10 | 多次 Windows 登录失败 | 4625 密集爆发（聚合） | | 60115 | 9 | 用户账户已锁定（多次登录错误） | 4740 | | 92652 | 6 | 远程登录成功 - ANONYMOUS LOGON，可能是哈希传递攻击 | 4624 (NTLM 握手) | | 60118 | 3 | Windows 工作站登录成功 | 4624（本地 UAC 提权 - 良性） | ### 意外发现 - 规则 92652 在任何 4625 失败事件出现之前，Wazuh 对来自 `192.168.1.36` 的 ANONYMOUS LOGON 触发了规则 92652。这是 NetExec 正在执行其 NTLM 协商握手。Windows 将其记录为一次成功的匿名登录（4624），Wazuh 正确地将其标记为潜在的哈希传递攻击预备指标。 在真实的 SOC 中，此警报会在暴力破解量警报*之前*触发——根据您的环境，这是一个更早且可能具有更高置信度的信号。来自外部主机的匿名 NTLM 登录在非常特定的遗留配置之外是极不寻常的。 ### 发现的误报 - 规则 60118 在 22:05 出现了两次 60118 "Windows 工作站登录成功"事件。审查原始事件数据显示，这些事件来自 `consent.exe`，通过 `::1`（本地主机）用于本地账户——这是机器上的 UAC 提升提示，而非成功的暴力破解。攻击者从未得逞；Administrator 账户在任何密码尝试成功之前就已锁定。 这值得记录，因为它代表了真实的分析师工作：在暴力破解序列中间出现的登录成功警报看起来很惊人，直到您阅读了源 IP 和进程名称。 ## 自定义检测规则 内置规则涵盖了基本场景，但存在一些值得解决的盲区： - **60122** 会对级别为 5 的*任何*失败登录触发 - 设计宽泛，但会因服务账户、本地身份验证失败等产生噪音。 - **60204** 聚合了失败事件，但未限定于特定的攻击特征，如仅限 NTLM 或针对特权账户。 - **92652** 会对*所有*匿名 NTLM 登录触发，包括来自 `::1` 的良性本地主机事件——这在正常 Windows 操作中会频繁产生误报。 下面的自定义规则针对上述每一点进行了收紧。 ### 规则文件：`local_rules.xml` ``` 60122 (?i)administrator 3 NTLM NTLM network authentication failure targeting Administrator account from $(win.eventdata.ipAddress) T1110.001 brute_force,authentication_failed, 100002 CRITICAL: Brute force attack - 5+ NTLM failures against Administrator within 120s [T1110.001] T1110.001 brute_force,authentication_failed, 92652 ^(?!::1$|127\.0\.0\.1$|-).* NTLM Anonymous NTLM remote logon from external host $(win.eventdata.ipAddress) - brute force handshake or pass-the-hash staging [T1550.002] T1110.001 T1550.002 brute_force,authentication_success,pth_staging, ``` ## 检测结果 - 自定义规则 | 规则 ID | 级别 | 描述 | 触发情况 | |---|---|---|---| | 100004 | 10 | 来自外部主机的匿名 NTLM 握手 | 在失败开始前的首个警报 | | 100002 | 6 | 来自 192.168.1.36 针对 Administrator 的 NTLM 失败 | 每次尝试 | | 100003 | 12 | 严重 (CRITICAL) - 120 秒内出现 5 次以上失败 | 触发并在攻击持续期间重新触发 | 规则 100003 在攻击时间窗口内触发了两次，因为频率计数器会重置并在新事件到达时重新触发。在生产环境中，这使得不断升级的警报在持续攻击期间保持活跃，而不是触发一次后就归于平静。 ## 完整攻击链时间轴 ``` 22:20:00.413 100004 (lvl 10) - Anonymous NTLM logon from 192.168.1.36 NetExec NTLM handshake, pre-auth recon MITRE: T1550.002 22:20:05 100002 (lvl 6) - 4625 failure #1, Administrator, NTLM, logonType 3 22:20:07 100002 (lvl 6) - 4625 failure #2 22:20:09 100002 (lvl 6) - 4625 failure #3 22:20:11 100002 (lvl 6) - 4625 failure #4 22:20:13 100003 (lvl 12) - CRITICAL: 5th failure, frequency threshold hit MITRE: T1110.001 22:20:15–21 100002 (lvl 6) - Continued failures 22:20:23 100003 (lvl 12) - CRITICAL: re-triggered 60115 (lvl 9) - Account lockout (4740), Administrator MITRE: T1531 ``` ## subStatus 参考 4625 事件中的 `subStatus` 字段对分类非常有用，值得了解： | subStatus | 含义 | 分析师备注 | |---|---|---| | `0xc000006a` | 账户存在，密码错误 | 本实验中的所有失败均属此情况 - 确认攻击者正在针对真实账户 | | `0xc0000064` | 账户不存在 | 用户名枚举，攻击者正在猜测账户 | | `0xc0000234` | 账户已锁定 | 攻击已触发锁定策略 | | `0xc0000072` | 账户已禁用 | 账户存在但已被禁用 | ## 经验教训 **匿名登录是最早的信号。** 规则 100004 在任何 4625 事件之前触发。在真实环境中，针对此模式（外部 NTLM 匿名登录）进行调优，能让您在基于数量的规则有时间聚合之前，在暴力破解检测中抢占先机。 **subStatus 提供的信息比警报描述更多。** 内置警报显示“未知用户或密码错误”——而 subStatus 会具体说明是哪一种。这种区别会影响分类优先级，并有助于判断您正在处理的是枚举攻击还是针对性的凭证攻击。 **误报意识很重要。** 暴力破解序列中间出现的 60118 登录成功起初看起来很可疑。通过阅读原始事件数据——`consent.exe`，来源 `::1`，本地账户——立刻澄清了事实。习惯阅读原始事件数据而不仅仅是警报描述，正是区分有价值分类与噪音的关键。 **规则链比单事件检测更有用。** 仅 100002 就会生成大量警报。而以它为基础并带有频率阈值的 100003 才使检测具有可操作性——这就是“有一些失败”和“现在有东西正在主动攻击此账户”之间的区别。 ## 仓库结构 ``` wazuh-brute-force-detection-lab/ ├── README.md ├── alerts/ │ └── wazuh-alerts-4.x-2026.05.06#*.json ├── rules/ │ └── local_rules.xml └── screenshots/ ├── 01-dashboard-overview.png ├── 02-4625-flood-filtered.png ├── 03-full-event-timeline.png ├── 04-attack-chain-closeup.png └── 05-custom-rules-firing.png ``` ## 参考 - [Wazuh 规则语法](https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html) - [SwiftOnSecurity Sysmon 配置](https://github.com/SwiftOnSecurity/sysmon-config) - [MITRE ATT&CK T1110.001 - 暴力破解：密码猜测](https://attack.mitre.org/techniques/T1110/001/) - [MITRE ATT&CK T1550.002 - 哈希传递攻击](https://attack.mitre.org/techniques/T1550/002/) - [Windows 安全事件 ID 参考 - Ultimate Windows Security](https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/)

标签：AMSI绕过, Cloudflare, Conpot, Hydra, MITRE ATT&CK, NetExec, NTLM暴力破解, Proxmox家庭实验室, SMB协议, Sysmon, Wazuh SIEM, Windows安全, 事件日志分析, 凭证获取, 威胁检测, 安全实验, 安全运营, 扫描框架, 攻击模拟, 攻击溯源, 日志降噪, 网络认证, 自定义检测规则, 蓝队建设, 驱动签名利用, 高保真检测