uzairshahidgithub/Detection-Engineering-Alert-Tuning-Threat-Hunting-Lab
GitHub: uzairshahidgithub/Detection-Engineering-Alert-Tuning-Threat-Hunting-Lab
基于 Wazuh 和 Zeek 的检测工程与威胁猎杀实战实验室，覆盖从规则编写、告警调优到主动猎杀的完整蓝队工作流。
Stars: 0 | Forks: 0
## 前置条件
- 运行第 4 周 SOC 技术栈：Wazuh + Suricata + Shuffle + TheHive + MISP + Grafana
- 可通过 `http://localhost:55000` 或你的系统 1 IP 访问 Wazuh 控制台
- 至少注册了一个 Wazuh agent（Windows 虚拟机或 Linux 虚拟机）
- 在 Windows agent 虚拟机上安装了 Sysmon（安装步骤在第 0 阶段介绍）
- 暂不需要 Zeek：将在第 1 阶段安装
## MITRE ATT&CK 覆盖范围
| 检测项 | 战术 | 技术 | 子技术 |
|---|---|---|---|
| 规则 1: 暴力破解 + 成功 | TA0006 凭证访问 | T1110 暴力破解 | T1110.001 密码猜测 |
| 规则 2: 可疑的 PowerShell | TA0002 执行 | T1059 命令脚本 | T1059.001 PowerShell |
| 规则 3: 新地理位置认证 | TA0001 初始访问 | T1078 有效账户 | T1078.002 域账户 |
| 猎寻 1: DNS 隧道 | TA0011 命令与控制 | T1071 应用层协议 | T1071.004 DNS |
| 猎寻 2: 信标通信 | TA0011 命令与控制 | T1071 应用层协议 | T1071.001 Web 协议 |
| 猎寻 3: 横向移动 | TA0008 横向移动 | T1021 远程服务 | T1021.002 SMB/管理员共享 |
## 环境拓扑图
## 第 0 阶段：实验前置设置 (30 分钟)
### 0.1: 在 Windows Agent 虚拟机上安装 Sysmon
Sysmon (System Monitor) 是一项 Windows 服务，用于记录进程创建、网络连接、文件创建和注册表修改，其详细程度远超 Windows 原生事件日志。它是对 Windows 终端最具影响力的免费防御增强措施。
```
# 在 Windows Agent VM 上：以管理员身份运行 PowerShell
# 下载 Sysmon
Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" -OutFile "$env:TEMP\Sysmon.zip"
Expand-Archive "$env:TEMP\Sysmon.zip" -DestinationPath "$env:TEMP\Sysmon"
# 下载 SwiftOnSecurity Sysmon config（社区维护，生产级别）
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" -OutFile "$env:TEMP\sysmonconfig.xml"
# 使用该 config 安装 Sysmon
& "$env:TEMP\Sysmon\Sysmon64.exe" -i "$env:TEMP\sysmonconfig.xml" -accepteula
# 验证 Sysmon 正在运行
Get-Service Sysmon64
```
```
# 验证 Sysmon 事件是否出现在 Windows Event Log 中
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5 |
Select-Object TimeCreated, Id, Message | Format-List
```
**本次实验中将用到的关键 Sysmon 事件 ID：**
| ID | 事件 | 检测价值 |
|---|---|---|
| 1 | 进程创建 | PowerShell/cmd 派生，LOLBAS |
| 3 | 网络连接 | 发起外部连接的进程 |
| 7 | 镜像加载 | DLL 注入，未签名的 DLL |
| 10 | 进程访问 | LSASS 凭证转储 |
| 11 | 文件创建 | 恶意软件投递器，勒索软件 |
| 12/13 | 注册表设置/删除 | 持久化机制 |
| 22 | DNS 查询 | C2 DNS 解析 |
### 0.2: 验证 Wazuh 接收到 Sysmon 事件
```
# 在 Wazuh Manager 上（System 1 终端）
# 检查 Sysmon 事件是否到达 manager
tail -f /var/ossec/logs/alerts/alerts.log | grep -i "sysmon"
# 或通过 API 检查
curl -k -u admin:SecretPassword \
"https://localhost:55000/events?pretty=true&limit=5&q=sysmon"
```
在 Wazuh 控制台中：
1. 导航至 **Threat Hunting → Events**
2. 添加过滤器：`data.win.system.channel: Microsoft-Windows-Sysmon/Operational`
3. 确认事件已显示，并包含诸如 `data.win.eventdata.image`、`data.win.eventdata.commandLine` 等字段
如果没有出现 Sysmon 事件：需要在 Wazuh agent 的 `ossec.conf` 中添加 Sysmon 日志通道：
```
Microsoft-Windows-Sysmon/Operational
eventchannel
```
```
# 更改 config 后重启 agent
Restart-Service -Name "OssecSvc"
```
### 0.3: 安装和配置 Zeek
```
# 在 System 1 上（Ubuntu/Kali）
sudo apt update && sudo apt install -y zeek
# 验证安装
zeek --version
# 确定你的监控接口
ip link show
# 使用连接到你的实验网络的接口：通常是 eth0 或 ens33
# 配置 Zeek 以监控你的接口
sudo nano /etc/zeek/node.cfg
```
```
# /etc/zeek/node.cfg
[zeek]
type=standalone
host=localhost
interface=eth0 # Change to your actual interface
```
```
# 配置 Zeek 的日志输出为 JSON（Wazuh 摄取所需）
sudo nano /etc/zeek/local.zeek
```
在 `/etc/zeek/local.zeek` 文件末尾添加：
```
# 为所有日志启用 JSON 输出
@load policy/tuning/json-logs
# 加载额外的检测脚本
@load policy/protocols/conn/duration-core
@load policy/protocols/dns/detect-external-names
@load policy/protocols/http/detect-sqli
@load policy/protocols/ssl/expiring-certs
@load policy/frameworks/files/hash-all-files
```
```
# 启动 Zeek
sudo zeekctl deploy
# 验证 Zeek 是否正在生成日志
ls -la /opt/zeek/logs/current/
# 你应该会看到：conn.log, dns.log, http.log, ssl.log, files.log, weird.log
# 跟踪 conn.log 以确认 JSON 输出
tail -f /opt/zeek/logs/current/conn.log | python3 -m json.tool | head -30
```
### 0.4: 将 Zeek 日志导入 Wazuh
```
# 安装 Filebeat 以将 Zeek 日志发送到 Wazuh
sudo apt install -y filebeat
# 为 Zeek 创建 Filebeat config
sudo nano /etc/filebeat/filebeat.yml
```
```
# /etc/filebeat/filebeat.yml
filebeat.inputs:
- type: log
enabled: true
paths:
- /opt/zeek/logs/current/conn.log
- /opt/zeek/logs/current/dns.log
- /opt/zeek/logs/current/http.log
- /opt/zeek/logs/current/ssl.log
- /opt/zeek/logs/current/files.log
- /opt/zeek/logs/current/weird.log
json.keys_under_root: true
json.add_error_key: true
fields:
log_type: zeek
fields_under_root: true
output.logstash:
hosts: ["localhost:5044"]
# Or direct to Wazuh manager if using wazuh-logstash pipeline
```
```
# 替代方案：直接使用 Wazuh agent 监控 Zeek 日志
# 在 Zeek 主机上的 /var/ossec/etc/ossec.conf 中添加
sudo nano /var/ossec/etc/ossec.conf
```
```
json
/opt/zeek/logs/current/conn.log
json
/opt/zeek/logs/current/dns.log
json
/opt/zeek/logs/current/http.log
```
```
sudo systemctl restart wazuh-agent
# 在 Wazuh dashboard 中验证：按 label.log_type: zeek_conn 过滤
```
## 第 1 阶段：检测工程 (90 分钟)
### Wazuh 检测规则的工作原理
在编写任何规则之前，先了解其引擎。Wazuh 通过管道处理日志：
```
Raw log → Decoder (extracts fields) → Rules (match fields) → Alert (if level ≥ 3)
```
规则是以 XML 文件形式存储在 `/var/ossec/etc/rules/local_rules.xml` 中的（这是你的自定义规则：切勿直接编辑 `/var/ossec/ruleset/rules/`，因为更新会覆盖该目录）。
**规则结构剖析：**
```
100000
powershell.exe
Suspicious PowerShell execution detected
T1059.001
windows,powershell,attack
```
**规则级别及其含义：**
| 级别 | 含义 | 动作 |
|---|---|---|
| 0 | 忽略：已抑制 | 无告警 |
| 1–3 | 信息性 | 仅记录 |
| 4–7 | 低：注意 | 记录，可能通知 |
| 8–11 | 中：可疑 | 告警，生成工单 |
| 12–14 | 高：攻击 | 立即告警 |
| 15 | 危急 | 呼叫值班人员 |
**你将用到的关键规则操作符：**
```
value
regex
string_in_raw_log
5
120
60106
100001
```
### 任务 1.1：规则 1：暴力破解后跟成功登录
**检测逻辑：** 60 秒内来自同一源 IP 的五次或更多失败身份验证尝试，随后是一次成功的身份验证。这是典型的凭证填充/密码喷洒模式：失败尝试表明在猜测，成功则表明已失陷。
**为什么是 5 次失败，而不是 1 次？** 单次失败是正常的（输错密码）。同一 IP 在 60 秒内失败五次在统计上是异常的。该阈值可根据环境进行配置：这是你的第一个调优决策。
```
# 在 Wazuh Manager 上打开你的自定义规则文件
sudo nano /var/ossec/etc/rules/local_rules.xml
```
```
5760
Brute force: 5 SSH failures from same IP in 60 seconds
T1110.001
authentication_failures,brute_force,attack
60122
Brute force: 5 Windows logon failures from same IP in 60 seconds
T1110.001
authentication_failures,windows,brute_force,attack
100001
5715
CRITICAL: Brute force succeeded: SSH login after repeated failures from same IP
T1110.001
authentication_failures,brute_force,attack,high_confidence
100002
60106
CRITICAL: Brute force succeeded: Windows logon after repeated failures from same IP
T1110.001
authentication_failures,windows,brute_force,attack,high_confidence
```
### 任务 1.2：规则 2：可疑的 PowerShell 执行
**检测逻辑：** PowerShell 是后期利用中被滥用最多的 Windows 内置工具。区分恶意 PowerShell 和管理型 PowerShell 的模式包括：编码命令（`-EncodedCommand`）、下载吊篮（`IEX`、`Net.WebClient`）、执行策略绕过标志，以及由异常父进程（Word、Excel、浏览器、Java）生成的 PowerShell。
```
61603
(?i)powershell(\.exe)?$
PowerShell process created (informational baseline)
windows,powershell,sysmon
100010
(?i)(-e\s|-en\s|-enc\s|-encoded\s|-encodedcommand\s)
PowerShell with encoded command: possible payload obfuscation
T1059.001
T1027
windows,powershell,obfuscation,attack
100010
(?i)(IEX|Invoke-Expression|Net\.WebClient|DownloadString|DownloadFile|WebRequest|curl|wget)
PowerShell download cradle detected: possible fileless malware or C2 staging
T1059.001
T1105
windows,powershell,download,attack
100010
(?i)(-ep\s*bypass|-executionpolicy\s*bypass|-exec\s*bypass)
PowerShell execution policy bypass: scripts running without restrictions
T1059.001
windows,powershell,policy_bypass,attack
100010
(?i)(winword\.exe|excel\.exe|outlook\.exe|mshta\.exe|wscript\.exe|cscript\.exe|chrome\.exe|firefox\.exe|iexplore\.exe|java\.exe)
CRITICAL: PowerShell spawned by Office/browser: high confidence phishing or macro execution
T1059.001
T1566.001
windows,powershell,office_macro,phishing,attack,high_confidence
100010
(?i)(amsi|AmsiScanBuffer|AmsiInitialize|Reflection\.Assembly|System\.Runtime\.InteropServices)
CRITICAL: AMSI bypass attempt in PowerShell: attacker disabling antimalware scanning
T1059.001
T1562.001
windows,powershell,amsi_bypass,attack,high_confidence
```
### 任务 1.3：规则 3：来自新源 IP 的身份验证
**检测逻辑：** 合法用户通常在同一地理范围和 IP 块内进行身份验证。来自前所未见 IP 的身份验证：尤其是在非工作时间或来自国外 ASN 时，是一个重大异常。此规则使用 Wazuh 的 `` 和频率逻辑来建立基线，并在出现偏差时触发。
**需要记录的重要限制：** Wazuh 原生不会在重启后维护每个用户的 IP 历史记录。此规则通过查找 `logon_type=3`（网络登录：远程）且在过去时间范围内没有来自相同 IP+用户组合的匹配成功登录来近似检测。在成熟的环境中，这可以通过基于机器学习的 UBA（用户行为分析）层来增强。
```
60106
3
Windows network logon (remote authentication observed)
windows,authentication,remote_logon
100020
(?i)(administrator|admin|sysadmin|root|service|backup)
Privileged account network logon: validate this is expected administrative activity
T1078.002
windows,authentication,privileged_account,remote_logon
100020
Remote authentication outside business hours: anomalous timing
T1078
windows,authentication,after_hours,anomaly
60122
Password spray: multiple usernames failed from same IP: horizontal brute force pattern
T1110.003
windows,authentication,password_spray,attack
5715
5715
86400
SSH login from IP with no prior successful authentication in past 24 hours
T1078
linux,authentication,new_source_ip,anomaly
```
### 任务 1.4：加载并测试自定义规则
```
# 在重载前验证 XML 语法（至关重要：错误的 XML 会静默破坏规则引擎）
sudo /var/ossec/bin/wazuh-logtest
# 无需重启整个 manager 即可重载规则
sudo systemctl reload wazuh-manager
# 或使用 API
curl -k -u admin:SecretPassword \
-X PUT "https://localhost:55000/manager/configuration?restart_after_apply=true" \
-H "Content-Type: application/json"
# 验证规则已加载
sudo grep -n "100001\|100010\|100020" /var/ossec/etc/rules/local_rules.xml
# 检查 manager 日志是否存在规则加载错误
sudo tail -50 /var/ossec/logs/ossec.log | grep -E "ERROR|WARNING|local_rules"
```
**使用 wazuh-logtest 针对样本日志行测试规则：**
```
sudo /var/ossec/bin/wazuh-logtest
```
粘贴此样本日志并验证规则 100011 是否触发：
```
2024 Jan 15 14:22:01 WinEvtLog: Microsoft-Windows-Sysmon/Operational: INFORMATION(1): Microsoft-Windows-Sysmon: CommandLine: powershell.exe -EncodedCommand JABjAGwAaQBlAG4AdA==
```
预期响应包含：`Rule: 100011` 和 `Level: 10`
### 任务 1.5：模拟攻击活动
生成真实的日志事件以触发你的检测规则。这些仅在您自己的实验虚拟机上运行的模拟命令。
**模拟暴力破解（Linux SSH：来自 Kali）：**
```
# 这将在你的实验 Linux VM 上生成 10 次失败的 SSH 尝试，随后是成功登录
# 将 LAB_LINUX_IP 替换为你实际的实验 VM IP
for i in $(seq 1 10); do
sshpass -p "wrongpassword${i}" ssh -o StrictHostKeyChecking=no \
labuser@LAB_LINUX_IP 2>/dev/null
sleep 1
done
# 现在成功进行身份验证
ssh labuser@LAB_LINUX_IP
```
**模拟暴力破解（Windows：来自受害者虚拟机的 PowerShell）：**
```
# 模拟 Windows 登录失败尝试
# 这将生成在 Wazuh 中可见的 Event ID 4625 条目
$credential_list = @("wrongpass1","wrongpass2","wrongpass3","wrongpass4","wrongpass5")
foreach ($pass in $credential_list) {
$securepass = ConvertTo-SecureString $pass -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential("Administrator", $securepass)
try {
Start-Process cmd.exe -Credential $cred -WindowStyle Hidden -ErrorAction Stop
} catch { }
Start-Sleep -Seconds 2
}
# 然后通过 RDP 或 net use 成功登录
```
**模拟可疑的 PowerShell（在 Windows 受害者虚拟机上）：**
```
# 这些操作都会生成 Sysmon Event ID 1，应该会触发你的规则
# 在受害 VM 上运行：这些是安全的模拟，没有实际的恶意活动
# 触发 Rule 100011（编码命令）
powershell.exe -EncodedCommand "JABuAGEAbQBlAD0AIgBHAEgATwBTAFQAXwBTAEkARwBOAEEATAAiAA=="
# 触发 Rule 100012（存在下载器语法作为字符串：未执行）
powershell.exe -Command "Write-Host 'Test: IEX Net.WebClient simulation'"
# 触发 Rule 100013（执行策略绕过）
powershell.exe -ExecutionPolicy Bypass -Command "Write-Host 'CIPHER Lab Test'"
```
```
# 验证 Wazuh 中是否出现告警
# Dashboard：Threat Hunting → Security Alerts
# 过滤器：rule.id: (100001 OR 100010 OR 100011 OR 100012 OR 100013 OR 100020)
```
## 第 2 阶段：告警调优练习 (60 分钟)
### 未经调优的检测规则带来的问题
你在第 1 阶段编写的规则会产生**误报**：在技术上符合规则逻辑，但代表正常活动的告警。在生产 SOC 中，过多的误报对运营是灾难性的：它们会降低分析师的敏感度，导致告警疲劳，并使真实的攻击被淹没在噪音中。
调优的目标是：**在最低误报率下实现最高的真实阳性率。** 这始终是一种权衡：你需要明确地将其记录下来。
### 任务 2.1：识别误报
在你的 Windows 虚拟机上运行以下命令，并观察哪些规则被错误触发：
```
# 这些是你的规则可能会错误标记的合法管理活动
# 合法：IT 管理员使用编码命令执行部署脚本
powershell.exe -EncodedCommand "V3JpdGUtSG9zdCAnTGVnaXRpbWF0ZSBhZG1pbiBhY3Rpb24n"
# 合法：SCCM / Intune 推送软件（从服务账户生成 PowerShell）
# 模拟：来自已知管理员进程的 PowerShell
powershell.exe -Command "Get-WindowsUpdate"
# 合法：IT 支持人员下班后的紧急 RDP（合法但属于下班时间）
# 这将会触发 Rule 100022
```
**在你的调优记录中进行记录：**
| 误报事件 | 触发的规则 | 根本原因 | 误报严重程度 |
|---|---|---|---|
| 管理员部署脚本 | 100011 | Base64 编码的管理员脚本 | 中：需要抑制 |
| 非工作时间的服务台 RDP | 100022 | 值班支持模式 | 低：白名单用户 |
| SCCM agent PowerShell | 100010 | 预期的管理流量 | 低：白名单进程 |
### 任务 2.2：向规则添加调优逻辑
Wazuh 支持多种调优机制。按精确度从高到低依次应用它们：
**方法 1：使用 `` 白名单已知的安全进程**
```
100010
(?i)(-e\s|-en\s|-enc\s|-encoded\s|-encodedcommand\s)
(?i)(C:\\Program Files\\SCCM|C:\\Windows\\CCM|C:\\Admin\\Scripts\\Approved)
PowerShell encoded command: possible obfuscation (admin paths excluded)
T1059.001 T1027 windows,powershell,obfuscation,attack
```
**方法 2：使用 `` 白名单已知的管理员用户**
```
100020
SOC_ADMIN|HELPDESK_ONCALL|BACKUP_SVC
Remote authentication outside business hours: excluding on-call accounts
T1078 windows,authentication,after_hours,anomaly
```
**方法 3：提高阈值以过滤噪音**
```
5760
Brute force: 8 SSH failures from same IP in 60s (threshold raised from 5 after tuning)
T1110.001 authentication_failures,brute_force,attack
```
**方法 4：通过 `ossec.conf` 排除项抑制特定资产的规则**
```
100022
005
-8
```
### 任务 2.3：完成调优记录
以这种格式记录每一个调优决策。这是你的**审计追踪**：如果没有它，未来的分析师将无法理解规则为何表现出这种行为。
```
===========================================================
TUNING RECORD: SIGNAL CLARITY LAB
Date: [DATE]
Analyst: [YOUR NAME]
SIEM: Wazuh 4.x
===========================================================
RULE 100011: PowerShell Encoded Command
-----------------------------------------
Initial FP Rate: 12 alerts/day (audit week 1)
FP Root Causes:
1. SCCM deployment scripts use base64 encoding by design
2. IT admin batch deployment runs at 7am daily
Tuning Applied:
- Added path exclusion: C:\Program Files\SCCM and C:\Admin\Scripts\Approved
- Added user exclusion: SCCM_SERVICE, IT_ADMIN
Post-Tuning FP Rate: 1 alert/day (92% FP reduction)
True Positive Verified: Atomic Red Team T1059.001 still triggers: coverage maintained
Acceptable Residual Risk: Yes: excluded paths are restricted, monitored separately
RULE 100001: SSH Brute Force
-------------------------------
Initial FP Rate: 5 alerts/day
FP Root Cause:
- RDP thin client reconnection generates 3-4 failed SSH sessions on timeout
Tuning Applied:
- Raised frequency threshold: 5 → 8 attempts
Post-Tuning FP Rate: 0 alerts in 3 days (100% FP reduction)
True Positive Verified: 10-attempt SSH brute force simulation still triggers at 8: coverage maintained
Acceptable Residual Risk: Yes: genuine attacker generates far more than 8 attempts
RULE 100022: After-Hours Authentication
-----------------------------------------
Initial FP Rate: 8 alerts/day (on-call staff)
FP Root Cause:
- Helpdesk on-call access 10pm-6am is legitimate business process
Tuning Applied:
- User exclusion list: SOC_ADMIN, HELPDESK_ONCALL, BACKUP_SVC
Post-Tuning FP Rate: 0 alerts in 5 days
True Positive Verified: Unknown user after-hours RDP still fires: coverage maintained
Acceptable Residual Risk: Yes: excluded accounts have MFA enforced at IAM level
SUMMARY
-------
Total initial FP volume: 25 alerts/day
Post-tuning FP volume: 1 alert/day
FP reduction: 96%
Detection coverage: 100% maintained (all ATT&CK techniques still detected)
===========================================================
```
## 第 3 阶段：使用 Wazuh + Zeek 进行威胁猎寻 (60 分钟)
### 猎寻与告警：区别所在
检测工程（第 1 阶段）是**被动的**：你定义一个已知的恶意模式并等待它出现。威胁猎寻是**主动的**：你对攻击者的行为提出假设，查询历史数据并寻找可能未触发任何告警的证据。
**猎寻循环 (PEAK 模型)：**
```
Prepare → hypothesis formed from threat intel or ATT&CK
Engage → query historical data, explore anomalies
Analyse → correlate findings, rule out false leads
Knowledge → document findings, convert confirmed hunts to detection rules
```
每次猎寻要么发现异常（创建检测规则），要么一无所获（记录下未发现证据：这同样具有价值）。
### 任务 3.1：猎寻 1：DNS 隧道 (Zeek dns.log)
**假设：** 攻击者正在利用 DNS 渗透数据或与 C2 通信。选择 DNS 是因为它很少被阻断，也很少被检查。指标：异常长的 DNS 查询、对单个域名的查询量极高、查询的子域中包含类似 base64 的字符串。
**为什么为此使用 Zeek：** Wazuh 会传输 Sysmon DNS 事件（事件 ID 22），但它们是单次查询的，难以聚合。Zeek 的 `dns.log` 已经按域名结构化包含了查询长度、响应时间和查询计数：这更适合进行体量分析。
```
# 在运行 Zeek 的系统上
# 检查 dns.log 中的异常
# 查询 1：查找具有异常长查询名称的域名（>50 个字符 = 可疑）
cat /opt/zeek/logs/current/dns.log | \
python3 -c "
import sys, json
for line in sys.stdin:
try:
rec = json.loads(line)
query = rec.get('query', '')
if len(query) > 50:
print(f'LONG QUERY [{len(query)} chars]: {query} | Src: {rec.get(\"id.orig_h\",\"?\")}')
except: pass
"
```
```
# 查询 2：查找具有高 DNS 查询量的 IP（信标模式）
cat /opt/zeek/logs/current/dns.log | \
python3 -c "
import sys, json
from collections import Counter
counts = Counter()
for line in sys.stdin:
try:
rec = json.loads(line)
counts[rec.get('id.orig_h','?')] += 1
except: pass
for ip, count in counts.most_common(10):
print(f'{count:5d} queries from {ip}')
"
# 一个小时内产生 500+ 次 DNS 查询的内部主机是异常的
```
```
# 查询 3：查找具有 base64 或十六进制类似模式的子域名（通过 DNS 进行数据渗出）
cat /opt/zeek/logs/current/dns.log | \
python3 -c "
import sys, json, re
b64_pattern = re.compile(r'^[A-Za-z0-9+/]{20,}={0,2}\.')
hex_pattern = re.compile(r'^[0-9a-fA-F]{16,}\.')
for line in sys.stdin:
try:
rec = json.loads(line)
query = rec.get('query','')
if b64_pattern.match(query) or hex_pattern.match(query):
print(f'SUSPICIOUS DNS: {query} | Src: {rec.get(\"id.orig_h\",\"?\")}')
except: pass
"
```
**在 Wazuh 控制台中 (OpenSearch 查询)：**
导航至：Discover → 添加 Zeek 索引 → 使用此查询：
```
data.log_type: zeek_dns AND data.query.length:[50 TO *]
```
```
# 按域名聚合以查找数量异常
# 在 Wazuh Dashboard 中：Visualise → Vertical Bar
# Bucket：字段 data.query 上的 Terms 聚合
# Metric：Count
# Filter：data.log_type: zeek_dns
```
**记录猎寻发现：**
1. 发现任何长查询了吗？
2. 在捕获时间窗口内是否有任何 IP 发起了 >200 次 DNS 查询？
3. 是否存在任何 base64 模式的子域？
4. 如果什么也没发现：记录为“在此捕获期间没有 DNS 隧道的证据”：这是一个有效的猎寻结果
### 任务 3.2：猎寻 2：信标通信检测 (Zeek conn.log)
**假设：** 一台受损的主机正在以固定的时间间隔与 C2 通信。C2 信标通信表现出到单个外部 IP 的一致连接间隔（例如，每 60 秒一次）。正常的人类网络流量具有高度可变的时间。信标通信在统计上是规律的。
```
# 查找具有可疑一致间隔的连接（信标特征）
cat /opt/zeek/logs/current/conn.log | \
python3 << 'EOF'
import sys, json
from collections import defaultdict
connections = defaultdict(list)
for line in sys.stdin:
try:
rec = json.loads(line)
src = rec.get('id.orig_h', '')
dst = rec.get('id.resp_h', '')
ts = float(rec.get('ts', 0))
# Only look at external destinations (skip RFC1918)
if not any(dst.startswith(p) for p in ['10.','192.168.','172.']):
key = f"{src} -> {dst}:{rec.get('id.resp_p','?')}"
connections[key].append(ts)
except:
pass
print("\n=== BEACONING CANDIDATES ===")
for conn, timestamps in connections.items():
if len(timestamps) > 5:
timestamps.sort()
intervals = [timestamps[i+1]-timestamps[i] for i in range(len(timestamps)-1)]
avg_interval = sum(intervals)/len(intervals)
# Standard deviation: low StdDev = consistent = beaconing
variance = sum((x-avg_interval)**2 for x in intervals)/len(intervals)
stddev = variance**0.5
jitter_pct = (stddev/avg_interval*100) if avg_interval > 0 else 0
if jitter_pct < 15 and len(timestamps) > 8: # <15% jitter = suspicious
print(f"BEACON CANDIDATE: {conn}")
print(f" Connections: {len(timestamps)}, Avg interval: {avg_interval:.1f}s, Jitter: {jitter_pct:.1f}%")
EOF
```
```
# 威胁狩猎：查找持续时间长且流量小的连接（C2 保活模式）
cat /opt/zeek/logs/current/conn.log | \
python3 -c "
import sys, json
for line in sys.stdin:
try:
rec = json.loads(line)
duration = float(rec.get('duration', 0))
bytes_sent = int(rec.get('orig_bytes', 0))
dst = rec.get('id.resp_h','')
# Long duration + low data = keep-alive C2
if duration > 300 and bytes_sent < 5000 and not any(dst.startswith(p) for p in ['10.','192.168.','172.']):
print(f'LONG+LOW: {rec[\"id.orig_h\"]} -> {dst}:{rec[\"id.resp_p\"]} | Duration: {duration:.0f}s | Bytes: {bytes_sent}')
except: pass
"
```
**在 Wazuh 控制台中：**
```
# 用于信标狩猎的 OpenSearch 查询
data.log_type: zeek_conn AND NOT data.id_resp_h: (10.* OR 192.168.* OR 172.*)
```
使用 Wazuh 的 **Visualise** 创建时间线散点图：
- X 轴：`@timestamp`
- Y 轴：Count
- 拆分依据：`data.id_resp_h` (目标 IP)
- 时间线上规律的峰值模式 = 信标通信特征
### 任务 3.3：猎寻 3：横向移动 (Wazuh + Windows 日志)
**假设：** 攻击者在一台机器上立足后，将尝试使用有效凭证通过 SMB、RDP 或 WMI 横向移动到其他系统。指标：成功网络登录（类型 3）在短时间内从同一源用户扩散到多个主机。
**在 Wazuh 控制台中：OpenSearch 查询：**
```
# 查找来自同一用户跨多个目标的网络登录（Event 4624，类型 3）
rule.groups: authentication_success AND data.win.eventdata.logonType: 3
```
在 Wazuh 中构建此可视化：
1. **Discover** → 过滤器：`data.win.eventdata.logonType: 3 AND data.win.eventdata.logonProcessName: NtLmSsp`
2.添加列：`data.win.eventdata.targetUserName`、`data.win.eventdata.ipAddress`、`agent.name`
3. 按 `@timestamp` 升序排序
4. 查找：相同的 `targetUserName` 在短时间窗口内出现在多个不同的 `agent.name`（不同机器）上
**特定的 SMB 横向移动（如果启用了 SMB 日志记录，则为 Zeek smb.log）：**
```
# 在 Zeek local.zeek 中启用 SMB 日志记录
echo "@load policy/protocols/smb" >> /etc/zeek/local.zeek
sudo zeekctl deploy
# 威胁狩猎管理员共享访问模式
cat /opt/zeek/logs/current/smb_mapping.log | \
python3 -c "
import sys, json
for line in sys.stdin:
try:
rec = json.loads(line)
path = rec.get('path','')
if any(share in path.upper() for share in ['ADMIN$','C$','IPC$']):
print(f'ADMIN SHARE: {rec.get(\"id.orig_h\",\"?\")} → {path}')
except: pass
"
```
### 任务 3.4：将猎寻发现转化为检测规则
这是 PEAK 模型的**知识化** 阶段。任何无法被现有规则检测到的已确认猎寻发现都必须成为一条新的检测规则。
```
60106
3
Same user authenticated to 3+ different hosts within 10 minutes: lateral movement pattern
T1021.002
T1078
windows,lateral_movement,attack,hunt_derived
100030
(?i)(administrator|admin|sysadmin)
CRITICAL: Privileged account lateral movement: admin user spreading across multiple hosts
T1021.002
windows,lateral_movement,privileged_account,attack,high_confidence
```
## 第 4 阶段：Wazuh 高级功能 (30 分钟)
### 任务 4.1：主动响应配置
Wazuh 可以自动响应高置信度告警：阻断 IP、隔离 agent、运行脚本。为确认的暴力破解配置防火墙阻断。
```
firewall-drop
local
100003,100004
3600
```
```
# 验证 active response 脚本存在
ls /var/ossec/active-response/bin/firewall-drop.sh
# 手动测试 active response（将为 1.2.3.4 添加一条 DROP 规则）
sudo /var/ossec/active-response/bin/firewall-drop.sh add - 1.2.3.4 0 0 0 0
# 验证 iptables 规则已添加
sudo iptables -L INPUT -n | grep 1.2.3.4
# 清理测试
sudo /var/ossec/active-response/bin/firewall-drop.sh delete - 1.2.3.4 0 0 0 0
```
### 任务 4.2：Wazuh 漏洞检测器
Wazuh 使用 NVD 和 Red Hat 漏洞源扫描 agent 的已知 CVE。
```
yes
12h
6h
yes
yes
1h
yes
1h
8
9
```
```
sudo systemctl restart wazuh-manager
# 检查漏洞扫描结果
# Dashboard：Vulnerability Detection → Inventory
# 过滤条件：Critical 或 High 严重级别
# 通过 API
curl -k -u admin:SecretPassword \
"https://localhost:55000/vulnerability/000?pretty=true&severity=critical&limit=10"
```
### 任务 4.3：用于实验室 KPI 的自定义 Wazuh 仪表板
在 Wazuh 中为你的三个检测规则组构建一个集中的安全仪表板。
1. 导航至 **Dashboards → Create Dashboard**
2. 添加以下面板：
**面板 1：按规则组划分的告警量（过去 24 小时）**
- 可视化类型：Vertical Bar
- 指标：Count
- 分桶：Terms on `rule.groups`
- 过滤器：`rule.groups: (brute_force OR powershell OR authentication_failures)`
**面板 2：告警时间线（随时间检测规则活动）**
- 可视化类型：Area Chart
- X 轴：Date Histogram on `@timestamp` (1 小时间隔)
- 指标：Count
- 拆分系列：Terms on `rule.id`
- 过滤器：`rule.id: (100001 OR 100003 OR 100011 OR 100014 OR 100022)`
**面板 3：主要攻击源 IP**
- 可视化类型：Data Table
- 指标：Count
- 分桶：Terms on `data.srcip` (前 10 名)
- 过滤器：`rule.groups: attack`
**面板 4：MITRE ATT&CK 覆盖图**
- 使用 Wazuh 内置的 MITRE ATT&CK 模块
- 导航至：**MITRE ATT&CK → Overview**
- 按你的自定义规则组过滤：`hunt_derived OR high_confidence`
## 交付物
| # | 项目 | 阶段 |
|---|---|---|
| 1 | Wazuh 控制台中可见的 Sysmon 事件（截图） | 第 0 阶段 |
| 2 | Wazuh 中可见的 Zeek 日志（带有 zeek_conn 过滤器的截图） | 第 0 阶段 |
| 3 | `local_rules.xml`：编写并加载的所有三个规则集 | 第 1 阶段 |
| 4 | Wazuh 控制台显示规则 100001–100031 已触发 | 第 1 阶段 |
| 5 | 显示每个规则集匹配的 wazuh-logtest 输出 | 第 1 阶段 |
| 6 | 完整的调优记录（使用任务 2.3 中的模板） | 第 2 阶段 |
| 7 | DNS 隧道猎寻：已记录的发现（正向或负向） | 第 3 阶段 |
| 8 | 信标通信猎寻：Zeek conn.log 分析输出 | 第 3 阶段 |
| 9 | 横向移动猎寻：用户到主机关联截图 | 第 3 阶段 |
| 10 | 源于猎寻的新检测规则 (规则 100030/100031) | 第 3 阶段 |
| 11 | 主动响应测试：iptables 阻断条目截图 | 第 4 阶段 |
| 12 | 包含所有 4 个面板的自定义 Wazuh 仪表板（截图） | 第 4 阶段 |
## 最终输出：三条生产规则（摘要卡）
```
===========================================================
DETECTION RULE DOCUMENTATION: SIGNAL CLARITY
Analyst: [YOUR NAME] Date: [DATE] SIEM: Wazuh 4.x
===========================================================
RULE 1: Brute Force + Successful Authentication
IDs: 100001 (SSH), 100002 (Windows), 100003/4 (success chain)
Level: 6 (count) → 14 (success after brute)
Threshold: 8 failures / 60 seconds / same source IP
MITRE: T1110.001
Tuning: Raised from 5→8 to eliminate RDP reconnect FPs
FP Rate: 0/day post-tuning
TP Verified: Yes: 10-attempt SSH simulation triggers at attempt 8
RULE 2: Suspicious PowerShell Execution
IDs: 100010 (base), 100011 (encoded), 100012 (download),
100013 (bypass), 100014 (Office parent), 100015 (AMSI)
Level: 3 → 10 → 12 → 14 based on severity of indicator
MITRE: T1059.001, T1027, T1105, T1562.001, T1566.001
Tuning: SCCM path exclusion, admin user exclusion
FP Rate: 1/day (acceptable residual from custom scripts)
TP Verified: All 5 attack variants confirmed via Atomic Red Team
RULE 3: Authentication Anomaly (New Source / Spray / After-Hours)
IDs: 100020 (base), 100021 (privileged), 100022 (hours),
100023 (spray), 100024 (new SSH source)
Level: 3 → 8 → 10 → 12 based on context
MITRE: T1078.002, T1110.003
Tuning: On-call user exclusion, business hours definition
FP Rate: 0/day post-tuning
TP Verified: Password spray (3 users/60s) confirmed trigger
HUNT-DERIVED RULE: Lateral Movement
IDs: 100030 (3+ hosts/user/10min), 100031 (privileged escalation)
Level: 3 → 12
MITRE: T1021.002, T1078
Source: Derived from proactive hunt: Hunt 3
FP Rate: Untested: requires 5-day baseline period
TP Verified: Simulated 4-host lateral logon chain triggers
===========================================================
Total rules written: 12
Total FP reduction: 96% (25/day → 1/day)
ATT&CK techniques covered: 9
Hunt cycle completed: Yes: 3 hunts, 1 converted to rule
===========================================================
```
## 评分标准
| 部分 | 分数 |
|---|---|
| 环境设置：Sysmon + Zeek 日志导入 Wazuh | 15 |
| 规则集 1：暴力破解链（全部 4 条规则，逻辑正确） | 20 |
| 规则集 2：PowerShell 检测（全部 5 个变体，正则表达式正确） | 20 |
| 规则集 3：身份验证异常（全部 5 条规则，已应用调优） | 15 |
| 调优记录（完整、量化、有记录的方法论） | 10 |
| 威胁猎寻 1：DNS (Zeek 查询 + 发现) | 5 |
| 威胁猎寻 2：信标通信 (间隔分析 + 发现) | 5 |
| 威胁猎寻 3：横向移动 (关联分析 + 新规则) | 5 |
| Wazuh 仪表板（已构建全部 4 个面板） | 5 |
| **总计** | **100** |
及格分数：70
标签：AMSI绕过, ATT&CK框架, CIDR查询, Cloudflare, Conpot, DNS隧道, EDR, Grafana, Metaprompt, MITRE ATT&CK, OPA, OpenCanary, PoC, PowerShell监控, Rootkit, Shuffle, SOAR, SOC分析师, SOC实验室, Suricata, Sysmon, TheHive, Wazuh, Windows安全, Zeek, 企业安全架构, 信标检测, 告警调优, 威胁检测, 安全实验, 安全运营, 开源安全工具, 异常登录检测, 扫描框架, 暴力破解, 横向移动, 现代安全运营, 端点安全, 编程规范, 网络安全实战教程, 网络安全实验室, 网络流量分析, 脆弱性评估, 补丁管理, 逆向工程平台, 靶场