委派攻击原理

攻防渗透
,

之前看过好多委派攻击的原理说明还都是很迷糊不明白，最近打了几个靶场慢慢能稍微理解一下。
也来记录下网上师傅写的原理

委派

先来说一下什么是委派：域委派是指将域内用户的权限委派给服务账号，使得服务账号能以用户权限访问域内的其他服务。

为什么要域委派

这里引用别的师傅的表述：

比如现在有web服务器和文件服务器，当用户A访问web服务器去请求某个资源时，web服务器上本身并没有该资源，所以web服务器就会从文件服务器上调用这个资源，其中发生的过程若以域委派的形式进行，那么就是：用户A访问web服务器，服务器再以用户A的身份去访问文件服务器。

可以进行域委派的用户

一种是主机账户，活动目录中的computers组内的计算机，也被称为机器账号。如下图:

另一种是用setspn手动添加的服务账户。简单来说,服务账号，域内用户的一种类型，服务器运行服务时所用的账号，将服务运行起来并加入域。例如MS SQL Server在安装时，会在域内自动注册服务账号SqlServiceAccount，这类账号不能用于交互式登录，也就是说无法通过SqlServiceAccount来通过3389进行rdp登录。

看一下具体的域委派的流程，参考域渗透攻防指南

域用户 xie\test 以 Kerberos 身份验证访问 Web 服务器，请求下载文件。但是真正的文件在后台的文件服务器上。于是，Web 服务器的服务账号 websrv 模拟域用户 xie\test，以 Kerberos 协议继续认证到后台文件服务器。后台文件服务器将文件返回给 Web 服务器，Web 服务器再将文件返回给域用户 xie\test 。这样，就完成了一个委派的流程。

委派的分类

  • 非约束委派(Unconstrained Delegation, UD)
  • 约束委派(Constrained Delegation, CD)
  • 基于资源的约束委派(Resource Based Constrained Delegation, RBCD)

非约束委派

先来看一下非约束委派的流程

具体流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
（1）用户通过发送一个 KRB_AS_REQ 消息，向 KDC 密钥分发中心 KDC 的 AS认证服务进行身份验证，请求一个可转发的 TGT1 认购权证。
（2）KDC 在 KRB_AS_REP 消息中返回了一个可转发的 TGT1 认购权证。
（3）用户根据上一步获取到的可转发的 TGT1 认购权证请求另一个可转发的TGT2 认购权证，这一步是通过 KRB_TGS_REQ 消息请求。
（4）KDC 在 KRB_TGS_REP 消息中为用户返回可转发的 TGT2 认购权证。
（5）用户使用步骤 2 中返回的 TGT1 认购权证向 KDC 请求 Service1 的 ST 服务票据。
（6）KDC 的 TGS 服务在 KRB_TGS_REP 消息中返回给用户 Service1 的 ST 服务票据。
（7）用户发送 KRB_AP_REQ 消息请求 Service1，KRB_AP_REQ 消息中包含了TGT1 认购权证和 Service1 的 ST 服务票据、TGT2 认购权证、TGT2 认购权证的SessionKey。
（8）service1 以用户的名义向 KDC 的 TGS 服务发送 KRB_TGS_REQ 请求，请求 Service2 的 ST 服务票据。请求中包含用户发过来的 TGT2 认购权证。
（9）KDC 的 TGS 服务在 KRB_TGS_REP 消息中返回 Service2 的 ST 服务票据给 Service1，以及 service1 可以使用的 sessionkey。ST 服务票据将客户端标识为用户，而不是 Service1。
（10）Service1 以用户的名义向 Service2 发起 KRB_AP_REQ 请求。
（11）Service2 响应 service1 的 KRB_AP_REQ 请求。
（12）有了步骤 11 这个响应，Service1 就可以响应步骤 7 中用户的KRB_AP_REQ 请求。
（13）这里的 TGT 认购权证转发委派机制没有限制 Service1 使用 TGT2 认购权证来申请哪个服务，所以 Service1 可以以用户的名义向 KDC 申请任何其他服务的ST 服务票据。
（14）KDC 返回步骤 13 中请求的 ST 服务票据。
（15）Service1 以用户的名义来请求其它 service N 服务。
（16）Service N 服务将响应用户的请求一样响应 Service1。
在该流程中，TGT1 认购权证请求的 ST 服务票据用于访问 service1 服务，TGT2认购权证请求的 ST 服务票据用于访问 service2 服务

