NickYan7
commented
1 year ago 逛 GitHub 时突然发现以前研究绕过敏感用户禁止委派时提的这个问题，今天抽空对该问题做下解答。
截止 6-23-2022，发现两种突破敏感用户禁止委派的方式： 1、Bronzebit（CVE-2020-17049）； 2、已控制恶意服务账号（A），在具有目标服务账号（B）的凭据（HASH/TGT）的情况下，可以突破禁止委派；
第一个没什么好说的，就是漏洞，触发点位于 KDC 对于 additional-ticket 票据的 forwardable 标志位为 1 时的一处逻辑判断：如果 forwardable 标志位为 1，且二者之间具备委派配置，那么就返回票据。
微软此补丁的解决方案是添加了一个【票据签名】，防止篡改。虽然 s4u2self 过程中修改 fowardable 标志位为 1 是可行的，但 KDC 会在 s4u2proxy 过程中进行检查，最后拒绝返回票据并输出 KDC_AP_ERR_MODIFIED 错误
重点说说第二个（即七友文章中提到的），为什么在具备目标服务账号 HASH（服务 B）的情况下可以突破禁止委派的限制？获取了目标计算机账户（或服务）的 HASH 进行利用，跟银票很相似，那这种利用方式与银票的区别是什么？
首先，这种攻击方式跟我们预期的「配置 rbcd 后，突破禁止委派的限制」是有差异的，因为在已取得目标主机凭据的情况下，这更像是一种隐蔽的权限持久化方式。而我们期待的，是通过突破禁止委派的限制，提升权限从而能够访问目标主机。
可以说，这种方式就是一种特殊的「银票」，特殊在这种银票跟域控制器是有交互的（2 次），而传统意义上的银票跟 kdc 无交互。这里之所以能够突破【敏感用户禁止委派】的限制，是因为服务器并不检查用户是否被设置了禁止委派，这个工作是由 kdc 完成的，服务器只使用自身的 HASH 解密 TGS 票据，如果能够解密，则判断票据有效，允许访问（不检查 PAC 的情况下）。
而与 kdc 交互的 2 次，分别是： 1、利用目标服务器（dc01$）的 HASH 向 kdc 申请一张 TGT； 2、拿着这张 TGT 通过调用 s4u2self 向 kdc 申请一张 spn 为目标服务器（dc01$，此时 spn 并不完整）的 TGS 票据（即 additional-ticket）；
然后再修改 spn 为完整的指向目标服务器的某个服务（cifs/ldap/rpcss...），发送给目标服务器，由于此 TGS 是由目标服务器的 HASH 加密的，对方可以成功解密，通过了身份认证。
而银票的一个特征是可以伪造域内不存在的用户，因为其不与 KDC 交互，直接与服务交互，在不启用 PAC-Validation 的情况下，服务器不检查用户名。而 S4U2Self 是需要与 KDC 交互的，KDC 会检查用户名是否存在，所以不能伪造不存在的用户，这就是两者的区别与联系。
师傅你好，一点关于【基于资源的约束委派攻击】的问题想向你请教一下：
在你的技术文档【域渗透——基于资源的约束委派利用】（
https://www.redteaming.top/2020/03/23/%E5%9F%9F%E6%B8%97%E9%80%8F%E2%80%94%E2%80%94%E5%9F%BA%E4%BA%8E%E8%B5%84%E6%BA%90%E7%9A%84%E7%BA%A6%E6%9D%9F%E5%A7%94%E6%B4%BE%E5%88%A9%E7%94%A8/#%E8%A7%A3%E5%86%B3%E6%95%8F%E6%84%9F%E7%94%A8%E6%88%B7%E4%B8%8D%E5%8F%AF%E5%A7%94%E6%B4%BE%E7%9A%84%E9%97%AE%E9%A2%98）中，解决敏感用户不可委派那一节，动图中python convert.py的 python 脚本是什么作用？有源码吗？在解决【敏感用户不可委派】这个问题的时候，我执行了： 1、
rubeus s4u ... /nowrap伪造域管理员针对域控的 cifs 票据，复制 base64 票据部分（已经换行处理）； 2、rubeus tgsub /ticket:<base64_code> /altservice:.....修改 spn； 但还是不能 dir 获得结果，报错 ACCESS DENIED，应该是票据的问题。与你的动图中比较只差执行 python 脚本的那一步，请问 convert.py 的作用是？是将 base64 部分转换成 kirbi 文件吗？多谢！