企业官网建设流程全解析

刚结束某家企业的授权评估任务，我按惯例在内网做了一轮信息收集，结论相当“干净”：系统补丁齐全，域管账号没有暴露，也没发现明显的弱口令。就在我准备收尾时，顺手查了一遍委派配置，结果看到一台业务服务器开着非约束委派，而且这台服务器上恰好有一个低权限服务账号已经被前期测试控制住。接下来的两个小时内，域管权限就这样被一张“委派牌”打穿了。

这不是个例。接触过不少内网评估项目后，我越来越确信，域委派攻击是域渗透里出现频率极高的横向移动手法，但很多企业在配置活动目录时，对它几乎没有概念。域委派的本意是让服务程序代替用户完成跨系统访问，一旦配置错误，它就会变成一个“身份代理漏洞”，攻击者只需要拿到一个普通账号，就可能冒充高权限账号访问核心服务。这篇文章我会把域委派攻击的前因后果、攻击原理、检测手法和加固方案完整梳理一遍，适合红队、蓝队以及负责AD域运维的朋友参考。

1. 域委派到底是什么，攻击者为什么盯上它

1.1 委派机制的业务价值

要理解域委派攻击，先得理解域委派本身。在域环境里，经常会出现一个很常见的业务场景：用户在前端网页发起查询，网页应用运行在一个服务账号下，它需要再去后端数据库或文件服务器取一次数据。传统的NTLM认证不支持这种“转跳”，用户也不可能每跳一次就输一次密码，Kerberos就给出了一个方案——委派。前端服务可以以自己的身份作为桥梁，代表用户去访问后端，整个过程对用户是透明的。

听起来很方便，对吧？问题在于，委派这个动作本质上是在“转交身份”。它把用户的认证身份缓存到中间服务的进程里，中间服务一旦被攻破，转交身份的能力就落到了攻击者手里。所以域委派不是漏洞，而是一把双刃剑。业务上它解决了单点登录和跨服务调用的问题，安全上它又等于给了服务账号一把“万能钥匙”，能开几扇门，完全取决于配置的人怎么设置。

我见过不少企业，应用跑不起来就顺手在域控上给服务账号勾上“信任此计算机委派任何服务”，完全没想过这台应用服务器事后可能被攻击者控制。等域管权限被拿走了，回头查日志才发现源头就是这么个不起眼的配置。这就是为什么红队爱打它、蓝队怕它。

1.2 三种委派模型

活动目录里的委派模型不是只有一种，搞混的话后面很多判断都会出问题。我习惯把它分成三类来记：

简单类比一下Kerberos里的两个核心票证：TGT相当于你进办公大楼刷过卡之后领到的一张“全楼临时通行证”，服务票据则像某间办公室的门禁卡。非约束委派相当于你把那张“全楼临时通行证”直接交给了前台保管，任何进过前台的人都可能偷偷复印一张；约束委派则是只给了一张特定房间的门禁卡，但依然存在“代刷”的可能；RBCD更特殊，它相当于每个房间自己决定“谁可以代别人刷卡进门”，而有些房间的管理员权限是落在普通员工手里的。

1.3 攻击视角下的委派价值

回到攻击者的视角。域渗透的核心目标是域控权限或者核心业务数据，但现在的域控越来越难打：补丁更新快、账号防护越来越严、历史漏洞基本都被堵死了。可委派配置呢？很多时候是几年前的架构遗留，上线之后基本没人维护。一旦攻击者拿到一个有委派权限的服务账号，就相当于拿到了“代刷身份”的能力，而且不需要碰域管密码。

更重要的一点是，域委派攻击往往需要多个条件叠加才能生效。它的隐蔽性恰恰来自于这种复杂性。企业安全体系如果只盯着补丁漏洞、弱口令，很少会主动去检查“哪些普通用户可以往高价值服务器上写ACL”。攻击者却会主动去翻这些配置，因为找到一条可利用路径的收益常常是直接获得域管等效权限。所以在我做的每一个评估里，域委派检查都是必选项，而不是可选项。

2. 域委派攻击的常见攻击面与原理拆解

2.1 非约束委派的弱点

非约束委派的风险逻辑非常简单：域内用户在访问配置了非约束委派的服务时，会把TGT一并提交给该服务，服务会将TGT缓存在进程内存中。攻击者控制了这台主机的服务进程，就可以把内存里缓存的TGT导出来带离线使用，完全不需要知道密码。

