kerberos之委派

委派的原理

委派的定义：
先知社区某篇文章中，对委派的的定义是：域委派是指将域内用户的权限委派给服务账号，使得服务账号能以用户的权限在域内展开活动。

另一种说法：在域中如果出现A使用Kerberos身份验证访问域中的服务B，而B再利用A的身份去请求域中的服务C，这个过程就可以理解为委派。仁者见仁、智者见智，这两种说法本质都是一样的。需要注意的一点是接受委派的用户只能是服务账户或者计算机用户,在Windows系统中，普通用户的属性中没有委派（Delegation）这个选项卡，只有服务账号、主机账号才有，也就是当前用户账户下存在相对应的服务，比如mssql，http等等服务

委派一共分为三种，本文也主要对约束委派和非约束委派进行介绍，以便于理解约束委派攻击以及非约束委派攻击。

• 非约束委派
• 约束委派
• 基于资源的约束委派。

非约束委派

在拿到用户TGT之后，可以以用户的身份对域内所有服务进行访问。

流程

1.  用户通过发送KRB_AS_REQ消息请求可转发 TGT（forwardable TGT，为了方便我们称为TGT1）。

2.  KDC在KRB_AS_REP消息中返回TGT1。

3.  用户再通过TGT1向KDC请求转发TGT（forwardedTGT，我们称为TGT2）。

4.  在KRB_TGS_REP消息中返回转发TGT2。

5.  用户使用TGT1向KDC申请访问Service1的ST（ServiceTicket）。

6.  TGS返回给用户一个ST。

7.  用户发送KRB_AP_REQ请求至Service1，这个请求中包含了TGT1和ST、TGT2、TGT2的SessionKey。

8.  Service1使用用户的TGT2通过KRB_TGS_REQ发送给KDC，以用户的名义请求能够访问Service2的票据。

9.  KDC在KRB_TGS_REP消息中返回Service2到Service1的票据。

10.  Service1以用户的名义像Service2发送KRB_AP_REQ请求。

11.  Service2响应步骤10中Service1的请求。

12.  Service1响应步骤7中用户的请求。

13.  在这个过程中的TGT转发机制，没有限制Service1对TGT2的使用，也就是说Service1可以通过TGT2来请求任意服务。

14.  KDC返回步骤13中请求的票据。

15和16即为Service1通过模拟用户来访问其他Service。

可以看到在前5个步骤中User向KDC申请了两个TGT（步骤2和4），一个用于访问Service1一个用于访问Service2，并且会将这两个都发给Service1。并且Service1会将TGT2保存在内存中。

约束委派

有非约束委派的特性可知，当拿下委派机器时可以代表用户访问域内的任意服务，所以非约束委派是十分不安全的。因此微软在windows2003中发布了约束委派的功能。对Kerberos协议进行了拓展，引入了S4U，其中S4U支持两个子协议：Service for User to Self (S4U2Self)和 Service for User to Proxy (S4U2proxy)，这两个扩展都允许服务代表用户从KDC请求票证。S4U2self可以代表自身请求针对其自身的Kerberos服务票据(ST)；S4U2proxy可以以用户的名义请求其它服务的ST，约束委派就是限制了S4U2proxy扩展的范围。

流程

1. 用户向service1发出请求。用户已通过身份验证，但service1没有用户的授权数据。通常，这是由于身份验证是通过Kerberos以外的其他方式验证的。

2. 通过S4U2self扩展以用户的名义向KDC请求用于访问service1的ST1。

3. KDC返回给Service1一个用于用户验证Service1的ST1，该ST1可能包含用户的授权数据。

4. service1可以使用ST中的授权数据来满足用户的请求，然后响应用户。
注：尽管S4U2self向service1提供有关用户的信息，但S4U2self不允许service1代表用户发出其他服务的请求，这时候就轮到S4U2proxy发挥作用了

5. 用户向service1发出请求，service1需要以用户身份访问service2上的资源。

6. service1以用户的名义向KDC请求用户访问service2的ST2

7. 如果请求中包含PAC，则KDC通过检查PAC的签名数据来验证PAC ，如果PAC有效或不存在，则KDC返回ST2给service1，但存储在ST2的cname和crealm字段中的客户端身份是用户的身份，而不是service1的身份。

8. service1使用ST2以用户的名义向service2发送请求，并判定用户已由KDC进行身份验证。

9. service2响应步骤8的请求。

10. service1响应用户对步骤5中的请求。

查找约束委派与非约束委派

• 当服务账号或者主机被设置为非约束性委派时，其userAccountControl属性会包含TRUSTED_FOR_DELEGATION

• (&(objectCategory=computer)(objectClass=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))

• 当服务账号或者主机被设置为约束性委派时，其userAccountControl属性包含TRUSTED_TO_AUTH_FOR_DELEGATION，且msDS-AllowedToDelegateTo属性会包含被约束的服务

• (&(objectCategory=computer)(objectClass=computer)(userAccountControl:1.2.840.113556.1.4.803:=16777216))

约束委派与非约束委派的利用

非约束委派

设置非约束委派，委派只能对计算机账号和服务账号进行设置。
作为攻击者，一旦找到具有Kerberos无约束委派的服务器，那么下一步可以如下：

1. 通过管理员或服务帐户攻击服务器。
2. 通过社会工程学使用Domain Admin连接到服务器上的任何服务，并且具有无约束委派权限。
3. 当管理员连接到此服务时，管理员的TGS服务票证（使用TGT）将发送到服务器并存入LSASS中，以方便以后使用。

设置机器账号可以委派

使用 Enter-PSSession -ComputerName + 计算机名 ， 链接允许委派的服务器，链接成功后我是直接提取没办法提取到administrator的票据，再执行任何内容后即可提取到

导入票据

非约束委派+Spooler打印机服务

如果只是单纯的非约束委派话需要管理员主动连接，所以在实战环境利用比较鸡肋。

利用非约束委派+Spooler打印机服务可以强制指定的主机进行连接。 ==这个实现了前提是：需要获取一台主机账户开启了非约束委派域内机器的权限 ==

利用原理：利用Windows打印系统远程协议（MS-RPRN）中的一种旧的但是默认启用的方法，在该方法中，域用户可以使用MS-RPRN RpcRemoteFindFirstPrinterChangeNotification（Ex）方法强制任何运行了Spooler服务的计算机以通过Kerberos或NTLM对攻击者选择的目标进行身份验证。

注：Print Spooler服务默认是自动运行的

向域控的Spooler服务发送请求，强制其访问某台委派服务器进行身份验证

SpoolSample.exe 域控 委派机器

使用Rubeus 或者 mimikatz搞出票据，列出hash ,就可以高出黄金票据了。

约束委派

约束委派没啥意思，掠过，，，，

防御措施

1.不要使用Kerberos无约束委派权限 -----配置需要使用约束委派进行委派的服务器

2.将所有高权限的管理员帐户配置为“帐户敏感且无法委派”

3.从Windows Server 2012 R2域功能级别开始提供的“受保护用户”组也可以缓解此问题，因为此组中的帐户不允许委派。

参考

https://daiker.gitbook.io/windows-protocol/kerberos/2
https://www.freebuf.com/articles/system/198381.html
https://www.anquanke.com/post/id/200680
https://xz.aliyun.com/t/7217
https://y4er.com/post/kerberos-unconstrained-delegation/
https://www.cnblogs.com/backlion/p/9268346.html