约束委派攻击

0x00 原理

回顾

首先回顾一下什么是委派？

服务/用户	主机名
用户A	hostA
服务B	hostB
服务C	hostC

委派就是用户A委派主机hostB上的服务代表自己去访问了主机hostC上的服务C，委派需要提前在域控上进行配置，它可以理解成是一种权限。

约束性委派原理

由于⾮约束委派的不安全性（配置了⾮约束委派的机器在 LSASS 中缓存了⽤户的 TGT 票据可模拟⽤户去访问域中任意服务），微软在 Windows Server 2003 中引⼊了约束委派，对 Kerberos 协议进⾏拓展，引⼊了 S4U(S4U2Self / S4U2proxy), 这两个扩展都允许服务代表⽤户向 KDC 请求票据。

S4U2self (Service for User to S4U2Self) 可以代表自身请求针对其⾃身的 Kerberos 服务票据(ST)；如果⼀个服务账户的 userAccountControl 标志TRUSTED_TO_AUTH_FOR_DELEGATION , 则其可以代表任何其他⽤户获取⾃身服务的 ST。

S4U2proxy (Service for User to Proxy) 可以以⽤户的名义请求其它服务的 ST【读完你会发现这就是前面我们回顾的委派的原理】，而约束委派则是限制了 S4U2proxy 扩展的范围。

约束性委派的大致流程：
用户访问开启约束性委派的服务A
（情况一：无S4U2Self 参与）首先需要经过KDC认证，KDC发现服务A开启了约束性委派，于是在TGS_REP截断返回给用户ST1（可转发ST），用户拿着ST1访问服务A，服务A先与KDC进行身份验证获得一个有效TGT，然后拿着ST1经过S4U2PROXY协议向KDC发起TGS_REQ，KDC返回ST2（用户身份的ST），然后服务A拿着ST2访问之前设置的只能被指定访问的服务。
（情况二：有S4U2Self 参与）用户通过其他方式（如NTLM认证，表单认证等）获取了服务A的信任，但是此时服务A并没有来自用户的ST1，按情况一中的流程，服务A就不能完成委派。所以这个时候服务A会以自己的身份向KDC发起申请获取一个可转发TGT（获取KDC信任），然后用这个TGT发起TGS_REQ获得指定用户的ST1【也就是在这里我们可以伪造用户身份了，类似白银票据原理了】，既然获取了ST1，就继续情况一中的流程即可了（然后拿着ST1经过S4U2PROXY协议向KDC发起TGS_REQ，KDC返回ST2（用户身份的ST