文章总结： 本文介绍了如何枚举MSSQL和HTTPS服务的EPA保护状态，以避免在NTLM中继攻击中浪费时间。文章详细解释了EPA的背景知识、不同服务器实现的细微差别，以及如何通过客户端错误来枚举EPA状态。作者发布了RelayInformer工具，包括Python实现和BOF，用于自动化EPA枚举过程，帮助攻击者更有效地评估中继攻击的可行性。
综合评分： 85
文章分类： 渗透测试,漏洞分析,网络安全,红队

少喷洒,多中继——枚举 MSSQL 和 HTTPS 服务的 EPA 保护状态

Nick Powers

securitainment

2025年11月30日 19:11
广东

TL;DR– 在设置和尝试攻击之前,了解你的 NTLM 中继是否会被 EPA 等完整性保护机制阻止非常重要。在本文中,我们分享如何为额外的协议 (MSSQL 和 HTTP) 解决这个问题,并发布 RelayInformer 工具来自动化该解决方案。

问题陈述

NTLM 中继攻击具有挑战性且耗时,尤其是当中继通过命令与控制 (C2) 进行时。在设置、强制认证、隧道和流量重定向之间,有大量变量需要考虑。如果目标服务配置了扩展身份验证保护 (EPA),所有这些设置和准备工作可能都会白费。

多年来,攻击性安全社区将 NTLM 中继到 LDAPS,判断 EPA 强制执行的唯一指标就是中继成功或失败。这在一段时间内是”可以接受的”,因为 EPA 强制执行并不常见,但现在情况已不再如此,我们已有解决这个问题的方案。然而,对于其他已成为 NTLM 中继攻击日益流行目标的协议,我们仍然没有类似的解决方案。一些例子包括 MSSQL 和 HTTPS。

在本文中,我们将:

• 演示如何识别和枚举 MSSQL 和 IIS HTTP/S 的所有可能 EPA 设置的过程
• 提供一种方法论,使你能够在其他协议实现中识别 EPA 强制执行
• 指出流行服务器 (例如 IIS) 在 EPA 实现默认值方面的特性以及所暴露的额外攻击面
• 发布 RelayInformer——一个 Python 项目和多个 Beacon 对象文件 (BOF),用于对多种协议执行 EPA 枚举

不关心细节?请随意跳到工具发布 / 结论和关键要点部分。

为什么重要?

我们提到了 NTLM 中继到 LDAP 和 LDAPS 服务的流行性 (例如 KrbRelayUp风格的权限提升)。在过去五年中,在环境中配置 LDAP 签名和 LDAPS 上的 EPA 强制执行越来越常见。然而,从攻击角度来看,现有工具 (例如 LdapRelayScan、LdapSignCheck和 SharpLdapRelayScan) 提供了一种低成本机制来确定这些 NTLM 缓解措施是否存在,从而判断攻击路径是否值得追求。

相比之下,我们在 Misconfiguration Manager 的 TAKEOVER-1 攻击 (即对 SCCM 站点数据库的 MSSQL 服务进行 NTLM 中继) 方面取得了相当一致的成功,我们个人在生产环境中尚未见到站点数据库的 MSSQL 服务上启用 EPA 强制执行。我们预计这种情况将在不久的将来开始改变,因为 Microsoft 的 2024 年 12 月发布的 SCCM 增加了对 MSSQL EPA 的支持。

我们最初着手添加工具来覆盖 MSSQL 检查,最终演变为包括检查 Active Directory 证书服务 (ADCS) ESC8 保护。ESC8 自 2021 年 Certified Pre-Owned 白皮书发布以来一直为人所知,许多组织此后已对其进行了修复。大多数组织通过完全删除 ADCS Web 注册服务来做到这一点,尽管我们仍然偶尔会见到该服务,但直到现在还没有有效的方法来确定 EPA 是否保护了 IIS HTTP/S 站点。

EPA 背景和基础知识

介绍和基础

EPA 是攻击性安全社区中一个常被误解的协议,这也情有可原。协议可以通过多种方式利用这种保护,而服务器选择如何强制执行它的变化空间更大。然而,充分理解 EPA 非常重要,这样我们才能知道何时何地可能存在中继攻击面。

从高层次来看,EPA 是一种安全功能,用于保护身份验证机制 (如 NTLM 和 Kerberos) 的完整性。它通过在客户端将身份验证绑定到预期的通道和 / 或服务,然后在服务器端验证该绑定来实现这一点。跨服务器实现的 EPA 实现通常由三个强制执行级别组成:

• 禁用 / 从不
• 允许 / 接受 / 支持时
• 必需

