企业官网建设流程全解析

“域内权限维持”这个话题，做内网方向的朋友应该都不陌生。而DCSync几乎是这条链路上绕不开的一环——它不往目标机器上落地任何文件，不需要在域控上开一个交互式会话，也不会去碰 LSASS 进程，只是安安静静地“要一份数据”，域控就老老实实把凭据交了出来。我第一次在授权环境里接触它的时候，最大的感受不是“好用”，而是“太安静了”，安静到很多防守方事后复盘时根本意识不到有人来过。这篇文章我想把 DCSync 在域内权限维持场景下的原理、落地思路、检测与对抗掰开揉碎讲一遍，重点不是教你“打”，而是让你在防守时知道该看哪里，在授权测试时知道该记什么、留什么证据。内容适合有过 AD 基础、做过内网横向、或者负责域环境安全加固的同行参考，纯小白顺着原理部分也能理解个大概——毕竟这个东西的底层逻辑，其实跟“两个仓库管理员互相调货”差不多。

1. DCSync 的技术底子：它到底在“同步”什么

1.1 多主复制模型是这一切的前提

要理解 DCSync，得先理解 Active Directory 为什么需要复制。AD 是一个多主（multi-master）的目录数据库，一个域里通常有多台域控，任何一台都可以接受写操作，写完之后再通过复制把变更传播给其他域控。为了让这个过程高效且可追溯，每一台域控都会为目录里的每个对象维护一组 USN（Update Sequence Number），并且通过 KCC（Knowledge Consistency Checker）自动计算复制拓扑，站点内默认 15 秒触发一次通知式复制，站点间按链路开销和计划表走。

关键在于，这套复制机制并没有规定“只有域控才能发起复制请求”。协议层面，它信任的是调用方是否持有正确的权限，而不是“调用方是不是一台域控”。这就留下了一个非常微妙的口子：只要某个安全主体在域命名上下文上被授予了“复制目录更改”相关的扩展权限，它就可以像一台域控一样，向真正的域控发起复制请求，然后拿到包括密码哈希在内的敏感属性。

生活化的类比是这样的：两家仓库之间有固定的调货流程，管理员 A 只要出示一张合规的调货单，管理员 B 就会把货交出来。B 不会去核实 A 到底是不是仓库管理员，他只看单子对不对。DCSync 做的，就是伪造一张“合规的调货单”。

1.2 DRSBind 与 DRSGetNCChanges 两个调用构成了核心链路

从协议层面看，DCSync 走的是 Microsoft Directory Replication Service（DRS）Remote Protocol，核心是两个 RPC 调用。

第一个是DRSBind，作用类似于“报到”。调用方向域控的\pipe\lsarpc或 DRSUAPI 接口发起绑定，把自己伪装成一个复制伙伴。这一步本身不涉及敏感数据，只是建立一个上下文。

第二个是DRSGetNCChanges，这才是真正“提货”的动作。调用方需要指定命名上下文（NC，比如DC=example,DC=local这个域分区），并且可以指定想要拉取的属性集。如果请求里带了DRS_EXTENDED_OP之类的标志，还可以要求返回更完整的数据。域控收到请求后，会做一次权限检查：调用方是否具备该分区上的复制权限？有，就把数据打包返回。

返回的数据包里，包含的是目录对象的完整属性，这里面就有unicodePwd、dBCSPwd、supplementalCredentials这类敏感字段。对于用户对象而言，unicodePwd本身就是 NT 哈希的存储形式，supplementalCredentials里则可能包含 Kerberos 的 AES 密钥。换句话说，一次成功的复制请求，等于把域内所有账户的凭据材料打包带走。

提示：很多人以为 DCSync 只能拿 krbtgt，其实它的能力范围是整个分区的所有对象属性，包括计算机账户、服务账户、msDS-KeyCredentialLink 等。理解这一点，对后续设计检测规则很重要。

1.3 三个权限位决定了“能不能提货”

