前言
简单记录下委派攻击的概念。具体的攻击演示/复现这里没有。
强烈建议反复通读《域渗透攻防指南》P242开始的4.5！！！
以前看gitbook那个学的，yysy，真的不怎么适合零基础的看。
趁课上认真看了看4.5章，赶紧记一下。
域内委派的框架：
其中服务A和服务B都是服务账户或机器账户。
代表用户 <=> 以用户权限
服务2 <=> 待攻击的服务
（所以说为什么RBCD牛逼？因为RBCD是直接配服务2！）
非约束委派（UD）
核心在于，用户会把TGT缓存到服务1的LSASS中，我们可以dump出lsass缓存的高权限hash。
流程
流程：（这里只写服务1，服务2的情况，服务N同理）
关键点：Client最初请求了两个TGT，TGT1和TGT2。
第一个TGT，TGT1：是client用来证明自己有访问/委派服务1的权限。（KDC签发的TGT1）
第二个TGT，TGT2：是client向KDC申请的访问服务2的权限，然后会把TGT2在第（7）步请求服务1时一起发给服务1，这样服务1就有服务2的访问授权了。（来自client给的KDC发的TGT2）。
这样看，TGT2需要forwardable也很好理解了。
其实这两个TGT的作用和区别很关键，因为后面约束委派S4U2SELF就是"模拟"了TGT1的过程。
漏洞利用点
前面提到过，非约束委派会让client的TGT（TGT1，TGT2，……TGTN）一起发给服务1，服务1的LSASS缓存有TGT。所以可以让高权限用户访问服务1。（这里没提需不需要发起client用服务1 的委派，我觉得不需要，可能服务1的非约束配置决定了任意用户访问服务1，服务1都会当成一个委派，然后缓存TGT票证）
约束委派（CD）
配置细节这里不提，还是重点关注流程+漏洞利用点。
核心点：服务1（配置了CD的服务）发起S4U的时候是不需要用户凭据的！
流程
流程：（还是以服务1，服务2为例）
（这里开始按着书上的画的，后面发现书上少了两步，呃呃呃。。。）
(1)：Client请求和非约束委派不一样的点在于，这里的client不一定经过了Kerberos认证（可能通过NTLM之类的其它协议的认证）来访问服务1。
(2)(3)：由于(1)所说的其它协议认证，服务1并没有获得ST，所以得拿一个ST1，才能继续S4U2PROXY。
（可以这样理解：理想的流程就是用户用ST1访问服务1，服务1代表用户拿一个服务2的ST2。）
但是由于Kerberos协议，必须要有AS_REQ/AS_REP。
所以这里服务1向KDC获取了一个的可转发的TGT。
(4)(5)：走完AS_REQ/AS_REP的“流程”后，服务1用S4U2SELF代表用户向KDC申请访问服务1（自身服务）的forwardable ST（ST1）。
这里对应到wireshark包，就能看到SNAME和CNAME都是服务1账户本身。
然后服务1用ST1返回自身服务给用户。
(6)(7)：用户又发起了服务2的请求，由于配置了服务1到服务2的约束委派，所以服务1会利用S4U2PROXY向KDC申请服务2的ST2，这个TGS_REQ的additional ticket带上了可转发的ST1。
KDC验证后会返回forwardable ST2。
并且ST2的CNAME标识的是Client而不是服务1！
(8)……：服务1用ST2，代表用户访问服务2。
思考：
Q：为什么需要S4U2SELF？
A：因为第一步Client访问服务1给的凭据不一定是Kerberos，不一定是ST，所以需要走S4U2SELF获得一个ST。
漏洞利用点
可以看到在S4U2SELF的步骤中，是不需要用户凭据的。
即整个流程其实都是可以不要用户凭据的。
虽然可能在正常的流程中，client访问服务1需要相应凭据，但我们代表用户获得ST1，ST2的时候都不需要凭据！
这里再列一下漏洞利用流程，加深理解：
-
服务账户 N0用自己的凭据向KDC申请一个可转发的TGT。
-
服务账户 N0用S4U2SELF，代表admin申请一个访问服务1（自身服务）的可转发的ST1，TGS_REQ的CNAME和SNAME都是服务账户N0。
-
服务账户 N0用上一步的可转发的ST1，以高权限用户admin的身份用S4U2PROXY向KDC申请访问域控CIFS服务的ST2。
此时TGS_REP中的CNAME是用户 admin，SNAME是域控。
-
PTT以域管权限访问域控CIFS。
基于资源的约束委派（RBCD）
跟CD的区别（✨）
CD：服务1是配置了约束委派的服务账户，然后设置对应可PROXY的服务2。
RBCD：服务2是配置了基于资源的约束委派的服务账户，然后在xxx属性配置了服务1的SID。
可以看到，
- CD是一个正向的配置过程；RBCD是一个反向的配置过程。
- CD配的是服务1；RBCD配的是服务2。
- CD是已经决定了中转服务1，配置代理终点的服务2；RBCD是已经决定了代理的终点服务2，决定代理中转点服务1
- CD一般需要域管及以上权限；RBCD可以用机器自身和将机器加入域的域用户的权限。
- RBCD可跨域委派。
流程
这里省略了用户请求的这一步。
其实本质都和前面CD那儿一样，区别在于：
- 拿到的ST1不是可转发的。
- 即使ST1不可转发，由于是RBCD，KDC还是会返回ST2。（）
漏洞利用点
RBCD的好处就在于权限要求低了很多，而且不需要走KDC审核权限。
（KDC看的是服务2的配置中有无服务1的SID）
书中也说了，RBCD可以用机器自身和将机器加入域的域用户的权限。
而域用户的权限是比较好拿的，拿了后我们自己创一个机器账户（以这个域用户的身份），然后配置一个RBCD，配置要PROXY到的本机（maybe其它也行？）服务，将服务1（也需要我们拿下）的SID加进来，就可以做隐藏后门了。
也记录下具体攻击流程，加深理解：
（这里以本机提权为例）：假设我们拿到了一台主机的域用户，且这个域用户有配置RBCD的权限。我们想要提权到SYSTEM：
- 以机器账户machine$身份向KDC请求可转发的TGT。（我们自己配的，有密码/HASH）
- KDC返回可转发的TGT
- S4U2SELF：机器账户machine$以高权限用户admin的身份访问自身服务。
- KDC返回一个不可转发的ST1。
- S4U2PROXY：机器账户machine$高权限用户admin的身份申请本机CIFS服务的ST2，additonal ticket中带上上一步获得的不可转发的ST1。
- KDC返回以高权限用户admin身份访问本机CIFS服务的ST2.
- PTT。以域管身份访问本机CIFS，拿到SYSTEM权限。
大致还是很清晰了，就是还有个疑问：
我们拿到的域用户对应的机器账户能配置本机外的其它服务吗？🤔