用大佬总结的原理就是用户B想访问服务A，于是向KDC提交认证，KDC发现A是非约束性委派，会把TGT放在ST中一并给用户B。然后用户B用这个ST去访问服务A，服务A就相当于获得了用户B的TGT，把TGT放入lsass进程，然后就可以拿着用户B的TGT以用户B的身份去访问该用户权限能够访问的服务了。所以其实在我们攻击者的视角来看的话就是如果控制了一台配置了非约束委派的机器，就可以诱骗其他用户来访问这台机器来获得他们的TGT。

具体利用方式有三种参考以下文章
https://forum.butian.net/share/1591

约束委派

为了在 Kerberos 协议层面对约束性委派的支持，微软对 Kerberos 协议扩展了两个子协议 S4u2self(Service for User to Self) 和 S4u2Proxy (Service for User to Proxy )。S4u2self 可以代表任意用户请求针对自身的 ST 服务票据；S4u2Proxy 可以用上一步获得的 ST 服务票据以用户的名义请求针对其它指定服务的 ST 服务票据。

还是同样的先来看看流程

1
2
3
4
5
6
7
8
9
10
（1）用户向 Service1 发出请求，用户已通过身份验证，但 Service1 没有用户的授权数据，这通常是由于用户的身份验证是通过 Kerberos 以外(基于表单的 web 认证、NTLM 认证等)的其他方式验证的。
（2）Service1 已经通过 KDC 进行了身份验证，并获得了 TGT 认购权证。它通过S4U2self 协议代表用户向 KDC 请求一张访问自身 Service1 服务的可转发 ST 服务票据。
（3）KDC 返回给 Service1 一张访问 Service1 自身服务的可转发 ST1 服务票据，就像是用户使用自己的 TGT 认购权证请求的一样，该可转发的 ST1 服务票据可能包含用户的授权数据。
（4）Service1 可以使用 ST1 服务票据中的授权数据来满足用户的请求，然后响应用户。
（5）用户向 Service1 发出请求，请求访问 Service2 上的资源。
（6）Service1 利用 S4U4Proxy 协议以用户的名义向 KDC 请求访问 Service2 的ST2 服务票据，该请求中带上了可转发的 ST1 服务票据
（7）如果请求中存在 PAC 特权属性证书，则 KDC 通过检查 PAC 结构的签名数据来验证 PAC。如果 PAC 有效或不存在，KDC 返回 Service2 的可转发 ST2 服务票据，并且存储在 ST2 服务票据中的 cname 和 crealm 字段中的客户端标识是用户，而不是 Service1。
（8）Service1 以用户身份使用可转发 ST2 服务票据向 Service2 发起请求。
（9）Service2 响应步骤 8 的请求。
（10）Service1 响应用户对步骤 5 中的请求。

还是记录下大佬的总结
由于服务用户只能获取某个用户（或主机）的服务的ST1而非TGT ， 所以只能模拟用户访问特定的服务 ；但是如果能够拿到约束委派用户（或主机）的明文密码或hash，那么就可以伪造S4U的请求，伪装成服务用户以任意用户的权限申请访问指定服务的ST2。

具体利用还是参考上面的链接。

基于资源的约束性委派

看下流程图：

