dawidmarch/SOC-Lab-Detection-Engineering

GitHub: dawidmarch/SOC-Lab-Detection-Engineering

基于 Wazuh、Sysmon 和 Kali Linux 搭建的企业级 SOC 实验室,通过模拟真实攻击场景并进行多源日志关联分析来验证和优化威胁检测机制。

Stars: 0 | Forks: 0

# 家庭 SOC 实验室 - 威胁检测与日志分析 我创建该项目是为了在隔离的网络环境中实际测试威胁检测机制。我主要关注系统遥测分析、SIEM 系统中的日志关联以及对原始网络数据包的检查。整个过程基于对真实黑客技术的模拟,并将其映射到 MITRE ATT&CK 矩阵中。 ## Hardware & Host OS (硬件平台) 整个实验室在本地物理计算机上运行。合理的资源分配对于确保 SIEM 管理器 (Wazuh) 在客户端机器同时运行时保持稳定至关重要。大容量的 RAM (32 GB) 使得整个拓扑结构能够顺畅无阻地运行,而无需对虚拟机进行激进的内存限制。 * **宿主机操作系统:** Windows 10 Pro (64-bit) * **处理器 (CPU):** Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz * **内存 (RAM):** 32.0 GB * **硬盘:** SSD Patriot P210 512GB ## Oprogramowanie i Wirtualizacja (软件栈) * **Hypervisor:** Oracle VirtualBox (版本 7.2.10) – 用于创建对宿主操作系统完全安全的隔离 Host-Only 网络 (`10.0.2.0/24`)。 * **SIEM / XDR:** Wazuh Manager (基于 Ubuntu 的虚拟设备) – `10.0.2.3` (集中收集和分析日志的中心节点)。 * **Endpoint (受害者):** Windows 10 Pro – `10.0.2.4` (安装了 Wazuh agent 以及配置了 SwiftOnSecurity 策略的 Microsoft Sysmon sensor)。 * **攻击系统:** Kali Linux – `10.0.2.5` (用于产生流量和模拟攻击的平台)。 * **网络分析:** Wireshark – 用于捕获和分析原始数据包 (PCAP) 的工具。 ## 案例研究 1:SMB Reconnaissance 与 Brute-Force ### 1. 攻击过程 我从 Kali Linux 机器上执行了一次快速端口扫描以寻找开放的服务,随后针对 Windows 机器上的 SMB 服务发起了针对本地 Administrator 账户的自动登录 (brute-force) 尝试。 * **端口扫描 (Nmap):** nmap -F 10.0.2.4 * **SMB 身份验证尝试 (SMBClient):** smbclient -L //10.0.2.4 -U administrator%BledneHaslo123! ### 2. 映射至 MITRE ATT&CK * **战术:** Reconnaissance ([TA0043](https://attack.mitre.org/tactics/TA0043/)) $\rightarrow$ **技术:** Active Scanning ([T1595](https://attack.mitre.org/techniques/T1595/)) * **战术:** Credential Access ([TA0006](https://attack.mitre.org/tactics/TA0006/)) $\rightarrow$ **技术:** Brute Force ([T1110](https://attack.mitre.org/techniques/T1110/)) ### 3. 检测与日志分析 #### 系统日志: Windows Security Event ID 4625 Wazuh agent 成功捕获并提交了一条关于失败身份验证的日志。在分析过程中,以下变量是关键: * **Logon Type:** `3` (Network Logon) – 证实了登录尝试是通过网络发起的,而不是从本地控制台发起的。 * **Source IP:** `10.0.2.5` – 直接指向 Kali Linux 机器作为攻击源。 * **Target Account:** `administrator` wazuh-alert-4625 *实施推论:* 在第一次尝试期间,Windows Defender Firewall 完全丢弃了网络数据包,导致系统未生成审核日志。直到重新配置了相应的防火墙策略配置文件后,遥测数据才开始正确地流入 SIEM。 #### 网络流量分析: Wireshark PCAP 在对系统日志进行分析的同时,我还验证了数据包级别的流量。 wireshark-smb-attack 对 `smb` 协议进行过滤后,显示了一系列会话协商数据包,最终以 Windows 服务器发出的一条明确消息结束:`STATUS_LOGON_FAILURE`。这是一个直接的网络层证据,与主机日志中的 Event ID 4625 相互关联。 ## 案例研究 2:PowerShell Reverse Shell 与 Execution Detection ### 1. 攻击过程 为了模拟后渗透阶段 (Post-Exploitation),我在受害者机器上运行了一个脚本,将原始 TCP socket 反弹回攻击者机器,从而允许在操作系统中远程执行命令 (Reverse Shell)。 * **Kali 上的监听 (Netcat):** nc -lvnp 4444 * **Windows 上运行的命令:** 我使用了一段 PowerShell 单行脚本,它创建了一个 `System.Net.Sockets.TCPClient` 对象,将流量指向 `10.0.2.5:4444` 地址。 ### 2. 映射至 MITRE ATT&CK * **战术:** Execution ([TA0002](https://attack.mitre.org/tactics/TA0002/)) $\rightarrow$ **技术:** Command and Scripting Interpreter: PowerShell ([T1059.001](https://attack.mitre.org/techniques/T1059/001/)) * **战术:** Command and Control ([TA0011](https://attack.mitre.org/tactics/TA0011/)) $\rightarrow$ **技术:** Application Layer Protocol ([T1071](https://attack.mitre.org/techniques/T1071/)) ### 3. 检测与日志分析 #### 系统日志: Sysmon Event ID 1 (Process Creation) 在测试期间,我遇到了 Windows Defender (AMSI) 的保护机制,该机制阻止了在 PowerShell 控制台中直接执行脚本。为了完成模拟,我暂时关闭了实时防护,随后 Sysmon sensor 记录到了进程创建事件。 wazuh-sysmon-event1-powershell-execution_1 wazuh-sysmon-event1-powershell-execution_2 *Sysmon 机制分析:* 将恶意代码直接粘贴到先前打开的 PowerShell 控制台中不会生成新的 Event ID 1(因为没有创建新进程,代码是在现有的 PID 内执行的)。为了在 SIEM 中正确记录此事件,我通过经典的命令提示符 (`cmd.exe`) 调用了该脚本,并强制使用了 `-Command` 标志。通过这种方式,SIEM 中的 `data.win.eventdata.commandLine` 字段完整地暴露了包含攻击者编码 IP 地址的整个恶意 payload。 ## 项目的主要结论 * **关联数据源:** 该项目证明了将主机遥测数据 (Sysmon/Event Viewer) 与网络层证据 (Wireshark) 相结合的重要性。只有将这些数据关联起来,才能呈现事件的全貌。 * **调整 sensor:** 系统的默认配置遗漏了许多关键事件(例如 CommandLine 的详细信息或对 PowerShell 网络连接的监控)。部署带有适当过滤器的 Sysmon 极大地提高了 SOC 分析师的可见性 (visibility)。
标签:AMSI绕过, Cloudflare, CTI, MITRE ATT&CK, Wazuh, 威胁检测, 安全运营中心, 插件系统, 网络安全, 网络映射, 隐私保护