AD 域应急-DCSync攻击狩猎

在 Active Directory 环境中，DCSync 是一种极具破坏性的凭据窃取技术。它不需要攻击者在域控上执行代码，也不需要物理接触服务器——只需一组足够高权限的域账号，就能把整个域的密码哈希”同步”走。在真实的红队行动与 APT 案例中，DCSync 几乎已经成为域内权限达顶之后的标准动作。

DCSync 攻击原理

DCSync 本质上是对 MS-DRSR（Directory Replication Service Remote Protocol） 的滥用。

在正常的 AD 架构中，当企业部署了多台域控制器时，域控之间需要定期同步目录数据，确保各 DC 上的信息保持一致。这个同步机制使用的正是 MS-DRSR 协议，其中的核心 RPC 调用是：

• IDL_DRSGetNCChanges — 请求从另一台 DC 复制目录变更

微软为了让这个机制正常工作，设计了相应的扩展权限。拥有以下权限的账号，都可以发起目录复制请求：

• Replicating Directory Changes（DS-Replication-Get-Changes）
• Replicating Directory Changes All（DS-Replication-Get-Changes-All）
• Replicating Directory Changes In Filtered Set（仅特定场景）

问题在于：这些权限的校验发生在协议层，而不在”你是不是真正的 DC”这一层。

也就是说，只要一个域账号被授予了上述权限，无论它是不是域控制器，都可以调用 IDL_DRSGetNCChanges，向真实的 DC 发出”复制请求”，拿到域内任意账号的密码哈希——包括 krbtgt 和所有域管理员。

攻击者正是利用这一机制，使用 mimikatz 等工具在普通成员机上模拟域控行为，直接拉取 NTDS 数据库内容，而全程不需要登录域控、不需要接触 NTDS.dit 文件。

攻击前置条件

DCSync 并非”无门槛”攻击。在发动 DCSync 之前，攻击者通常需要完成以下准备：

具备以下任一条件之一：

1. 获取了 Domain Admins、Enterprise Admins 或 Domain Controllers 组的成员账号
2. 通过 ACL 滥用、委派攻击等方式，将目标账号手动授予了复制权限
3. 控制了 Account Operators 等具备修改权限能力的账号，间接提权后授予复制权限

在实战中，DCSync 通常出现在以下攻击链的末尾：

初始访问 → 本地提权 → 横向移动 → 域管权限 → DCSync → 持久化 / 横向扩展

一旦攻击者到达 DCSync 阶段，往往意味着域内已经出现了较深度的失陷。

攻击执行过程

使用 mimikatz 执行 DCSync

最常见的攻击工具是 mimikatz，通过 lsadump::dcsync 模块直接发起复制请求：

# 转储指定用户（如 krbtgt）的哈希
lsadump::dcsync /domain:corp.local /user:krbtgt

# 转储所有域账号的哈希
lsadump::dcsync /domain:corp.local /all /csv

执行成功后，攻击者可以在终端中直接看到目标账号的：

• NTLM Hash（可用于 Pass-the-Hash）
• AES-128 / AES-256 Key（可用于 Pass-the-Key、制作 Golden Ticket）
• 历史密码哈希

使用 Impacket 远程执行

除 mimikatz 外，Impacket 工具包中的 secretsdump.py 同样支持 DCSync：

python3 secretsdump.py corp.local/domainadmin:'Password123'@192.168.1.10 -just-dc

这种方式完全在攻击者的 Linux 机器上执行，目标域内几乎不会留下进程痕迹，检测难度更高。

攻击效果

一旦拿到 krbtgt 的哈希，攻击者可以：

• 制作 Golden Ticket，在域内任意伪造身份（有效期可达数年）
• 对任何域用户执行 Pass-the-Hash 横向移动
• 在清除后门被发现、账号被重置后，借助 Golden Ticket 重新进入域环境

DCSync 的危险之处正在于此：它一旦成功，攻击者掌握的不只是当前的访问权限，而是整个域的永久钥匙。

从日志中如何发现 DCSync 攻击

DCSync 的隐蔽性来自于”合法协议的滥用”——真实的域控之间每天都在进行目录复制，攻击产生的流量看起来与正常复制行为无异。因此，检测的核心不是找异常协议，而是找异常的发起主机。

关键事件：Event ID 4662

在域控制器的 安全日志（Security Log） 中，当一个账号对 AD 目录对象执行了”需要扩展权限”的操作时，会生成 Event ID 4662（对象操作审计）。

DCSync 攻击会触发该事件，关键字段如下：

字段	正常值（DC 间复制）	异常值（DCSync 攻击）
Subject Account Name	域控计算机账号（如 DC01$）	普通用户账号或非 DC 账号
Object Type	domainDNS	domainDNS
Access Mask / Properties	包含复制相关 GUID	包含复制相关 GUID

重点检测的 Properties（属性 GUID） 包括：