1
2
3
4
①：服务 A 使用自己的服务账号密码向 KDC 申请一个可转发的 TGT 认购权证。
②：服务 A 利用 S4U2Self 协议代表用户申请一个获得针对服务 A 自身的 ST 服务票据。这一步区别于传统的约束性委派。在 S4U2Self 协议里面提到，返回的 ST服务票据可转发的一个条件是服务 A 配置了传统的约束委派。KDC 会检查服务 A的 msDS-AllowedToDelegateTo 字段，如果这个字段赋值了，则 KDC 返回可转发的 ST 服务票据。但是由于这里是基于资源的约束性委派，是在服务 B 上配置的，服务 B 的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性配置了服务 A的 SID，因此服务 A 并没有配置 msDS-AllowedToDelegateTo 字段。因此 KDC返回的 ST 服务票据是不可转发的。
③：服务 A 利用 S4U2Proxy 协议以用户的身份向 KDC 请求访问针对服务 B 的可转发的 ST 服务票据(上一步获得的不可转发的 ST 服务票据放在请求包的AddtionTicket 里面)。KDC 返回一张访问服务 B 的可转发的 ST 服务票据。
④：服务 A 拿着上一步获得的可转发的 ST 服务票据访问服务 B。

原理

在windows server 2012开始加入了新功能（基于资源的约束性委派RBCD），而且不需要域管理员去设置相关属性，RBCD把设置委派的权限赋予了机器自身，机器自己可以决定谁可以被委派来控制我，也就是说机器自身可以直接在自己账户上配置msDS-AllowedToActOnBehalfOfOtherIdentity属性来设置RBCD，简单来说就是如果我们拥有了配置某台机器msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限，那么我们就对这台机器拥有完全控制的权限，以下这些拥有配置msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限：

1
2
3
1.将某机器加入域的域用户
2.机器自身
3.域管理员

我们可以利用域用户添加一个机器账户作为服务1，注意是机器账户，不是普通账户，普通账户没有SPN，因为S4U2self协议会用到SPN，而且通过S4U2Self得到的ST服务票证是不可被转发的，而S4U2Proxy的作用就是将可转发的ST票据转发到其他服务进行委派认证的，但是在基于资源的约束委派过程中，不可转发的ST仍可以通过S4U2Proxy转发到其他服务进行委派认证，并且最后还会返回一张可转发的ST服务票证，如果我们可以在服务2上配置允许服务1的资源约束委派，就可以通过服务1利用S4U2self向KDC请求用于访问自身的票据，在使用S4U2Proxy转发此票据去请求访问服务2的票据，最终就可以模拟任何用户去访问服务2了

攻击条件

1.机器账户：是由某个域用户创建的主机，只要拿下这个域账户，那么就能拿下这个域用户所创建的所有机器账户的最高权限（默认每个域用户能创10个机器账户） 

2.拥有一个有权修改msDS-AllowedToActOnBehalfOfOtherIdentity属性的域用户账号密码(将机器拉进域的域用户)、或者在account operators组内的域用户 

3.域控需要是server2012和2012 R2以上的（因为2008及以下没有msDS-AllowedToActOnBehalfOfOtherIdentity属性）

4.任意用户对该主机的属性具有写权限，那么这个用户就可以对该主机进行攻击，所以可以枚举域内ACL策略，查看哪些对主机有GenericAll权限，GenericWrite、WriteProperty、WriteDacl等等权限，都是可以的

来一个攻击图

具体利用方式还是参考第一个链接。

约束委派和基于资源的约束委派区别：

传统的约束性委派是“正向的”，通过修改服务账户 A 的”msDS-AllowedToDelegateTo”属性，添加服务 B 的 SPN（Service Principle Name），设置约束委派对象为服务 B，服务 A 便可以模拟任意用户向域控制器请求访问服务 B 的 ST 服务票据。

基于资源的约束性委派则是相反，通过修改服务 B 的”msDS- AllowedToActOnBehalfOfOtherIdentity”属性，添加服务 A 的 SID，达到让服务 A 模拟任意用户访问服务 B 资源的目的。

如图所示

参考文章：
https://mp.weixin.qq.com/s/LXeFNmHaAwi3fnZ3AJaFiQ
https://mp.weixin.qq.com/s/mALL2koAmEONSsrSudaAdA
https://forum.butian.net/share/1591
谢公子域渗透攻防指南