Mithilreddy62/purple-team-detection-lab
GitHub: Mithilreddy62/purple-team-detection-lab
一个以「检测即代码」为核心的紫队实验室，在隔离分段环境中实现攻击执行、遥测采集、Sigma 检测规则编写与告警调优的完整闭环。
Stars: 0 | Forks: 0
# 紫队检测实验室
## 本项目展示的内容
我构建了一个隔离的、通过防火墙进行网络分段的实验室，用于端到端地实践**检测工程**：运行真实的攻击，捕获其生成的遥测数据，为其编写检测规则，验证告警是否触发，然后进行调优以消除噪音。这些检测规则以代码形式进行版本控制，映射到 MITRE ATT&CK 技术，并在 CI 中进行验证。
目标是展示完整的紫队闭环——不仅仅是“我有一个 SIEM”，而是针对每种技术展示**执行攻击 → 原始事件 → 检测逻辑 → 触发告警 → 调优决策**。
## 实验室架构
```
flowchart LR
subgraph LAN["LAN — 10.10.20.0/24"]
KALI["Kali Linux
10.10.20.101
Splunk Enterprise (SIEM)
+ Attacker toolkit"] WIN["Windows 11
10.10.20.102
Splunk Universal Forwarder
WinEventLog://Security"] end subgraph DMZ["DMZ — 10.10.10.0/24"] META["Metasploitable 2
Vulnerable target"] end PF["pfSense
Firewall / Segmentation"] KALI --- PF WIN --- PF PF --- META WIN -. "forwards Windows Security logs" .-> KALI ``` | 组件 | 角色 | 地址 | |---|---|---| | pfSense | 防火墙，网络分段 (LAN / DMZ) | gateway | | Kali Linux | SIEM 主机 (Splunk Enterprise) + 攻击机 | 10.10.20.101 | | Windows 11 | 检测目标；通过 Splunk Universal Forwarder 发送 `WinEventLog://Security` | 10.10.20.102 | | Metasploitable 2 | 位于 DMZ 中故意存在漏洞的目标 | 10.10.10.0/24 | **技术栈：** Splunk Enterprise · Splunk Universal Forwarder · Sigma · MITRE ATT&CK · pfSense · NetExec · GitHub Actions (CI) ## 检测目录 | # | 技术 | ATT&CK ID | 数据源 | 检测 | 状态 | |---|---|---|---|---|---| | 1 | SMB 暴力破解 | T1110.001 | Windows Security (4625) | `smb_bruteforce.yml` | ✅ 触发中 | | 2 | RDP 暴力破解 | T1110.001 · T1021.001 | Windows Security (4625, Logon Type 10) | `rdp_bruteforce.yml` | ✅ 触发中 | | 3 | 网络服务发现 | T1046 | pfSense / 防火墙日志 | `nmap_scan.yml` | 🚧 进行中 | | 4 | ARP 缓存中毒 (AiTM) | T1557.002 | 网络 / pfSense | `arp_spoof.yml` | 🚧 计划中 | ## 实战示例：SMB 暴力破解（攻击 → 检测 → 调优） ### 1. 攻击 使用 **NetExec (`nxc`)** 对 Windows 11 主机上的 SMB 进行密码猜测——Windows 11 协商使用 SMBv2/3，而 Hydra 的 SMB 模块无法妥善处理，因此 NetExec 是正确的工具。 ``` nxc smb 10.10.20.102 -u administrator -p wordlist.txt ``` 每次失败的尝试都会在目标机上生成 **Event ID 4625**。*（测试凭据特意未予公开。）* ### 2. 检测 核心检测逻辑是计算短时间内每个来源的失败登录次数： ``` index=* host="Win11-target" source="WinEventLog:Security" EventCode=4625 | stats count AS failed_attempts, values(Account_Name) AS targeted_accounts, min(_time) AS first_attempt, max(_time) AS last_attempt by Source_Network_Address | where failed_attempts > 5 | sort - failed_attempts ``` **验证结果：** 源地址 `10.10.20.101`，针对 `administrator` 的 6 次失败尝试，整个突发过程不到一秒——这是人类无法产生的自动化特征。将其保存为计划告警（严重程度为高），触发后会进入 Triggered Alerts 队列。    ### 3. 调优 字段名称因采集路径而异——Splunk 编译生成的名称与原始采集的名称对同一数据的命名方式不同（`Source_Network_Address` / `Account_Name`），因此该规则提供了两种 SPL 变体，以确保无论采用哪种接入方式都能触发。不到一秒的突发时间窗口也启用了基于速率的逻辑，从而将自动化的暴力破解与用户输错密码的情况区分开来。 ## 工程实践发现 - **字段名称标准化至关重要。** 相同的事件在不同的采集路径下会显示不同的字段名称；检测规则必须同时考虑到这两者，否则会静默失败。 - **只有当主机真正被分段时，网络分段才起作用。** 攻击机 (Kali) 和目标机 (Win11) 位于同一子网，因此 pfSense 的阻断规则永远看不到子网内部的流量。*修复进行中：* 将目标机移至 DMZ，使攻击流量必须穿过防火墙。 - **工具的选择由目标决定。** Hydra 的 SMB 模块在面对 Windows 11 的 SMBv2/3 时会失败；NetExec 才是正确的工具。 ## 仓库结构 ``` ├── rules/ # Sigma detection rules ├── spl/ # Splunk SPL translations ├── screenshots/ # Alert + dashboard evidence └── .github/workflows/ # CI: validates Sigma rule syntax ``` ## 关于 由 **Mithil Pashapu** 构建——网络安全硕士（佛罗里达大西洋大学）。研究方向：检测工程 / SOC / 紫队。 - GitHub: [Mithilreddy62](https://github.com/Mithilreddy62)
10.10.20.101
Splunk Enterprise (SIEM)
+ Attacker toolkit"] WIN["Windows 11
10.10.20.102
Splunk Universal Forwarder
WinEventLog://Security"] end subgraph DMZ["DMZ — 10.10.10.0/24"] META["Metasploitable 2
Vulnerable target"] end PF["pfSense
Firewall / Segmentation"] KALI --- PF WIN --- PF PF --- META WIN -. "forwards Windows Security logs" .-> KALI ``` | 组件 | 角色 | 地址 | |---|---|---| | pfSense | 防火墙，网络分段 (LAN / DMZ) | gateway | | Kali Linux | SIEM 主机 (Splunk Enterprise) + 攻击机 | 10.10.20.101 | | Windows 11 | 检测目标；通过 Splunk Universal Forwarder 发送 `WinEventLog://Security` | 10.10.20.102 | | Metasploitable 2 | 位于 DMZ 中故意存在漏洞的目标 | 10.10.10.0/24 | **技术栈：** Splunk Enterprise · Splunk Universal Forwarder · Sigma · MITRE ATT&CK · pfSense · NetExec · GitHub Actions (CI) ## 检测目录 | # | 技术 | ATT&CK ID | 数据源 | 检测 | 状态 | |---|---|---|---|---|---| | 1 | SMB 暴力破解 | T1110.001 | Windows Security (4625) | `smb_bruteforce.yml` | ✅ 触发中 | | 2 | RDP 暴力破解 | T1110.001 · T1021.001 | Windows Security (4625, Logon Type 10) | `rdp_bruteforce.yml` | ✅ 触发中 | | 3 | 网络服务发现 | T1046 | pfSense / 防火墙日志 | `nmap_scan.yml` | 🚧 进行中 | | 4 | ARP 缓存中毒 (AiTM) | T1557.002 | 网络 / pfSense | `arp_spoof.yml` | 🚧 计划中 | ## 实战示例：SMB 暴力破解（攻击 → 检测 → 调优） ### 1. 攻击 使用 **NetExec (`nxc`)** 对 Windows 11 主机上的 SMB 进行密码猜测——Windows 11 协商使用 SMBv2/3，而 Hydra 的 SMB 模块无法妥善处理，因此 NetExec 是正确的工具。 ``` nxc smb 10.10.20.102 -u administrator -p wordlist.txt ``` 每次失败的尝试都会在目标机上生成 **Event ID 4625**。*（测试凭据特意未予公开。）* ### 2. 检测 核心检测逻辑是计算短时间内每个来源的失败登录次数： ``` index=* host="Win11-target" source="WinEventLog:Security" EventCode=4625 | stats count AS failed_attempts, values(Account_Name) AS targeted_accounts, min(_time) AS first_attempt, max(_time) AS last_attempt by Source_Network_Address | where failed_attempts > 5 | sort - failed_attempts ``` **验证结果：** 源地址 `10.10.20.101`，针对 `administrator` 的 6 次失败尝试，整个突发过程不到一秒——这是人类无法产生的自动化特征。将其保存为计划告警（严重程度为高），触发后会进入 Triggered Alerts 队列。    ### 3. 调优 字段名称因采集路径而异——Splunk 编译生成的名称与原始采集的名称对同一数据的命名方式不同（`Source_Network_Address` / `Account_Name`），因此该规则提供了两种 SPL 变体，以确保无论采用哪种接入方式都能触发。不到一秒的突发时间窗口也启用了基于速率的逻辑，从而将自动化的暴力破解与用户输错密码的情况区分开来。 ## 工程实践发现 - **字段名称标准化至关重要。** 相同的事件在不同的采集路径下会显示不同的字段名称；检测规则必须同时考虑到这两者，否则会静默失败。 - **只有当主机真正被分段时，网络分段才起作用。** 攻击机 (Kali) 和目标机 (Win11) 位于同一子网，因此 pfSense 的阻断规则永远看不到子网内部的流量。*修复进行中：* 将目标机移至 DMZ，使攻击流量必须穿过防火墙。 - **工具的选择由目标决定。** Hydra 的 SMB 模块在面对 Windows 11 的 SMBv2/3 时会失败；NetExec 才是正确的工具。 ## 仓库结构 ``` ├── rules/ # Sigma detection rules ├── spl/ # Splunk SPL translations ├── screenshots/ # Alert + dashboard evidence └── .github/workflows/ # CI: validates Sigma rule syntax ``` ## 关于 由 **Mithil Pashapu** 构建——网络安全硕士（佛罗里达大西洋大学）。研究方向：检测工程 / SOC / 紫队。 - GitHub: [Mithilreddy62](https://github.com/Mithilreddy62)
标签：AMSI绕过, 代码化检测, 威胁检测, 安全实验环境, 紫队, 红队行动