红队提权 - 基于RBCD的提权

本地主机 NTLM 中继技术概述

在这种情况下，我们利用这样一个事实，即从非特权用户上下文中，我们可以诱导以 NT AUTHORITY\SYSTEM 身份运行的本地服务通过 HTTP 对运行在 localhost 上的攻击者服务执行 NTLM 身份验证，使用主机的计算机帐户密码进行身份验证。然后，攻击者可以将该身份验证尝试中继到 LDAP 服务，以配置基于资源的约束委派 (RBCD) ，以允许攻击者控制的用户或计算机帐户冒充任何用户访问受害计算机。Elad Shamir 在他的文章“Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory”中对这种攻击背后的理论基础进行了更深入的讨论。

在他的文章“Gone to the Dogs”中，Elad Shamir 概述了一种通过利用自定义 Windows 锁定屏幕的能力，以非特权用户身份获取“基于 HTTP 的计算机帐户 NetNTLM 身份验证”原语的方法。Simone Salucci 和 Daniel Jiménez 随后发布了 Change-LockScreen 工具，该工具允许通过 Cobalt Strike 的信标触发原语，而无需通过 RDP 或控制台访问 与 Windows 桌面进行手动交互。

要成功利用该漏洞，需要满足以下先决条件：

1. 运行 Windows Server 2012 或更新操作系统的域控制器
2. 攻击者必须有权访问具有服务主体名称集的用户或计算机帐户对象，或者能够将新计算机添加到域
3. 域控制器不得配置为强制执行 LDAP 签名和 LDAP 通道绑定（默认设置）
4. 受害计算机必须安装并运行“webclient”服务（默认安装在 Windows 10 上）
5. 必须允许用户自定义 Windows 锁定屏幕（默认权限）

在随后的部分中，我们将描述操作员可以通过 Cobalt Strike 完全利用此问题的步骤。在我们的示例场景中，攻击者已成功对用户 JSMITH 进行网络钓鱼，结果在 CONTOSO.LOCAL 域内的 DESKTOP-KOERA35 上执行了代码。在此示例中，CONTOSO.LOCAL 域在运行 Windows Server 2019 的域控制器上以“Windows Server 2008”的域功能级别运行。

通过 Cobalt Strike Beacon 进行开发

操作员必须首先在 Cobalt Strike 中启用和配置 SOCKS 代理，并在 Cobalt Strike Team Server 上安装必要的依赖项。具体来说，利用该问题需要在主机上安装代理链、Python 3 和 Impacket。然后操作员启动一个 SOCKS 代理，在本例中我们利用端口 8889，然后proxychains.conf 文件中配置代理链以利用该端口。

配置 SOCKS 代理功能后，我们必须获得对具有服务主体名称或计算机帐户的用户的访问权限，该用户始终具有服务主体名称集，因为这是执行 S4U Self 和 S4U 代理操作所必需的。我们可以利用“SharpView” 实用程序通过执行程序集从域对象中读取“ms-ds-machineaccountquota”属性。下面给出了执行此操作的示例命令。

execute-assembly /home/engineer/hgfs/tools/SharpTeam/SharpView.exe Get-DomainObject -Domain CONTOSO.LOCAL

运行此命令的结果输出如下图所示：

假设“ms-ds-machineaccountquota”设置不允许用户创建新的计算机帐户。在这种情况下，攻击者可能会尝试使用通过 Kerberoasting 配置的服务主体名称 (SPN) 来破坏用户。或者，攻击者可能会尝试在其当前用户帐户上设置 SPN。默认情况下，Active Directory 不允许这样做；但是，在某些情况下，管理员可能会修改默认架构权限以允许这样做。

然后我们可以利用下面给出的命令来执行 LDAP 中继攻击。在这种情况下，我们将 HTTP 侦听器配置为侦听端口 8080。然后我们指定“--serve-image”标志以及要设置为锁定屏幕背景的图像路径。需要注意的是，如果用户之前没有配置过锁屏图片，这个图片会在利用完成后显示在用户的锁屏上。如果用户配置了自定义锁屏图像，Change-LockScreen 工具会将该图像恢复为其原始值。默认的 Windows 锁定屏幕个性化图像位于 C:\Windows\Web\Screen\。这些图像可能会被用作新的锁屏图像，而不会提醒用户。我们还指定了“--escalate-user”标志，指示 ntlmrelayx 允许“DESKTOP-JSMITH”用户对任何中继计算机帐户执行 RBCD。我们将主机定位在 192.168.184.135，这是一个 Windows Server 2019 域控制器。此外，“–no-validate-privs”选项可以包含在代理连接速度较慢的环境中。

sudo proxychains python3 examples/ntlmrelayx.py -t ldap://192.168.184.135 --http-port 8080 --
delegate-access --serve-image wallpaper.jpg --escalate-user 'DESKTOP-JSMITH$' --no-dump --
no-da --no-acl

rportfwd 和 Change-LockScreen 命令的预期输出如下所示：

然后，我们可以期望在收到身份验证时看到下面显示的输出。在这种情况下，当前用户帐户 JSMITH 将首先执行身份验证以获取图像。随后将使用计算机帐户密码通过 HTTP 执行后续身份验证。

