此计算机必须为委派而被信任_实际利用Kerberos Bronze Bit漏洞绕过委派限制（CVE202017049）...

0x00 前言

本文主要说明如何针对Kerberos Bronze Bit漏洞(CVE-2020-17049)进行实际利用的过程。在阅读这篇文章之前，我强烈建议大家首先阅读《Bronze Bit攻击理论》这篇文章，以了解这种攻击的根本原因和攻击效果。

值得关注的是，Microsoft在2020年11月10日发布了该漏洞的补丁程序。这个补丁程序的发布将持续到2021年2月9日。以下的攻击场景中假设攻击者在未安装补丁的域控制器环境中进行。

Bronze Bit漏洞攻击是Kerberos委派导致的其他已知攻击的一种扩展方法。此前Elad Shamir和Will Schroeder曾发表过文章，说明了这些攻击方法以及利用条件。而Bronze Bit的漏洞利用则是绕过了现有原始路径的两种潜在缓解措施，从而提高了漏洞利用的有效性和功能性。攻击者现在可以执行以下操作：

1、攻击者可以冒充不允许委派的用户。其中包括Protected Users组的成员，以及任何其他明确配置为“敏感且无法委派”的用户。

2、攻击者可以从不允许执行身份验证协议转换的服务发起攻击。这意味着，如果配置的服务没有TrustedToAuthForDelegation属性(在AD GUI中显示为“信任此用户仅委派指定的服务 - 仅使用Kerberos”)，则攻击者可以利用漏洞利用来获取票证，其效果等价于设置了TrustedToAuthForDelegation属性(在AD GUI中显示为“信任此用户仅委派指定的服务 - 使用任何身份验证协议”)的情况。

0x01 通用攻击路径

该漏洞的一般攻击路径如下：

1、攻击者在AD环境中找到立足点；

2、攻击者获取环境中服务的密码哈希。我们将这个服务称为Service1。攻击者可以通过多种方式获取必要的哈希，例如DC Sync攻击、Kerberoasting，甚至可以通过Powermad使用SPN创建新的计算机帐户。

3、Service1与另一个服务具有受约束的委派信任关系。我们将其称为Service2。信任关系可以是下列之一：

  (1) Service1配置为执行对Service2的约束委派。也就是说，Service2在Service1的AllowedToDelegateTo列表中。

  (2) Service2配置为接受来自Service1的基于资源的约束委派。也就是说，Service1在Service2的PrincipalsAllowedToDelegateToAccount列表中。

    i. 如果攻击者对AD中的Service2对象具有写权限(GenericAll、GenericWrite、WriteOwner等)，则攻击者可以将Service1添加到Service2的PrincipalsAllowedToDelegateToAccount列表中。这样就不再需要Elad Shamir和Will Schroeder所描述的域管理员特权了。

4、攻击者利用该漏洞仿冒为Service1，并获得Kerberos服务票证作为Service2的目标用户。

5、攻击者冒充目标用户，向Service2提供服务票证。攻击者现在已经作为目标用户向Service2进行身份验证，并可以在目标用户的权限下与Service2进行交互。

0x02 漏洞利用

我们使用的Bronze Bit漏洞利用，是由SecureAuth的优秀研究人员开发的Impacket框架的扩展。目前已经提交合并请求，期待能作为其中一个新的漏洞利用功能。Impacket中内置了许多出色的功能，但是我们对其中的getST.py程序比较感兴趣。我们先不看漏洞利用，回顾一下之前的步骤。在第4步，我们进入到攻击路径。假设我们已经获得了Service1的哈希值，Service1与Service2的委派信任关系受到限制，