渗透攻防实战：在不破坏业务的前提下验证 Active Directory 委派与 ACL 越权链路

背景在授权内网渗透中，域权限问题往往不是单个高危漏洞，而是由错误委派、嵌套组和对象 ACL 叠加形成的攻击链。典型场景是：普通域用户对某个业务组拥有写成员权限，该业务组又被授予服务器本地管理员权限，最终使低权限账号跨越主机权限边界。本文以只读发现、受控验证、日志核对和配置修复为主，不执行凭据导出、持久化或横向载荷投递。测试前应明确域、账号、时间窗口、允许验证的对象，以及禁止触碰的生产服务器。问题定位先从当前身份、域控制器和组关系入手，避免一开始就进行大范围扫描。以下命令可在域成员机上执行，使用的是 Windows 自带能力和 ActiveDirectory 模块。whoami /all
nltest /dsgetdc:corp.example
set LOGONSERVER

Import-Module ActiveDirectory
Get-ADDomain | Select-Object DNSRoot,DomainMode,PDCEmulator
Get-ADUser $env:USERNAME -Properties MemberOf |
Select-Object SamAccountName,MemberOf重点检查三类边界：普通用户能否修改组成员；业务组是否通过 GPO 或本地配置进入服务器管理员组；服务账号是否拥有不必要的目录对象控制权。测试账号应使用专门创建的低权限账号，不能用日常管理员账号代替，否则容易掩盖真实权限。技术分析Active Directory 的访问控制由对象安全描述符决定。对组对象而言，GenericAll、GenericWrite、WriteDacl、WriteOwner，以及针对 member 属性的 WriteProperty，都可能影响成员关系。风险不只来自直接 ACE，还可能来自组嵌套和继承。仅凭 ACL 中出现某个 SID 不能直接判定可利用。需要同时确认 ACE 类型为允许、权限未被拒绝 ACE 覆盖、主体确实属于该 SID 对应的用户或组、目标对象没有额外保护机制，并核对权限是否作用于目标属性。只读枚举与链路确认先解析目标业务组的 ACL。下面脚本只读取目录，不修改对象。将组名和域 DN 替换为授权范围内的值。Import-Module ActiveDirectory
$group = Get-ADGroup -Identity 'APP-SRV-OPS'
$acl = Get-Acl (\"AD:\\$($group.DistinguishedName)\")

$acl.Access |
Where-Object {
$_.ActiveDirectoryRights.ToString() -match
'GenericAll|GenericWrite|WriteDacl|WriteOwner|WriteProperty'
} |
Select-Object IdentityReference,AccessControlType,
ActiveDirectoryRights,ObjectType,IsInherited |
Format-Table -AutoSize随后展开嵌套成员，确认可疑主体是否能够从当前测试账号到达。递归查询可能在复杂域中产生较多 LDAP 请求，应限定到具体组，而不是遍历全域。Get-ADGroupMember -Identity 'APP-SRV-OPS' -Recursive |
Select-Object objectClass,SamAccountName,DistinguishedName

Get-ADPrincipalGroupMembership -Identity 'pt-lowuser' |
Select-Object Name,GroupScope,DistinguishedName如果怀疑该业务组通过组策略获得服务器本地管理员权限，应检查 GPO，而不是直接登录所有主机。可先生成组策略结果，再查看受控主机上的本地组实际状态。gpresult /scope computer /h C:\\Windows\\Temp\\gp.html
Get-GPResultantSetOfPolicy -Computer 'APP01' -ReportType Html \
-Path 'C:\\Windows\\Temp\\APP01-RSoP.html'

# 仅在已授权的目标主机执行只读核对
Invoke-Command -ComputerName APP01 -ScriptBlock {
Get-LocalGroupMember -Group 'Administrators'
}受控验证步骤生产环境不建议通过添加真实人员账号来证明权限。更稳妥的方式是由域管理员创建一次性验证组和一次性验证用户，将对象放在隔离 OU，并确保该组未关联任何主机或业务权限。测试人员仅验证自己能否修改这个无业务影响的对象。由管理员创建 LAB-ACL-PROBE 组和 pt-probe 用户，设置明确过期时间。将与生产问题相同的单条委派规则复制到实验组，不复制其他高权限关系。测试账号执行一次成员添加，再立即移除，记录 UTC 时间和工单号。管理员从域控制器安全日志核对事件，确认写操作对应的账号、对象和来源。删除实验对象，并检查复制完成后所有域控制器上均无残留。# 仅针对管理员准备的隔离验证对象
$probeGroup = 'LAB-ACL-PROBE'
$probeUser = 'pt-probe'

Add-ADGroupMember -Identity $probeGroup -Members $probeUser
Get-ADGroupMember -Identity $probeGroup |
Where-Object SamAccountName -eq $probeUser
Remove-ADGroupMember -Identity $probeGroup -Members $probeUser -Confirm:$false不要在 Domain Admins、服务器运维组、备份组或任何已映射到业务主机的组上做写入验证。对生产对象应以 ACL 证据、组关系和日志关联完成证明。日志留痕与证据关联域控制器应启用“审核目录服务更改”和“审核安全组管理”。与本场景直接相关的事件通常包括 4728、4729、4732、4733、4756、4757；启用目录服务更改审核并配置相应 SACL 后，还可结合 5136 查看对象属性变化。不同组作用域对应的事件编号不同，不能只检索一个编号。$start = (Get-Date).AddHours(-2)
$ids = 4728,4729,4732,4733,4756,4757,5136

Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = $ids
StartTime = $start
} | Select-Object TimeCreated,Id,MachineName,Message |
Export-Csv C:\\Windows\\Temp\\ad-acl-review.csv \
-NoTypeInformation -Encoding UTF8证据中至少保留测试主体 SID、目标对象 DN、变更前后成员列表、命中的 ACE、域控制器名称、事件记录 ID 和统一时区时间。不要只保存截图；文本或 CSV 更利于复核，也便于与 SIEM 数据关联。常见误判把读取 member 属性误认为具有修改 member 属性的权限。忽略 Deny ACE、继承范围或 ObjectType，看到 WriteProperty 就直接定为高危。只分析直接组成员，未展开嵌套组，导致链路遗漏。使用高权限测试账号执行枚举，使查询成功被错误归因于低权限主体。发现业务组名称包含 admin 就判断具备主机管理权，却未核对 GPO 和主机本地组。风险评估风险应按链路可达性评估，而不是按单条 ACE 定级。如果低权限用户能直接修改已部署到服务器管理员组的域组，通常属于高风险权限边界突破；如果只能修改隔离组，且该组无嵌套、无 GPO 映射和无资源 ACL，则影响明显较低。还要考虑目标主机是否承载域管理会话、部署凭据或高价值业务。修复建议删除对业务组不必要的 GenericAll、GenericWrite、WriteDacl 和 WriteOwner 权限，将委派收敛到具体对象和具体属性。将“账号管理”“服务器运维”“GPO 管理”拆分为不同角色，避免同一帮助台组同时拥有多个控制面权限。清理历史嵌套组，禁止普通业务组间接进入本地 Administrators；优先使用受控的按需授权或短时效组成员资格。对高价值组设置成员变更告警，并核对 4728、4732、4756 与 5136 事件；告警字段应包含操作者、目标组、成员 SID 和来源主机。定期导出关键对象 ACL 建立基线，对新增 ACE、继承变化和所有者变化做差异审计。修复后使用原低权限账号重复只读检查，确认危险 ACE 已移除、嵌套链断开，并验证合法运维流程未受影响。总结AD 内网渗透中的权限边界验证，关键不是制造一次高权限登录，而是用最小影响的证据证明完整链路：当前主体拥有什么目录写权限、目标组如何映射到主机权限、变更由哪些日志记录，以及修复后链路是否真正断开。只读枚举、隔离对象验证和事件日志关联，通常足以形成可复现、可审计的渗透测试结论。