1131f6aa-9c07-11d1-f79f-00c04fc2dcd2   # DS-Replication-Get-Changes
1131f6ad-9c07-11d1-f79f-00c04fc2dcd2   # DS-Replication-Get-Changes-All
89e95b76-444d-4c62-991a-0facbeda640c   # DS-Replication-Get-Changes-In-Filtered-Set

当上述任意 GUID 出现在 4662 日志的 Properties 字段中，且执行主体不是域控计算机账号时，就具备了极高的调查价值。

注意：4662 审计默认并不开启。需要在”高级审核策略”中启用 “审核目录服务访问（DS Access）” 才能看到该事件。

关键事件：Event ID 4624 / 4776（配合使用）

如果攻击者使用 Impacket 等工具远程执行 DCSync，往往会先使用域管账号从非 DC 的主机发起 网络登录（Logon Type 3）。

此时，域控上会出现：

• Event ID 4624：登录成功，Logon Type = 3，Source IP 为非域控机器
• Event ID 4776：NTLM 凭据验证（若使用 NTLM 方式登录）

结合来源 IP 进行排查，若登录源指向一台普通工作站，则需要进一步核查该账号后续的操作行为。

关键事件：Event ID 4673（特权服务调用）

在部分日志配置下，DCSync 行为还可能触发 Event ID 4673（调用特权服务），其中会包含操作名称和调用账号信息，可作为 4662 的辅助佐证。

DCSync 攻击排查思路总结

在真实应急场景中，可以按照以下步骤快速确认是否发生过 DCSync：

第一步：确认 4662 审计是否开启

在域控上检查”高级审核策略配置 → 目录服务访问”是否已启用审计。若未开启，历史日志将无法追溯，需要立即开启并转向其他线索。

第二步：筛选 4662 日志，定位复制权限操作

在域控的安全日志中，筛选 Event ID 4662，重点关注：

• Properties 字段中包含以上三个复制 GUID 之一
• Subject Account Name 不以 $ 结尾（即不是计算机账号）

满足以上两个条件的事件，即为高度可疑。

第三步：确认发起账号与来源主机

记录可疑 4662 事件的账号名，结合 4624 登录日志，追查：

• 该账号最近从哪些主机发起了网络登录？
• 登录时间是否与 4662 事件高度吻合？
• 源主机是否为已知域控制器？

若登录来源是一台普通工作站或服务器，则基本可以断定发生了 DCSync。

第四步：检查工具痕迹（进程与命令行）

如果环境中部署了 Sysmon，可以在进程创建日志（Event ID 1）中检索以下关键词：

mimikatz
lsadump
dcsync
secretsdump

即便攻击者对工具进行了重命名，命令行参数中的 lsadump::dcsync 或 /user:krbtgt 等特征依然难以完全掩盖。

第五步：评估已泄露哈希的影响范围

确认攻击发生后，需要立即评估攻击者可能获取的账号范围：

• 如果执行了 /all 或 /csv 参数，可认为全域哈希已泄露
• 如果仅针对特定账号（如 krbtgt），需要重点评估 Golden Ticket 风险
• 无论哪种情况，必须重置 krbtgt 密码两次（间隔 10 小时以上），并重置所有高权限账号密码

一个容易被忽视的检测盲区

很多组织在部署检测规则时，会重点监控域控本身——但 DCSync 的特殊性恰恰在于：攻击流量不是从域控”流出”，而是从攻击者主机”流入”域控。

这意味着：

• 如果只监控域控的出站流量，可能完全看不到 DCSync 行为
• 关键证据在域控的安全事件日志中，而不是网络流量中
• Impacket 的 secretsdump 还可能绕过部分基于进程检测的规则，因为攻击全程在攻击者机器上执行

因此，检测 DCSync 的核心能力要求是：域控安全日志的实时采集与集中分析，这是其他检测手段无法替代的。

缓解与防护建议

与 NTDS.dit 转储类似，DCSync 滥用的同样是一种”合法机制”，并不存在直接打补丁的解决方案。防护的重点在于权限管控与持续监控。

权限层面：

• 定期审计域内具备复制权限的账号，重点关注非 DC 账号是否被意外授权
• 收紧 Default Domain Policy 和 Domain NC 对象的 ACL，避免非必要账号持有复制相关扩展权限
• 落实最小权限原则，严格控制 Domain Admins 组的成员数量

监控层面：

• 开启域控”高级审核策略 → 目录服务访问”审计，确保 4662 日志可被采集
• 在 SIEM 中建立针对 4662 + 复制 GUID + 非 DC 账号 的组合告警规则
• 将该规则的告警级别设为最高优先级，一旦触发立即响应

事件响应层面：

• 一旦确认 DCSync 攻击，视同全域凭据泄露处理
• 重置 krbtgt 密码两次（这是使所有现存 Golden Ticket 失效的唯一方法）
• 对全域高权限账号强制密码重置
• 排查是否存在新创建的高权限账号或 ACL 变更（持久化迹象）
• 审计域控制器登录记录，溯源攻击者的初始进入路径

赞赏

微信赞赏支付宝赞赏