域渗透-基于委派的权限维持

Delegation Golden Ticket

Posted by hmoytx on February 2, 2021

域渗透-基于委派的权限维持

Goldent Ticket介绍

金票是通过窃取krbtgt的hash后,离线伪造的TGT,伪造TGT的全程在本地完成,不与KDC进行交互。其中关键的点,需要的是krbtgt的hash,而这个账号的hash会因为账号密码的修改而修改,导致金票失效。

Delegation Golden Ticket

这里介绍一个方法,通过域内委派,来制作“金票”,不再依赖于krbtgt的hash,能够防止出现因为krbtgt账号密码的修改而导致权限丢失的情况。但也有一定的缺点,需要对域内用户进行操作,操作过程中必然会留下系统日志。
这并不是一个新技术,只能算一个小技巧,网上对应文章也比较多,这里我就挑关键步骤讲。

委派 Delegation

关于委派,我在之前的文章中测试过非约束委派与约束委派,这里不再对委派的概念进行重复。详情可以去看这里:https://www.c0bra.xyz/2020/02/19/%E5%9F%9F%E6%B8%97%E9%80%8F-Kerberos%E5%A7%94%E6%B4%BE%E5%AD%A6%E4%B9%A0/
这里只对其中约束委派中的一组kerberos协议扩展进行简单的介绍。
区别于非约束委派,出于安全性考虑,约束委派在Kerberos中User不会直接发送TGT给服务,而是对发送给service1的认证信息做了限制,不允许service1代表User使用这个TGT去访问其他服务。这里包括一组名为S4U2Self(Service for User to Self)和S4U2Proxy(Service forUser to Proxy)的Kerberos协议扩展。
其中:

  • Service for User to Proxy (S4U2proxy) Constrained delegation
  • Service for User to Self (S4U2self) Protocol transition

对于一个请求资源情况如下:
User –> service1 –> service2

User访问了service1后,service1要利用kerberos协议以User的身份去访问service2,但是这要求User访问service1的时候,也是利用的kerberos协议去与service1进行验证的。如果这时候使用的不是kerberos协议而是通过web账号密码登录(非域内账号密码),怎么办?
这个时候就需要Protocol transition来进行验证协议切换,切换完成后通过S4U2proxy,也就是Constrained Delegation完成验证。
所以在实际过程中就会存在多次请求,这个会在下面工具中体现。

实际操作

环境:
域 DE1AY.COM
域控名为:DC IP:10.10.10.10 操作系统:2008/2012 (一开始为2012但失败了,后换为2008)
域成员:PC IP:10.10.10.201 操作系统: win7

利用前提:
1.已经拿到域控
2.一个普通的域账号
3.普通的域账号为服务账号,即设置spn

这里我建了一个testa,在”Domain Users”组中,普通账号。

设置一个SPN。
setspn -U -A backdoor/golden testa

然后再域控上设置委派,即开启这个账号s4u2self的权限,并设置S4U2Proxy列表。
其中选择“仅信任此用户作为指定服务的委派”,即选择constrained delegation权限,也就是S4U2Proxy权限,该选项下的“使用任何身份验证协议”则是protocol transition权限,也就是S4U2self权限。在S4U2Proxy列表中我们要添加的目标SPN是 krbtgt/DE1AY.COM(对kerberos协议理解过关的,应该是能想明白为什么“金票”需要krbtgt的hash,这里为什么设置的是krbtgt/DE1AY.COM)。但是由于krbtgt这个域账号默认是禁用且无法启用,导致我们无法利用界面来添加这个SPN。

通过powershell命令来添加。

Import-Module activedirectory
$a = Get-ADUser ateam -Properties "msDS-AllowedToDelegateTo"
Set-ADObject $a -Add @{ "msDS-AllowedToDelegateTo" = @("krbtgt/DE1AY.COM") }


执行完命令后会修改“使用任何身份验证协议”为“仅使用kerberos”,需要手动再修改回来。

然后使用工具kekeo,去完成申请TGT的操作。
执行命令:
tgt::ask /user:testa /domain:de1ay.com /password:[email protected]

然后去利用这个TGT申请TGS票据,执行命令:
tgs::s4u /tgt:[email protected] /user:[email protected] /service:krbtgt/de1ay.com
这里就存在坑了,2012没有成功,卡在了S4U2Proxy这个第二次的申请票据的过程,前面第一次申请的访问自身服务的票(backdoor/golden这个服务),是成功的,后面带上这张票通过S4U2Proxy去申请访问krbtgt/DE1AY.COM的票失败。
后来将域控换成了2008才成功。

下面是在2008为域控的情况下成功的截图。
成功后会生成对应的票据,通过mimikatz的kerberos::ptt直接导入即可。

没有导入票据前。

通过mimikatz导入票据。

再尝试访问域控的资源,可以发现已经成功了。

总结

从最直观的效果展现出来,在拿下域控后通过一系列的设置,最终我们可以通过testa这个普通的域账号,利用S4U协议,拿到Adminstrator这个账号(可以是域内任何账号 在tgs::s4u 这个过程中可以自己指定)的一张 TGT。 通过整个过程去看,就能理解为什么Delegation Golden Ticket相比Golden Ticket,完全不惧krbtgt的密码修改,原则上来说只要testa密码没有改,我就可以通过testa申请到域内任何账户对应的票据,因为整个过程中根本就没有利用到krbtgt这个账户相关的任何信息。

参考

https://paper.seebug.org/620/#_ 1