使用 krbrelayx 和 mitm6 通过 DNS 中继 Kerbeos

前言

我喜欢的一件事是，当我认为我很好地理解了一个主题，然后有人证明我完全错了。这或多或少发生在 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 角色的域控制器

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

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

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

滥用 DNS 身份验证

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

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

这最初打动我的原因有两个：

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

解决了这两个问题后，没有什么能真正阻止我们进入假 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 记录，这将是响应主机名中的权威名称服务器，这将允许受害者为我们的目标请求 Kerberos 服务票证，而不是合法的 DNS 服务器

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

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

攻击示例

让我们看看实际情况如何，首先我们设置 krbrelayx ，指定 AD CS 主机（我实验室中的 adscert.internal.corp ）作为目标，并指定接口的 IPv4 地址作为绑定的接口DNS 服务器到，这可以防止循环监听通常使用的循环，例如：Ubuntu Conflicting DNS server back to adapter

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 elayx 的 DNS 服务器发送到 krbr，该服务器接受并转发到 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 的最安全方法是阻止 DHCPv6 流量和 Windows 防火墙中的传入路由器广告通过组策略，完全禁用 IPv6 可能会产生不必要的副作用，预定义以下设置规则以阻止而不是允许阻止攻击起作用：

减少对 AD CS 的中继

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

相关工具

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

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