Jayden-j/Home-lab-Active-Directory-Attack-and-Defense-

# Active Directory 攻防实验室 这是我构建的一个包含四台虚拟机的 Active Directory 实验室，旨在端到端地运行完整的攻击链：从一个通过网络钓鱼获取的普通用户账户开始，一直到完全接管整个域，随后利用 Windows 事件日志和自定义的 Wazuh 规则来捕获攻击的每一个步骤。 **技术：** Kerberoasting、Pass-the-Hash、DCSync **技术栈：** Windows Server 2022、Windows 11、Kali Linux、Wazuh SIEM、Sysmon **映射至：** MITRE ATT&CK (T1558.003, T1550.002, T1003.006) ## 概述 我想要一个实验室，在里面我可以像攻击者那样执行真实的域接管，然后思考 SOC 分析师会如何察觉它。我在 VMware 中从零开始构建了它，在 Kali 上手动执行了每一次攻击，并确认每种攻击技术都能在我可以检测到的地方——即原始 Windows 日志和 SIEM 中——留下痕迹。 最让我满意的是检测部分。Wazuh 默认不会标记 DCSync，因此我编写了自己的规则来捕获它。 ## 实验室架构 | 主机 | 角色 | 操作系统 | IP | |------|------|-----|-----| | **DC01** | 域控制器 (`LABBOX.local`) | Windows Server 2022 | `192.168.1.10` | | **WS01** | 加入域的工作站 | Windows 11 | `192.168.1.20` | | **Kali** | 攻击者 | Kali Linux | `192.168.1.250` | | **Wazuh** | SIEM / 日志分析 | Ubuntu Server | `192.168.1.15` | 安装完所有组件后，我禁用了每台虚拟机上的 NAT，并将它们全部放在仅主机模式的 `192.168.1.0/24` 网络中，以便将攻击流量完全限制在内部。  ## 攻击链 ``` j.rivera (phished employee, low privilege) └─▶ Recon with BloodHound └─▶ Kerberoast svc-sql → crack weak password offline └─▶ Pass-the-Hash into WS01 as SYSTEM └─▶ DCSync → dump every credential in the domain ``` ### 1 · 使用 BloodHound 进行侦察 从钓鱼获取的 `j.rivera` 账户开始，我使用 `bloodhound-python` 拉取了完整的域节点图，并将其加载到 BloodHound CE 中，以寻找通往 Domain Admin 的路径。 ``` bloodhound-python -u j.rivera -p 'Summer2025!' -d labbox.local -ns 192.168.1.10 -c All --zip ```  返回结果包含 2 台计算机、7 个用户、52 个组和 3 个 OU。 BloodHound 从 `j.rivera` 到 Domain Admins 的最短路径查询返回为空——这是正确的，而不是故障。BloodHound 映射的是 ACL 和权限边（例如组隶属关系、GenericAll 等），而 `j.rivera` 没有任何这些权限。这在这里之所以重要，仅仅是因为它*是一个经过身份验证的域用户*，而这正是 Kerberoasting 所需的全部条件。真正的提权是离线破解密码，这不是 BloodHound 可以绘制为边的东西。  随后，一旦 `svc-sql` 被攻破，情况就发生了变化。一次全新的收集显示了从 `svc-sql` 直达 Domain Admins 的真实路径——即对 DC01 计算机对象的 GenericWrite 权限，以及一条通往域的 CoerceToTGT 边：  ### 2 · Kerberoasting (T1558.003) 任何通过身份验证的用户都可以请求具有 SPN 的账户的服务票据（Ticket），并且该票据使用该服务账户的密码哈希进行加密——因此我可以获取它并进行离线破解。我将目标锁定在 `svc-sql` 上。 ``` impacket-GetUserSPNs labbox.local/j.rivera:'Summer2025!' \ -dc-ip 192.168.1.10 -request -outputfile kerberoast.hash ```   由于该服务账户使用了弱密码（`Welcome1`），该哈希在 `rockyou.txt` 面前不到一秒钟就被破解了。 ``` john --wordlist=/usr/share/wordlists/rockyou.txt kerberoast.hash ```  ### 3 · Pass-the-Hash (T1550.002) `svc-sql` 在 WS01 上拥有本地管理员权限——这在真实环境中很常见——因此我使用其 NT 哈希直接登录。全程无需输入一次密码。 ``` impacket-psexec -hashes : LABBOX/svc-sql@192.168.1.20 ``` 这让我在 WS01 上获得了一个 SYSTEM shell。值得注意的是：Defender 和 Tamper Protection 在最初几次尝试中阻止了 Payload——这很好地提醒了我们，内置的 AV 确实能捕捉到这一点——因此我不得不绕过它来获取 shell。  ### 4 · DCSync (T1003.006) `svc-sql` 被授予了 Replicating Directory Changes 权限——这就是在真实环境中过度授权的服务账户的样子。有了这个权限，我可以冒充域控制器，并从域中复制出每一个凭证哈希，包括用于伪造 Golden Ticket 的 `krbtgt` 哈希。 ``` impacket-secretsdump -hashes : LABBOX/svc-sql@192.168.1.10 ``` 此时，整个域已被完全接管。所有用户、服务和计算机账户的哈希都被导出了。   ## 检测与防御 执行攻击只是一半的工作。我回过头来审查了每一种技术，并确认了它们出现在 Windows 遥测和 Wazuh 中。 ### 原生 Windows 事件特征 | 攻击 | 事件 ID | 暴露原因 | |--------|----------|--------------------| | Kerberoasting | **4769** | 服务账户的票据加密类型为 `0x17` (RC4) | | Pass-the-Hash | **4624** | 登录类型为 3 且身份验证包为 NTLM | | DCSync | **4662** | 使用复制权限 GUID `{1131f6aa-...}` 进行的对象访问 |  ### 自定义 Wazuh 检测规则 上面的表格告诉了您需要寻找什么，但没有人会一整天盯着事件查看器。为了将这些转化为告警，我在 `/var/ossec/etc/rules/local_rules.xml` 中编写了三条自定义规则，每次攻击一条，每条规则都映射到其对应的 MITRE 技术，并在 Agent 已经转发的 Windows Security 事件基础上触发。 **Kerberoasting。** 单独一个 4769 事件是正常的——每个服务票据请求都会生成一个。破绽在于加密类型：现代 Kerberos 会颁发 AES 票据，因此针对服务账户的 RC4 请求 (`0x17`) 值得被标记。