EPA 的实现通过通道绑定、服务绑定或两者的某种组合来进行。通道绑定通过将来自底层安全通道的唯一数据 (例如 TLS 会话标识符或加密证明) 合并到身份验证交换中来工作,确保双方验证它们在同一受保护通道上运行。服务绑定通过将目标服务的服务主体名称 (SPN) 的验证作为身份验证过程的一部分来工作。一个常见的误解是 EPA = 通道绑定,但事实并非如此。对于某些服务器,就 EPA 而言,可能只验证通道绑定 (例如域控制器 [DC] 上的 LDAPS)。这是有道理的,因为未加密的连接已经通过服务器签名具有完整性保护。然而,情况并非总是如此。服务绑定可用于验证执行 NTLMv2 身份验证的未加密连接的完整性。

当服务器从客户端验证 EPA 时,将检查客户端的 Type 3 NTLM 身份验证消息中的以下属性 / 值 (AV) 对:

• 通道绑定—— MsvAvChannelBindings
• 服务绑定—— MsvAvTargetName

这些”绑定”在网络上是什么样子的?

一般来说,了解目标服务器关心哪些属性不仅对枚举策略有用;它还将告知我们何时可以期望强制认证或中毒的身份验证产生成功的中继。现代 Windows 安全支持提供程序接口 (SSPI) 在构建 NTLMv2 身份验证时默认包含 MsvAvChannelBindings 和 MsvAvTargetName AV 对,无论目标协议是否实际支持通道绑定。这种默认行为在理解如何枚举 EPA 强制执行时变得很重要。

因此,想象一下你刚刚强制执行 NTLM 身份验证以开始常见中继攻击,使用以下方式:

• PetitPotam 或 Printerbug 强制执行 NTLM 身份验证 (SMB 或 WebDAV)
• Responder 中毒广播流量,导致基于 SMB 的 NTLM 身份验证
• Mitm6 中毒 DHCPv6,导致 NTLM 身份验证

这些都将_通常_导致 Windows SSPI 启动 NTLMv2 身份验证流程,并 (默认情况下) 包含与 EPA 相关的 AV 对,即使值为 null。null 值仍然向服务器表明客户端支持 EPA。

简单来说,我什么时候可以进行中继?

• EPA = 禁用 / 从不

• 你通常应该能够使用 NTLM 中继进行定位,无论客户端对 EPA 的支持或使用的 NTLM 版本如何

• EPA = 允许 / 接受 / 支持时

• 你理论上可以进行 NTLM 中继,但常见的中继场景将不起作用,因为标准强制认证 / 中毒技术 (上述) 将导致添加与 EPA 相关的 AV 对,表明客户端对 EPA 的支持

• EPA = 必需

• NTLM 中继应该会通过验证 EPA 相关 AV 对中提供的值而被阻止

服务器实现的细微差别

如前所述,EPA 可以保护加密连接和未加密连接。对于加密连接,可以使用诸如 tls-server-end-point (IIS)、tls-unique (MSSQL) 和 tls-unique-for-telnet 等算法来实现通道绑定令牌。对于未加密连接,大多数 NTLMv2 客户端都包含服务绑定,其中包含目标服务的服务主体名称 (SPN)。那么当在服务器上以某种方式配置 EPA 时,默认情况下应该对两者都有保护……对吗?

MSSQL EPA 实现和默认值

MSSQL 服务器表现出预期的行为。MSSQL 服务器可以同时支持加密和未加密连接。当在 MSSQL 上启用可选的”强制加密”配置和 EPA (无论是”允许”还是”必需”) 时,该实现会直观地将保护应用于两种连接类型——但验证不同的绑定:

• 加密连接——通道绑定验证 (使用 tls-unique)
• 未加密连接——服务绑定验证

需要注意的重要一点是,在标准 MSSQL 服务对 EPA 的强制执行中,服务器默认同时支持通道和服务绑定。

虽然上面的保护场景相对简单,但在没有图形的情况下,跨不同配置检查哪个绑定会很快变得混乱。所以我们将慢慢构建这个图表来跟踪每个配置中哪种保护是重要的。

偏差——IIS EPA 实现和默认值

IIS 的 EPA 实现不太直接。来自 Synactiv 的 Pierre Milioni 和 Geoffrey Bertoli 发布了一篇关于这个主题的非常深入的博客,它比我们在这里更详细地涵盖了 IIS 的细微差别。总之,当在 IIS 管理器中启用 EPA 时,它将以通道绑定的形式_仅_将保护应用于加密的 HTTPS 服务。需要注意的是,IIS 站点可以有多个绑定,同时提供同一站点的 HTTPS 和 HTTP 版本 (有些管理员确实以这种方式配置 ADCS Web 注册服务)。这意味着当使用 IIS 管理器 GUI 配置 EPA 时,不会对普通 HTTP 站点绑定应用保护。