域控在做权限检查的时候，看的不是组 membership，而是对象 ACL 上有没有对应的控制访问项（ACE）。具体涉及三个扩展权限，它们的 GUID 是公开且固定的：

实际利用中，前两个是必须的，第三个是加分项。这三个权限默认只授予Domain Controllers、Enterprise Domain Controllers以及少数几个系统内置主体。也就是说，只要能给任意一个普通账户加上前两个 ACE，这个账户就具备了 DCSync 的能力。

这里有个容易被忽略的细节：ACE 是加在域根对象（DC=example,DC=local）上的，而这个 ACE 会继承到整个分区下的所有对象。所以不需要在每个 OU 上重复授予，一次授予，全域生效。这也是为什么权限维持场景下，攻击方特别喜欢这条路径——一次操作，长期有效，而且默认不会触发任何安全告警。

1.4 为什么它比常规凭据抓取更适合“维持”

对比一下常见的凭据获取手段，DCSync 的隐蔽性优势非常明显：

• 不落地文件：不需要往目标机器上传 mimikatz 之类的工具，全部操作通过 RPC 完成。
• 不触碰 LSASS：绕开了绝大多数基于 LSASS 访问的 EDR 检测点。
• 不需要交互式登录：只要能发起到域控 135/445/49152+ 端口的 RPC 连接，就可以执行。
• 可以跨网段：从一台普通工作站发起，只要网络可达即可。
• 日志稀疏：默认审计策略下，成功路径几乎不留痕迹，只有开启“目录服务访问”审核之后，才会在 4662 事件里留下记录。

这几点叠加起来，就解释了为什么 DCSync 在权限维持环节如此受欢迎——它不像黄金票据那样需要拿到 krbtgt 之后还要考虑票据生命周期，也不像影子凭据那样需要改目标对象的属性（会触发 5136 事件）。它更像是一种“订阅”关系：只要权限还在，随时可以再来取一次。

2. 权限维持视角下的落地思路

2.1 一次性窃取和长期维持是两套逻辑

很多人把 DCSync 当成“一次性拿哈希”的工具，用完就走。但在权限维持的语境下，思路要转过来：真正的价值不在于这一次拿到了什么，而在于下一次还能不能拿到。

一次性窃取的典型路径是：拿到某个具备复制权限的账户 → 执行一次复制 → 拿到域管哈希 → 横向 → 结束。这条路径的问题在于，一旦域管密码被重置，或者 krbtgt 被重置两次，之前拿到的材料就全部作废，需要重新找入口。

长期维持的思路则完全不同：目标不是“拿到哈希”，而是“建立一个可重复调用的通道”。具体表现为，在域内留一个低关注度的安全主体（比如一个看起来像服务账户的用户，或者一个嵌套很深的组），给它赋予复制权限，然后让这个主体处于休眠状态。需要的时候激活它，执行复制，再休眠。这种模式下，即使防守方做了一次全面排查，只要没有专门审计 ACL，这个通道依然存在。

2.2 权限授予的几条路径与痕迹对比

在实际授权测试中，给主体授予复制权限的路径不止一条，留下的痕迹也不一样。我整理了一个对比表：

第三条路径值得多说两句。AdminSDHolder 是 AD 里一个特殊容器，系统有个后台线程（SDProp）默认每 60 分钟运行一次，把 AdminSDHolder 上的 ACL 强制覆盖到所有受保护对象（域管、企业管理员等）上。如果在 AdminSDHolder 上加一条 ACE，那么所有特权账户都会被“传染”上这条权限。这个手法的隐蔽性在于，它不需要直接改特权账户本身，但缺点是传播有固定周期，时序上很容易被关联分析抓出来。

第四条路径，也就是直接改nTSecurityDescriptor，是最不推荐的做法。这个属性一旦写错，很容易破坏 ACL 继承，导致域内权限混乱，严重的甚至需要从备份恢复。在授权测试里这么做，属于给自己挖坑。

注意：无论走哪条路径，在授权环境中都必须提前记录变更前的 ACL 快照。没有快照，事后清理就是一场灾难。这一点我在实际项目里吃过亏，后面会详细说。

