前言

我喜欢的一件事是当我认为我很好地理解了一个话题，然后有人证明我完全错了。当 James Forshaw 发表一篇关于 Kerberos 中继的博客时，或多或少发生了这种情况，这反驳了我几年前不能中继 Kerberos 的结论. James 表明，有一些技巧可以使 Windows 对不同的服务主体名称 (SPN) 进行身份验证，而不是通常从客户端连接到的主机名派生的名称，这意味着 Kerberos 并不像我假设的那样完全防中继。这促使我研究了一些替代的滥用路径，包括我几年前研究过但永远无法工作的东西：中继 DNS 身份验证。当您能够使用 mitm6 通过 DHCPv6 欺骗来欺骗 DNS 服务器时，这一点尤其重要。在这种情况下，您可以让受害机器使用 Kerberos 及其机器帐户可靠地向您进行身份验证。此身份验证可以中继到任何不强制完整性的服务，例如基于 Active Directory 证书服务 (AD CS) http(s) 的注册，AD CS 中继。与使用 mitm6 中继 WPAD 身份验证相比，此技术更快、更可靠且侵入性更小，但当然需要使用 AD CS。这篇博客描述了这项技术的背景以及我对 krbrelayx 所做的更改，以支持这次真正的 Kerberos 中继。

基于 DNS 的 Kerberos

如果您熟悉 Kerberos，您就会知道 DNS 是拥有有效的 Kerberos 基础架构的关键组件。但是您知道 Active Directory 中的 DNS 还支持使用 Kerberos 在 DNS 上进行身份验证的操作吗？这是“安全动态更新”操作的一部分，用于使具有动态地址的网络客户端的 DNS 记录与其当前 IP 地址保持同步。下图显示了动态更新过程中涉及的步骤：

步骤如下（按照上面的数据包从上到下）。在此交换中，客户端是 Windows 10 工作站，服务器是具有 DNS 角色的域控制器。

1. 客户端查询其名称的授权开始 (SOA) 记录，该名称指示哪个服务器对客户端所在的域具有权威性。
2. 服务器使用授权的 DNS 服务器进行响应，在本例中为 DC icorp-dc.internal.corp。
3. 客户端尝试使用他们在区域中的名称对 A 记录进行动态更新internal.corp。
4. 服务器拒绝此动态更新，因为未提供身份验证。
5. 客户端使用TKEY查询来协商经过身份验证的查询的密钥。
6. 服务器回答TKEY资源记录，完成身份验证。
7. 客户端再次发送动态更新，但现在伴随着一条TSIG记录，该记录是使用在步骤 5 和 6 中建立的密钥的签名。
8. 服务器确认动态更新。新的 DNS 记录现已到位。

让我们仔细看看第 5 步和第 6 步。TKEY 查询实际上是通过 TCP 发送的，因为它比 UDP 允许的最大 512 字节大很多。这主要是因为相当大的 TKEY 附加记录，其中包含我们经常看到的用于 Kerberos 身份验证的结构：

事实证明，此查询包含完整的 GSSAPI 和 SPNEGO 结构，其中包含 Kerberos AP-REQ。这本质上是对服务的正常 Kerberos 身份验证流程。回复再次包含一个 GSSAPI 和 SPNEGO 结构，指示认证成功，并使用 AP-REP 回复。此 AP-REP 包含一个新的会话密钥，客户端可以使用该密钥通过TSIG记录签署其 DNS 查询。请注意，encAPRepPart通常使用只有客户端和服务器知道的会话密钥进行加密，但是因为我将测试域中各种系统的 Kerberos 密钥加载到 Wireshark 接受的密钥表中，我们可以解密整个交换以查看它包含。

此流程的概念相当简单（实际实现并非如此）。客户端使用 Kerberos 进行身份验证并安全地交换会话密钥，然后使用该会话密钥签署进一步的更新查询。服务器可以存储密钥和经过身份验证的用户/计算机，并以经过身份验证的方式处理更新，而不必将身份验证绑定到特定的 TCP 套接字，因为以后的查询可能通过 UDP 发送。

滥用 DNS 身份验证

