DetectionLab 构建指南：面向防御者的自动化 Windows 安全检测实验环境-平芜编程栈

网络安全
运维
DevOps

【免费下载链接】DetectionLab

Automate the creation of a lab environment complete with security tooling and logging best practices

项目地址：https://gitcode.com/gh_mirrors/de/DetectionLab

DetectionLab 是一个面向防御者（蓝队）设计的自动化安全实验环境项目，其核心目标是通过一键式脚本快速搭建一个预装安全工具链、并遵循系统日志最佳实践的 Windows 域环境。本文基于仓库根目录的 README.md 展开，并结合Vagrant/目录下的实际部署脚本与配置，完整讲解实验室的架构设计、内置安全特性、构建前置检查、部署流程与构建后验证方法，帮助读者快速上手并理解其底层实现原理。

一、项目定位：为防御者打造的"可见性与内省"实验室

DetectionLab 的设计初衷非常明确：以防御者（defender）为中心。它的主要用途是让使用者能够快速构建一个 Windows 域，该域预先加载了安全工具以及系统日志配置的最佳实践，并且"可以轻松修改以适应大多数需求，或扩展以包含额外主机"（README 原文）。

从仓库目录结构来看，项目以「多平台可移植」为设计目标，同时提供了 Vagrant（VirtualBox / VMware / HyperV / LibVirt）、AWS Terraform、Azure Terraform + Ansible、ESXi Terraform + Ansible 与 Proxmox 等多种部署途径，其中本地虚拟化场景以 Vagrant 为主力。

在阅读和使用本项目时，有两点必须铭记（README 原文强调）：

本实验环境未经任何加固（hardened），且使用默认的 vagrant 凭证运行。请勿将它连接或桥接到任何你所在意的网络。
实验室被有意设计为不安全（deliberately designed to be insecure），其首要目的是为每个主机提供可见性与内省（visibility and introspection）能力，让防御者能清楚地观察攻击者在域内的一举一动。

此外，README 明确标注：自 2023-01-01 起，DetectionLab 不再积极维护，但仓库仍会通过每周六定时触发的 CircleCI 工作流持续验证构建是否通过，因此现有版本仍可作为学习与复现蓝队环境的参考。

二、实验室核心架构：四台主机 + 一个域

从 Vagrant/Vagrantfile 可以看到，本地 Vagrant 版实验室由 4 台核心主机组成（如需 Exchange 可自行扩展，仓库也提供了相关脚本）：

主机名	系统	内网 IP（192.168.56.0/24）	资源（VirtualBox 默认）	角色
`logger`	Ubuntu 20.04（bento/generic）	192.168.56.105	4GB 内存 / 2 vCPU	Splunk、Fleet、Zeek、Suricata、Velociraptor、Guacamole
`dc`	Windows Server 2016	192.168.56.102	3GB 内存 / 2 vCPU	域控制器（windomain.local）、Microsoft ATA 轻量级网关
`wef`	Windows Server 2016	192.168.56.103	2GB 内存 / 2 vCPU	Windows Event Collector、Splunk Universal Forwarder、Microsoft ATA Center
`win10`	Windows 10	192.168.56.104	3GB 内存 / 2 vCPU	加入域的客户端工作站

2.1 网络与 DNS 设计

Vagrantfile 中每个节点都通过vm.network :private_network挂在192.168.56.0/24的 host-only 网段上：

dc与wef、win10的 DNS 指向192.168.56.102（DC 本身承担 DNS 角色）；
wef和win10的 gateway 为192.168.56.1（宿主机）；
logger使用 8.8.8.8 等公共 DNS，但同时保留了对192.168.56.102的解析，用于访问域内资源。

Windows 主机在加入域前，通过 Vagrant/scripts/join-domain.ps1 将网卡 DNS 临时切换为 DC 的 IP（SetDNSServerSearchOrder("192.168.56.102")），完成域加入后再交由域策略接管。dc主机则在 create-domain.ps1 中通过Install-ADDSForest创建windomain.local林，并禁用密码复杂度策略、将管理员密码设为vagrant——这再次印证了该环境"未加固、默认凭证"的设计前提。

2.2 域内 OU 划分

域内预先按角色划分了两个 OU，以便 GPO 定向应用：

OU=Servers,DC=windomain,DC=local：wef、exchange 等服务器加入此处；
OU=Workstations,DC=windomain,DC=local：win10 加入此处。

这些 OU 由 configure-ou.ps1 创建，域控自身则在ou=Domain Controllers默认容器。后续所有日志类 GPO 均按这三个 OU 分别链接，实现差异化策略。

三、内置安全特性（Primary Lab Features）逐项解析

