fozithebear/Virtualized-SOC-Malware-Analysis-Home-Lab

# 虚拟化 SOC 与恶意软件分析家庭实验室 一个基于 VMware 构建的两阶段安全运营实验室，模拟针对 故意配置脆弱的 Windows Server 的真实攻击链（暴力破解、凭据转储、横向移动），同时部署了 **Splunk** 和 **Wazuh** 作为 SIEM 处理相同的遥测数据。该实验室是本报告中每个检测、仪表板和 IR 产物的来源。 ## 目录 - [架构](#architecture) - [环境](#environment) - [阶段 1 — Splunk 部署](#stage-1--splunk-deployment) - [阶段 2 — Wazuh（容器化）](#stage-2--wazuh-containerized) - [攻击模拟与检测](#attack-simulations--detection) - [1. 暴力破解 (Hydra) → RDP/NTLM](#1-brute-force-hydra--rdpntlm) - [2. 凭据转储 (Mimikatz)](#2-credential-dumping-mimikatz) - [3. 横向移动 (PsExec)](#3-lateral-movement-psexec) - [检测工程：失败之处与修复方法](#detection-engineering-what-failed--what-fixed-it) - [MITRE ATT&CK 覆盖范围](#mitre-attck-coverage) - [经验教训与重建计划](#lessons--what-id-rebuild) - [参考](#references) ## 架构 该实验室是**双宿主**的，以平衡两个相互竞争的需求：足够的隔离性，以便在本地家庭网络安全地运行活体恶意软件和暴力破解流量；以及足够的互联网访问权限，以便在需要时拉取更新、包和威胁情报源。 ``` flowchart TB subgraph Internet["Internet"] direction LR Updates["Updates, threat feeds,
Wazuh/Splunk downloads"] end subgraph Host["Host Machine (macOS)"] direction LR HostNet["Host network
192.168.86.0/24"] end subgraph VBox["VMware Workstation"] direction TB end Host --> VBox subgraph LabNet["Isolated Lab Network — Host-Only (192.168.86.0/24)"] direction TB Kali["Kali Linux
attacker
192.168.86.130
2 vCPU · 2 GB · 20 GB"] Windows["Windows Server 2025
victim
192.168.86.129
1 vCPU · 2 GB · 64 GB
Sysmon (SwiftOnSecurity →
Olaf Hartong modular)
Wazuh Agent"] Ubuntu["Ubuntu Server
SIEM host
192.168.86.131
2 vCPU · 16 GB · 50 GB"] end VBox --> LabNet subgraph UbuntuBox["Ubuntu Server internals"] direction TB Docker["Docker Engine"] subgraph Stack["docker-compose stack"] Wazuh["Wazuh Manager
+ Indexer
+ Dashboard
:55000 / :9443"] end Docker --> Stack end Ubuntu -. "Wazuh Agent
TCP 1514" .-> Stack Kali -. "RDP 3389
SMB 445
WinRM 5985" .-> Windows Windows -. "Sysmon +
Security/Application
event logs" .-> Stack Internet -. "Outbound only
(toggleable via script)" .-> Ubuntu Internet -. "Pull packages" .-> Kali style Kali fill:#2b1d1d,stroke:#ff2e63,color:#fff style Windows fill:#1d2b2b,stroke:#00ffd5,color:#fff style Wazuh fill:#0a0e14,stroke:#00ffd5,color:#fff style Docker fill:#0a0e14,stroke:#00ffd5,color:#fff style Internet fill:#0a0e14,stroke:#666,color:#fff style Host fill:#0a0e14,stroke:#666,color:#fff ``` **为什么选择双宿主而不是仅仅使用一个适配器？** 每个 VM 上的单个 NAT 适配器仍然会通过主机的家庭网络路由流量。由于涉及 Mimikatz、PsExec 和暴力破解流量，其爆炸半径是不可接受的。修复方案如下： - **适配器 1 — Host-Only (192.168.86.0/24)：** 三个实验室 VM 所在的唯一网络。Kali 可以访问 Windows，Windows 可以访问 Ubuntu SIEM，但都无法访问家庭 LAN。 - **适配器 2 — NAT：** 仅限出站互联网。在 Kali 上默认通过一个简单的 bash 切换命令禁用（`ifdown eth1` / `ifup eth1`），因此除非我明确希望它拉取包，否则攻击者 VM 仅与实验室子网通信。 真正的 SOC 分析师会认识到，这与驱动生产网络分段的逻辑相同：分析师工作站和受监控的终端位于不同的信任区域，而 SIEM 层则位于其自己的区域。 ## 环境 | 组件 | 规格 | 角色 | |---|---|---| | **Kali Linux** | 2 vCPU, 2 GB 内存, 20 GB 磁盘 | 攻击平台 (Hydra, Nmap, Mimikatz, Impacket) | | **Windows Server 2025** | 1 vCPU, 2 GB 内存, 64 GB 磁盘 | 受害者 — 故意削弱 (Defender 关闭, SMBv1 开启, 弱本地账户, 无 NLA 的 RDP) | | **Ubuntu Server 22.04** | 2 vCPU, 16 GB 内存, 50 GB 磁盘 | SIEM 主机 (Docker + Wazuh stack) | | **VMware Workstation** | — | Hypervisor；提供上述双 NIC 拓扑 | | **Sysmon** | SwiftOnSecurity config → Olaf Hartong modular (Research) | Windows 上的终端遥测丰富 | Windows VM **故意**采用最差实践配置，以便检测内容有目标可触发。请勿在实验室外部署任何这些设置。 ## 阶段 1 — Splunk 部署 在 Wazuh 之前，实验室运行的是 Splunk。动机是一样的：一个合适的 SIEM，而不是在 Event Viewer 上使用 `grep`。Windows 上的 Universal Forwarder 是关于 agent 到 indexer 管道连接的第一堂真正课程。 第一个端到端检测是对本地 Administrator 账户的 Hydra 暴力破解，使用以下 SPL 捕获： ``` index=* sourcetype="WinEventLog:Security" (EventCode=4625 OR EventCode=4624) | eval Status=case(EventCode=4625, "Failed Attempt", EventCode=4624, "Successful Login") | timechart span=1m count by Status ``` 图表显示在 04:01 来自单一来源的 **8 次失败登录尝试** — 这是密码喷射的教科书式特征。同样的调查继续深入到 Event 4625 的细节中： | 字段 | 值 | |---|---| | Account Name | `Administrator` | | Workstation Name | `kali` | | Source Network Address | `192.168.86.130` | | Source Port | `0` | | Logon Process | `NtLmSsp` | | Authentication Package | `NTLM` | | Failure Reason | `Unknown user name or bad password` | | Status / Sub Status | `0xC000006D` / `0xC000006A` | 与 Kali 子网匹配的源 IP 就是铁证 — 这就是为什么在告警级别（而不仅仅是计数）记录攻击者 IP 值得额外编写 SPL 的原因。 第一个 SOC 仪表板是一个单一面板：一个针对受害用户名饼图的失败登录尝试威胁仪表，并附带违规尝试的时间轴。这很基础，但对于建立“事件源 → indexer → search head → dashboard”的心智模型来说是一个坚实的基础。 **对 Splunk 的评价：** 它运行良好，SPL 非常强大，而且仪表板是一流的。对于学习型实验室来说，它很昂贵，而且免费层级有摄取限制。转向 Wazuh 是出于成本考虑，也是真正有兴趣看看开源的 XDR 级 SIEM 能直接提供什么功能。 ## 阶段 2 — Wazuh (容器化) Wazuh 是比 Splunk 更重的技术栈：manager + indexer + dashboard，每个都有各自的资源配置文件。最初计划在一个 4 GB 的 VM 上与 Splunk 并行运行，但显然失败了（启动时有 50 GB 的日志量，manager 服务发生 OOM）。容器化方法是正确的选择，但需要真正下功夫才能搞定。 **有效的启动顺序：** 1. 全新的 Ubuntu Server 22.04 安装。 2. 安装 Docker + `docker-compose`。 3. 拉取 Wazuh single-node stack YAML。 4. 在主机上设置 `vm.max_map_count=262144`（Elasticsearch 要求）。 5. 扩展 LVM 逻辑卷 — 默认的 Ubuntu Server 安装仅将 50 GB 虚拟磁盘中的约 24 GB 分配给根 LV，而 Wazuh 在一小时内就将其填满了。 6. 使用 manager 的 IP 在 Windows 主机上部署 Wazuh agent，在 `ossec.conf` 中**明确**设置 — 如果没有这个，agent 会静默注册失败。 **第一个 agent 注册后的仪表板：** 标准的 Wazuh 概览以摘要形式显示了 agent 的终端安全态势 — agent 数量、按严重程度划分的告警明细、MITRE ATT&CK 快捷方式，以及开箱即用的 IT 卫生/合规性面板（PCI DSS、GDPR、HIPAA、CIS 基准）。首次摄取时值得注意的数据如下： | 面板 | 首次摄取时的值 | |---|---| | Critical alerts (24h) | 0 | | High alerts (24h) | 0 | | Medium alerts (24h) | 316 | | Low alerts (24h) | 647 | | Active agents | 1 | | MITRE techniques observed | 9 Impact, 1 Defense Evasion | 在没有任何攻击流量的情况下的漏洞数量是更有趣的数字。针对 Wazuh 内置漏洞扫描程序，默认 Windows Server 2025 安装上的漏洞检测面板产生了以下结果： | 严重性 | 数量 | |---|---| | Critical | 12 | | High | 574 | | Medium | 264 | | Low | 6 | 这对于任何“此 VM 是否已具备生产环境条件”的决策来说都是一个有用的基准 — 并且有力地证明了为什么即使是全新安装的 Windows 主机在真实环境中也能从持续的漏洞扫描中受益。 ## 攻击模拟与检测 下面的每个场景都遵循相同的结构：**设置 → 执行 → 检测 → 结果**。引用的每个检测都是在该实验室中触发的真实 Wazuh rule ID，规则描述完全照搬自告警。 ### 1. 暴力破解 → RDP/NTLM **设置。** 创建了一个具有弱密码的本地账户 `Administrator`。启用不带 Network Level Authentication 的 RDP。Hydra 从 Kali 主机在实验室子网上针对 Windows 主机运行。 **执行。** ``` hydra -l Administrator -P /usr/share/wordlists/rockyou.txt \ -t 4 -V 192.168.86.129 rdp ``` **检测 — Splunk 阶段（上面的 4625 + 4624 SPL）：** 一分钟内有 8 次失败的登录尝试，来自单一源 IP。Splunk 将模式可视化；其余工作由分析师完成。 **检测 — Wazuh 阶段（rule 1014, level 10）：** Hydra 最终获得了有效的凭据。level-10 严重性是因为规则链旨在准确标记暴力破解后“刚产生 4625 风暴的主机首次成功进行 NTLM 登录”的场景。**这是一枪毙命的告警。** 看到此规则在生产网络上触发的 SOC L1 会立即开具 P1 工单。 **结果。** 本地 Administrator 账户的凭据泄露。该账户被重置，并且在任务持续期间将源 IP 添加到了监视列表中。 ### 2. 凭据转储 **设置。** Windows VM 启用了 SMBv1 并具有可写的 `C$` 共享（本地管理员的默认设置）。Mimikatz 暂存在 Kali 上，并通过 SMB 投放到受害者机器。 **执行。** ``` # 在 Kali 上 — 通过 SMB 将 mimikatz 投递到受害者的 C: 盘 smbclient //192.168.86.129/C$ -U Administrator > put mimikatz.exe # Pivot 到 Impacket PsExec 进行执行 impacket-psexec Administrator:'Admin!'@192.168.86.130 C:\> C:\mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit" ``` **检测 — 文件投放（rule 92218, level 6）：** 这是当二进制文件通过 SMB 落入 `C:\` 时触发的 Wazuh 规则，对于合法的可执行文件来说，这是一个不寻常的路径。源 IP 同样是 `192.168.86.130`。 **检测 — 服务安装（rule 67027 / 92650, level 3 / 12）：** 针对其映像路径位于 `C:\` 中可疑二进制文件的全新服务发出 level-12 告警，这种类型的检测不需要已知的恶意签名。它是根据行为的**特征**触发的，这正是它对新型工具仍然有用的原因。 **检测 — 命令行（Sysmon + 4688 结合 audit policy）：** 完整的命令行被保留在告警中： ``` C:\mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit" ``` 这正是 **Advanced Audit Policy Configuration → Detailed Tracking → Include Command Line in Process Creation Events** 设置发挥关键作用的地方。如果没有它，告警只会显示 `mimikatz.exe ran`；有了它，就能捕获完整的意图。 **结果 — 以及一个重要的失败模式。** `sekurlsa::logonpasswords` 模块**没有**在 Wazuh 告警中产生明文凭据。原因：Windows Server 2025 上的 **Credential Guard** 将 LSASS 进程与任何非 TrustedInstaller 进程隔离 — 包括 admin 上下文下的 Mimikatz。token 模拟成功（`NT AUTHORITY\SYSTEM`），但对 LSASS 内存的读取被阻止了。 另一种 `lsadump::sam` 模块，它读取的是 SAM 注册表配置单元而不是 LSASS，该方法仍然有效并转储了 NTLM 哈希： ``` Administrator:500: aad3b435b51404ee:aad3b435b51404ee: 580b16d486d8d2cafa00b314d41fa396::: ``` 这是我认为对初级 SOC 分析师最有用的报告部分：**实验室遇到了真正的现代防御，并且检测链（文件投放 → 服务安装 → 异常 cmd → 命令行捕获）仍然实现了端到端的触发。** 即使在实际攻击目标被部分阻止时仍能触发的检测，比仅在成功入侵时才触发的检测更有价值。 ### 3. 横向移动 **设置。** 在 Mimikatz 运行之后，同一台 Kali 机器尝试使用 Impacket 的 PsExec 对同一受害者进行横向移动（在此实验室中，“横向”目标是单独子网上的第二个受害者；为了模拟，使用同一台主机以保持实验室的最小化）。 **执行。** ``` impacket-psexec Administrator:'Admin!'@192.168.174.130 \ cmd.exe # Impacket 将 KKtqVIHf.exe 上传到 ADMIN$，创建服务 RlJW， # 执行，返回 nt authority\system ``` **检测 — 随机二进制文件创建的服务（rule 92307, level 3）：** 这里有趣的信号是二进制文件名称。Impacket 每次执行时会生成随机的 8 字符名称（`KKtqVIHf.exe`、`LovMhziA.exe`，服务名为 `sJXO`）。一个由 8 个随机字符组成的服务名指向昨天还不存在的 `C:\` 二进制文件，这是高保真的 PsExec 特征。Wazuh 的 `syscheck` + `sysmon` 集成加上 `New-Windows-Service-Created` 规则恰好涵盖了这种情况。 **结果。** 检测到基于服务的横向移动，攻击者在目标上实现了 `nt authority\system`。检测在文件创建时触发，早于服务启动 — 如果有真正的 SOC 在监控，其速度足以采取行动。 ## 检测工程：失败之处与修复方法 如果实验室一切都在第一次正常工作，那它就失去了意义。以下是我遇到的实际问题，按发生顺序排列。 ### 1.map 扫描未生成告警 **症状。** 从 Kali 运行了 `nmap -sS 192.168.86.129`。Wazuh 仪表板保持安静。Windows 上的 `pfirewall.log` 显示了连接；Wazuh 却没有将它们显露出来。 **根本原因。** 默认的 Wazuh agent 配置明确排除了 Event ID 5156（Windows 防火墙允许连接通过）和 5157（Windows 防火墙阻止了连接）— 它们在生产环境中非常嘈杂。 **修复方案。** `secpol.msc` → Advanced Audit Policy Configuration → **Object Access** → 启用 *Audit Filtering Platform Connection* 和 *Audit Filtering Platform Packet Drop*，包括 Success 和 Failure。Wazuh 随后开始显示连接事件。 **经验教训。** 不要盲目相信 `ossec.conf` 中的默认 `` 块。它们针对生产环境的噪音进行了优化；而实验室需要相反的立场。 ### 2. Sysmon 配置过滤掉了感兴趣的事件 **症状。** Sysmon 已安装，但相对于实际活动，实验室的告警显得有些单薄。 **根本原因。** SwiftOnSecurity 配置经过生产环境调优以忽略噪音。此实验室中的大多数攻击 — 尤其是那些远程发起的攻击 — 都属于“被忽略”的范畴。 **修复方案。** 切换到 **Olaf Hartong 的 Sysmon-Modular**（*Research* 变体）。它默认记录更多事件，并且模块化结构使得添加/删除 include 规则变得容易，而无需重写整个配置。 **经验教训。** 正确的 Sysmon 配置取决于您要防御什么。生产环境 ≠ 研究环境。 ### 3. LVM 分区为 24 GB 而不是 50 GB **症状。** Wazuh 服务拒绝启动。`systemd` 中没有错误，`journalctl` 中也没有错误。直接挂掉。 **根本原因。** 默认的 Ubuntu Server 安装程序仅将 50 GB 虚拟磁盘中的约 24 GB 分配给根逻辑卷。Wazuh 在首次运行时就将其填满了。 **修复方案。** 使用 `lvextend` 扩展 LV，并使用 `resize2fs` 调整文件系统大小。这是永久性的修复。 **经验教训。** 容器化技术栈中磁盘已满的故障通常表现为不透明的服务启动失败。每次都要首先检查 `df -h`。 ### 4. Wazuh agent 未注册 — 静默 **症状。** Agent 安装在 Windows 上，服务已启动，但 manager 中从未显示它。Agent 日志中也没有错误消息。 **根本原因。** Windows 端的 `ossec.conf` 没有明确设置 manager IP。Agent 尝试通过默认广播来查找它，但静默失败了。 **修复方案。** 在 `ossec.conf` 中显式设置 `