这类验证建议把“发现链路”和“触发链路”分开：先用只读 LDAP、事件日志和配置快照证明路径存在，不要直接申请服务票据、修改委派属性或写入目标对象。尤其避免在生产域执行 RBCD 写入、改组成员、重置密码、添加 SPN 这类会留下真实控制面的动作。

可以先采集三类对象，形成变更前基线：

# 仅查询，不修改目录
Import-Module ActiveDirectory

# 非约束/约束委派
Get-ADComputer -LDAPFilter '(|(userAccountControl:1.2.840.113556.1.4.803:=524288)(msDS-AllowedToDelegateTo=*))' \
  -Properties userAccountControl,msDS-AllowedToDelegateTo,servicePrincipalName |
  Select-Object Name,DistinguishedName,userAccountControl,msDS-AllowedToDelegateTo

# RBCD：哪些目标对象配置了可代表其行动的主体
Get-ADComputer -LDAPFilter '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)' \
  -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
  Select-Object Name,DistinguishedName,msDS-AllowedToActOnBehalfOfOtherIdentity

# 高价值对象 ACL，只看可能形成控制权的 ACE
$targets = 'OU=Servers,DC=corp,DC=example','CN=Domain Admins,CN=Users,DC=corp,DC=example'
foreach ($dn in $targets) {
  (Get-Acl "AD:$dn").Access | Where-Object {
    $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner|ExtendedRight'
  } | Select-Object @{n='Target';e={$dn}},IdentityReference,ActiveDirectoryRights,
      ObjectType,InheritedObjectType,IsInherited,AccessControlType
}

