域内横向渗透-委派攻击之约束委派攻击

约束委派原理

由于非约束委派的不安全性，微软在windows server 2003中引入了约束委派，对Kerberos协议进行了
拓展，引入了S4U，其中S4U支持两个子协议：**Service for User to Self ( S4U2Self )和 Service for User to Proxy** ( S4U2proxy )，这两个扩展都允许服务代表用户从KDC请求票证。S4U2self可以代表自身请求针对其自身的可转发的Kerberos服务票据(ST1)；S4U2proxy可以以用户的名义请求其它服务的ST2，约束委派就是限制了S4U2proxy扩展的范围。
S4U2Self（用用户的TGT向KDC请求用户的可转发的ST1，再用这张ST1去发起S4U2proxy请求。）通过此扩展可以拿到一张标识任意用户身份的ST，它的作用其实是协议转换。有时用户会通过其他协议（例如NTLM或什至基于表单的身份验证）对服务进行身份验证，因此他们不会将TGS发送给服务。在这种情况下，服务可以调用S4U2Self来要求身份验证服务为其自身的任意用户生成TGS，然后可以在调用 S4U2Proxy时将其用作依据。例如网站A服务器可以使用它去向KDC请求一张用户B身份的ST1，网站A 服务器再用这张ST1去发起S4U2proxy请求。
S4U2proxy（拿用户的可转发的ST1请求用于访问服务器的ST2） 该拓展作用是使用一张用户A身份的
ST1去向KDC请求一张用于访问文件服务器B的ST2，这张ST2的身份还是用户的，这样的话网站A就可以利用用户A的权限去访问文件服务器B上的文件了。

大致流程

user访问serviceA，向DC发起kerberos认证，域控返回user的TGT和ST1票据，user使用ST1票据对 serviceA进行访问（S4U2Self）。
如果配置了serviceA到serviceB的约束委派，则serviceA能使用S4U2Proxy协议将用户发给自己的可转发的ST1票据以用户的身份发给DC（S4U2proxy）。
域控返回serviceA一个用来访问serviceB的ST2票据,这样serviceA就能以用户的身份对serviceB发起访问。

看不清下附一张原图。

由于服务用户，而服务用户只能获取到用户ST1而并不是TGT，所以只能模拟用户访问特定的服务，但是如果能拿到约束委派用户（或主机）的密码或者hash就可以伪造S4U2的请求，伪装成服务用户以任意用户权限访问指定的服务。

基于资源的约束委派

注意：server2012才引入了基于资源的约束委派！！！
无需域管设置相关属性，请求ST的过程与先前的约束委派类似，传统的约束委派S4U2Self返回的票据一定是可转发的，如果不可转发那么S4U2Proxy将失败；但是基于资源的约束委派不同，就算S4U2Self返回的票据不可转发（可不可以转发由TrustedToAuthenticationForDelegation决定），S4U2Proxy也是可以成功（基于资源的约束委派与普通约束委派的区别），并且S4U2Proxy返回的票据总是可转发总之需要用户对主机的属性具备写权限(条件）

基于资源的约束委派(RBCD)是在Windows Server 2012中新加入的功能，与传统的约束委派相比，它不再需要域管理员权限去设置相关属性。RBCD把设置委派的权限赋予了机器自身，既机器自己可以决定谁可以被委派来控制我。也就是说机器自身可以直接在自己账户上配置msDS-AllowedToActOnBehalfOfOtherIdentity属性来设置RBCD。 这里的关键就是谁可以修改属性.

REDTEAM\hack -> WriteProperty（将机器加入域的账号，也就是mS-DS-CreatorSID属性中的账户）
NT AUTHORITY\SELF -> WriteProperty（机器账户自身也可以修改）
我们再回顾一个知识点，默认域控的ms-DS-MachineAccountQuota属性设置允许所有域用户向一个域添加多达10个计算机帐户，就是说只要有一个域凭据就可以在域内任意添加机器账户。这个凭据可以是域内的用户账户、服务账户、机器账户