Kerberos委派攻击全解析：从非约束委派到RBCD与Spooler触发

一次授权内网测试里我在客户现场盯着一台普通文件服务器看了很久。目标域有三千多用户域控制器权限划分得比较谨慎常规漏洞没抓到什么机会。后面想起来翻了一下LDAP里的委派配置发现这台文件服务器竟然开了非约束委派顺手配了Print Spooler的强制回连半小时后域管账户的TGT就躺在了本机LSA缓存里。这篇内容不打算探讨“哪条命令能打穿域”而是把Kerberos认证、非约束委派、约束委派、RBCD基于资源的约束委派以及Spooler触发这几块拼图完整串起来讲清楚它们为什么会出问题、利用链怎么搭建、防守方又该盯哪几个位置。对红队来说这是路线图对蓝队来说这是一份检测清单。1. Kerberos认证的“地基”委派攻击绕不开的票据机制1.1 AS-REQ/AS-REPTGT是怎么签发的理解委派攻击必须先理解Kerberos认证里最基础的两个概念TGT和ST。TGT的全称是Ticket Granting Ticket可以把它理解成“身份证的身份证”。用户要访问某个服务不是直接拿账号密码去敲服务端的大门而是先向KDC也就是域控申请一张TGT。这个过程叫AS-REQ/AS-REP。用户提供的是自己的密码哈希派生出的长期密钥KDC验证通过后会生成一张TGT内容里包含用户SID、所属组SID等身份信息然后用krbtgt账户的哈希加密整张票据。客户端本地缓存TGT之后后续一段时间内都不用再向KDC证明“我是我”了。这里有个关键点TGT不是密文给用户存着那么简单KDC同时还会下发一个会话密钥用户和KDC之间后续通信用它来包裹内容。很多初学者容易忽略的细节是TGT的加密密钥是krbtgt的哈希所以只有KDC才能解密TGT。任何域用户都可以向KDC申请TGT但拿到TGT之后能不能解开里面内容完全取决于krbtgt是谁。这意味着TGT在域内是“黄金通行证”也解释了为什么拿到某个账户的TGT等于直接接管该账户在Kerberos体系下的全部身份。1.2 TGS-REQ/TGS-REP与AP-REQ服务票据的流转有了TGT之后用户访问某个具体服务时需要拿着TGT再次请求KDC这个过程叫TGS-REQ。KDC收到请求后会验证TGT是否有效然后生成一张STService Ticket服务票据用目标服务账户的哈希加密。用户拿到ST去找目标服务目标服务用自己的哈希解开ST验证用户身份然后决定是否放行。整条链路里ST的有效期通常只有几十分钟到几小时TGT在默认策略下是10小时。初次接触域渗透的人容易把TGT和ST搞混ST的目标是某个具体SPN比如cifs/DC01TGT则是和KDC对话的通行证可以在TGS-REQ阶段换出多个不同服务的ST。这个区别在委派攻击里极其关键因为非约束委派缓存的是TGT约束委派和RBCD操作的是ST。另外要提一下PACPrivilege Attribute Certificate特权属性证书。PAC是嵌在票据里的一个结构保存了用户的权限属性包括用户RID、组SID和域SID。KDC签发票据时会对PAC签名。服务端解密ST后默认只检查PAC是否有效但如果服务端配置了“强制验证PAC签名”之类的策略攻击者伪造PAC的难度会大幅上升。委派攻击里ST的PAC是由KDC签的而不是由委派服务签的所以即便委派服务被控它也无法自主篡改被模拟用户的PAC内容——这一点保证了S4U2Proxy拿到的ST具备合法的权限属性。1.3 委派的本质把用户身份“转交”给服务的机制委派机制被设计出来的初衷很朴素服务进程经常需要代表用户去访问后端资源。最典型的例子是Web应用用户在前端登录后Web服务需要以用户的身份去访问SQL Server或文件服务器不能要求用户反复输入密码。于是AD引入了三种委派模式非约束委派、约束委派、基于资源的约束委派。它们的共同点是一个主体通常是服务账户或机器账户被授予了“代表另一个用户去请求/使用服务”的权限。在Kerberos层面这种“代表”体现在票据的转发或模拟上。不分清这三者的区别后面看任何利用文章都会一头雾水。简单归纳非约束委派是服务能直接拿到用户的TGT并随意使用约束委派是服务只能对指定SPN列表发起代表请求RBCD则是让资源自己决定“我允许谁代表其他用户访问我”。三者权限从宽到窄但每个都有对应的绕过方式。这也是为什么委派安全在内网横向移动里始终是热点——它不是配置错了才存在的漏洞而是正常功能里天然包含的高风险面。2. 非约束委派域内最高调的“票据中转站”2.1 如何识别一台非约束委派机器非约束委派在AD里通过账户的userAccountControl属性标识机器账户或服务账户的UAC字段会设置TRUSTED_FOR_DELEGATION标志位对应十六进制是0x80000。很多红队工具都能直接查询PowerView或ADFind是最常用的。查询命令大致是这样# ADFind AdFind.exe -f ((objectCategorycomputer)(userAccountControl:1.2.840.113556.1.4.803:524288)) -dn # PowerView Get-DomainComputer -Unconstrained -Properties SamAccountName,userAccountControl这里524288就是0x80000的十进制表示AD查询里用了位匹配规则来筛选包含该标志的条目。在真实环境中这类机器往往是因为某些老业务需要“双跳”比如IIS后端的应用程序池账户需要代表用户访问数据库管理员在配置向导里勾选了“信任此计算机对任何服务使用委派”之后再也没有回过过头。防御方值得注意非约束委派不仅会作用在机器账户上服务账户同样可以。很多安全团队只扫描计算机对象漏掉了用户账户上配置的TRUSTED_FOR_DELEGATION标志这属于排查死角。我在项目中经常遇到的情况是一台MSSQL服务账户被配置成非约束委派而它所在的机器已经被攻陷很久了蓝队却一直没发现这个入口。2.2 拿到SYSTEM权限之后的票据收割攻击者如果已经拿到了非约束委派机器的SYSTEM权限接下来要做的就是从LSA缓存里提取TGT。核心原理是当某个用户访问这台机器上的服务时比如域管通过SMB登录过来、或者通过WinRM跑了一条命令被访问的服务进程在Kerberos认证过程中会把用户的TGT放在LSA凭据缓存里以便之后代表该用户去访问其他服务。提取TGT的常用工具是Mimikatz的sekurlsa::tickets模块能把内存里的Kerberos票据导出成.kirbi文件然后通过kerberos::ptt注入到当前会话。Rubeus的dump和ptt也同样是经典组合。这里踩过的坑是不是机器上缓存的所有票据都能直接使用要看票据的目标账户和当前环境是否匹配另外TGT默认10小时有效但域策略可能已经调整导出票据后尽快使用更稳妥。这里要澄清一个常见误解非约束委派机器的价值不只在“域管访问过”。域内任何域用户账户访问过该机器攻击者拿到该用户的TGT后都可以冒充该用户访问其有权访问的所有服务。很多时候测试者只盯着高权限账户忽略了业务账号但业务账号往往挂着DBA、虚拟机管理员等特殊权限组横向空间反而更大。2.3 让域管主动上门与Spooler触发的首次联动非约束委派利用的难点其实不在“抓票据”而在“让目标用户访问委派机”。域管不会无缘无故跑到一台文件服务器上敲命令。早期的思路是投放鱼叉链接、诱导管理员访问该机器上的Web服务或者等管理员日常运维时自动踩上去。这些方法都不够稳定所以后来的技术圈开始研究“强制认证”——让目标主机主动发起对攻击者主机的认证请求。Print Spooler就是其中最有名的触发通道之一。通过向目标机器的Spooler服务发送特定RPC请求可以让目标机器向任意指定的IP地址发起SMB连接这个连接会携带目标机器账户的凭据。如果攻击者控制的主机开启了非约束委派这次SMB连接发生的Kerberos认证过程中目标机器账户的TGT就会被缓存下来。机器账户TGT能做什么在域内机器账户默认只拥有对域内标准资源的访问权限但拿到DC机器账户的TGT后通常可以执行DCSync的变体攻击或者把机器账户加入特权组再或者利用机器账户的SPN配置进行后续横向。非约束委派加Spooler触发之所以被大量讨论是因为它们解决了一个关键问题不用等管理员犯错攻击者可以主动把域控的机器账户“拉”到自己面前。从检测角度来看这类攻击在日志上往往表现为域控产生一条指向攻击者IP的SMB出站连接很多企业SIEM对这类“域控主动回连”的行为没有告警规则这也是它能反复生效的原因。3. 约束委派把攻击路径锁进SPN列表之后3.1 从“任意服务”到“指定服务”的安全演进微软显然知道非约束委派太过危险所以在后续版本里推出了约束委派。约束委派的账户同样会设置UAC标志TRUSTED_TO_AUTH_FOR_DELEGATION十六进制0x1000000同时还需要在msDS-AllowedToDelegateTo属性里明确列出允许委派的目标SPN。这意味着即便一台机器配置了约束委派攻击者拿到它的控制权后也只能代表用户访问这份SPN列表里点名的那几个服务不能再对任意服务发起委派请求。从机制上看约束委派比非约束委派干净很多但它并没有杜绝滥用因为SPN列表里的“服务”不等于“权限最小化”。比如管理员为了让某个报表应用能访问域控上的文件共享配置了cifs/DC01这个SPN虽然只指向文件共享但一旦攻击者控制了报表应用机器他就能用cifs票据去访问域控的SMB服务而SMB服务承载了远程计划任务、共享管理、注册表远程管理等多个横向通道。还有一个容易被忽略的点约束委派的配置粒度在“服务”而不在“操作”。管理员通常只思考“要不要让A访问B”很少进一步考虑B服务上哪些操作是必须开放的。这就给了攻击者横向移动的窗口。3.2 S4U2Self与S4U2Proxy协议转换背后的隐患约束委派攻击利用的核心是Kerberos协议扩展里的两个服务S4U2Self和S4U2Proxy。S4U2Self的本意是解决“用户在认证时没有用Kerberos而是走了NTLM或表单登录”的场景。服务可以先代表该用户向KDC申请一张发送给自身的ST从而获得该用户身份。这个过程也被称为协议转换。如果服务启用了“使用任何身份验证协议”选项它可以用任意用户名去申请这张ST且这张ST通常带有FORWARDABLE标志也就是说它可以被再次转发。S4U2Proxy则是把S4U2Self得到的可转发票据再以用户身份向msDS-AllowedToDelegateTo里指定的目标SPN申请ST。两次请求配合起来相当于攻击者只要控制了一个开启了协议转换的约束委派账户并拥有该账户的密钥就能以任意域用户身份获取指定服务的ST。微软对这个机制的理解是“服务本来就能代表用户去访问它白名单里的服务”但危险在于白名单本身太宽。3.3 一条真实的约束委派攻击链解剖假设当前域内有一台机器APP01它的机器账户被配置了约束委派允许委派到cifs/DC01并且勾选了协议转换。攻击者已经拿到了APP01$的哈希或明文密码。利用过程可以简化为三步使用Rubeus以APP01$身份发起S4U2Self请求模拟域管理员administrator拿到一张发给APP01$的可转发ST。用这张ST发起S4U2Proxy请求目标SPN填cifs/DC01拿到一张administrator身份的CIFS服务票据。将票据注入当前会话然后通过SMB协议访问DC01。对应的命令大致如下Rubeus.exe s4u /user:APP01$ /rc4:APP01的NT哈希 /impersonateuser:administrator /msdsspn:cifs/DC01 /ptt拿到票据后可以用dir \\DC01\C$验证访问或者直接使用PsExec类工具在DC01上执行命令。技术点在于S4U2Self阶段使用的模拟用户不一定非得是域管只要该用户对目标服务有读取权限就可以。但做横向移动时测试者通常选域管来保证落地成功。而对于防御方需要关注的是一台应用服务器为什么具备向域控申请cifs服务票据的委派权限合规配置里这种情况几乎不会出现一旦出现就可以直接认定为异常。4. 基于资源的约束委派RBCD权限边界上的“合法暗门”4.1 资源侧说了算RBCD的机制差异RBCD是Windows Server 2012之后引入的委派模型思路和传统委派完全相反。传统委派是域管在“服务侧”配置“我能代表谁”比如域管在APP01上配置它可以委派到DC01而RBCD是“资源侧”自己决定“我允许哪个账户代表其他用户来访问我”。具体落地时目标对象的msDS-AllowedToActOnBehalfOfOtherIdentity属性会写一个安全描述符里面列出允许做RBCD的账户SID。这个设计的初衷是为了简化委派管理。以前配置约束委派必须依赖域管权限在大型组织里流程很重现在资源对象的所有者可以自己授权不需要反复申请域管介入。但这也带来了新的攻击面一旦攻击者拿到某台机器的写权限就能把自己控制的账户写入该机器的msDS-AllowedToActOnBehalfOfOtherIdentity属性之后以任意用户身份申请访问该机器的ST。在AD环境中对机器账户拥有GenericAll、GenericWrite、WriteDacl等写权限的主体在错误配置下可能是一个普通域用户也可能是一台已经失陷的机器。这就把“对某台机器有写权限”这个看似普通的能力直接升级成了“可以拿到该机器上任意服务访问权”的高危权限。4.2 从“拥有写权限”到“拿到服务票据”的完整链路RBCD攻击的完整链路非常清晰我复现过很多次条件满足的情况下成功率极高。前置条件有两个一是攻击者能控制一个具备SPN的域账户一般用自建的机器账户因为域内默认的MachineAccountQuota允许普通域用户最多创建10个机器账户二是攻击者对目标机器拥有写权限。具体步骤可以用Impacket全家桶来完成第一步创建机器账户impacket-addcomputer -computer-name EVIL$ -computer-pass Evil123 -dc-ip DC01 -target-domain corp.local第二步把EVIL$的SID写入目标机器TARGET$的msDS-AllowedToActOnBehalfOfOtherIdentity属性impacket-rbcd -delegate-to TARGET$ -delegate-from EVIL$ -dc-ip DC01 -action write第三步用EVIL$账户的密钥模拟域管理员向cifs/TARGET申请STimpacket-getST -spn cifs/TARGET -impersonate administrator -dc-ip DC01 corp.local/EVIL$:Evil123第四步把生成的票据路径设置给环境变量然后透过SMB执行命令export KRB5CCNAMEadministrator.ccache impacket-smbexec -no-pass -k corp.local/administratorTARGET这条链路里最关键的认知点在于S4U2Self和S4U2Proxy并不是约束委派的专利只要目标机器存在RBCD配置就被允许使用。EVIL$是刚创建的机器账户原本没有任何特殊权限但它已经被目标机器“信任”为可代表其他用户访问自己的主体于是就能通过S4U扩展拿到administrator的ST。整个过程不需要密码破解、不需要漏洞利用完全走的Kerberos正常功能。4.3 实战中RBCD利用最容易失败的几个环节我在这条链路上翻过车主要问题集中在三个地方第一目标机器账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性可能设置了强制访问控制列表导致写入失败。默认情况下机器账户的NTFS/AD ACL允许域计算机写自己的这个属性但经过加固的环境会把写权限限定到特定组攻击者拿不到写入机会。第二创建的机器账户必须能正常通过后续的Kerberos操作。如果域策略设置了“机器账户密码长度/复杂性”或“阻止创建大于X个字符的密码”addcomputer时会报错。另外在较新域环境中创建机器账户后通常需要一点时间让KDC缓存账户信息立刻使用偶尔会出现KDC_ERR_C_PRINCIPAL_UNKNOWN稍等几十秒重试即可。第三模拟的用户身份不一定是administrator。如果域管账户启用了“敏感账户不能被委派”之类的保护属性RBCD利用会直接失败因为KDC会拒绝为受保护账户签发可转发的ST。这种情况下可以改为模拟其他高权限业务账户或者直接模拟目标机器的本地管理员。5. Spooler触发技术强制认证是如何撬动横向的5.1 Print Spooler为何长期是内网横向的“杠杆”Print Spooler打印后台处理服务在Windows域环境里几乎是默认运行的服务很多企业根本没有关闭它。它对外暴露了一个RPC接口支持远程管理打印机队列等操作而且这个接口在设计时没有对调用者的权限做足够约束普通域用户也能调用。这个服务的价值在于通过精心构造的RPC调用可以让目标机器主动向攻击者指定的IP发起SMB/UNC路径连接。机器在发起连接时会带着自己的机器账户凭据完成认证认证方式可能是NTLM也可能在特定条件下是Kerberos。这种“强制回连”能力一旦和委派攻击结合就能让攻击者无需等待受害者主动访问主动权完全在自己手里。从安全测试视角看这类技术属于“MS-RPRN”接口滥用最常见的就是SpoolSample。即使微软修复了大名鼎鼎的PrintNightmareSpoolSample这种“强制打印机反连”的能力在很长时间内依然有效直到后续补丁对接口调用链做了层层封堵。即便如此内网环境中仍然存在大量未打补丁或接口行为默许的资产这也是Print Spooler相关利用在横向移动篇中地位居高不下的原因。5.2 从SpoolSample到PetitPotam强制认证触发器的发展SpoolSample最初是Lee Christensen公开的一个PoC利用原理是向远程主机的Spooler服务发送一个特定请求让它向攻击者控制的服务器发起SMB回连。这个请求并不需要管理员权限也不需要目标机器开启“文件和打印机共享”只要能访问到\\target\pipe\spoolss这个命名管道的账户即可。后来为了挖掘更多类似效果研究者陆续翻出了其他强制认证接口。PetitPotam利用了Windows的EFSEFSRPC即Encrypting File System Remote Protocol接口通过EfsRpcOpenFileRaw之类的调用让目标主机向指定UNC路径发起认证。DFSCoerce则基于DFSNM接口。这些技术内部的RPC细节不同但攻击者要的效果都是同一个让受害者的机器账户作为认证凭据送上门。在委派攻击背景下触发器的选择主要取决于目标环境的补丁状态。某些环境Spooler接口已经不可用但EFS接口还开着另一些环境则相反。内网测试中我一般会同时准备两个以上的触发工具挨个试。防御方做补丁梳理时也需要把这几条RPC链全查一遍不能只盯着PrintNightmare缓解措施。5.3 与委派体系组合的典型攻防全过程把委派和Spooler触发组合起来是域内横向里性价比很高的一条路线。比如前面提到的非约束委派机器A加上Spooler让域控DC回连A整个过程大致是这样的攻击者获取A的SYSTEM权限确认A开启了非约束委派。从A上向DC的Spooler服务发起强制回连请求指定回连地址为A的IP。DC的Spooler服务随即向A发起SMB认证A的LSA缓存中写入DC机器账户的TGT。攻击者在A上导出DC机器账户的TGT然后以DC机器账户身份访问域控或域内其他关键资源。利用机器账户的横向权限进一步回收域管账户或执行DCSync。这套链路里真正有价值的不光是域管TGT任何高权限机器账户的TGT都可能打开新大陆。防御方在日志里可以看到域控在某时刻对外发起了SMB连接如果这个出站连接的目标不是已知的备份服务器、集中日志服务器或域控本身就是一个非常值得关注的信号。6. 防守方视角委派滥用的检测逻辑与加固清单6.1 日志证据链事件ID与关键字段委派攻击并非无迹可循关键在于把域控安全日志、AD属性变更日志、NTLM认证日志串成一条证据链。以下这几个事件ID是我在防守方项目里最常盯的事件ID日志来源关键字段/行为告警场景4769域控安全日志服务票据请求含Account Name、Service Name、Ticket Encryption Type同一主机大量请求cifs/、ldap/等服务票据或用户账户请求与自身业务无关的服务票据4768域控安全日志TGT请求含源IP、票据生命周期源IP与账户常驻位置不符、TGT生命周期异常4741域控安全日志计算机账户创建非预期时机创建新机器账户尤其是普通用户权限下创建的机器账户5136AD目录服务变更日志目录对象属性修改如msDS-AllowedToActOnBehalfOfOtherIdentity非域管账户修改机器账户的RBCD属性4624域控或主机安全日志登录类型、源IP、认证协议域控等关键主机出现来源不明的IP登录或SMB回连只靠单一事件误报率不低所以更推荐做关联分析。比如4769中“账户名称”是某个新创建机器账户的$结尾对象同时它的Service Name指向一台域控且创建该机器账户的4741事件发生在同一时间段这三条拼起来基本可以认定一条RBCD攻击链。6.2 从架构层面削弱委派攻击面加固的核心思路是“让委派不可见、让强制回连不可用、让高权限账户不可委派”。具体执行上我建议按优先级做第一对所有AD对象做委派配置盘点至少每季度跑一遍LDAP查询把配置了非约束委派、约束委派、RBCD属性的机器和服务账户全部罗列出来。没有业务依据的委派配置一律清除。第二将域管账户、高权限服务账户加入Protected Users组。该组成员默认不允许被委派Kerberos的AES加密策略也更严格可以挡掉相当一部分票据抓手。第三对Print Spooler服务统一管控。园区环境确实存在打印需求可以评估直接通过组策略禁用Spooler或者用ACL限制远程访问spoolss管道。无论如何域控和关键服务器上的Print Spooler应当列为重点关注对象。第四启用Credential Guard和LSA保护。即使攻击者拿下一台机器的SYSTEM权限提取TGT和长期凭据的难度也会大幅上升。6.3 我的一点加固执行心得在实际执行委派加固时最容易出现的情况是“查出了配置但不敢动”。我遇到过一家企业域内有四十多台机器开了非约束委派其中大半是历史遗留。这种情况强行整改会引发业务中断所以我的建议是分阶段收敛先给高优先级资产域控、财务系统、运维跳板机取消委派再把剩余机器的委派模式从非约束降级为约束委派最后逐步过渡到RBCD或托管服务账户方案。还有一个小技巧在AD中启用“目录服务更改”审计后可以针对msDS-AllowedToActOnBehalfOfOtherIdentity属性专门写一条PowerShell监控任务一旦非域管账户修改了该属性就触发告警。这个属性平时正常变更频率极低属于典型的“低误报、高价值”日志源。把这些监控点布好之后委派攻击的隐蔽性就会大幅降低。