README 列出了实验室开箱即用的十大核心特性。下面逐项说明，并结合仓库脚本给出实现依据，方便读者深入定位到具体代码。

3.1 Microsoft Advanced Threat Analytics（ATA）

特性：Microsoft ATA 安装在 wef 主机上（Center 角色），DC 上安装轻量级 ATA 网关。
实现依据：install-microsoft-ata.ps1 完成 ATA 1.9 的 ISO 下载（带 SHA256 哈希校验与 bitsadmin 重试）、Center 静默安装，并通过 REST API 将 DC 注册为域同步器；随后在 DC 上远程拉取网关部署包并安装ATAGateway服务，最后等待服务进入 Running 状态，失败即抛出异常。

3.2 Splunk 与预建索引、技术插件

特性：Splunk forwarder 预装，所有索引预创建，技术插件（TA）预配置。
实现依据：logger 由 logger_bootstrap.sh 的install_splunk()函数完成 Splunk Enterprise 的自动版本解析、下载与安装，并一次性创建wineventlog、osquery、sysmon、powershell、zeek、suricata、threathunting、evtx_attack_samples、msexchange等 9 个索引；随后安装 Windows TA、Sysmon TA、Zeek TA、ASNgen、ThreatHunting 等应用，并在inputs.conf中开启splunktcp://9997接收 Windows 主机转发上来的事件。各 Windows 主机则通过 install-splunkuf.ps1 静默安装 Splunk Universal Forwarder，并直接指向192.168.56.105:9997。wef 上额外执行 install-windows_ta.ps1 安装 Windows 技术插件（仅需在 WEF 服务器上安装一次）。

3.3 自定义 Windows 审计策略 GPO（命令行进程审计 + 系统级日志）

特性：通过 GPO 设置自定义 Windows 审计配置，包含命令行进程审计（Command Line Process Auditing）与额外的 OS 级日志。
实现依据：configure-AuditingPolicyGPOs.ps1 从resources/GPO/导入三套审计策略 GPO——Domain Controllers Enhanced Auditing Policy、Servers Enhanced Auditing Policy、Workstations Enhanced Auditing Policy，分别强制链接到对应 OU。这三套 GPO 是攻击行为可见性的基础：进程创建（4688）附带命令行参数，大幅提升 Splunk 中威胁狩猎的检索价值。

3.4 Palantir Windows Event Forwarding 订阅与自定义通道

特性：实现 Palantir 的 Windows Event Forwarding（WEF）订阅与自定义通道。
实现依据：所有主机先由 download_palantir_wef.ps1 从 Palantir 仓库拉取windows-event-forwarding源码包；wef 上再由 install-wefsubscriptions.ps1 完成：注册CustomEventChannels.dll清单、将 WEC 通道容量调至 4GB、启动 Windows Event Collector 服务（wecsvc）、批量导入并启用所有 XML 订阅、执行wecutil qc快速配置，最后轮询确认服务正常运行。GPO 侧则由 configure-wef-gpo.ps1 导入Windows Event Forwarding Server与Custom Event Channel Permissions两套 GPO，链接到三个 OU 并gpupdate /force生效。

3.5 PowerShell 转录日志（Transcript Logging）

特性：PowerShell 转录日志已启用，所有日志保存到\\wef\pslogs。
实现依据：双层实现——configure-powershelllogging.ps1 通过 GPO（Powershell Logging）开启 PowerShell Module、ScriptBlock 与 Transcript 日志并链接到各 OU；configure-pslogstranscriptsshare.ps1 在 wef 上创建c:\pslogs目录与pslogsSMB 共享，ACL 设计为：Administrators 完全控制，Everyone 仅写 + 读属性（防止用户列出其他机器的转录文件），最终由 Splunk Forwarder 读取并索引。这份设计源自 PowerShell 蓝队最佳实践，是检测横向移动与脚本攻击的关键数据源。

3.6 osquery + Fleet 分布式端点遥测

特性：每台主机安装 osquery，通过 TLS 连接 Fleet 服务器；Fleet 预配置了 Palantir 的 osquery 配置。
实现依据：logger_bootstrap.sh 的install_fleet_import_osquery_config()在 logger 上完成 Fleet 全流程：准备 MySQL 数据库、下载最新 Fleet/fleetctl 二进制、fleet prepare db、注册 systemd 服务、fleetctl setup创建管理员账号、写入统一 enrollment secret（enrollmentsecretenrollmentsecret）、将查询间隔从生产值（3600s/28800s）调短为实验室值（300s/1800s）以适配实验节奏，最后批量导入 Palantir osquery 配置与 packs。Windows 侧 install-osquery.ps1 通过 Chocolatey 安装 osquery，下载 Palantir 的 flags 文件，将 TLS 端点指向fleet:8412（hosts 文件映射到 192.168.56.105），写入 enrollment secret，并注册osqueryd服务。