如果我们能够拦截 DNS 查询，就有可能欺骗受害客户端向我们发送真实 DNS 服务器的 Kerberos 票证。这种拦截可以在默认的 Windows 配置中由同一 (V)LAN 中的任何系统使用mitm6 完成。mitm6 将自己宣传为 DNS 服务器，这意味着受害者将发送SOA到我们的假服务器，如果我们拒绝他们的动态更新，则使用 Kerberos 进行身份验证。现在这有点棘手。通常 DNS 服务器角色将在域控制器上运行。因此，DNS 服务的服务票证已经适用于在 DC 上运行的服务，因为它们使用相同的帐户，我们可以更改票证中的服务名称。这意味着我们可以将此票证中继到例如 LDAP。但是，如果我们仔细查看 TKEY 查询中的身份验证器，我们会看到设置了请求完整性（签名）的标志。

这将自动触发 LDAP 签名，这会使整个攻击失败，因为如果没有在每条消息上提供有效的加密签名，我们之后就无法与 LDAP 交互。我们无法生成此签名，因为我们转发了身份验证并且实际上并不拥有解密服务票证和提取会话密钥所需的 Kerberos 密钥。

这最初让我碰壁有两个原因：

1. 当时没有任何已知的默认高价值服务会接受设置了完整性标志的身份验证，但不会在协议级别强制执行它。
2. 客户端专门请求他们在其 Kerberos 票证请求中使用的 SPN 中的“dns”服务类。此 SPN 仅在实际的 DNS 服务器上设置，因此要中继到的合法主机的数量非常少。

在阅读了 James 的博客后重温这一点，我意识到这些都不是当今知识的问题：

1. 由于 AD CS 研究是由 Lee Christensen 和 Will Schroeder发表的，因此我们有一个高价值的端点，它存在于大多数 AD 环境中，并为受害者提供代码执行可能性，如我在上一篇关于 AD CS 中继的博客中所述。
2. 正如 James 在他的博客中所描述的，许多服务类实际上会隐式映射到 HOST 类。事实证明，这包括 DNS，因此当我们的受害者请求 DNS 服务的票证时，这实际上适用于具有 HOST SPN 的任何帐户。这是默认在域中的所有计算机帐户上设置的，因此可以针对在这些帐户下运行的任何服务。

解决了这两个问题后，没有什么能真正阻止我们将我们在假 DNS 服务器上收到的 Kerberos 身份验证转发到 AD CS。完成后，我们可以为我们转发的计算机帐户申请证书，并使用我在之前的博客中谈到的 NT 哈希恢复技术或 S4U2Self 技巧。使用这些技术，我们可以SYSTEM访问受害计算机，这有效地使其成为可靠的 RCE，只要 AD CS http 端点可用于中继。

对 krbrelayx 和 mitm6 的更改

最初，krbrelayx 并不是真正的中继工具。相反，它通过使用不受约束的委派配置（系统）帐户来捕获 Kerberos TGT，并且以与 ntlmrelayx 相同的方式使用这些 TGT 可以使用传入的 NTLM 身份验证。由于现在有一个实际中继 Kerberos 身份验证的用例，因此我更新了 krbrelayx 中的功能，使其可以在中继模式下运行，而不是在无约束委托模式下运行。如果您未指定任何可用于从传入的 Kerberos 身份验证中提取信息的 NT 散列或 AES 密钥，它实际上将默认为此模式。简而言之，krbrelayx 现在可用于中继 Kerberos 身份验证，但仅支持中继到 HTTP 和 LDAP。至于 mitm6，我添加了指定中继目标的选项，当受害者询问 SOA 记录时，这将是权威名称服务器响应中的主机名。这将使受害者为我们的目标服务而不是合法的 DNS 服务器请求 Kerberos 服务票证。

需要注意的一点是，当目标 AD CS 服务器不是受害者用于 Kerberos 操作的 DC 时，这种方法效果最好。如果它们位于同一主机上（例如在较小的或实验室环境中），同时针对 KDC 和 AD CS 服务器的服务器，可能会导致受害者将其 Kerberos 票证请求 (TGS-REQ) 发送给您而不是 DC。虽然您可以代理此流量，但这超出了本项目的范围，您最终可能无法获得任何身份验证数据。

我们必须克服最后一个障碍。Kerberos AP-REQ 实际上并没有告诉我们哪个用户在进行身份验证，这仅在 Authenticator 的加密部分中指定。所以我们不知道哪个用户或机器帐户正在向我们进行身份验证。幸运的是，这在默认的 AD CS 模板方案中并不重要，因为它们允许将任何名称指定为 CN，并且无论如何它都会被 Active Directory 中的名称覆盖。然而，为了获得最佳结果，我建议您使用 mitm6 将攻击范围限定在一台主机上，并--victim在 krbrelayx 中指定该主机名，以便正确填写字段。

