Kerberos Bronze Bit攻击(CVE-2020-17049)是国外netspi安全研究员Jake Karnes发现的漏洞
Microsoft在2020年11月10日发布了该漏洞的补丁程序，补丁发布持续到2021年2月9日。以下攻击情形假设域控制器没有这个补丁，攻击者正在发起攻击。
Bronze Bit漏洞启用的攻击是Kerberos委派引起的其他已知攻击的扩展。Bronze Bit漏洞绕过了现有攻击路径的两种可能的缓解措施，从而提高了其有效性和攻击性。攻击者现在可以执行以下操作：
攻击者可以模拟 “受保护用户”组的成员以及 “账户敏感且无法委派”配置的用户。
攻击者可以禁止执行身份验证协议转换的服务，发起攻击。这意味着，如果配置的服务没有“ TrustedToAuthForDelegation”属性（在AD GUI中显示为“信任此用户，仅委派指定的服务（Trust this user for delegation to specified services only）——仅使用Kerberos”），则攻击者可以利用漏洞来获取票据，就和设置了“ TrustedToAuthForDelegation”属性一样。
这个漏洞可以绕过受保护组和设置了"敏感用户，禁止委派"的用户。或者攻击设置了信任该计算机来委派指定的服务器选项===> 仅使用Kerberos
大致的攻击思路如下：
首先攻击者获取了在域内的某台机器作为立足点。并且攻击者获取了域环境里面的服务密码hash，这里我的环境里面，我获取的服务hash是DM1的。 DM1与另一个服务具有受约束的委派信任关系。在我的测试环境里是DM2。此信任关系可以是以下其中一种：把DM1配置为对DM2进行约束委派。也就是说，DM2在DM1的“ AllowedToDelegateTo”列表中。把DM2配置为接受DM1基于资源的约束委派。也就是说，Service1在Service2的“ PrincipalsAllowedToDelegateToAccount”列表中。 接着攻击者通过CVE-2020-17049漏洞来获取DM2的服务票据 攻击者利用此漏洞充当Service1，并获得Kerberos服务票证作为Service2的目标用户。 攻击者冒充目标用户，向Service2提供服务票证。攻击者现在已作为目标用户向Service2进行身份验证，并且可以在目标用户的权限下与Service2进行交互。
以下来自作者文章：https://blog.netspi.com/cve-2020-17049-kerberos-bronze-bit-attack/ Bronze Bit漏洞是Impacket框架的延伸。新漏洞利用功能目前正等着pull请求的合并。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的长期密钥解密、可转发标志集进行解密，然后重新加密。更改后的票据会附加在S4U2proxy交换中，KDC将作为目标用户返回Service2的服务票据。
绕过限制并准备好服务票据后，攻击者可以模拟目标用户和Service2进行交互
实验环境配置：
域:one.com 域控：dc，IP：192.168.8.155，用户：administrator 域内机器1：dm1，IP：192.168.8.158，用户：user0x1 域内机器2：dm2，IP：192.168.8.156，用户：user0x2
Example Attack #1
一开始在域控制器中对dm1进行设置，设置为仅信任此计算机来委派指定的服务。并且是选择为Kerbberos
接着要为user0x2设置SPN，然后再把它加入到受保护组或者是设置为“敏感用户，不能被委派”
接着我们在dm1中来访问dm2，这个时候是不能访问到dm2的。
按照委派约束的攻击是已经失败了的！和基于资源委派那个把administrator设置了敏感用户不能委派的差不多！
接着需要获取到dm1的hash和AES256-CTS-HMAC-SHA1-96。需要注意的就是dm1的hash格式是需要LM：NTLM这种格式，也就是需要带上空密码的那个
runas.exe /profile /user:dm1administrator cmd
mimikatz.exe
privilege::debugsekurlsa::ekeys
获得到了必要的条件之后，使用getST.py来进行攻击，一开始不加上-force-forwardable标识，是不能获取到票据的。加上-force-forwardable标识便利用漏洞成功。
python3 getST.py -spn cifs/dm2.one.com -impersonate administrator -hashes-aesKeyone.com/dm1
获取到了票据之后，通过mimikatz把票据导入进入到内存。这里我获取了一个cifs的票据
但是使用cifs的票据并不能直接登录控制到dm2的机器。
接着我再导入了一个host票据就可以登录进入到对方的机器了。
Example Attack #2
第二个是基于资源委派的攻击，首先把之前的实验配置都还原。首先删除dm1的委派权限。连接DC，并把dm1配置为“不信任此计算机进行委派”。
编辑dm2计算机对象， 授予user0x1写入权限。当我们直接向据点用户授予权限时，用户通常通过特权组的成员身份获得对一个或多个AD对象的写入权限。用户不一定是域管理员。
这里user0x1已经对dm1具有了写入权限了，那么就可以通过user0x1用户来创建用户。这里我创建一个AServer的账户，并且密码是q123456.
Import-Module .powermad.ps1
New-MachineAccount -MachineAccount AServer -Password $(ConvertTo-SecureString 'q123456.' -AsPlainText -Force)
接着使用mimikatz获取这个用户的hash值和aes加密值
用PowerShell Active Directory模块检查我们新创建的计算机帐户。由于该模块尚不可用，所以需要安装相应的功能，这里确定了AServer用户已经添加成功。
确认计算机帐户的存在之后，我们可以在dm2和AServer之间建立受约束的委派信任关系。因为user0x1（我们的受控据点帐户）对dm2对象具有写入权限，所以我们可以把AService添加到dm2的PrincipalsAllowedToDelegateToAccount列表中。这将在dm2上建立基于资源的约束委派，并从AService接受约束委派。
Set-ADComputer dm2 -PrincipalsAllowedToDelegateToAccount AService$
Get-ADComputer dm2 -Properties PrincipalsAllowedToDelegateToAccount
python3 getST.py -spn cifs/Service2.test.local -impersonate user0x2 -hashes-aesKeyone.com/AService -force-forwardable
接着使用mimikatz把Kerberos缓存导入进内存，就可以访问到dm2服务器了。
接着就可以访问到dm2.one.com了，但是不知道为什么我这里不能通过PsExec来登录进入到dm2。接着在申请到了一个host的服务票据就可以连接了。
本文由 Jen 撰写