3.7 Sysmon + Olaf Hartong 的模块化配置

特性：Sysmon 安装并使用 Olaf Hartong 开源的 sysmon-modular 配置。
实现依据：install-sysinternals.ps1 下载 Sysmon64 及全套 Sysinternals 工具（Autoruns、Procmon、PsExec、Process Explorer、Sdelete、Tcpview）到C:\Tools\Sysinternals，随后下载sysmon-modular的sysmonconfig.xml，以-accepteula -i安装驱动并轮询确认Sysmon64服务运行，最后通过wevtutil调整 Sysmon 事件通道 ACL 使其可被收集。脚本中也保留了 SwiftOnSecurity sysmon-config 作为备选配置的注释说明。

3.8 自启动项日志化（AutorunsToWinEventLog）

特性：所有自启动项（autostart items）通过 AutorunsToWinEventLog 写入 Windows 事件日志。
实现依据：install-autorunstowineventlog.ps1 从 Palantir WEF 仓库安装 AutorunsToWinEventLog，并针对上游 HTTPS 下载失败问题做了 HTTP 回退修补（对应仓库 issue #597），注册AutorunsToWinEventLog计划任务并立即触发一次，之后每天 11 点自动运行，将 Autoruns 扫描结果写入事件日志供 Splunk 索引——这对检测持久化机制尤为重要。

3.9 网络流量监控：Zeek 与 Suricata

特性：Zeek 与 Suricata 预配置，用于监控并对网络流量告警。
实现依据：logger 上通过 logger_bootstrap.sh 安装并配置两者。Zeek 安装zeek-lts，加载 JA3、SMB、Intel 情报等脚本，按 CPU 数量配置 eth0/eth1 多 worker（AWS 环境自动跳过 eth0），并由 systemd 托管；Suricata 安装后启用et/open与 attackdetection 规则源，禁用与 Zeek 重复的协议解码规则，配置 500MB 每小时轮转的 logrotate 策略。两者的日志最终都被 Splunk 监控摄入（suricata/zeek索引）。

3.10 Apache Guacamole 浏览器远程访问

特性：Apache Guacamole 安装，可从浏览器方便地访问所有主机。
实现依据：同样由 logger_bootstrap.sh 的install_guacamole()编译安装 Guacamole server 1.3.0、部署guacamole.war到 Tomcat9，配置user-mapping.xml与guacd服务，最终可通过http://192.168.56.105:8080/guacamole/在浏览器中直接操作 RDP/VNC 会话，省去逐个打开虚拟机控制台的麻烦。

四、构建前置检查：prepare 脚本

README 强调：在本地构建 DetectionLab 前，务必使用Vagrant目录内的prepare.[sh|ps1]脚本，确保系统通过构建的前置检查。macOS / Linux 使用 prepare.sh，Windows 使用prepare.ps1。

以 prepare.sh 为例，它依次完成以下检查：

PATH 工具检查：Vagrant（必须，版本建议 ≥ 2.2.9）、curl（构建后检查需要）、Packer（仅自建 box 时需要，缺失只告警不阻断）。
Box 目录检查：检测Boxes目录是否已有手工构建的.box文件，避免与预构建 box 冲突。
磁盘空间检查：主分区建议 ≥ 80GB 可用空间，不足时输出警告。
已有机检查：通过vagrant status判断是否已创建实例，如已有实例提示先vagrant destroy -f清理。
插件检查：确认vagrant-reload插件已安装（缺失时自动安装）。
Provider 枚举：检测 VirtualBox、VMware Fusion/Workstation 及其官方插件、vagrant-vmware-utility是否就绪，并给出VAGRANT_DEFAULT_PROVIDER设置建议；同时针对 macOS Big Sur 下 VMware Fusion 的已知问题给出 workaround 提示。

检查通过后，脚本提示"To get started building DetectionLab, runvagrant up."

五、构建与部署途径

README 为不同平台提供了对应的部署指南，仓库内也存放了对应实现：

本地虚拟化：macOS（VirtualBox 或 VMware Fusion）、Windows（VirtualBox 或 VMware Workstation）、Linux（VirtualBox 或 VMware Workstation），核心入口为 Vagrant/Vagrantfile；
AWS：通过 Terraform 部署，见 AWS/Terraform；
Azure：Terraform 创建资源 + Ansible 完成配置，见 Azure/Terraform/main.tf 与 Azure/Ansible/detectionlab.yml；
ESXi：Terraform + Ansible，见 ESXi/main.tf；
HyperV：见 HyperV/Vagrantfile；
LibVirt / Proxmox：分别见 Vagrant/Vagrantfile 中的 libvirt provider 配置与 Proxmox/Terraform/main.tf。