这里有个新手容易忽略的点：非约束委派的危险并不只在于“服务账号被入侵”，域管账号只要访问过那台服务器，TGT同样可能被缓存。很多企业舍不得清理非约束委派，理由是“这台服务器内网访问受限”“防火墙隔离了”，可内网一旦从一个低权限点被突破，这台服务器就是横向移动的最佳跳板。进一步地，攻击者还会主动诱导高权限主机来访问自己。业内把这类技术叫做“打印机回调”，本质是利用Windows打印服务的一个远程调用接口，让域控等目标主机主动向攻击机发起认证。这样攻击机即使没有任何用户凭据，也能拿到目标机器账号的TGT，再通过机器账号去访问受限资源。

对非约束委派的评估，不能只看“有没有配置”，还要看“有哪些账号会访问到这台机器”。一个域管每天登录的管理终端如果恰好开了非约束委派，那个管理终端基本就是域内的一个火药桶。

2.2 约束委派与协议转换

约束委派比非约束委派收敛得多，它只允许服务代表用户访问指定的SPN。很多运维觉得，既然目标SPN已经固定了，风险就可控了。但实际攻击场景里，约束委派仍有利用空间，关键在S4U2Self和S4U2Proxy这两个Kerberos扩展。

S4U2Self允许服务代表任意用户向自己申请一份票据，即使该用户并没有真正访问过它。也就是说，服务可以先用S4U2Self“伪造”一份以自己为服务名的用户票据，再通过S4U2Proxy把这份票据转发给约束列表里允许的目标SPN。如果约束委派的目标是域控上的CIFS或LDAP这类高权限服务，一个低权限服务账号就能代表任意域用户（包括域管）访问目标。

拿一个实际场景来说：某企业给一台备份服务器的服务账号配置了约束委派，目标SPN指向文件服务器。攻击者拿下了这个备份服务账号的哈希，不等任何域管登录备份系统，直接就用S4U2Self+S4U2Proxy模拟域管身份向文件服务器申请票据，随后顺利读取了文件服务器上的敏感共享。整个过程中域管账号的密码完全没被破解，而且操作都符合Kerberos协议的标准流程，常规WAF和IDS根本拦不住。

约束委派还有一个容易出问题的地方是“协议转换”。约束委派里如果勾选了“使用任何身份验证协议”，攻击者还能从NTLM或者非Kerberos认证场景转换成Kerberos票据，进一步扩大攻击面。

2.3 基于资源的约束委派为什么最难防

基于资源的约束委派（RBCD）是这三种模型里最后出现的，也是近两年域渗透中被利用频率最高的一种。它的设计初衷是把委派配置的控制权下放给资源对象自己，由目标服务器决定“允许谁来代表用户访问我”。好处是方便了业务部门自助式管理，坏处是“写权限”成了决定因素。

如果攻击者对一个计算机账号或者服务账号拥有GenericAll、GenericWrite这类ACL权限，就可以在自己控制的账号上，向目标对象的msDS-AllowedToActOnBehalfOfOtherIdentity属性写入委派信任关系。一旦写入成功，攻击者就能利用S4U2Self和S4U2Proxy完成票据申请，最终拿到目标机器服务的访问权限。

RBCD难防，是因为攻击者的操作完全符合AD的“合法配置”语义。它不会触发暴力破解告警，不会产生异常的网络扫描流量，只是在目标对象上新增了一条委派信任关系。更麻烦的是，普通域用户对计算机账号拥有写权限的情况在很多企业并不少见，可能是历史遗留的委派管理需要，也可能是某个应用安装时顺手把权限放宽了。这种问题只看配置本身根本察觉不到异常，必须结合权限归属关系做审计。

2.4 触发攻击的几个关键条件

梳理一下，域委派攻击要真正打通，通常需要三个条件叠加：

第一，攻击者能控制一个账号或者一台主机，这个控制点可以是一个弱密码服务账号、一个通过漏洞打下来的机器，甚至是一个被接管的前几个员工账号。

第二，该账号或关联对象具备可被利用的委派相关属性，包括非约束委派、约束委派、RBCD写权限等。

第三，目标服务的SPN具备足够高的权限，域控、备份服务器、密码管理平台这类高价值目标才算值得打，如果目标SPN只是一个普通业务服务，链路跑通也拿不到太多东西。

这三个条件不同时存在的时候，企业看似安全，但任何一个环节变化都可能被攻击者组合利用。例如，一个普通账号不具备委派属性，但它对某台服务器有写权限；攻击者同时控制了另一个注册了SPN的账号，一条RBCD链路就可以成立。这就是为什么委派评估不能只看单点配置，要看整条攻击链。