192.168.86.131

` 并重启 agent 服务。 **经验教训。** 阅读实际的日志文件，而不仅仅是 `systemctl status`。Wazuh 的 agent 端日志非常详细；答案就在其中。 ## MITRE ATT&CK 覆盖范围 | 战术 | 技术 | 子技术 | 实验室证据 | |---|---|---|---| | **Credential Access** | T1110 Brute Force | T1110.001 Password Guessing | Hydra → 8 × Event 4625 (Splunk) | | **Credential Access** | T1003 OS Credential Dumping | T1003.002 Security Account Manager | `lsadump::sam` 输出 (Mimikatz) | | **Credential Access** | T1003 OS Credential Dumping | T1003.001 LSASS Memory (被 Credential Guard 阻止) | `sekurlsa::logonpasswords` 尝试 (Mimikatz) | | **Lateral Movement** | T1021 Remote Services | T1021.002 SMB/Windows Admin Shares | `smbclient` 投放，`ADMIN$` 滥用 (rule 92218) | | **Lateral Movement** | T1569 System Services | T1569.002 Service Execution | Impacket PsExec 服务安装 (rules 67027, 92307, 92650) | | **Execution** | T1059 Command and Scripting Interpreter | T1059.001 PowerShell, T1059.003 Windows Command Shell | `cmd.exe` 链，异常-cmd rule 92052 | | **Defense Evasion** | T1027 Obfuscated Files or Information | — | 随机命名的 PsExec 服务二进制文件 | | **Defense Evasion** | T1562 Impair Defenses | T1562.001 Disable or Modify Tools | 受害者上的 Defender 被禁用（故意的） | | **Persistence** | T1543 Create or Modify System Process | T1543.003 Windows Service | Mimikatz / PsExec 服务安装 (rule 92650) | | **Impact** | (观察到) | — | Wazuh MITRE 面板 — 首次摄取时 9 个 Impact，1 个 Defense Evasion（漏洞扫描程序噪音） | ## 经验教训与重建计划 **我艰难学到的教训：** 1. **默认的 SIEM 配置是针对生产环境噪音而非实验室信号进行优化的。** Wazuh 排除 5156/5157 防火墙事件的默认设置，在拥有 1 万个终端的部署中是正确的选择，但对于单台 VM 的实验室来说却是错误的。阅读每一个 `` 块。 2. **Audit policy 是检测的基础底线。** 如果 OS 没有生成 SIEM 要匹配的事件，那么 SIEM 就毫无用处。命令行审计（4688 结合 `Include Command Line`）和对象访问审计（5156/5157）是将该实验室从“漂亮的仪表板”变成“真正的检测”的两个设置。 3. **Credential Guard 是真实的，而且它是现代 Windows Server 上的默认设置。** 初级分析师在阅读较旧的 Mimikatz 教程时，会因为 `sekurlsa::logonpasswords` 静默失败而感到困惑。知道 **SAM 转储仍然有效** 是实用的结论。 4. **Sysmon 配置是一个项目，而不是一个设置。** SwiftOnSecurity 与 Olaf Hartong 之间的选择代表了在生产环境的信噪比和实验室/研究覆盖范围之间真正的权衡。对于 SOC 中的检测工程，您可能会运行一个混合配置 — Hartong 的基础配置，并在顶层叠加生产环境的噪音规则。 5. **SOC 中最重要的 SPL/Sigma 规则并不是针对已知恶意哈希值触发的规则。** 它是针对“具有随机 8 字符名称并投放到 `C:\` 且注册为 Windows 服务的二进制文件”触发的规则 — 因为该模式涵盖的是一*系列*攻击，而不是单个样本。 **我打算重建的部分：** - **在实验室交换机和受害者之间的 SPAN 端口上添加 Suricata 或 Zeek。** Wazuh 技术栈以终端为中心；添加网络遥测（DNS 日志、TLS SNI、HTTP 请求）可以在杀伤链的更早阶段捕获横向移动。 - **将日志集中到家庭 SIEM 中**，而不仅仅是实验室 SIEM。主机上通过摄取实验室 agent 日志的 Wazuh manager 将允许我针对实时数据运行 Sigma 规则。 - **使用自动化攻击脚本对实验室进行时间限制。** 一个每小时触发一次随机 MITRE 技术的 cron 任务，并在单独的通道上进行告警，将允许我持续验证检测覆盖率，而不是一次性的。 - **接入真实的威胁情报源。** AbuseIPDB 或 EmergingThreats Suricata 规则会将一部分 Wazuh 告警转化为“已知恶意源”分类，这更接近真实 SOC 的分类方式。 ## 参考 - **Wazuh 文档** — https://documentation.wazuh.com/ - **Sysmon Modular (Olaf Hartong)** — https://github.com/olafhartong/sysmon-modular - **SwiftOnSecurity Sysmon config** — https://github.com/SwiftOnSecurity/sysmon-config - **MITRE ATT&CK** — https://attack.mitre.org/ - **Impacket** — https://github.com/fortra/impacket - **Mimikatz** — https://github.com/gentilkiwi/mimikatz - **Bejtlich, R.** *The Practice of Network Security Monitoring* (免费 PDF，与此项目无关，仅仅是教会了我 如何思考 SOC 的那本书)

标签：Docker, PE 加载器, TGT, VMware, Wazuh, 安全运营中心, 安全防御评估, 攻防演练, 红队行动, 网络映射, 请求拦截