若需手工构建 Vagrant box，仓库在 Packer 目录提供了 Windows 10 / Windows 2016 的 Packer 模板（windows_10.json、windows_2016.json）及answer_files/下的 Autounattend.xml 无人值守安装应答文件。默认情况下，dc/wef/win10使用detectionlab/win2016、detectionlab/win10预构建 box，logger使用bento/ubuntu-20.04（libvirt 下为generic/ubuntu2004）。

5.1 Windows 主机的启动流程

理解 Vagrant/Vagrantfile 中 dc/wef/win10 的 provision 序列，有助于排障：

fix-second-network.ps1：修正第二块网卡的静态 IP；
provision.ps1（Vagrant/scripts/provision.ps1）：设置 UTC 时区、处理 Windows 评估版过期、禁用 IPv6；首次执行时因主机名仍是 vagrant 原值而跳过域操作，随后触发vagrant reload重启；
重启后再执行provision.ps1：此时主机名已变为目标主机名，若未加域则走create-domain.ps1（dc）或join-domain.ps1（其余主机）完成建域/加域，并自动配置开机自动登录；
随后按主机角色执行工具安装与 GPO 配置脚本（详见第三节）。

整个流程中wevtutil el ... wevtutil cl会清空除 LiveId 外的所有事件日志，确保 Splunk 索引从"干净"状态开始采集。

六、构建后验证：post_build_checks

构建完成后，建议运行 post_build_checks.sh（macOS/Linux）或post_build_checks.ps1（Windows）验证关键服务是否就绪。该脚本对以下 5 个服务做 HTTP 探活：

服务	检查方式
Splunk	`https://192.168.56.105:8000`（登录页关键字`This browser is not supported by Splunk`）
Fleet	`https://192.168.56.105:8412`（关键字`Fleet for osquery`）
Microsoft ATA	`https://192.168.56.103`（期望 HTTP 401，即服务在线但需认证）
Velociraptor	`https://192.168.56.105:9999`（关键字`app/index.html`）
Guacamole	`http://192.168.56.105:8080/guacamole/`（关键字`Apache Software`）

任一服务不可达时，脚本会输出警告提示对应组件可能未正确安装，便于针对性排查。

七、使用与访问要点

实验室构建完成后，主要访问入口集中在 logger 主机：

Splunk：https://192.168.56.105:8000，默认账号admin，密码changeme；已启用 SSL，且配置了预置 dashboard；
Fleet：https://192.168.56.105:8412，管理员账号admin@detectionlab.network，初始密码Fl33tpassword!；
Guacamole：http://192.168.56.105:8080/guacamole/，可浏览器内访问 dc/wef/win10；
Velociraptor：https://192.168.56.105:9999；
Microsoft ATA：https://192.168.56.103；
各 Windows 主机的本地/域账号均为vagrant（密码vagrant），域为windomain.local。

（以上凭证均可在仓库脚本中直接确认，属于 README 所述"默认 vagrant 凭证"范畴，切勿用于生产网络。）

八、贡献与致谢

如需参与开发，README 要求全部开发在自己的 fork 的功能分支上进行，贡献规范见 CONTRIBUTING.md。项目代码有相当一部分借鉴自 Stefan Scherer 的 packer-windows 与 adfs2 仓库，README 同时向 Palantir（WEF、osquery 配置）、Microsoft、Splunk、osquery、Fleet、Sysinternals、SwiftOnSecurity、Atomic Red Team、Velociraptor、BadBlood、PurpleSharp、EVTX-ATTACK-SAMPLES 等项目致谢，这些上游项目共同构成了 DetectionLab 的能力底座。

九、总结

DetectionLab 的价值在于把"日志采集 + 端点遥测 + 网络监控 + 域内活动可见性"这一套蓝队基础设施，压缩成一条可复现的自动化构建流水线：从 Vagrant/Vagrantfile 定义的四主机拓扑，到 logger_bootstrap.sh 中的 Splunk/Fleet/Zeek/Suricata 全家桶，再到 DC 上通过 GPO 批量下发的审计策略与 WEF 订阅，每一步都有仓库脚本可查、可改。需要再次强调的是，这是一个刻意不安全的实验环境，请务必隔离运行；同时项目已停止积极维护，使用时应以本仓库当前代码为准，并结合实际环境验证可用性。对于希望系统学习 Windows 事件日志、威胁狩猎与检测工程实践的读者而言，它仍是一份不可多得的完整参考实现。