ACL 判断不能只看 GenericAll。实际排查中更容易漏掉的是对象级 WriteProperty、可重置密码的 ExtendedRight、对 OU 的继承 ACE，以及组嵌套后才生效的权限。建议把 SID 解析、组嵌套和 ACE 继承范围一起记录，否则容易误判链路。

如果要验证“当前账号是否确实具备写权限”，优先在隔离 OU 创建无业务依赖的测试对象，并由变更单明确限定对象 DN、属性和回滚时间。生产对象只做读取。测试时仅修改一个无安全语义的扩展属性，修改前后保存值并立即恢复；不要拿 msDS-AllowedToActOnBehalfOfOtherIdentity、servicePrincipalName 或组成员关系当探针。

# 示例：仅适用于事先批准的隔离测试对象
$dn = 'CN=acl-probe,OU=Security-Lab,DC=corp,DC=example'
$before = Get-ADObject $dn -Properties extensionAttribute15
Set-ADObject $dn -Replace @{extensionAttribute15='authorized-acl-probe'}
$after = Get-ADObject $dn -Properties extensionAttribute15

# 回滚原值
if ($null -eq $before.extensionAttribute15) {
  Set-ADObject $dn -Clear extensionAttribute15
} else {
  Set-ADObject $dn -Replace @{extensionAttribute15=$before.extensionAttribute15}
}

证据侧建议同步核对域控安全日志：目录对象变更关注 5136，组成员变更关注 4728/4732/4756，计算机账户创建关注 4741，Kerberos 服务票据关注 4769。5136 需要先启用“审核目录服务更改”，并给关键对象配置 SACL；否则没有日志不能说明没有写入。采集时保留调用账号、对象 DN、属性名、旧值/新值、域控和时间窗口，便于和变更单闭环。

最后按链路逐段下结论更稳妥：主体可控、ACE 可达、属性可写、委派条件满足、目标服务存在，这五段分别标记“配置证据/日志证据/实验室验证”。生产环境不触发最终认证动作，也能证明风险成立；修复后再重复同一组只读查询，确认危险 ACE、继承来源和委派属性均已消失。