Hitansh1601/Windows-Security-Monitoring-Lab

# Windows 安全监控实验室 [](https://wazuh.com) [](https://microsoft.com) [](https://attack.mitre.org) [](https://vmware.com) []() ## 目录 - [实验室架构](#lab-architecture) - [使用的技术](#technologies-used) - [本实验室可检测的内容](#what-this-lab-detects) - [MITRE ATT&CK 覆盖范围](#mitre-attck-coverage) - [设置 — Windows 终端加固](#setup--windows-endpoint-hardening) - [设置 — Wazuh 服务器](#setup--wazuh-server) - [设置 — 代理部署](#setup--agent-deployment) - [检测证据](#detection-evidence) - [文件完整性监控结果](#file-integrity-monitoring-results) - [安全配置评估](#security-configuration-assessment) - [经验教训](#lessons-learned) - [未来改进](#future-improvements) ## 实验室架构 三台 VMware Workstation 虚拟机连接在一个隔离的 **VMnet2 (192.168.100.0/24)** 网段上，与主机的主网络适配器完全实现气隙隔离。 ``` ┌──────────────────────────────────────────────────────────────────────┐ │ VMware Workstation — VMnet2 │ │ Isolated Lab Network │ │ 192.168.100.0/24 │ │ │ │ ┌─────────────────────┐ ┌──────────────────────────────┐ │ │ │ LABWIN10 │ │ wazuh-hit (Ubuntu 24.04) │ │ │ │ Windows 10 Edu │─agents─▶│ Wazuh Manager v4.7.5 │ │ │ │ 192.168.100.10 │ logs │ Wazuh Indexer (OpenSearch) │ │ │ │ Wazuh Agent v4.7.5 │ │ Wazuh Dashboard │ │ │ │ Sysmon installed │ │ 192.168.100.30 │ │ │ └─────────────────────┘ └──────────────────────────────┘ │ │ │ │ Telemetry Pipeline: │ │ Windows Audit Logs + Sysmon Events │ │ → Wazuh Agent (port 1514) │ │ → Wazuh Manager (correlation + rules) │ │ → OpenSearch (indexing + storage) │ │ → Wazuh Dashboard (visualization + MITRE mapping) │ └──────────────────────────────────────────────────────────────────────┘ ``` **代理状态 — 确认活跃：**  ## 使用的技术 |组件 |版本 |角色 | |--------------------|---------------|--------------------------------------------------------------| |VMware Workstation |17.x |Hypervisor — 隔离的虚拟网络 (VMnet2) | |Windows 10 Education|10.0.19045.2965|受害终端 — LABWIN10 (192.168.100.10) | |Ubuntu Server |24.04.4 LTS |Wazuh 平台主机 — wazuh-hit (192.168.100.30) | |Wazuh Manager |4.7.5 |SIEM/XDR — 关联引擎，规则匹配 | |Wazuh Indexer |4.7.5 |OpenSearch 2.x — 日志存储和索引 | |Wazuh Dashboard |4.7.5 |基于 Kibana 的 UI — 告警，MITRE，FIM，SCA | |Sysmon |15.x |Windows 终端遥测 (事件 ID 1, 3, 5, 7, 11, 12, 13) | |Windows auditpol |内置 |细粒度审核子类别配置 | |Group Policy Editor |内置 |审核策略和 Event 4688 中的命令行日志记录 | ## 本实验室可检测的内容 |Windows 事件 ID|事件类型 |配置方式 |结果 | |----------------|------------------------------------|--------------------------|---------------------| |4624 |成功登录 |auditpol + Group Policy |✅ 捕获 208 个事件 | |4625 |失败登录 |auditpol + Group Policy |✅ 捕获 4 个事件 | |4688 |进程创建 (包含命令行) |auditpol + GPO 注册表键 |✅ 活跃 | |4672 |特殊权限登录 |auditpol |✅ 活跃 | |Sysmon 1 |进程创建 |Sysmon |✅ 活跃 | |Sysmon 5 |进程终止 |Sysmon |✅ 捕获 155 个事件 | |FIM 规则 550 |完整性校验和已更改 (级别 7) |Wazuh syscheck |✅ 24小时内命中 256 次| |FIM 规则 554 |文件被添加到系统 (级别 5) |Wazuh syscheck |✅ 活跃 | ## MITRE ATT&CK 覆盖范围 Wazuh 的 MITRE ATT&CK 模块将所有检测到的事件实时映射到对手技术：  |战术 |告警数 |关键技术 | |------------------------|-------|-----------------------------------------------------------------------| |**影响** |**158**|T1565 数据操纵, T1499 终端拒绝服务 | |**防御规避** |**95** |T1562 削弱防御, T1070 指示器移除 | |**持久化** |**53** |T1547.001 注册表自启动项, T1543 创建/修改系统进程 | |**权限提升** |**53** |T1547 启动/登录自启动, T1068 利用漏洞进行权限提升 | |**发现** |**46** |T1082 系统信息发现, T1057 进程发现 | ## 设置 — Windows 终端加固 默认的 Windows 10 几乎不会生成任何有用的安全事件。本实验室中的每一项检测都需要首先进行细致的审核策略配置。 ### 步骤 1 — 通过组策略配置高级审核策略 `gpedit.msc` → 计算机配置 → Windows 设置 → 安全设置 → 高级审核策略配置 → 系统审核策略 **登录/注销子类别：**  *审核登录 = 成功和失败，审核注销 = 成功和失败，审核账户锁定 = 成功和失败* **详细跟踪 — 进程创建：**  *详细跟踪 > 审核进程创建 = 成功* **对象访问 — 文件系统：**  *对象访问 > 审核文件系统属性 = 成功和失败 (勾选两个复选框)* **账户管理：**  *账户管理 > 审核用户账户管理 = 成功和失败* ### 步骤 2 — 在 Event 4688 中启用命令行参数 默认情况下，事件 ID 4688 会捕获进程创建，但省略了命令行参数 — 这使得它对于检测 PowerShell 滥用和 LOLBins 毫无用处。 **通过组策略启用：** *管理模板 → 系统 → 审核进程创建 → 在进程创建事件中包含命令行 → 已启用*  *“在进程创建事件中包含命令行” = 已启用 — 命令行参数现在将写入事件 ID 4688* **通过注册表启用：**  *HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit — ProcessCreationIncludeCmdLine_Enabled DWORD = 1* **策略设置说明界面：**  *策略描述：“决定创建新进程时在安全审核事件中记录哪些信息… 事件 4688”* ### 步骤 3 — 通过 PowerShell 配置 auditpol ``` auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable ```  *PowerShell (管理员): auditpol /set /subcategory:“Process Creation” /success:enable — “命令已成功执行。”* **完整子类别批量配置：**  *CMD (管理员): 多条 auditpol /set 命令 — 安全组管理，进程创建，审核策略更改，敏感权限使用，登录，账户锁定，注销，特殊登录，用户账户管理 — 全部返回“命令已成功执行。”* **验证 — 完整策略输出：**  *auditpol /get /category:* — 登录/注销 = 成功和失败，对象访问: 文件系统 = 成功和失败，权限使用: 敏感权限使用 = 成功和失败，详细跟踪: 进程创建 = 成功和失败*  *续输出 — 权限使用，策略更改: 审核策略更改 = 成功和失败，账户管理: 用户账户管理 = 成功和失败* ### 步骤 4 — Sysmon 安装 Sysmon 文件下载至 `C:\Users\Hitansh\Downloads\Sysmon\`：  *Windows 资源管理器：Downloads/Sysmon 文件夹 — Eula (8KB), Sysmon (8.2MB), Sysmon64 (4.4MB), Sysmon64a (4.8MB) — 日期均为 2/21/2026* Sysmon 在安装后立即开始捕获遥测数据 — 事件查看器确认：  *事件查看器 → 应用程序和服务日志 → Microsoft → Windows → Sysmon → Operational：155 个事件。高亮显示的事件 ID 5 (进程已终止)，包含 RuleName 和 UtcTime 2026-02-22 05:08:04.142。计算机: DESKTOP-BDBM5IR* ## 设置 — Wazuh 服务器 ### 安装 ``` curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh chmod +x wazuh-install.sh sudo bash wazuh-install.sh -a -i ``` **首次尝试 (2026年2月)：** wazuh-indexer (OpenSearch/Java) 在启动期间超时 — 虚拟机上堆内存不足。安装被自动清理，虚拟机被关机以添加更多内存。  *首次尝试：wazuh-indexer 服务启动超时。“无法启动 wazuh-indexer.service — Wazuh-Indexer。找不到单元 wazuh-manager.service。”* **第二次尝试 (2026年3月4日) — 成功：**  *Wazuh 4.7.5 完整安装日志：indexer ✓ (13:52:59), manager ✓ (14:06:15), Filebeat ✓ (14:06:53), dashboard ✓ (14:10:51) — “安装完成。”* ### 服务验证 ``` sudo systemctl status wazuh-manager --no-pager ```  *wazuh-manager：自 2026-03-04 14:06:37 UTC 起 active (running)。列出所有子进程：wazuh-authd (46410), wazuh-db (46425), wazuh-execd (46437), wazuh-analysisd (46451), wazuh-syscheckd (46476), wazuh-remoted (46491), wazuh-logcollector (46554), wazuh-monitord (46572), wazuh-modulesd (46594)*  *同时确认 wazuh-dashboard (active/running, Main PID 50740 node, Memory 266.2M) 和 wazuh-indexer (自 15:41:30 起 active/running)* ### 网络配置 Ubuntu Wazuh 服务器需要在其实验室子网上配置第二块 NIC (ens37)，以便 LABWIN10 能够访问它：  *ip addr show ens37 确认 ens37 = 192.168.100.30/24 — Wazuh 服务器可在 VMnet2 上从 LABWIN10 访问* Windows 终端双 NIC 确认：  *PowerShell: ipconfig /all — Ethernet0 = 192.168.100.10 (实验室网络), Ethernet1 = 192.168.13.133 (NAT)。两个接口均处于活动状态。* VMware 网络适配器配置：  *VMware 虚拟机设置 > 网络适配器 > 自定义：选择 VMnet2 — 将实验室流量与主机网络隔离* ### API 连接调试 安装后，Wazuh Dashboard 显示 “No API available to connect”。调试步骤： ``` # 确认 API 端口正在监听 sudo ss -tlnp | grep 55000 ```  *sudo ss -tlnp | grep 55000 → LISTEN 0 128 0.0.0.0:55000 users:((“python3”,pid=50130,fd=41)) — API 端口打开并正在监听* ``` # 确认 API 响应（401 = 存活，连接被拒绝 = 宕机） curl -k -u wazuh-wui:wazuh-wui https://127.0.0.1:55000 ```  *curl 响应：{“title”:“Unauthorized”,“detail”:“No authorization token provided”} — API 处于活跃状态，dashboard 配置需要正确的 IP 而不是 localhost* ## 设置 — 代理部署 ### 注册命令 Wazuh Dashboard 会在 Deploy new agent 下生成确切的 PowerShell 命令：  *步骤 4: Invoke-WebRequest 下载 wazuh-agent-4.7.5-1.msi，参数为 WAZUH_MANAGER=192.168.100.30, WAZUH_AGENT_NAME=LABWIN10, WAZUH_REGISTRATION_SERVER=192.168.100.30。步骤 5: NET START WazuhSvc* ``` # 在 LABWIN10 上以 Administrator 身份运行 Invoke-WebRequest -Uri "https://packages.wazuh.com/4.x/windows/wazuh-agent-4.7.5-1.msi" ` -OutFile "${env:tmp}\wazuh-agent" msiexec.exe /i "${env:tmp}\wazuh-agent" /q ` WAZUH_MANAGER='192.168.100.30' ` WAZUH_AGENT_NAME='LABWIN10' ` WAZUH_REGISTRATION_SERVER='192.168.100.30' NET START WazuhSvc ``` ### 代理安装目录  *Windows 资源管理器：ossec-agent 目录 — active-response, bookmarks, incoming, logs, queue, rids, ruleset, shared, syscheck, tmp, upgrade, wodles — 所有文件夹均创建于 3/10/2026 11:11 PM* ### 确认代理服务正在运行 ``` Get-Service WazuhSvc # Status: Running Name: WazuhSvc DisplayName: Wazuh ```  *Windows 10 虚拟机上的 PowerShell (管理员)：Get-Service WazuhSvc = Running。NET START WazuhSvc = “请求的服务已经启动。” 两个虚拟机均显示在 VMware 侧边栏中。* ### 代理在 Dashboard 中处于活跃状态  |字段 |值 | |-----------------|----------------------------------------------| |Agent ID |001 | |Agent Name |LABWIN10 | |状态 |● active | |IP 地址 |192.168.100.10 | |操作系统 |Microsoft Windows 10 Education 10.0.19045.2965| |Wazuh 版本 |v4.7.5 | |Cluster Node |node01 | |代理覆盖率 |**100.00%** | |注册日期 |Mar 11, 2026 @ 19:27:30 | |最后 Keepalive |Mar 11, 2026 @ 19:38:23 | ## 检测证据 ### Wazuh 模块 Dashboard 服务器上线后加载的所有 Wazuh 功能模块：  *Wazuh Dashboard 模块页面：安全信息管理 (安全事件，完整性监控)，审核与策略监控 (策略监控，系统审核，安全配置评估)，威胁检测与响应，法规合规性* ### Windows 事件日志分析 **失败登录事件 (事件 ID 4625)：** 在配置审核策略之前，未记录任何失败的登录。配置 auditpol 后，安全日志捕获到：  *针对事件 ID 4625 (审核失败) 过滤的安全日志 — 在 2026 年 2 月 22 日 10:46–10:47 捕获了 4 个事件。过滤对话框显示输入了事件 ID 4625。* **成功登录事件 (事件 ID 4624)：**  *事件 ID 4624 过滤器 — 208 个审核成功事件。事件详情：“账户已成功登录。”计算机：DESKTOP-BDBM5IR* **包含命令行的进程创建 (事件 ID 4688)：**  *事件 ID 4688 属性：SubjectUserName DESKTOP-BDBM5IR$, NewProcessName C:\Windows\SoftwareDistribution\Download\Install\AM_Delta_Patch_1.445.1840.exe — 命令行日志记录正常工作* **网络和 IP 配置 (用于验证双 NIC 实验室设置)：**  *CMD：whoami = desktop-bdbm5ir\hitansh, net user = Administrator / DefaultAccount / Guest / Hitansh / WDAGUtilityAccount, ipconfig /all = Host Name: DESKTOP-BDBM5IR, IPv4: 192.168.13.131* ## 文件完整性监控结果 Wazuh FIM 监控关键的 Windows 目录，并在文件创建、修改和删除时发出告警。 - **规则 550** (级别 7)：完整性校验和已更改 - **规则 554** (级别 5)：文件被添加到系统 **时间范围：** 2026年3月10日 @ 19:39 → 2026年3月11日 @ 19:39 (24小时窗口) **总事件数：256 次命中**  ``` syscheck.path: c:\programdata\microsoft\diagnosis\eventstore.db-wal syscheck.event: modified rule.description: Integrity checksum changed rule.level: 7 rule.id: 550 timestamp: Mar 11, 2026 @ 19:39:27.282 ``` 时间轴上 18:00 的峰值对应于 Windows Update 活动 — 这是 SOC 分析师在编写基于阈值的检测规则之前必须了解的正常基线。 ## 安全配置评估 Wazuh SCA 在每次扫描周期时针对 LABWIN10 运行 CIS Microsoft Windows 10 Enterprise Benchmark v1.12.0。  **SCA 配置文件：** `cis_win10_enterprise` **基准：** CIS Microsoft Windows 10 Enterprise Benchmark v1.12.0 在此单一终端上检测到的 PCI DSS 合规性覆盖范围： |PCI DSS 控制 |告警数 | |----------------------------------------|-----------| |2.2 (系统加固) |395 | |11.5 (文件完整性监控) |243 | |2.2.5 (移除不必要的功能)|53 | |4.1 (加密传输) |44 | |10.6.1 (审查日志) |25 | ## 代理清单 Wazuh 会在每个注册的代理上自动盘点硬件、OS、网络接口和开放端口。  *可通过 Wazuh Dashboard 中的 Agents → LABWIN10 → Inventory data 标签页访问代理概览和清单数据。* **捕获的清单：** - **主机名：** DESKTOP-BDBM5IR - **OS：** Microsoft Windows 10 Education x86_64 (10.0.19045.2965) - **CPU：** 11th Gen Intel Core i3-1115G4 @ 3.00 GHz - **RAM：** 2,047.05 MB - **网络接口：** 3 (Ethernet0, Ethernet1, Loopback Pseudo-Interface 1) - **开放端口：** 48 (135 RPC, 137–139 NetBIOS, 445 SMB, 3389 RDP) - **最后扫描：** Mar 11, 2026 @ 19:35:04 ## 经验教训 **1. 默认的 Windows 10 审核策略几乎捕获不到任何内容。** 如果不对每个相关的子类别运行 `auditpol`，进程创建、权限使用、对象访问和登录事件就不会出现在安全日志中。配置是先决条件。 **2. Event 4688 中的命令行日志记录默认是关闭的。** 如果不通过注册表或组策略设置 `ProcessCreationIncludeCmdLine_Enabled = 1`，Event 4688 会显示进程已运行，但不显示执行了什么命令 — 这对于检测 PowerShell 滥用毫无用处。 **3. Wazuh indexer 需要足够的内存空间。** 首次安装尝试失败，因为 OpenSearch/Java 进程在 RAM 不足的虚拟机上启动超时。Wazuh 服务器虚拟机至少需要 4GB 内存。 **4. 必须刻意进行网络分段。** Windows 虚拟机和 Ubuntu 服务器都需要明确的 VMnet2 适配器配置。只有在适配器分配正确的情况下，实验室网络 (192.168.100.0/24) 和 NAT 网络 (192.168.13.0/24) 才能在双 NIC 虚拟机上共存而不会发生路由冲突。 **5. 实时 Windows 终端上的 FIM 数量很高。** 在完全正常的系统活动下，24小时内有 256 个 FIM 事件。有效的检测工程在编写阈值规则之前需要一个基线 — 否则一切都是误报。 **6. Wazuh API 返回 401 是个好消息。** “Connection refused” 意味着 API 宕机。“Unauthorized” (HTTP 401) 意味着 API 处于活跃状态，dashboard 只需要正确的 JWT 配置 — 这是一个关键的故障排除区别。 ## 未来改进 - [ ] 运行 Atomic Red Team 模拟并验证各项技术的检测覆盖率 - [ ] 为特定攻击模式 (暴力破解、PowerShell 编码命令、LOLBins) 编写自定义的 Wazuh XML 检测规则 - [ ] 添加 Kali Linux 作为主动攻击者虚拟机 — 针对实验室 LABWIN10 使用 Nmap、Hydra、Metasploit - [ ] 配置 Wazuh Active Response 以自动阻止攻击者 IP - [ ] 添加带有 Active Directory 的 Windows Server 2022，以模拟加入域的企业攻击 - [ ] 集成 Shuffle SOAR，以实现自动化的告警分流和工单创建 - [ ] 部署 Zeek/Suricata，与基于主机的检测一起进行网络层检测 - [ ] 为所有自定义的 Wazuh 检测构建等效的 Sigma 规则 ## 展示的技能 `Wazuh v4.7.5` `SIEM 管理` `Windows 审核策略 (auditpol)` `组策略编辑器 (Group Policy Editor)` `Sysmon` `Windows 事件日志分析` `事件 ID 4624/4625/4688` `文件完整性监控` `安全配置评估` `CIS 基准` `PCI DSS` `MITRE ATT&CK` `VMware Workstation` `Ubuntu Server 24.04` `多虚拟机实验室设计` `网络分段` `蓝队运营` `SOC 分析师工作流` `检测工程` *由 [Hitansh Waghela](https://linkedin.com/in/hitansh-waghela-99554a274) 构建 — 计算机工程，孟买大学* *[GitHub](https://github.com/Hitansh1601) · [TryHackMe](https://tryhackme.com/p/hitansh1601) · [whitansh@gmail.com](mailto:whitansh@gmail.com)*

标签：AI合规, Sysmon, VMware, Wazuh, x64dbg, 安全实验室, 越狱测试