滥用多播投毒通过 HTTP 使用 Responder 和 krbrelayx 进行预认证的 Kerberos 中继

1. 简介

Kerberos 中继载体最近引起了相当多的关注，这可能与越来越多的强化 Active Directory 环境有关，这些环境限制其网络上的 NTLM 身份验证，从而防止众所周知的 NTLM 中继攻击。

尽管与 NTLM 技术相比，Kerberos 中继技术有其自身的挑战和局限性，但它们仍然有效并导致高影响的权限提升场景。许多与 Kerberos 中继相关的研究源自James Forshaw 于 2021 年发表的原始研究。到目前为止，研究人员已经发布了两种 Kerberos 中继载体的实现：通过 DNS 的 Kerberos 中继和通过 SMB 的 Kerberos 中继。

本文提出了第三个 Kerberos 中继载体的实现，该载体再次由 James Forshaw 发现：通过多播毒化在 HTTP 上进行 Kerberos 中继。这种替代方法与 DNS/SMB 方法具有不同的先决条件，并且可以在无法利用这两个方法的特定情况下加以利用。

本文的第一部分提供了有关 Kerberos 中继的一些提醒。第二部分介绍了替代的 HTTP 中继向量以及使用Responder和krbrelayx 的建议实现。第三部分描述了所述攻击媒介的用例和局限性。

2. Kerberos 中继：最新技术

我们假设读者了解标准 Kerberos 身份验证流程。如果不是这种情况，您可以参考以下深入介绍该主题的文章。如果您已经熟悉 Kerberos 中继概念，请直接跳至第 3 部分。

• 对于 Kerberos 来说，身份验证过程中的最后一个请求（以及决定是否授予用户访问服务的权限的请求）就是AP-REQ请求。AP-REQ由两个元素组成：

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

身份验证器，它是使用与 相关联的会话密钥加密的数据块ST。所述会话密钥由 中的 KDC 返回给用户TGS-REP，并使用只有用户才能访问的票证授予票证会话密钥进行加密。

当服务收到时AP-REQ，它将解密ST，提取会话密钥，并验证身份验证器。如果成功，则允许访问该服务。事实上，只有请求它的合法用户ST才能使用其秘密来检索会话密钥并构建有效的身份验证器。

AP-REQ没有什么可以从本质上阻止针对Kerberos 协议中的请求的中继攻击。如果攻击者能够拦截AP-REQ合法客户端向目标服务发送的有效消息，则可以使用它来验证该目标服务是否为客户端。仍需注意的是，与 NTLM 中继攻击类似，AP-REQ只有当目标服务不强制执行完整性要求时，中继才会起作用，例如通过签名。事实上，如果是这种情况，通过中继的身份验证可能会成功，但后续通信将会失败，因为攻击者不拥有签署数据包所需的会话密钥。

AP-REQ传递信息时应该考虑额外的挑战。包含AP-REQ使用ST SPN 中指定的目标主机的秘密加密的。例如，ST请求的CIFS/ad01-srv1SPN 将使用机器账户的密钥加密ad01-srv1$。

因此，想要针对敏感服务发起 Kerberos 中继攻击的攻击者应该以某种方式：

• 强迫受害者构建一个使用攻击者想要中继身份验证的主机的秘密加密的AP-REQ a 。ST

• 强迫受害者将上述内容发送AP-REQ给攻击者的机器而不是合法主机。

Kerberos 中继攻击的视觉表示。

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

据我们所知，目前没有任何服务执行检查以确保 SPN 的 CLASS 确实与其特定服务相匹配。这稍微放宽了 Kerberos 中继要求，因为攻击者只应强迫受害者AP-REQ为正确的目标主机构建地址，而不关心客户端前缀的 SPN 的 CLASS。

目前，公共工具中已记录两种执行 Kerberos 中继的技术：

• 通过 DNS 进行 Kerberos 中继：第一个利用DNS安全动态更新在 Active Directory 中的工作方式。它是由Dirk-jan Mollema发现的，并在mitm6 / krbrelayx中实现。

• 通过 SMB 进行 Kerberos 中继：第二个技巧是由 James Forshaw 发现的，它滥用了 SMB 客户端在请求时构建 SPN 的方式ST。存在几种实现，并且Hugo Vincent 将其集成到 krbrelayx 中。

2. 利用多播投毒通过 HTTP 执行 Kerberos 中继：通过 Responder 和 krbrelayx 实现

James Forshaw 在 2021 年发表的研究提到了另一个 Kerberos 中继向量，据我们所知，该向量目前尚未在 Active Directory 攻击工具中实现。本节对上述向量进行了描述，然后提出了通过Responder和krbrelayx来实现的方法。

理论

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

• 浏览器（Internet Explorer、Edge、Google Chrome、Firefox）

• WebDav Web客户端

• .NET 框架

这些客户端都具有相同的有趣怪癖：当 Web 服务器请求 Kerberos 身份验证时，它们不会使用目标 URL 来确定ST应检索的 SPN，而是使用DNS 响应的答案名称。

正常情况下，这两者应该是一致的。例如，如果用户浏览到http://internalserver/loginURL，HTTP 客户端应该对 执行 DNS 查询internalserver，并且响应应该返回 的答案名称internalserver。如果 Web 服务器随后要求进行 Kerberos 身份验证，HTTP 客户端将要求提供STSPN ，并从中HTTP/internalserver构建一个。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. 受害者请求ST中继目标的 SPN。然后将结果发送AP-REQ到攻击者的 Web 服务器。

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

