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

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