接下来，我们利用带有 hash 子命令的 Rubeus 实用程序从 DESKTOP-JSMITH 计算机帐户的密码生成 AES256 密钥。此生成的密钥将在后续步骤中用于执行 S4U Self 和 S4U Proxy 操作。下面给出的命令可以与 Rubeus 一起使用，从生成的计算机帐户名和密码生成 AES256 密钥：

/
execute-assembly /home/engineer/hgfs/tools/Rubeus.exe hash /password:3UZBahMCcuTMsDF
/user:DESKTOP-JSMITH$ /domain:CONTOSO.LOCAL

该命令的预期输出如下所示，但有一个关键区别。在这种情况下，我们省略了 /nowrap 标志，以使示例屏幕截图中的命令输出更具可读性。

然后，操作员必须将 Rubeus 生成的票证的格式（代表 kirbi 格式的编码 TGS 票证的 base64 编码字符串）转换为 ccache 格式以与 Impacket 兼容。幸运的是，Impacket 通过利用 ticketConverter.py 实用程序本机支持此操作。操作员可以利用下面给出的命令序列将生成的 base64 编码的 kirbi 文件转换为 ccache 格式。

$ vim administrator.kirbi.base64
$ cat administrator.kirbi.base64 | base64 --decode > administrator.kirbi
$ python3 examples/ticketConverter.py administrator.kirbi administrator.ccache

下图显示了在认证和后续执行信标负载时的预期输出。

在这种情况下，操作员会收到一个回调，指示作为管理员用户在高完整性模式下运行的信标已成功执行。检查与生成的信标相关的权限，我们可以看到我们现在在主机上拥有管理权限，如下所示。

我们现在可以使用“socks stop”和“rportfwd stop 80”命令关闭SOCKS代理和远程端口转发，如下图所示，利用完成。攻击者可能希望以管理员用户身份在主机上建立持久性并删除关联的 RBCD 配置，以避免在环境中留下配置更改的残余。

与 Kerberos 相关的常见错误

运营商试图执行“传递票证”或其他基于 Kerberos 的攻击的常见错误是指定 IP 地址或缩写主机名，而不是服务主体名称中指定的值（通常是完整的非缩写主机名） . 这个错误如下图所示。操作员指定了 IP 地址 (192.168.184.144)，而不是与生成的 TGS 票证 (DESKTOP-KOERA35.CONTOSO.LOCAL) 关联的服务主体名称中指定的完整主机名。

我们观察到的另一个常见错误是，操作员可能会尝试使用 Rubeus 从主机生成新的信标，以将执行 S4U 时检索到的 TGS 票证导入其当前登录会话。虽然这种技术在针对其他主机时有效，但在尝试使用来自同一主机的 WMI 执行信标时似乎没有执行“完全网络登录”。相反，会利用与流程关联的安全令牌。该结果如下图所示。即使“管理员”用户的 TGS 令牌与他们的登录会话相关，辅助信标仍以“JSMITH”用户的身份产生。为了避免遇到这个问题，我们必须通过使用 SOCKS 将 Impacket 代理到主机来执行完整的网络登录。

整治指导

禁用对 msDS-AllowedToActOnBehalfOfOtherIdentity 字段的写访问似乎是一种有效的权宜之计，可以阻止利用 [1]。但是，此控制一般不能有效地修复 LDAP 中继攻击，仅适用于计算机帐户接管情况。执行 LDAP 签名和 LDAP 通道绑定是一般补救 LDAP 中继攻击风险的最有效的长期措施 [7]。

还存在充分的机会来实施专注于检测基于资源的约束委派或 LDAP 中继攻击的高保真检测。在某些环境中，额外的检测措施可能比实施进一步的技术控制更可取。例如，组织可能会利用许多不支持 LDAP 签名或 LDAP 通道绑定的第三方应用程序，从而使修复变得困难。

防御者可以考虑实施一个新的系统审计控制列表 (SACL)，旨在检测对“msDS-AllowedToActOnBehalfOfOtherIdentity”字段的写入。在大多数环境中，基于资源的约束委派的合法用例非常少见。此外，包括 RBCD 在内的 Kerberos 委托通常仅由服务器使用，因此防御者应仔细考虑员工工作站计算机帐户对“msDS-AllowedToActOnBehalfOfOtherIdentity”属性的任何修改。

截至 2020 年 3 月，Microsoft 还支持启用可选的审核设置来审核 LDAP 签名和 LDAP 通道绑定 [10]。可以利用事件 ID 2889 和事件 ID 3039 来识别对 LDAP 进行身份验证的系统，而无需利用通道绑定或 LDAP 签名 [10]。在不支持这些措施的情况下，防御者可能会构建一个运行第三方应用程序的已知主机列表。可以调查与此已知基线的任何偏差，以识别潜在的 LDAP 中继攻击。

结论

本文介绍了在与适当的身份验证原语结合使用时，基于资源的约束委派 (RBCD) 允许本地权限提升（以及潜在的远程代码执行）的方法。我们还介绍了运营商可以使用 Cobalt Strike 执行网络旋转的标准方法。对于从内部渗透测试过渡到红队操作的工程师来说，这个领域经常很棘手，因为通过 Cobalt Strike 而不是客户提供的基于 Linux 的跳转主机使用这些工具很复杂。