3. 实战视角：从发现到验证的完整思路

3.1 信息收集阶段该看什么

进入内网之后，我不会无脑地把所有AD数据拉下来再慢慢翻，而是带着明确目标去查：第一，域内有哪些账号和计算机设置了委派相关属性；第二，这些委派属性关联的SPN是否落在高价值主机上；第三，哪些普通域用户对这些高价值主机或服务账号有写权限。这三轮查询做完，基本就能画出一张风险地图。

这里也要提醒一下，查询AD属性本身属于常规信息收集操作，但放在真实的渗透测试或者红队评估里，一切查询都必须在甲方明确授权的范围内进行。没有授权的“信息收集”不是渗透测试，是违法行为，这一点没什么可商量的。

3.2 快速定位委派配置

下面这套查询命令既适合红队做信息收集，也适合蓝队做风险自查。我直接用PowerShell写出来：

# 查询所有启用非约束委派的用户 Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation, ServicePrincipalName # 查询所有启用非约束委派的计算机 Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation # 查询所有配置了约束委派目标的对象 Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo, ServicePrincipalName # 查询所有配置了RBCD信任关系的计算机 Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity | Where-Object {$_.msDS-AllowedToActOnBehalfOfOtherIdentity.Count -gt 0}

看到输出后，先别急着高兴，要结合SPN来判断价值。同一个非约束委派配置，落在域控和落在普通文件服务器上的影响完全不同。我在评估里会把这些对象按照“主机角色 + 委派类型 + 涉及账号权限”三个维度打分，优先验证高危组合，再往中低危扩散。

3.3 验证攻击路径的实验思路

以RBCD为例，验证一条攻击链路的思路大概是这样：先确认攻击者控制账号A，再确认A对目标计算机B有写权限。随后在攻击者控制的另一个账号C上注册一个与B相同SPN的服务名，这是为了满足Kerberos S4U2Proxy在处理转发票据时对目标SPN的匹配要求。接着在B的msDS-AllowedToActOnBehalfOfOtherIdentity属性中写入与A/C相关的委派信任关系，然后通过Kerberos扩展申请目标服务票据。最后检查这张票据能不能访问B上的指定服务。

这里我没有展开特定利用工具的详细参数，原因是这类验证必须在受控实验环境中由专业人员进行，不同AD环境的复制延迟、SPN注册方式、账号控制标志都存在差异，直接复制生产路径很容易引发事故。但思路本身的价值很大，你只要理解了S4U2Self和S4U2Proxy的先后关系，再看任何工具的报错和输出，基本都能判断问题出在哪个环节。

3.4 攻击成功的标志与影响

在授权评估里，判断攻击链是否走通，就看能不能用获得的票据访问目标服务。光拿到一张高权限票据但访问不了目标，只能算半成功，说明中间还隔着一层ACL或防火墙限制。真正走通后，我会从三个方面评估影响范围：

服务运行身份决定的是“服务本身的权限级别”，主机角色决定“这台机器在域内的地位”，SPN类型决定“能访问到什么服务”。举个例子，如果拿到的是域控的LDAP服务票据，攻击者就可以像域管一样通过LDAP查询和修改域内对象；如果是CIFS，则可能直接读取域控共享文件；如果是HTTP，影响范围就取决于对应Web服务。综合这三个方向，才能判断这个委派链路是否达到了“域控等效权限”的级别。

4. 防守方的检测与加固清单

4.1 通过事件日志发现异常

域委派攻击最终会在域控上留下Kerberos票据请求记录，关键事件ID是防守方必须背下来的。我常用的监控事件如下：

对配置了非约束委派的主机，重点监控LSASS进程访问行为；对被委派的高价值服务，重点监控4769事件中出现大量“服务代表用户访问目标”的场景。如果发现某一个低权限账号在短时间内不停请求高价值SPN的服务票据，这往往是委派攻击正在进行中。

还要注意，RBCD攻击后往往会出现票据加密类型不一致的现象。比如域环境已经开启AES支持，但异常请求却使用了RC4加密，这种组合异常值得进一步深挖。

4.2 高危配置的排查与收敛

配置排查不要只做一次，要形成周期性制度。我给蓝队的安全清单一般包括这几项：