b.执行

当谈到多播毒化时，Responder是首选的攻击工具。这就是为什么为了实施所描述的攻击，我们提交了一个拉取请求，通过标志向 Responder 添加一个参数。该参数允许指定在 LLMNR 响应中返回的任意答案名称。-N

关于接收的中继部分AP-REQ，我们决定使用出色的krbrelayx工具。我们提交了一个拉取请求，将中继逻辑添加到 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 身份验证。此外，攻击者未经身份验证。让我们执行一次经典的 ESC8 攻击，但通过 HTTP 中继 Kerberos 身份验证。第一个例子将通过机会性地响应失败的名称解析来演示攻击，而第二个示例将依赖于 WebDav 身份验证强制。

• 机会性地响应失败的名称解析

首先，攻击者使用标志运行 Responder -N，表明 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 出现了拼写错误。中毒的 LLMNR响应将发送给客户端，其答案名称为ad01-pki 。Responder 中会出现以下日志。

[*][LLMNR]Poisonedanswersenttofe80::21bb:3ade:e5b8:135bfornametpyo (spoofedanswernamead01-pki)
[*][LLMNR]Poisonedanswersentto 192.168.123.18fornametpyo (spoofedanswernamead01-pki)
[*][LLMNR]Poisonedanswersenttofe80::21bb:3ade:e5b8:135bfornametpyo (spoofedanswernamead01-pki)
[*][LLMNR]Poisonedanswersentto 192.168.123.18fornametpyo (spoofedanswernamead01-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 from192.168.123.18, prompting for authentication
[*] HTTPD: Client requested path: /aa
[*] HTTPD: Received connection from192.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 响应。

LLMNR 回应带有欺骗性的答案名称。

• WebDav 身份验证强制

同样的利用场景也适用于 WebDav 身份验证强制。这使得攻击者无需依赖于拼写错误或配置错误就可以瞄准多播范围内的特定主机 - 但需要身份验证和活动的 WebClient 服务。以下屏幕截图使用PetitPotam工具从ad01-wks1机器向不存在的主机名(1)触发 WebDav 请求IDONOTEXIST。响应者返回 LLMNR 响应，欺骗答案名称 (2)，krbrelayx 处理中继部分 (3)。

通过 WebDav 强制利用 Kerberos 中继。

3. 用例和限制

所提出的中继技术的主要优点是它可以通过标准多播中毒在无需身份验证的情况下执行。因此，当无法利用 mitm6 等攻击媒介时，它可以作为通过 DNS 进行 Kerberos 中继的可行替代方案。

虽然通过 SMB 中继 Kerberos 更可靠，因为它可以潜在地针对多播范围之外的任意机器，但它仍然需要身份验证，要么添加包含CREDENTIAL_TARGET_INFORMATION结构的 DNS 记录，要么至少强制机器尝试访问包含结构的主机名，CREDENTIAL_TARGET_INFORMATION然后再使用本地 DNS 解析协议进行回复。请注意，答案名称技巧不适用于 SMB 客户端，这意味着不可能在 LLMNR 中机会性地使用包含   CREDENTIAL_TARGET_INFORMATION结构的答案名称来回答 SMB 中不存在的主机名。

所提出的技术限制在于，中继受害者必须位于攻击者的多播范围内，并且网络上必须启用 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
.0000... .... .... = Opcode: Standard query (0)
        .... .1.. .... .... = Authoritative: Server is an authority for domain
        .... ..0. .... .... = Truncated: Message isnot 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, classIN, addr 192.168.123.16
            Name: ad01-pki.corp.com
            Type: A (1) (Host Address)
.000000000000001 = 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 解析失败。尽管该协议实现了事务 ID，并且客户端可以使用它来将查询与欺骗响应链接起来，但 NBTNS 的情况也是如此。

我们尝试了各种技巧，试图通过涉及 CNAMES 和附加记录的 mDNS 和 NBTNS 实施攻击，但没有成功。我们当然希望证明我们在这个问题上是错误的。

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

不幸的是事实并非如此。当使用协商安全包（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 中，构成 Kerberos 中继的相关目标的一些标准高价值 HTTP 服务包括：

• ADCS Web 注册端点。

• SCCM 管理点和 SCCM 分发点。

结论

可以将旧的攻击原语（例如本地名称解析投毒）与最新的身份验证中继技术一起利用，以便在 Active Directory 环境中创建新的攻击路径。通过 HTTP 执行 Kerberos 中继可能会让攻击者在域中站稳脚跟并开始横向移动。人们甚至可以想象利用通过 HTTP 中继的 Kerberos 通过 ESC8 攻击获得对域的经过身份验证的访问权限，然后通过 SMB 中继 Kerberos 利用相同的漏洞来破坏域控制器。

保护 Active Directory 域免受文章中描述的攻击相当简单。如果没有功能需要（大多数情况下都是如此），则应禁用本地名称解析协议（例如 LLMNR），并且应在 Active Directory 服务级别实施反中继机制。更具体地说，关于 HTTP 服务，建议强制使用 TLS 并启用身份验证的扩展保护。

原文始发于微信公众号（Ots安全）：滥用多播投毒通过 HTTP 使用 Responder 和 krbrelayx 进行预认证的 Kerberos 中继