三种委派 非约束委派 约束委派 基于资源的约束委派 概念

前言

简单记录下委派攻击的概念。具体的攻击演示/复现这里没有。

---

强烈建议反复通读《域渗透攻防指南》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的时候都不需要凭据！

这里再列一下漏洞利用流程，加深理解：

1. 服务账户 N0用自己的凭据向KDC申请一个可转发的TGT。

2. 服务账户 N0用S4U2SELF，代表admin申请一个访问服务1（自身服务）的可转发的ST1，TGS_REQ的CNAME和SNAME都是服务账户N0。

3. 服务账户 N0用上一步的可转发的ST1，以高权限用户admin的身份用S4U2PROXY向KDC申请访问域控CIFS服务的ST2。

   此时TGS_REP中的CNAME是用户 admin，SNAME是域控。

4. PTT以域管权限访问域控CIFS。

基于资源的约束委派（RBCD）

跟CD的区别（✨）

CD：服务1是配置了约束委派的服务账户，然后设置对应可PROXY的服务2。

RBCD：服务2是配置了基于资源的约束委派的服务账户，然后在xxx属性配置了服务1的SID。

可以看到，

1. CD是一个正向的配置过程；RBCD是一个反向的配置过程。
2. CD配的是服务1；RBCD配的是服务2。
3. CD是已经决定了中转服务1，配置代理终点的服务2；RBCD是已经决定了代理的终点服务2，决定代理中转点服务1
4. CD一般需要域管及以上权限；RBCD可以用机器自身和将机器加入域的域用户的权限。
5. RBCD可跨域委派。

流程

这里省略了用户请求的这一步。

其实本质都和前面CD那儿一样，区别在于：

1. 拿到的ST1不是可转发的。
2. 即使ST1不可转发，由于是RBCD，KDC还是会返回ST2。（）

漏洞利用点

RBCD的好处就在于权限要求低了很多，而且不需要走KDC审核权限。

（KDC看的是服务2的配置中有无服务1的SID）

书中也说了，RBCD可以用机器自身和将机器加入域的域用户的权限。

而域用户的权限是比较好拿的，拿了后我们自己创一个机器账户（以这个域用户的身份），然后配置一个RBCD，配置要PROXY到的本机（maybe其它也行？）服务，将服务1（也需要我们拿下）的SID加进来，就可以做隐藏后门了。

也记录下具体攻击流程，加深理解：

（这里以本机提权为例）：假设我们拿到了一台主机的域用户，且这个域用户有配置RBCD的权限。我们想要提权到SYSTEM：

1. 以机器账户machine$身份向KDC请求可转发的TGT。（我们自己配的，有密码/HASH）
2. KDC返回可转发的TGT
3. S4U2SELF：机器账户machine$以高权限用户admin的身份访问自身服务。
4. KDC返回一个不可转发的ST1。
5. S4U2PROXY：机器账户machine$高权限用户admin的身份申请本机CIFS服务的ST2，additonal ticket中带上上一步获得的不可转发的ST1。
6. KDC返回以高权限用户admin身份访问本机CIFS服务的ST2.
7. PTT。以域管身份访问本机CIFS，拿到SYSTEM权限。

大致还是很清晰了，就是还有个疑问：

我们拿到的域用户对应的机器账户能配置本机外的其它服务吗？🤔