可以通过手动编辑站点的 applicationHost.config文件并将 extendedProtection标记的 flag属性修改为 Synactiv 博客中概述的各种值,以服务绑定的形式将保护应用于未加密服务。正确设置后,这将为未加密和加密站点绑定启用保护;然而,保护两者的是服务绑定。

加密站点绑定的服务绑定保护有些不直观,虽然很可能是边缘情况,但在执行 EPA 强制执行判断时,我们需要记住这是可能的。

基于客户端错误的枚举策略

当我们了解目标服务器期望什么 AV 对以及何时期望时,在大多数情况下,我们可以使用它来枚举 EPA 的所有强制执行级别。我们可以在加密或未加密身份验证尝试期间操纵相关的 AV 对。这就是如何使用唯一错误从未经身份验证的角度确定 LDAPS EPA 的所有三个强制执行级别。

启用 EPA 枚举的关键洞察是,服务器对 EPA 验证失败的响应通常与标准身份验证尝试不同。通过控制客户端并操纵相关的 AV 对,我们可以识别这些唯一响应并确定强制执行级别。

我们的枚举策略包括:

1. 使用有效身份验证建立基线响应
2. 系统地操纵 MsvAvChannelBindings 和 MsvAvTargetName 值
3. 观察服务器响应的差异 (错误代码、消息、时间)
4. 基于响应模式推断 EPA 强制执行

MSSQL EPA 枚举

MSSQL 服务器可以支持未加密和加密身份验证,但可以选择配置为”强制加密”以仅允许加密连接。连接的加密状态决定在服务器端是使用通道绑定还是服务绑定来验证 EPA。有了这些知识,我们可以通过操纵 AV 对来运行测试用例以寻找唯一响应。

正如我们在上面看到的,当在对目标 MSSQL 服务的身份验证尝试中使用有效域凭据时 (无论凭据是否有权访问数据库),会识别出唯一响应。

因此,可以使用以下逻辑来确定所有 EPA 强制执行级别:

1. 使用正确的通道绑定和服务绑定验证提供的凭据

2. 发送 TDS 预登录消息以确定加密要求

3. 如果需要加密

4. 使用无效的通道绑定 AV 对值发送身份验证

5. 在没有通道绑定 AV 对的情况下发送身份验证

6. 如果不需要加密

7. 使用无效的目标名称 AV 对值发送身份验证

8. 在没有目标名称 AV 对的情况下发送身份验证

因此,使用_任何有效的域凭据_,我们可以确定目标 MSSQL 服务器上 EPA 的所有潜在强制执行级别。

注意:已识别出未经身份验证枚举 EPA 强制执行的边缘情况,例如当 MSSQL 配置了 GUEST 帐户时 (会出现错误的唯一性)。为防止混淆,我们选择实施更通用的方法。

HTTP/S EPA 枚举

对于 HTTP/S 的枚举,我们采用与 MSSQL 类似的方法。然而,为了使该技术的实现能够通用地应用于多个 HTTP/S 服务,同时仍然考虑到诸如 IIS 之类的偏差,我们使用 HTTP 200 (即”OK”) 响应代码作为基本成功案例。

这种方法的好处是能够在多个 HTTP/S 服务器实现中通用应用它,但缺点是需要能够产生 200 响应的凭据材料来确定强制执行级别。对于常见用例来说,这应该是一个现实的要求,例如默认情况下授予域用户访问权限的 ADCS Web 注册。

确定 HTTP/S 的确切 EPA 强制执行级别的逻辑,类似于 MSSQL 但也考虑了前面提到的偏差,如下所示:

1. 使用正确的通道绑定和服务绑定验证提供的凭据

2. 如果目标服务是 HTTPS

3. 使用无效的通道绑定 AV 对值发送身份验证

4. 在没有通道绑定 AV 对的情况下发送身份验证

5. 使用无效的目标名称 AV 对值发送身份验证

6. 在没有目标名称 AV 对的情况下发送身份验证

7. 如果目标服务是 HTTP

8. 使用无效的目标名称 AV 对值发送身份验证

9. 在没有目标名称 AV 对的情况下发送身份验证

因此,使用可以成功验证到目标 HTTP/S 服务的任何凭据,你可以确定 EPA 强制执行的确切级别。

注意:已识别出可以在没有凭据材料的情况下枚举 EPA 的边缘情况,特别是针对具有基于时间枚举的 IIS。我们选择了一种适用于更多潜在目标服务器的方法。

工具发布

RelayInformer 现已在 GitHub 上发布,作为 Python 工具和一系列 BOF,以便理想地适合你首选的攻击性工作流程。