2.3 维持链路的稳定性要提前设计

一个能长期存活的 DCSync 通道，需要考虑几个稳定性因素，这些因素在设计阶段就得想清楚，不能等通道断了再补。

第一是账户的生命周期。如果用的是新建账户，要考虑密码策略（默认域策略可能是 42 天过期）、账户锁定策略、以及是否会被资产管理系统标记为“僵尸账户”。比较稳妥的做法是挂靠在一个已有的、看起来合理的服务账户上，或者干脆利用机器账户——机器账户的密码是系统自动轮换的，不需要人工维护，反而更稳定。

第二是域控的可用性。域内通常有多台域控，如果只盯着其中一台，那台宕机或者被打补丁，通道就断了。实际做法是把所有域控的 IP 都列出来，做失败重试，只要能连上一台就能提货。

第三是权限的持久性。如果给某个账户授予了复制权限，而这个账户后来被加入了某个组，组的嵌套可能导致权限被间接放大或覆盖。另外，如果防守方做了 ACL 清理（比如用脚本批量移除可疑 ACE），通道就会断。所以好的设计会准备两条独立通道，一条在主路径上，另一条藏在不易被清理的位置。

第四是时间同步。DRS 协议对时间偏差有一定容忍度，但 Kerberos 认证本身要求客户端与域控的时间偏差在 5 分钟以内。如果发起复制的主机时间漂移过大，会在认证阶段就失败，表现为“绑定失败”而不是“权限不足”，排查时容易误判。

2.4 授权测试中的记录义务

这一节是写给做授权项目的同行的。DCSync 这类操作，在授权测试里有明确的记录要求：变更前 ACL 快照、变更的具体 ACE（谁、什么权限、加在哪个对象上）、变更时间、执行人、以及清理计划和清理验证结果。

我见过不止一个项目，测试结束后只写了一句“已清理”，结果防守方复测时发现 ACE 还在，直接导致验收不通过。原因很简单：ACL 的继承机制会导致“删了父对象上的 ACE，子对象上的显式 ACE 还在”，如果当初是在子对象上加的，清理时就必须回到子对象去删。

提示：清理之后一定要做一次回归验证，用同一个账户再发起一次复制请求，确认返回的是“访问被拒绝”，而不是“成功”。只删不验，等于没删。

3. 授权环境中的复现步骤与关键参数

3.1 前置条件核对清单

在动手之前，先把下面这张表过一遍，任何一项不满足，后续操作都会卡住。

这里重点说一下第五项。授予复制权限本身是一个 ACL 写操作，需要调用方对目标对象的nTSecurityDescriptor具备写权限。如果手上只有普通域用户凭据，是没法直接加 ACE 的。实际路径通常是通过某种方式先拿到 WriteDACL 能力，比如利用某些组的内置权限，或者通过已有的高权限会话。

3.2 权限授予的操作要点

授予操作的本质是往域根对象的 DACL 里追加一条ExtendedRight类型的 ACE，ObjectType指向前面表格里那两个 GUID，AccessControlType为Allow，IdentityReference指向目标主体。

操作上有几个细节必须注意：

第一，ACE 要加在域根上，不要加在 OU 上。加在 OU 上只对那个 OU 生效，覆盖面太窄，而且 OU 数量多，容易被逐层排查发现。加在域根上，继承机制会自动覆盖全域。

第二，继承标志要设对。一般设置为“应用到本对象及所有子对象”，也就是ContainerInherit | ObjectInherit。如果只设了ThisObject，那这个 ACE 只对域根自身有效，复制请求会被拒绝。

第三，主体选择要慎重。直接用域管账户加权限，等于把“这里有鬼”写在脸上。实际更常见的是选一个看起来人畜无害的主体，比如某个业务系统使用的服务账户，或者一个从名字上看像是备份用途的账户。

