渗透攻防实战：Windows 域内 GPO 权限边界验证、留痕排查与加固

背景在授权内网渗透中，组策略对象（GPO）经常被当作普通运维配置检查，却容易成为从低权限域账号通往终端本地管理员权限的边界缺口。典型问题不是域控本身存在漏洞，而是某个委派组对 GPO 拥有编辑权、GPO 文件目录 ACL 过宽，或者高权限 GPO 被链接到了不应覆盖的 OU。本文以一个已获书面授权的测试场景为例：测试账号属于 Helpdesk-GPO-Editors，目标是确认该组能否修改作用于 Workstations OU 的策略，并评估策略下发范围、审计留痕和修复方式。验证以读取配置、建立无害标记和回滚为主，不执行新增管理员、关闭安全软件或投递载荷等破坏性操作。测试前应明确域名、目标 OU、允许修改的 GPO、变更窗口和回滚负责人。生产域中不要直接验证未确认作用域的策略。问题定位首先在域成员管理机上确认当前身份、域上下文和策略结果。重点区分三类权限：Active Directory 中 GPO 对象的控制权限、SYSVOL 中策略文件的 NTFS 权限，以及 OU 上的 GPO 链接与继承关系。只检查其中一处，结论通常不完整。whoami /all
nltest /dsgetdc:corp.example
set LOGONSERVER
gpresult /scope computer /r
gpresult /scope computer /h C:\\Temp\\gpresult.html

# 在安装了 GPMC/RSAT 的授权管理终端执行
Get-GPO -All -Domain corp.example |
Select-Object DisplayName, Id, GpoStatus, ModificationTime

Get-GPInheritance -Target 'OU=Workstations,DC=corp,DC=example' |
Format-List如果 gpresult 中未出现预期 GPO，不要立即判断策略无效。还要检查安全筛选、WMI Filter、站点/域/OU 链接顺序、强制链接以及阻止继承。计算机策略使用的是计算机账户权限，而不是当前登录用户权限。技术分析：GPO 的双对象权限模型一个 GPO 同时存在于两处：AD 中的 Group Policy Container（GPC）保存版本、显示名等属性；SYSVOL 中的 Group Policy Template（GPT）保存 Registry.pol、脚本及其他策略文件。正常编辑会同步更新两边的版本号。如果攻击者或误配置主体仅能改 SYSVOL 文件，可能造成内容与版本不一致；如果能编辑 GPO 对象并写入 GPT，则具备实际策略篡改能力。检查面位置关注点GPCCN=Policies,CN=System,DC=...WriteProperty、WriteDacl、GenericAll、版本属性GPT\\域名\\SYSVOL\\域名\\Policies\\{GUID}Modify、Write、继承 ACL、异常脚本或策略文件链接站点、域或 OU 的 gPLink作用范围、顺序、Enforced、继承关系筛选GPO 权限与 WMI FilterApply Group Policy、计算机账户读取权限用 Get-GPPermission 获取受支持的权限视图，再用 Get-Acl 核对底层 ACL。发现 GpoEditDeleteModifySecurity、GenericAll、WriteDacl 或非预期的写权限时，应进一步确认主体是否为嵌套组成员。$gpoName = 'Workstation Baseline'
$domain = 'corp.example'
$gpo = Get-GPO -Name $gpoName -Domain $domain

Get-GPPermission -Guid $gpo.Id -Domain $domain -All |
Sort-Object Trustee |
Format-Table Trustee, TrusteeType, Permission -AutoSize

$gpc = 'AD:\\CN={' + $gpo.Id.Guid + '},CN=Policies,CN=System,DC=corp,DC=example'
(Get-Acl $gpc).Access |
Where-Object { $_.ActiveDirectoryRights -match 'Write|GenericAll' } |
Format-Table IdentityReference, ActiveDirectoryRights, AccessControlType, IsInherited

$gpt = '\\\\corp.example\\SYSVOL\\corp.example\\Policies\\{' + $gpo.Id.Guid + '}'
(Get-Acl $gpt).Access |
Where-Object { $_.FileSystemRights -match 'Write|Modify|FullControl' } |
Format-Table IdentityReference, FileSystemRights, AccessControlType, IsInherited操作步骤：以无害标记验证可写性生产环境不建议通过创建计划任务、启动脚本或本地管理员成员来证明风险，因为这些动作会改变执行面。更稳妥的方式是在隔离测试 OU 中复制目标 GPO，仅写入一个无安全影响的注册表标记，并观察目标测试机是否接收。复制后的 GPO 不应链接到生产 OU。建立仅包含一台测试虚机的 Lab-Workstations OU。复制待验证 GPO，并记录新 GPO 的 GUID、创建时间和操作者。只把副本链接到测试 OU，安全筛选限定为测试计算机账户。写入 HKLM\\Software\\AuthorizedPentest 下的字符串标记。刷新策略并核对结果、事件日志和文件版本，随后删除链接与副本。$src = 'Workstation Baseline'
$dst = 'PT-GPO-Write-Validation-20250308'
$targetOu = 'OU=Lab-Workstations,DC=corp,DC=example'

