渗透攻防实战：Windows 域内 DCSync 权限边界验证、日志留痕与修复

背景

在授权内网渗透中，域控本身没有可直接利用的漏洞，并不代表域凭据安全。实际项目里更常见的问题是：普通服务账号、历史运维组或已退出使用的同步账号，在域根对象上残留了目录复制权限。攻击者一旦控制这类主体，就可能通过 DCSync 路径请求密码数据，而不需要交互式登录域控。

本文只验证权限边界与审计链路，不执行口令哈希导出。测试前应明确授权域、测试账号、时间窗口，并确保域控审计日志已集中留存。

问题定位

DCSync 风险主要对应以下扩展权限：

• Replicating Directory Changes，GUID 为 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2。
• Replicating Directory Changes All，GUID 为 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2。
• Replicating Directory Changes In Filtered Set，GUID 为 89e95b76-444d-4c62-991a-0facbeda640c。
• GenericAll、WriteDACL、WriteOwner 等控制权限也需要关注，因为它们可能被用于间接写入上述 ACE。

不要只检查 Domain Admins。服务账号、嵌套组、外部信任主体以及 SIDHistory 都可能形成隐蔽路径。判断时应同时考虑显式 ACE、继承关系和组成员展开结果。

操作步骤一：读取域根对象 ACL

以下命令应在加入目标域的管理工作站上，以具备目录读取权限的测试账号执行。它只读取 ACL，不修改域对象。

Import-Module ActiveDirectory

$domain = Get-ADDomain
$rootDN = $domain.DistinguishedName
$acl = Get-Acl ("AD:\\" + $rootDN)

$replicationGuids = @(
  [Guid]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
  [Guid]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",
  [Guid]"89e95b76-444d-4c62-991a-0facbeda640c"
)

$acl.Access |
  Where-Object {
    $_.AccessControlType -eq "Allow" -and
    ($replicationGuids -contains $_.ObjectType -or
     $_.ActiveDirectoryRights.ToString() -match "GenericAll|WriteDacl|WriteOwner")
  } |
  Select-Object IdentityReference, ActiveDirectoryRights,
                ObjectType, IsInherited, InheritanceType |
  Sort-Object IdentityReference |
  Format-Table -AutoSize

输出中如果出现非预期的普通用户、服务账号或业务组，应继续解析其 SID 与嵌套组关系。仅看到账号名称还不够，因为同名迁移对象和 SIDHistory 可能导致误判。

操作步骤二：解析主体与嵌套成员

$suspect = "CORP\\svc_sync"

# 获取主体 SID
(New-Object System.Security.Principal.NTAccount($suspect)).Translate(
  [System.Security.Principal.SecurityIdentifier]
).Value

# 如果主体是组，递归展开成员
Get-ADGroupMember -Identity "Directory-Sync-Operators" -Recursive |
  Select-Object Name, SamAccountName, ObjectClass, SID

# 检查账号是否存在 SIDHistory
Get-ADUser -Identity "svc_sync" -Properties memberOf, SIDHistory,
  PasswordLastSet, LastLogonDate, Enabled |
  Select-Object SamAccountName, Enabled, PasswordLastSet,
                LastLogonDate, memberOf, SIDHistory

重点核对账号是否仍有业务用途、是否由托管服务使用、密码是否长期未轮换，以及权限是否通过组间接获得。对 gMSA 不应仅依据最近交互登录时间判断是否闲置，应结合服务配置与主机侧日志。

技术分析：判断是否形成完整风险路径

单独存在一条复制权限 ACE 不等于可以立即下结论。建议按以下链路验证：

• 主体可控性：测试团队是否已在授权范围内获得该账号，或能否通过既有权限重置其凭据。
• 权限有效性：ACE 是否为 Allow，是否作用于当前域根对象，是否被 Deny ACE 或权限范围限制。
• 网络可达性：账号所在主机到域控的目录服务相关端口是否可达。
• 审计可见性：目录服务访问审计是否开启，域根对象是否配置复制权限相关 SACL。
• 业务合理性：该权限是否属于身份同步、迁移或备份产品的明确需求。

报告中应区分“直接持有复制权限”和“可修改 ACL 后获得复制权限”。后者通常表现为 WriteDACL、WriteOwner 或 GenericAll，修复优先级同样较高，但证据链不同。

操作步骤三：检查域控审计配置

在域控上检查高级审核策略。重点关注目录服务访问，以及账号和组管理相关子类别。

auditpol /get /subcategory:"Directory Service Access"
auditpol /get /subcategory:"Directory Service Changes"
auditpol /get /subcategory:"Security Group Management"
auditpol /get /subcategory:"User Account Management"

# 查询最近 24 小时的目录服务访问事件
$start = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{
  LogName   = "Security"
  Id        = 4662
  StartTime = $start
} | Select-Object TimeCreated, Id, MachineName, Message

事件 4662 只有在高级审核策略和对象 SACL 同时满足条件时才会产生。仅启用审核策略但未配置 SACL，是不少环境“看似开启审计、实际没有记录”的原因。

日志判定方法

分析 4662 时，建议提取 SubjectUserSid、SubjectUserName、ObjectName、ObjectType、AccessMask 和 Properties。Properties 中出现复制权限 GUID 时，应结合来源账号、时间窗口和业务系统变更记录判断。

如果 SIEM 支持字段化解析，可以用复制权限 GUID 作为筛选条件，但不要只匹配事件正文中的显示名称；不同语言版本系统可能显示不同文本，GUID 更稳定。

只读验证与证据保全

在生产域中不建议为了证明风险而实际请求密码材料。通常以下证据已经足以支撑结论：