第四，操作完成后立刻验证。验证方式不是看 ACL 里有没有这条记录，而是实际发起一次复制请求，看能不能拿到数据。ACL 记录正确但复制失败的情况很常见，原因可能是继承没生效（需要等待或强制刷新）、或者主体被其他 Deny ACE 覆盖。

3.3 触发复制与验证

复制请求的触发，协议层面是构造DRSGetNCChanges调用，指定目标 NC 和需要的属性集。在实际操作中，通常会封装成工具来做，但核心参数就那么几个：

• 目标 NC：一般是域分区本身，格式为DC=example,DC=local。
• 对象 DN：可以指定只复制某个特定对象，比如只拉取krbtgt或者某个域管账户，减少数据量和日志噪音。
• 属性范围：可以选择全属性，也可以只拉取敏感属性。只拉敏感属性的话，日志里的数据包大小会小很多，但痕迹反而更可疑，因为正常复制不会只拉这几个属性。
• 复制标志：DRS_EXTENDED_OP这类标志会影响返回数据的完整性，一般保持默认即可。

验证成功的标志，是返回的数据结构里包含目标对象的凭据材料，而不是仅仅“调用没报错”。有些工具在权限不足时会静默返回空结果，看起来像是成功了，实际上是失败的。

注意：验证阶段不要用域管账户去测，否则一旦被审计到，等于把“域管账户发起了异常复制请求”这条高价值告警直接送到防守方手里。用那个专门为维持准备的低关注账户去测。

3.4 参数量级与性能考量

完整复制一个中等规模域（几万个对象）的数据量大概在几百 MB 到 1 GB 之间，这个量级在带宽充足的情况下几分钟就能拉完。但在权限维持场景下，根本不需要全量复制。

实际做法是精确指定目标对象，比如只拉krbtgt和两三个域管账户，数据量可以压缩到几十 KB。这样做的另一个好处是日志体积小，不容易在流量分析里触发告警。

对象 DN 的构造需要注意转义。如果对象名里包含逗号、加号、反斜杠这类特殊字符，必须按 RFC 4514 的规则转义，否则 DN 解析会失败，表现为“对象不存在”，而不是“权限不足”，很容易误导排查方向。

还有一个容易踩的坑是域控选择。如果域内有只读域控（RODC），复制请求打到 RODC 上会失败，因为 RODC 本身不具备完整的复制能力。所以脚本里要显式跳过 RODC，或者干脆只连可写域控。

4. 检测与排查：DCSync 留下的蛛丝马迹

4.1 审计策略必须先打开

这是所有检测工作的前提。默认状态下，Windows 的安全日志不会记录目录服务的访问，也就是说 DCSync 成功了也不会留下 4662 事件。很多环境之所以对这类行为“零感知”，根本原因是审计策略从来没配过。

需要开启的高级审计策略包括：

• 审计目录服务访问（Audit Directory Service Access）：对应 4662 事件，记录对象访问。
• 审计目录服务更改（Audit Directory Service Changes）：对应 5136 事件，记录对象属性修改。
• 审计账户管理：对应 4720/4728/4732 等，记录账户和组变更。
• 审计登录事件：对应 4624/4625，用于关联源主机。

开启方式可以通过组策略统一推送，路径在“计算机配置 → Windows 设置 → 安全设置 → 高级审核策略配置 → 对象访问”下。不要只开基础审核策略，基础策略在域控上的记录粒度不够，很多对象的访问根本不会记录。

开启之后，日志量会显著上升，尤其是 4662 事件，在大型域里每天可能产生几十万条。这时候就必须靠过滤规则来降噪，否则日志系统会被淹没。

4.2 4662 事件的正确读法

4662 事件的关键字段是Properties，它记录了本次访问涉及的对象属性 GUID 和扩展权限 GUID。要检测 DCSync，就是在这个字段里匹配前面提到的两个复制权限 GUID。

一个典型的可疑 4662 事件长这样：

事件 ID: 4662 主体: EXAMPLE\svc_backup 对象: DC=example,DC=local 属性: {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}

关键判断点有三个：