非约束委派账号和计算机原则上应清零，如果业务确实需要，必须走特批流程并用约束委派替代。域控、备份服务器、密码管理平台等高价值主机一律禁止开启非约束委派。约束委派的目标SPN必须严格限定在业务必需的范围内，杜绝“为了方便”把目标宽泛写成多个高权限SPN。定期审计普通用户对计算机账号和服务账号的ACL权限，重点看GenericAll和GenericWrite这一类高危写权限。对委派属性变更启用告警，一旦发现新增了非预期属性，立刻进入应急流程。

我特别建议把委派检查纳入每季度安全巡检，而不是等出了问题再查。很多企业的AD域已经存在好多年，早期架构里埋下的委派风险可能比任何一个新漏洞都可怕。

4.3 关键账号与服务的加固措施

账号层面的加固，我的核心建议是优先使用组托管服务账号。组托管服务账号的密码由系统自动管理、定期轮换，而且普通运维人员根本接触不到密码明文，能极大降低服务账号密钥被窃取的风险。同时，域策略里尽量开启Kerberos AES支持，关闭或降级RC4加密。攻击者在不需要密码的情况下申请票据时，RC4加密类型更容易被碰撞和离线破解，AES则让这条路难走很多。

主机层面的加固同样关键。启用Credential Guard或者类似的内核级凭证保护，可以有效降低LSASS进程内存被导出后解析出TGT和哈希的风险。域管账号一定要严格限制登录来源，域管尽量只用专门的管理跳板机，不要在日常业务服务器上登录。我在评估中经常发现，域管习惯性地在文件服务器上共享文件、跑个脚本，结果这台服务器被攻破后，TGT连同域管账号的哈希一起被带走。

4.4 纵深防御建议

域委派攻击本质上是信任关系的滥用，单点加固解决不了问题，因为攻击者可以从任意一个低权限系统发起。我建议蓝队建立一张“高价值对象清单”，把域控、核心业务服务器、委派账号、服务账号全部纳入监控范围。一旦这些对象出现ACL变更、委派属性新增、非预期登录关系，立刻触发告警。

同时，网络分段也要跟上。内网不是铁板一块，不同安全域之间的访问关系应该做白名单收敛，避免一个低安全区的服务器可以直接访问核心业务区。定期的红队验证性评估也很有价值，让外部视角来检验现有防护是不是真的有效，比团队内部自查更容易发现盲区。

5. 常见问题速查与经验记录

5.1 委派攻击常见问题速查表

我把被问到比较多的几个问题整理成了表格，方便平时查阅：

5.2 踩坑记录：验证环境中容易忽略的细节

我做实验环境验证的时候踩过不少坑，这里挑几个典型的说出来。

第一个坑是S4U2Self一直失败，排查了很久才发现是服务账号没注册正确的SPN。Kerberos在找服务凭据时完全依赖SPN定位，SPN不对，后续的票据申请自然跑不通。第二个坑是修改委派属性后不生效，通常会遇到的场景是活动目录复制延迟，AD域内控制器之间的同步没完成，改动没有立刻覆盖到所有域控。解决办法是等待复制周期，或者在测试环境中手动触发复制。第三个坑最容易混淆：约束委派看msDS-AllowedToDelegateTo，RBCD看msDS-AllowedToActOnBehalfOfOtherIdentity，两个属性名非常接近，但语义完全不同。我见过有人把RBCD的属性值写到约束委派的属性里，结果链路验证跑了一天都没通。

5.3 红蓝双方各自该注意什么

最后聊一点经验层面的建议。

红队角度，合法授权是一切操作的底线，评估过程中要控制影响范围，不要在生产域上直接做破坏性验证。委派攻击在域控上留下大量Kerberos日志，每一步都要记录好时间点，方便后续复盘和交代清晰。还有一点容易被忽略：委派链路验证看似拿到高权限票据，但很多环境的ACL比想象中复杂，不要因为“理论可行”就直接写进报告，要实际访问成功后才算数。

蓝队角度，最重要的是建立委派配置基线并持续监控变化。不要等到事件发生后才开始翻日志，那是被动挨打。把委派相关属性、ACL变更都纳入安全运营流程，再配合事件ID的告警，域委派攻击就会变得有迹可循。

我自己在实际项目里的体会是：域委派攻击这条技术线，真正吃透之后会让你对整个AD域的信任模型肃然起敬。它不依赖系统漏洞，而是依赖配置信任关系，企业哪怕打过所有补丁、过了所有合规检查，一个错误的委派配置都可能让前面所有的努力白费。所以我在每次评估里，都会把委派检查放进基础清单，也希望所有负责AD域安全的人，用同一份清单做一次彻底自查。保护AD域的核心，从来不是堆砌安全产品，而是管住每一个身份之间的信任关系。