AD提权-委派攻击如何实现？

本文中的部分图文内容均取自《域渗透攻防指南》，本人仅对感兴趣的内容做了汇总及附注。 导航 0 前言 1 实验环境 2 非约束性委派 3 约束性委派 4 基于资源的委派 5 杂项 0、前言 委派是指将域用户的权限委派给服务账户，使得服务账户能以域用户权限访问域内的其他服务。如下图所示，域用户 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、实验环境 域名 - skylark.com 主域控 - DC2012 - Windows 2012 R2 Standard - 192.168.56.50 备域控 - DC2013 - Windows 2012 R2 Standard - 192.168.56.51 域主机 - Win10 - Windows 10 专业版（22H2） - 192.168.56.14 域主机 - Win7 - Windows 7 旗舰版（SPK1） - 192.168.56.13 Kali - 192.168.56.20 普通域用户 - admin【注：虽然名称是 admin，但为了实验已将其从域管理组中踢出，此时它已经是一个普通域用户了。】 域管理员用户 - admin1 2、非约束性委派 工作原理 下面分析一下上述每个步骤的含义： 用户通过发送一个 KRB_AS_REQ 消息，向 KDC 的 AS 进行身份验证，请求一个可转发的 TGT1。 KDC 在 KRB_AS_REP 消息中返回了一个 可转发的 TGT1。 用户根据上一步获取的可转发的 TGT1 请求另一个可转发的 TGT2，这一步是通过 KRB_TGS_REQ 消息请求的。 KDC 在 KRB_TGS_REP 消息中为用户返回 可转发的 TGT2。 用户使用步骤 2 中返回的 TGT1 向 KDC 请求服务 1 的 ST。 KDC 的 TGS 服务在 KRB_TGS_REP 消息中返回给用户服务 1 的 ST。 用户发送 KRB_AP_REQ 消息请求服务 1，KRB_AP_REQ 消息中包含 TGT1 和服务 1 的 ST、TGT2、TGT2 的 SessionKey。【注：只要有用户访问服务 1（此时不管有没有服务 2），那么用户就会将自己的 TGT 票据和访问服务 1 的 ST 票据均通过 KRB_AP_REQ 消息发送到服务 1，服务 1 又会将其缓存在内存中。】 服务 1 以用户的名义向 KDC 的 TGS 发送 KRB_TGS_REQ，请求服务 2 的 ST。请求中包含用户发过来的 TGT2。 KDC 的 TGS 服务在 KRB_TGS_REP 消息中返回服务 2 的 ST 给服务 1，以及服务 1 可以使用的 SessionKey。ST 将客户端标识为用户，而不是服务 1。 服务 1 以用户的名义向服务 2 发起 KRB_AP_RE 请求。 服务 2 响应服务 1 的 KRB_AP_RE 请求。 有了步骤 11 的这个响应，服务 1 就可以响应步骤 7 中用户的 KRB_AP_REQ。 这里的 TGT 转发委派机制没有限制服务 1 使用 TGT2 来申请哪个服务，所以服务 1 可以以用户的名义向 KDC 申请任何其他服务的 ST。 KDC 返回步骤 13 中请求的 ST。 服务 1 以用户的名义来请求其他服务。 服务 N 将像响应用户的请求一样响应服务 1。 从网络攻击者的角度来看，如果攻击者控制了服务 1 , 则攻击者可以诱骗域管理员来访问服务 1，然后攻击者可以在服务 1 机器上获取域管理员的 TGT，从而可以用缓存的 TGT 模拟管理员访问任意服务，包括域控。 注：（1）在上述流程中，TGT1 请求的 ST 用于访问服务 1，TGT2 请求的 ST 用于访问服务 2。