最近James Forshaw发表的关于Kerberos中继的博客推翻了以前不能中继Kerberos的结论。其中介绍了一些技巧，可以将Windows身份验证转换为不同的服务主体名(Service Principal Name, SPN)，而不是通常从客户机连接的主机名派生出来的服务主体名，这意味着Kerberos并非如我所设想的那样是完全可靠的。这促使我去寻找一些其他的滥用途径，包括我在几年前研究过但从未付诸实践的做法——中继DNS认证。当你能够使用mitm6通过DHCPv6欺骗来欺骗DNS服务器时，这一点尤其重要。在这个场景中，你可以使用Kerberos和它们的设备帐户对受害设备进行可靠的身份验证。这种身份验证可以中继到任何不强制执行完整性的服务，例如Active Directory证书服务(AD CS)基于http(s)的注册，这反过来使它可以在该主机上以SYSTEM的形式执行代码，正如我在AD CS中继的博客中讨论的那样。与用mitm6中继WPAD身份验证相比，这种技术更快、更可靠、侵入性更小，但当然需要使用AD CS。这个博客描述了这项技术的背景，以及我对krbrelayx所做的更改，以便这次能够支持真实的Kerberos中继。

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

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

客户机在起始授权机构(SOA)记录中查询它的名称，这表明客户机所在的域的哪个服务器是授权的。

服务器响应授权的DNS服务器，在本例中是DC icorp-dc.internal.corp。

客户端尝试在区域 internal.corp 中使用其名称对 A 记录进行动态更新。

这个动态更新被服务器拒绝，因为没有提供身份验证。

客户端使用 TKEY 查询来协商经过身份验证的查询的密钥。

服务器以 TKEY 资源记录作为回复，完成身份验证。

客户端再次发送动态更新，但现在伴随着TSIG记录，这是使用步骤5和6中建立的密钥的签名。

服务器确认动态更新，新的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接受的keytab中，所以我们可以对整个交换进行解密，以查看它包含什么内容。

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

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

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

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

当时，没有任何已知的默认高值服务可以接受设置了完整性标志的身份验证，但不会在协议级别上强制它。

客户端专门请求他们在其 Kerberos 票证请求中使用的 SPN 中的“dns”服务类。此 SPN 仅在实际的 DNS 服务器上设置，因此要中继到的合法主机的数量非常少。

在阅读了James的博客后，我重新审视了这个问题：

由于AD CS研究由Lee Christensen和Will Schroeder发表，我们在大多数AD环境中都有一个高价值的端口，并提供了在受害者身上执行代码的可能性，正如我在上一篇关于AD CS中继的博客中所描述的那样。

正如James在他的博客中所描述的，许多服务类实际上会隐式地映射到HOST类。事实证明，这包括DNS，因此当受害者请求DNS服务的票据时，这实际上适用于任何带有HOST SPN的帐户。默认情况下，这是在域中的所有计算机帐户上设置的，因此可以针对在这些帐户下运行的任何服务。

解决了这两个问题后，我们就可以将在伪DNS服务器上接收到的Kerberos身份验证转发到AD CS。当这一切完成后，我们可以为我们中继的计算机帐户请求证书，并使用NT哈希恢复技术或S4U2Self技巧。使用这些技术，我们可以获得对受害计算机的SYSTEM访问权限，只要AD CS http端口可用来中继，这就有效地使其成为可靠的RCE。

最初，krbrelayx并不是一种真正的中继工具。相反，它通过使用不受约束的委托配置(系统)帐户来捕获Kerberos tgt，并且以与ntlmrelayx相同的方式使用这些tgt可以使用传入NTLM身份验证。由于现在有一个实际中转Kerberos身份验证的用例，所以我更新了krbrelayx中的功能，使其能够在中转模式而不是不受约束的委托模式下运行。如果你不指定任何NT哈希值或AES密钥(这些密钥可用于从传入的Kerberos身份验证中提取信息)，那么它实际上将默认使用这种模式。简而言之，现在可以使用krbrelayx中继Kerberos身份验证，尽管只支持中继到HTTP和LDAP。至于mitm6，我已经添加了指定中继目标的选项，当受害者询问查询SOA记录时，该目标将是授权命名服务器响应中的主机名。这将使受害者为我们的目标服务而不是合法的DNS服务器请求Kerberos服务票据。

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

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

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

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

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

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

我们看到了预期的流程：

受害者(192.168.111.73)查询其主机名的SOA记录。

我们指出我们的恶意DNS服务器是权威的名称服务器，受害者将向其发送动态更新查询。

该查询被mitm6拒绝，这将表明受害者需要验证他们的查询。

客户机与KDC对话，以获得我们所指示的服务的Kerberos票据。

客户端建立到krbrelayx的TCP连接，并发送包含Kerberos票据的TKEY查询。

该票据被转发到AD CS主机，从而导致我们的认证成功并颁发证书。

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

使用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 的注册功能上启用。

参考及来源：https://dirkjanm.io/ntlm-relaying-to-ad-certificate-services/