RelayInformer Python

Python 实现包括从 LdapRelayScan 移植的功能 (确定 LDAPS 通道绑定强制执行和 LDAP 服务器签名要求的能力),以及用于枚举 MSSQL 和 HTTP 的 EPA 的新模块。

对于 MSSQL,无论加密要求如何,都可以确定所有 EPA 强制执行级别:

以下演示了针对 ADCS Web 注册服务的 HTTP 和 HTTPS 枚举:

注意:如果服务绑定或通道绑定不是 DISABLED,它可能会影响你的 NTLM 中继。有关更多详细信息,请参阅强制执行设置 (常见客户端行为)部分。

以下演示了从未经身份验证的角度检查 LDAPS EPA 强制执行的移植能力,以及在提供凭据材料时检查 LDAP 服务器签名:

RelayInformer BOF

GitHub 存储库还包含 EPA 检查的 BOF 实现。BOF 利用当前登录会话,不接受 NTLM 身份验证的显式凭据。由于依赖于 Windows SSP,BOF 可以确定目标服务是否禁用了 EPA,但无法区分服务器端_必需_和_允许 / 接受_设置,因为相关的 AV 对将始终存在于 NTLM Type 3 消息中。

BOF 在 SSPICLI API 上设置硬件断点并使用异常处理程序来操纵调用参数以:

1. 强制执行 NTLM 身份验证,因为枚举方法围绕 NTLM AV 对操纵
2. 根据正在执行的测试使 MsvAvChannelBindings 和 MsvAvTargetName 无效

可以在 RelayInformer BOF README 上找到有关内部工作原理的更深入研究。来自 Cobalt Strike 的示例用法,针对存在 HTTP 和 HTTPS 站点绑定且通过 IIS 管理器 GUI 配置 EPA 的 ADCS Web 注册服务:

针对需要加密和 EPA 的 MSSQL 服务的示例用法:

OPSEC 注意事项

对于需要凭据材料进行枚举的技术 (基本上除了 LDAPS 之外的所有技术),将生成登录失败事件。尽管使用的密码有效,但由于服务 / 通道绑定强制执行而失败的登录尝试仍会生成 4625 事件 (帐户登录失败)。它不会增加用户的 badPwdCount 值。

结论和关键要点

我们现在可以从攻击性角度轻松枚举 MSSQL 和 HTTP/S (NTLM 中继的流行目标) 的 EPA 强制执行。理想情况下,这将:

1. 在分配时间准备攻击之前更好地告知何时可能进行 NTLM 中继
2. 在执行 NTLM 中继时更清楚地演示漏洞的根本原因

提醒一下何时需要经过身份验证的上下文,以下是 EPA 枚举场景的摘要:

• LDAPS——仍然不需要身份验证

• MSSQL——需要任何有效凭据,不需要 DB 访问权限

• 如果你在主机上进行身份验证,BOF 补充凭据要求

• HTTP/S——需要可以验证 (200) 到目标服务的凭据

• 如果你在主机上进行身份验证,BOF 补充凭据要求

我们希望所描述的方法将有助于未来的研究识别 EPA 实现中的差距以及其他 EPA 枚举机会。

防御者指南

如果你有不支持 EPA 的遗留系统或应用程序,将服务配置为将 EPA 强制执行为”允许” / “支持时” / “接受”仍然可以为中继攻击提供实质性保护。这是由于现代 Windows SSPI 默认包含 EPA 相关 AV 对,如强制执行设置 (常见客户端行为) 中所讨论的。配置此设置也降低了为不支持 EPA 的遗留应用或系统破坏身份验证的风险,因为该身份验证仍将被允许。

理想情况下,EPA 设置为”必需”以完全禁止不包含适当完整性值的客户端。首先在仅审核模式下强制执行 EPA 将有助于识别在启用强制执行之前是否存在将受此设置影响的遗留身份验证尝试。

参考文献和致谢

• Alex Demine——MSSQL EPA 研究的初步工作
• @Defte*——”A journey implementation Channel Binding on MSSQLClient.py”
• @lowercase_drm——LDAP3 库中 LDAP 通道绑定的早期开源实现
• Pierre Milioni & Geoffrey Bertoli——”A study on Windows HTTP Authentication (Part II)
• Adam Crosser——”Relaying to ADFS Attacks”
• 为 Impacket、msldap、LdapSignCheck 等库做出贡献的开源开发者

Less Praying More Relaying – Enumerating EPA Enforcement for MSSQL and HTTPS

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

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：securitainment Nick Powers《少喷洒,多中继——枚举 MSSQL 和 HTTPS 服务的 EPA 保护状态》