规则 100200 — Kerberoasting (T1558.003)

``` windows_security ^4769$ ^0x17$ Possible Kerberoasting: RC4-encrypted service ticket requested (MITRE T1558.003) T1558.003 ```

**Pass-the-Hash。** NTLM 网络登录（4624，类型 3）有合理发生的场景，因此该规则的级别调得较低，措辞为“审查”，而不是“已确认”。在生产环境中，我会将其限定为管理员账户或特定子网——普通的 NTLM 类型 3 登录无处不在，否则您会被误报淹没。

规则 100220 — Pass-the-Hash (T1550.002)

``` windows_security ^4624$ ^3$ NTLM NTLM network logon - review for Pass-the-Hash (MITRE T1550.002) T1550.002 ```

**DCSync。** 这是 Wazuh 默认漏掉的一个，也是我最满意的一个。事件 4662 在正常的 AD 活动中会不断触发，因此对所有的此类事件进行告警会让分析师应接不暇。解决方法是：仅在 4662 携带 DCSync 滥用的两个复制权限 GUID 之一时才触发。这种组合在真正的复制之外几乎从不出现——而当它来源于非域控制器时，这就是一个强烈的信号。

规则 100010 — DCSync (T1003.006)

``` windows_security ^4662$ 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2|1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 Possible DCSync attack: AD replication rights used by $(win.eventdata.subjectUserName) T1003.006 dcsync,mitre_credential_access, ```

添加规则后，重启 manager 以加载它们： ``` sudo systemctl restart wazuh-manager ``` 当我执行 DCSync 攻击时，该规则在大约 3 秒的时间窗口内触发了一连串 12 级告警——这与 `secretsdump` 发出复制请求的速度相匹配。它将 `svc-sql` 指定为负责的账户，并用 MITRE T1003.006 标记了该告警。    ## 事件响应总结 | 阶段 | 技术 | MITRE ID | 如何捕获 | |-------|-----------|----------|--------------------| | 侦察 | LDAP/SAMR 枚举 | T1087, T1069 | BloodHound 收集流量 | | 凭证访问 | Kerberoasting | T1558.003 | 事件 4769 (RC4 票据) | | 凭证访问 | 离线破解 | T1110.002 | 不可见（离线发生） | | 横向移动 | Pass-the-Hash | T1550.002 | 事件 4624 (NTLM, 类型 3) | | 凭证访问 | DCSync | T1003.006 | 事件 4662 + 自定义 Wazuh 规则 100010 | ### 在真实环境中我会采取的修复措施 - 为服务账户设置强且唯一的密码，或者将它们转移到支持自动轮换的 gMSA。单凭这一项更改就能彻底阻断 Kerberoasting 攻击路径。 - 检查委派权限并撤除任何过度的设置。任何服务账户都不应拥有 Replicating Directory Changes 权限。 - 让服务账户远离工作站上的本地管理员组，这样它们就无法被用于横向移动。 - 真正针对那些破绽进行告警：RC4 服务票据、来自本不该进行此类操作的账户的 NTLM 网络登录，以及来自非域控制器的复制请求。 ## 遇到的问题 使其正常运行意味着要解决实际问题，而不仅仅是敲击命令。Kerberos 一直抛出时钟偏差错误，直到我同步了攻击者和 DC 的时钟；WS01 的域信任关系断裂并需要修复；Defender 的 Tamper Protection 不断自行悄然重新开启；有一次，DCSync 事件根本没有到达 Wazuh，因为 manager 在攻击中途由于磁盘已满而崩溃。从中得到的最大收获是意识到 Wazuh 默认无法捕获 DCSync——并且由我自己编写规则来修复了它。 由 [Jayden Johnson](https://github.com/Jayden-j) 构建 · 信息系统（网络安全），默瑟县社区学院

标签：Windows域安全, 安全靶场, 数据展示, 红队