第一，主体是不是域控账户。正常的复制请求，主体应该是EXAMPLE$这类机器账户，或者Domain Controllers组。如果主体是一个普通的用户账户或服务账户，基本可以判定为异常。

第二，源主机是不是域控。事件里的Account Domain和Logon ID可以关联出源 IP。如果源 IP 是一台普通工作站或者服务器，同样高度可疑。

第三，属性组合是否符合正常复制模式。正常复制会请求大量的属性变更，而 DCSync 往往只请求少数几个敏感属性，这个特征可以作为辅助判断。

写一个简单的筛选逻辑，思路是这样的：

# 审计用途：从安全日志中筛出可能涉及复制权限的 4662 事件 $events = Get-WinEvent -FilterHashtable @{ LogName = 'Security' Id = 4662 StartTime = (Get-Date).AddHours(-24) } -ErrorAction SilentlyContinue $events | Where-Object { $_.Message -match '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' -or $_.Message -match '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' -or $_.Message -match '89e95b76-444d-4c62-991a-0facbeda640c' } | Select-Object TimeCreated, @{n='Detail';e={$_.Message}} | Export-Csv -Path .\dcsync_suspect.csv -NoTypeInformation -Encoding UTF8

这段代码只是把可疑事件捞出来，真正的判断还得靠人工看主体和源主机。机器判断很容易误报，因为某些备份软件也会调用类似的接口。

4.3 ACL 基线审计比日志更可靠

日志是“事后”的，ACL 是“事中”的。如果能在 ACL 层面定期比对基线，很多维持通道在建立阶段就会被发现，而不是等到复制发生。

审计的核心是找出所有非默认主体在域根上持有的复制权限。下面这段脚本可以直接用：

# 审计用途：列出域根上被授予复制权限的非默认主体 $root = "DC=example,DC=local" $replGuids = @( "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2", "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2", "89e95b76-444d-4c62-991a-0facbeda640c" ) $acl = Get-Acl -Path "AD:$root" $acl.Access | Where-Object { $_.ObjectType -and ($replGuids -contains $_.ObjectType.Guid.ToString()) } | Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType, ObjectType, InheritanceFlags, PropagationFlags | Format-Table -AutoSize

跑出来的结果里，如果出现了非Domain Controllers、非Enterprise Domain Controllers的主体，就需要逐个确认来源。建议把这份输出做成周度基线，每周跑一次，与上周结果做 diff，任何新增条目都要有人认领。

这个方法的优点是成本低、误报少，缺点是只能发现 ACL 层面的变更，对于“借用已有复制权限账户”的情况无能为力。所以它必须和日志检测配合使用。

4.4 排查速查表

真到了排查阶段，思路要按“从外到内”的顺序走，避免一上来就扎进日志里出不来。

这张表的价值在于给出一个明确的执行顺序。实际响应中最怕的就是“大家一起上”，结果 ACL 也改了、密码也重置了，最后连原始现场都没保住。先取证、再处置，这个顺序不能乱。

注意：如果确认存在未授权的复制行为，重置 krbtgt 密码需要连续执行两次，且两次之间要间隔大于域内最大票据生存期（默认 10 小时），再留出安全余量。只重置一次是没有意义的，旧票据依然有效。

5. 防御加固与对抗思路

5.1 权限最小化是根本

DCSync 能成立的前提，是有主体持有多余的复制权限。所以最根本的防御手段，就是把这份权限收归到最小范围。

具体做法包括：定期审计域根 ACL，确认复制权限只授予Domain Controllers和Enterprise Domain Controllers；对所有被授予复制权限的非默认主体，要求业务方书面说明用途，无说明的一律移除；把 ACL 审计纳入变更管理流程，任何 ACL 修改都要走审批。

这里有个现实问题：很多环境里，某些备份软件、监控系统确实需要复制权限。这种情况下不能一刀切删掉，而是要把这类账户纳入高价值目标管理——限制它的登录来源（只能从指定主机登录）、限制登录时段、启用更严格的监控。权限本身不可怕，可怕的是权限落在一个谁都能用的账户上。