• 域根 ACL 原始导出及采集时间。
• 主体 SID、组嵌套关系和 SIDHistory。
• 账号可控性的授权测试证据。
• 到域控的网络可达性记录。
• 审计策略、SACL 状态与相关 4662 日志。

可将 ACL 导出为 CLIXML，便于复核时保留对象类型和 GUID，避免复制表格造成字段丢失。

$domain = Get-ADDomain
$rootDN = $domain.DistinguishedName
Get-Acl ("AD:\\" + $rootDN) |
  Export-Clixml -Path ".\\domain-root-acl.xml"

Get-FileHash ".\\domain-root-acl.xml" -Algorithm SHA256

风险与修复建议

• 删除非必要的复制权限 ACE。修改前先备份 ACL，并确认权限是否由身份同步、迁移或备份产品使用。
• 不要直接在生产环境批量清理未知 ACE。先在变更窗口中验证依赖，否则可能导致目录同步中断。
• 将确需复制权限的账号隔离为专用主体，禁止交互式登录，限制可登录主机和网络来源。
• 服务场景优先使用 gMSA，并限制 PrincipalsAllowedToRetrieveManagedPassword。
• 清理不必要的 WriteDACL、WriteOwner 和 GenericAll，防止攻击者重新写回复制权限。
• 检查 AdminSDHolder、受保护组成员及历史委派，避免修复后因继承或自动任务重新出现 ACE。
• 为域根对象配置针对复制扩展权限的审计 SACL，并将 4662 日志转发到独立日志平台。
• 对复制权限变更建立基线。定期导出 ACL，将主体 SID、权限 GUID 和继承状态标准化后做差异比较。

修复后的复测

复测不应只确认目标 ACE 消失，还要检查间接路径是否仍然存在。至少重新执行域根 ACL 查询、组嵌套展开、SIDHistory 检查和审计事件验证。同时观察身份同步、备份与目录管理任务是否正常。

生产环境删除 ACE 前必须保留原始 ACL、明确回滚命令并经过变更审批。权限修复失败的影响可能不是单个账号不可用，而是目录同步或身份生命周期流程整体中断。

总结

DCSync 风险的核心不是某个工具，而是域根对象上的复制权限边界。授权渗透测试应把主体可控性、ACL 有效性、网络路径、审计留痕和业务依赖串成完整证据链。验证阶段优先采用只读方式，修复阶段则围绕最小权限、专用账号、来源限制、ACL 基线和 4662 审计展开，这比在生产域直接导出凭据更安全，也更容易形成可复核的整改结论。

这类验证建议把“能否复制目录”和“能否复制敏感属性”拆开测。DCSync 权限通常落在域根对象的 DACL 上，重点核对以下扩展权限 GUID：

• 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2：Replicating Directory Changes
• 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2：Replicating Directory Changes All
• 89e95b76-444d-4c62-991a-0facbeda640c：Replicating Directory Changes In Filtered Set

先从任意装有 AD PowerShell 模块的管理机导出域根 ACL，避免只看组成员关系而漏掉嵌套组、继承 ACE 或直接授权：

$dn = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$dn"

$guids = @(
  [guid]'1131f6aa-9c07-11d1-f79f-00c04fc2dcd2',
  [guid]'1131f6ad-9c07-11d1-f79f-00c04fc2dcd2',
  [guid]'89e95b76-444d-4c62-991a-0facbeda640c'
)

$acl.Access |
  Where-Object {
    $_.AccessControlType -eq 'Allow' -and
    ($_.ActiveDirectoryRights -band
      [System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight) -and
    $_.ObjectType -in $guids
  } |
  Select-Object IdentityReference, ObjectType, IsInherited,
                InheritanceType, ActiveDirectoryRights

也可以用 dsacls 保留原始证据，尤其适合修复前后做差异比较：

dsacls.exe "$(Get-ADDomain | Select-Object -ExpandProperty DistinguishedName)" > .\domain-root-acl-before.txt

日志侧不要只依赖默认审计。应在域控启用高级审计策略 DS Access / Audit Directory Service Access，并在域根对象配置针对上述扩展权限的成功审计 SACL。否则即便行为发生，安全日志里也未必有 4662。可先确认策略：

auditpol.exe /get /subcategory:"Directory Service Access"
auditpol.exe /get /subcategory:"Directory Service Changes"

验证时重点关联以下事件：

• 4662：对象操作；检查对象 DN、主体账号以及 Properties 中是否出现上述 GUID。单条 4662 不足以定性，要排除域控计算机账户和合法同步产品。
• 4624：登录来源；通过 Logon ID 与 4662 的 SubjectLogonId 关联，定位源地址和登录类型。
• 5136：目录对象被修改；用于追踪域根 nTSecurityDescriptor 的异常变更。
• 4732/4728/4756：高权限组成员变化；用于判断权限是否经嵌套组间接获得。

一个实用的告警条件是：4662 命中复制权限 GUID，且主体既不是域控机器账户（通常以 $ 结尾），也不在批准的目录同步账号清单内。不要简单按用户名包含 DC 放行，应基于域控资产清单和 SID 校验。

修复时优先删除最小范围的异常 ACE，而不是重置整个域根 ACL。先导出 ACL、解析账号 SID 和嵌套组来源，再用 ADUC 的“高级安全设置”或 dsacls /R 移除指定主体的显式授权。修改后重新导出 ACL，并确认三项复制权限均不存在；只移除 Changes All 而保留另外两项，通常仍然不算完成收敛。

另外要检查是否存在自动化脚本、GPO 启动脚本或身份同步平台周期性把 ACE 加回来。若修复后权限再次出现，应围绕 5136 的调用主体和时间点继续追，而不是反复手工删除。