刚结束某家企业的授权评估任务我按惯例在内网做了一轮信息收集结论相当“干净”系统补丁齐全域管账号没有暴露也没发现明显的弱口令。就在我准备收尾时顺手查了一遍委派配置结果看到一台业务服务器开着非约束委派而且这台服务器上恰好有一个低权限服务账号已经被前期测试控制住。接下来的两个小时内域管权限就这样被一张“委派牌”打穿了。这不是个例。接触过不少内网评估项目后我越来越确信域委派攻击是域渗透里出现频率极高的横向移动手法但很多企业在配置活动目录时对它几乎没有概念。域委派的本意是让服务程序代替用户完成跨系统访问一旦配置错误它就会变成一个“身份代理漏洞”攻击者只需要拿到一个普通账号就可能冒充高权限账号访问核心服务。这篇文章我会把域委派攻击的前因后果、攻击原理、检测手法和加固方案完整梳理一遍适合红队、蓝队以及负责AD域运维的朋友参考。1. 域委派到底是什么攻击者为什么盯上它1.1 委派机制的业务价值要理解域委派攻击先得理解域委派本身。在域环境里经常会出现一个很常见的业务场景用户在前端网页发起查询网页应用运行在一个服务账号下它需要再去后端数据库或文件服务器取一次数据。传统的NTLM认证不支持这种“转跳”用户也不可能每跳一次就输一次密码Kerberos就给出了一个方案——委派。前端服务可以以自己的身份作为桥梁代表用户去访问后端整个过程对用户是透明的。听起来很方便对吧问题在于委派这个动作本质上是在“转交身份”。它把用户的认证身份缓存到中间服务的进程里中间服务一旦被攻破转交身份的能力就落到了攻击者手里。所以域委派不是漏洞而是一把双刃剑。业务上它解决了单点登录和跨服务调用的问题安全上它又等于给了服务账号一把“万能钥匙”能开几扇门完全取决于配置的人怎么设置。我见过不少企业应用跑不起来就顺手在域控上给服务账号勾上“信任此计算机委派任何服务”完全没想过这台应用服务器事后可能被攻击者控制。等域管权限被拿走了回头查日志才发现源头就是这么个不起眼的配置。这就是为什么红队爱打它、蓝队怕它。1.2 三种委派模型活动目录里的委派模型不是只有一种搞混的话后面很多判断都会出问题。我习惯把它分成三类来记委派类型核心特征安全风险非约束委派服务保存用户TGT可代表用户访问任意服务风险最高TGT被缓存后所有访问过该服务的账号都可能被冒充约束委派只能代表用户访问指定SPN的服务配合协议转换S4U2SelfS4U2Proxy仍有扩展攻击面基于资源的约束委派RBCD由资源目标对象自己指定信任来源攻击者通过ACL写权限可以自行添加委派关系很难从配置合法性上拦截简单类比一下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指向文件服务器。攻击者拿下了这个备份服务账号的哈希不等任何域管登录备份系统直接就用S4U2SelfS4U2Proxy模拟域管身份向文件服务器申请票据随后顺利读取了文件服务器上的敏感共享。整个过程中域管账号的密码完全没被破解而且操作都符合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是防守方必须背下来的。我常用的监控事件如下事件ID含义重点关注4768请求TGT非工作时间大量TGT请求、新账号尝试4769请求服务票据同一账号短时间内大量申请不同SPN4672分配特殊权限非预期的高权限登录5136AD对象被修改委派属性、ACL属性变化对配置了非约束委派的主机重点监控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 委派攻击常见问题速查表我把被问到比较多的几个问题整理成了表格方便平时查阅问题说明非约束委派和RBCD最大的区别是什么非约束委派是服务缓存用户TGTRBCD是目标对象指定信任账号并配合S4U2扩展完成访问RBCD攻击必须知道目标账号的密码吗不需要关键在于控制一个有SPN的账号并且对目标对象有写权限约束委派目标SPN如果是域控的CIFS影响有多大攻击者可以模拟任意用户访问域控文件共享影响接近域管权限清除委派配置后需要重启服务吗部分场景需要刷新Kerberos票据缓存建议安排变更窗口后再验证如何快速判断是否被RBCD攻击查看目标对象的msDS-AllowedToActOnBehalfOfOtherIdentity属性是否存在非预期值5.2 踩坑记录验证环境中容易忽略的细节我做实验环境验证的时候踩过不少坑这里挑几个典型的说出来。第一个坑是S4U2Self一直失败排查了很久才发现是服务账号没注册正确的SPN。Kerberos在找服务凭据时完全依赖SPN定位SPN不对后续的票据申请自然跑不通。第二个坑是修改委派属性后不生效通常会遇到的场景是活动目录复制延迟AD域内控制器之间的同步没完成改动没有立刻覆盖到所有域控。解决办法是等待复制周期或者在测试环境中手动触发复制。第三个坑最容易混淆约束委派看msDS-AllowedToDelegateToRBCD看msDS-AllowedToActOnBehalfOfOtherIdentity两个属性名非常接近但语义完全不同。我见过有人把RBCD的属性值写到约束委派的属性里结果链路验证跑了一天都没通。5.3 红蓝双方各自该注意什么最后聊一点经验层面的建议。红队角度合法授权是一切操作的底线评估过程中要控制影响范围不要在生产域上直接做破坏性验证。委派攻击在域控上留下大量Kerberos日志每一步都要记录好时间点方便后续复盘和交代清晰。还有一点容易被忽略委派链路验证看似拿到高权限票据但很多环境的ACL比想象中复杂不要因为“理论可行”就直接写进报告要实际访问成功后才算数。蓝队角度最重要的是建立委派配置基线并持续监控变化。不要等到事件发生后才开始翻日志那是被动挨打。把委派相关属性、ACL变更都纳入安全运营流程再配合事件ID的告警域委派攻击就会变得有迹可循。我自己在实际项目里的体会是域委派攻击这条技术线真正吃透之后会让你对整个AD域的信任模型肃然起敬。它不依赖系统漏洞而是依赖配置信任关系企业哪怕打过所有补丁、过了所有合规检查一个错误的委派配置都可能让前面所有的努力白费。所以我在每次评估里都会把委派检查放进基础清单也希望所有负责AD域安全的人用同一份清单做一次彻底自查。保护AD域的核心从来不是堆砌安全产品而是管住每一个身份之间的信任关系。