攻击示例

让我们看看这在实践中的样子。首先我们设置 krbrelayx，将 AD CS 主机（在我的实验室中adscert.internal.corp）指定为目标，并将接口的 IPv4 地址指定为绑定 DNS 服务器的接口。这可以防止与通常在例如 Ubuntu 上侦听环回适配器的 DNS 服务器发生冲突。

sudo krbrelayx.py --target http://adscert.internal.corp/certsrv/ -ip 192.168.111.80 --victim icorp-w10.internal.corp --adcs --template Machine

然后我们设置 mitm6，使用 AD CS 主机的名称作为中继目标：

sudo mitm6 --domain internal.corp --host-allowlist icorp-w10.internal.corp --relay adscert.internal.corp -v

我们等待受害者获得 IPv6 地址并连接到我们的恶意服务器：

屏幕截图显示受害者试图更新他们的 DNS 记录，由于缺乏身份验证，我们拒绝这样做。身份验证通过 TCP 发送到 krbrelayx 的 DNS 服务器，后者接受并转发到 AD CS：

在线上，我们看到了预期的流程：

• 受害者 ( 192.168.111.73) 查询其主机名的 SOA 记录。
• 我们指出我们的流氓 DNS 服务器是权威名称服务器，受害者将向其发送动态更新查询。
• 该查询被 mitm6 拒绝，这将向受害者表明他们需要对他们的查询进行身份验证。
• 客户端与 KDC 对话以获取我们指定的服务的 Kerberos 票证。
• 客户端与 krbrelayx 建立 TCP 连接并发送包含 Kerberos 票证的 TKEY 查询。
• 票证被转发到 AD CS 主机，从而导致我们的身份验证成功并颁发证书。

有了这个证书，我们可以使用PKINITtools（或Windows 上的Rubeus）使用 Kerberos 进行身份验证并模拟域管理员来访问我们的受害者（在本例中icorp-w10）：

python gettgtpkinit.py -pfx-base64 MIIRFQIBA..cut...lODSghScECP5hGFE3PXoz internal.corp/icorp-w10$ icorp-w10.ccache

使用 smbclient.py 我们可以列出 C$ 驱动器以证明我们具有管理员访问权限：

此技术滥用 Windows 和 Active Directory 中的不安全默认设置。这里的主要问题是 Windows 对 IPv6 的偏好，以及 AD CS Web 应用程序的不良安全默认设置。这些可以通过以下方式缓解：

缓解 mitm6

mitm6 滥用了这样一个事实，即即使在仅 IPv4 的环境中，Windows 也会查询 IPv6 地址。如果您不在内部使用 IPv6，则阻止 mitm6 的最安全方法是通过组策略在 Windows 防火墙中阻止 DHCPv6 流量和传入路由器广告。完全禁用 IPv6 可能会产生不必要的副作用。将以下预定义规则设置为阻止而不是允许可防止攻击起作用：

• （入站）核心网络 - IPv6 的动态主机配置协议（DHCPV6-In）
• （入站）核心网络 - 路由器广告 (ICMPv6-In)
• （出站）核心网络 - IPv6 的动态主机配置协议（DHCPV6-Out）

减轻对 AD CS 的中继

默认CertSrv站点不使用 TLS，在启用进一步保护之前应首先强制执行。使用有效证书启用 TLS 后，在 IIS 中为身份验证启用扩展保护将防止中继攻击。这应该在提供此服务的所有单个 CA 服务器上的 AD CS 的所有基于 Web 的注册功能上启用。

工具

本博客中提到的所有工具都可以作为 GitHub 上的开源工具获得。

• mitm6 https://github.com/dirkjanm/mitm6
• krbrelayx https://github.com/dirkjanm/krbrelayx
• PKINITtools https://github.com/dirkjanm/PKINITtools

感谢本博客中提到的所有人以及我之前关于这些主题的帖子，感谢他们对研究和工具的贡献。

译文申明

• 文章来源为近期阅读文章，质量尚可的，大部分较新，但也可能有老文章。
• 开卷有益，不求甚解，不需面面俱到，能学到一个小技巧就赚了。
• 译文仅供参考，具体内容表达以及含义, 以原文为准 (译文来自自动翻译)
• 如英文不错的，尽量阅读原文。(点击原文跳转)
• 每日早读基本自动化发布(不定期删除)，这是一项测试

最新动态: Follow Me

微信/微博：red4blue

公众号/知乎：blueteams