5.2 凭据轮换策略要跟上

即使权限被收紧了，也不能假设之前的通道已经彻底断掉。攻击方可能已经通过 DCSync 拿到了哈希，这时候唯一的补救手段就是轮换。

轮换的优先级是：krbtgt → 域管账户 → 具备复制权限的服务账户 → 其他特权账户。krbtgt 必须重置两次，这是硬性要求。域管账户重置一次即可，但如果怀疑哈希已经被用于 Pass-the-Hash，还需要考虑清除相关会话。

轮换的时机也有讲究。不建议在业务高峰期做，因为 krbtgt 重置会导致所有 Kerberos 票据失效，用户需要重新认证，表现为短暂的登录异常。比较稳妥的窗口是业务低峰期，并且提前通知相关方。

5.3 蜜罐账户与诱饵权限

这是一个成本低、效果好的补充手段。思路是：创建一个看起来很有价值、但实际上无人使用的账户（比如名字叫svc_sql_backup、admin_backup这类），给它授予复制权限，然后对这个账户的任何复制行为设告警。

正常业务绝不会用这个账户发起复制，所以任何一次触发都是高置信度的告警。这个手法的关键在于诱饵要做得像真的——账户要有正常的描述、要有登录历史（可以用脚本模拟）、要放在合理的位置。如果诱饵账户一看就是新建的空壳，稍微有点经验的攻击方都不会碰。

同样的思路可以扩展到组：创建一个名字诱人的组，加入一些无关紧要的成员，然后监控对这个组的任何查询和修改。这类“主动防御”手段的价值不在于阻止，而在于把发现时间从“事后数月”提前到“事中数分钟”。

5.4 实操中容易踩的几个坑

第一个坑是只监控 4662 不监控 5136。4662 记录的是“访问”，5136 记录的是“修改”。如果攻击方还处在“加权限”的阶段，只有 5136 会记录。等 4662 出现的时候，权限已经加完了。两个事件必须一起看。

第二个坑是审计策略开了但没配 SACL。目录服务访问审核依赖对象上的系统访问控制列表（SACL）。如果只在组策略里开了审核，但域根对象上没有对应的 SACL 条目，4662 依然不会产生。这个配置需要在 ADSI Edit 里手动加，很多环境漏了这一步。

第三个坑是误把备份流量当成 DCSync。某些备份产品会调用类似的接口读取目录数据，特征是主体固定、源主机固定、时间规律。排查时先把这类流量加白名单，否则告警会被淹没。

第四个坑是ACL 清理不彻底。前面提过，继承机制会导致子对象上有显式 ACE 残留。清理时必须同时检查域根和各个 OU，确认没有遗漏。

5.5 我个人的几点体会

做了这么久的内网方向，我越来越觉得 DCSync 这类技术的防御难点不在技术本身，而在** visibility**。协议是微软公开的，权限是标准 ACL 机制，日志也是系统自带的，所有材料都摆在那里，问题只是有没有人去看。

我见过配置得非常好的环境，域根 ACL 每周自动比对，任何新增条目都会触发工单，4662 事件接入 SIEM 做实时关联，蜜罐账户一触发就打电话。也见过配置得很差的环境，域管账户密码三年没换，ACL 从来没人看过，出了事只能全量重置。两者的差距，不在工具，在有没有人真正把“权限基线”当回事。

最后分享一个小技巧：如果你手头没有 SIEM，又想低成本地做监控，可以用计划任务每天凌晨跑一次 ACL 导出，把结果存成带日期的 CSV，然后用一个简单的 diff 脚本比对前后两天的差异，有变化就发邮件。这套东西加起来不到一百行代码，但能覆盖住绝大部分 ACL 层面的维持手法。我在几个资源有限的环境里部署过，实测下来很稳，误报也少。

至于更深的对抗，比如针对msDS-KeyCredentialLink这类新型持久化手法的检测，那是另一个话题了，后面有机会再单独聊。