Copy-GPO -SourceName $src -TargetName $dst -SourceDomain corp.example -TargetDomain corp.example
New-GPLink -Name $dst -Target $targetOu -LinkEnabled Yes

# 限定为实验计算机；按实际测试机名称替换
Set-GPPermission -Name $dst -TargetName 'LAB-PC01$' `
-TargetType Computer -PermissionLevel GpoApply

Set-GPRegistryValue -Name $dst `
-Key 'HKLM\\Software\\AuthorizedPentest' `
-ValueName 'GPOWriteValidation' -Type String `
-Value 'change-ticket-CHG-1042'

# 在 LAB-PC01 上执行
gpupdate /target:computer /force
reg query HKLM\\Software\\AuthorizedPentest /v GPOWriteValidation
gpresult /scope computer /r验证完成后，先移除链接，再删除测试 GPO。目标机上的标记可通过临时清理命令删除。回滚也应记录在变更单中。Remove-GPLink -Name 'PT-GPO-Write-Validation-20250308' `
-Target 'OU=Lab-Workstations,DC=corp,DC=example'
Remove-GPO -Name 'PT-GPO-Write-Validation-20250308'

# LAB-PC01 清理标记
reg delete HKLM\\Software\\AuthorizedPentest /v GPOWriteValidation /f异常排查如果权限显示可编辑但测试机未收到策略，按以下顺序排查，避免反复改策略扩大影响。运行 gpresult /h，确认 GPO 是被拒绝、被 WMI Filter 排除，还是根本不在作用域内。检查 Microsoft-Windows-GroupPolicy/Operational 日志，关注策略发现、下载和处理失败。确认测试机可解析域名，并能访问域控的 LDAP、Kerberos、SMB；SYSVOL 和 NETLOGON 应可正常读取。比较 GPC 与 GPT 版本。Get-GPO 输出中的 UserVersion、ComputerVersion 应与 SYSVOL 内 GPT.INI 的版本变化一致。检查 AD 与 SYSVOL 复制状态，避免将复制延迟误判为权限利用失败。# 客户端策略日志
Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' -MaxEvents 100 |
Select-Object TimeCreated, Id, LevelDisplayName, Message

# 域控复制健康度，需相应授权
repadmin /replsummary
repadmin /showrepl

# 查看 GPT 版本文件
type \\corp.example\SYSVOL\corp.example\Policies\{GPO-GUID}\GPT.INI日志留痕与取证要点域控侧应启用 Directory Service Changes，并为 CN=Policies,CN=System 配置合适的 SACL。事件 5136 可记录目录对象属性变化，5137 和 5141 分别对应对象创建与删除。仅开启高级审核策略但不配置 SACL，通常看不到足够细的对象变更。SYSVOL 变更还需结合文件系统审核、SMB 共享访问日志和 EDR 文件事件。重点关注 Policies\\{GUID} 下 Registry.pol、GPT.INI、Machine\\Scripts、ScheduledTasks.xml、Groups.xml 等文件的新增或修改。客户端侧可将组策略 Operational 日志与注册表、服务、计划任务变更时间对齐。# 查看高级审核策略
auditpol /get /subcategory:'Directory Service Changes'
auditpol /get /subcategory:'File System'
auditpol /get /subcategory:'File Share'

# 查询近 24 小时目录服务对象变更
$start = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{
LogName='Security'; Id=5136,5137,5141; StartTime=$start
} | Select-Object TimeCreated, Id, Message检测时不要只按管理员账号过滤。被委派的普通域组、自动化服务账号以及从管理平台发起的变更更值得关注。建议把操作者 SID、目标 GPO GUID、修改属性、来源主机和工单号关联起来。风险判断风险高低取决于 GPO 实际覆盖对象，而不是 GPO 名称。一个名为 Test Policy 的对象如果链接到域根并作用于 Domain Controllers，风险仍然是最高级别。可按以下因素综合评级：可写主体是否为低权限用户、人数较多的支持组或可被间接控制的嵌套组。GPO 是否覆盖服务器、运维终端、域控或身份管理系统。是否允许修改 DACL，从而隐藏地授予其他主体持续控制权。是否缺少目录服务与 SYSVOL 文件审计，导致篡改难以及时发现。是否存在跨 OU 链接、强制继承或过宽的 Authenticated Users 应用权限。修复建议按职责拆分 GPO 编辑权与链接权。常规运维人员不应同时拥有创建、编辑、删除和修改安全权限。移除非必要的 GpoEditDeleteModifySecurity、GenericAll、WriteDacl 和 SYSVOL Modify 权限；不要只改一侧 ACL。对高价值 OU 使用独立 GPO，避免工作站策略与服务器、域控共用同一对象。安全筛选优先使用专用计算机组，定期核查嵌套成员；保留读取策略所需权限，避免粗暴删除 Authenticated Users 后造成策略读取异常。通过 AGPM、变更工单或代码化备份建立审批、差异比较和回滚机制。持续监控 5136、5137、5141 以及 SYSVOL 关键文件变化，对非常规来源主机和非变更窗口操作告警。修复后重新导出 Get-GPPermission、GPC ACL、GPT ACL 和 OU 继承关系，与修复前基线做差异核对。总结GPO 权限问题的验证重点不是证明“能执行危险动作”，而是把权限主体、双对象 ACL、链接范围、客户端生效结果和审计证据串成完整链路。授权测试中使用隔离 OU、GPO 副本和无害注册表标记，既能确认真实影响，也能控制生产风险。修复时必须同时处理 AD 对象权限、SYSVOL 文件权限和 OU 链接关系，并通过日志与基线复核确认边界已经收紧。

这类验证建议把 GPO 拆成两个权限面看：AD 中的 Group Policy Container（GPC）和 SYSVOL 中的 Group Policy Template（GPT）。只检查 GPMC 里的“委派”不够，常见问题是两边 ACL 不一致，或者某个业务组通过嵌套组继承了 WriteDacl、WriteOwner、GenericAll。

先记录目标 GPO 的 GUID、版本号和链接范围，再分别取证：

Get-GPO -All | Select DisplayName,Id,GpoStatus
Get-GPInheritance -Target "OU=Workstations,DC=corp,DC=local"
Get-GPOReport -Guid "{GPO-GUID}" -ReportType Xml -Path .\gpo-before.xml

$gpc = "AD:\CN={GPO-GUID},CN=Policies,CN=System,DC=corp,DC=local"
(Get-Acl $gpc).Access |
  Select IdentityReference,ActiveDirectoryRights,AccessControlType,IsInherited

$gpt = "\\corp.local\SYSVOL\corp.local\Policies\{GPO-GUID}"
(Get-Acl $gpt).Access |
  Select IdentityReference,FileSystemRights,AccessControlType,IsInherited

重点核对三处：GPC 的 nTSecurityDescriptor、GPT 目录 ACL，以及 GPO 链接对象上的 gPLink/gPOptions。拥有 OU 写权限的人即使不能修改 GPO 本体，也可能新增链接、调整顺序或启用强制继承，所以不能只盯着策略文件。

留痕方面，域控开启“目录服务更改”高级审核后，可关注安全日志 5136、5137、5141，并按目标 GPO GUID 过滤；SYSVOL 侧关注 4663，但前提是给对应 Policies 目录配置了 SACL。客户端 事件查看器中的 Microsoft-Windows-GroupPolicy/Operational 可用于确认策略何时被拉取和应用。版本号也值得比对：GPC 的 versionNumber 应与 GPT 的 GPT.INI 对得上，异常不一致可能是复制延迟，也可能是只改动了一侧。

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5136,5137,5141} |
  Where-Object { $_.Message -match '\{GPO-GUID\}' } |
  Select TimeCreated,Id,MachineName,Message

Get-ADObject "CN={GPO-GUID},CN=Policies,CN=System,DC=corp,DC=local" `
  -Properties versionNumber,whenChanged,uSNChanged

Get-Content "\\corp.local\SYSVOL\corp.local\Policies\{GPO-GUID}\GPT.INI"

还应排除 AD/SYSVOL 复制问题，特别是多域控环境。可用 repadmin /showrepl、repadmin /replsummary 和 DFS Replication 日志确认时间线，避免把尚未收敛的版本误判为篡改。

加固时建议给 GPO 管理建立专用组，编辑、链接和审批分离；移除普通运维组的写 ACL，只保留读取与“应用组策略”；高权限 GPO 单独管理，不与通用桌面策略共用委派。修复前先导出 ACL 和 GPO 备份，不建议直接重置整个 Policies 目录继承，否则容易破坏默认权限。最后用低权限测试账号分别验证：能否编辑 GPO、能否改 OU 链接、能否直接写 SYSVOL，并保存前后 ACL、事件日志和版本号，证据链会比单纯跑一次权限扫描可靠。