AD 提权-NTLM 中继攻击（诱导认证）

我醉欲眠卿且去，明朝有意抱琴来。

导航

• 0 前言
• 1 实验环境
• 2 SMB 转 SMB
• 3 SMB 转 LDAP
• 4 SMB 转 HTTP
• 5 HTTP 转 SMB
• 6 HTTP 转 LDAP
• 7 杂项

---

0、前言

NTLM 中继攻击的流程主要分为三个步骤：触发认证、中继攻击、后利用。其中，

• 触发认证又分为：主动强制认证、被动诱导认证；
• 中继攻击又包括：委派、ADCS 证书申请、影子凭证 等；
• 后利用 则根据 中继攻击 的不同，利用的方式亦有所不同。

主动强制认证常见的几个漏洞是：PeitiPotam、PrinterBug、DFSCoerce、ShadowCoerce、PrivExchange、Coercer。其中 PeitiPotam 漏洞无需提供域账户便可被检测和利用，因此它也是本文主要被使用的一种强制认证方法。

被动诱导认证：UNC 路径、恶意文档（Word、PDF）、图标文件（desktop.ini、scf 文件）、系统命令。

在这篇文章中，我们将 基于被动诱导认证 去探讨有关中继攻击的几种中继类型。例如，

• SMB 转 SMB：触发认证的是 SMB 协议，中继攻击使用的也是 SMB 协议。
• SMB 转 LDAP：触发认证的是 SMB 协议，但中继攻击使用的却是 LDAP 协议。
• SMB 转 HTTP：触发认证的是 SMB 协议，但中继攻击使用的却是 HTTP 协议。
• HTTP 转 SMB：触发认证的是 HTTP 协议，但中继攻击使用的却是 SMB 协议。
• HTTP 转 LDAP：触发认证的是 HTTP 协议，但中继攻击使用的却是 LDAP 协议。

以上最常见的中继类型是 SMB 转 SMB 和 SMB 转 LDAP，而有关 HTTP 相关的中继场景似乎都不太常见。

1、实验环境

• 域名 - skylark.com
• 主域控 - DC2012 - Windows 2012 R2 Standard - 192.168.56.50
• 备域控 - DC2013 - Windows 2012 R2 Standard - 192.168.56.51
• 域主机 - Win10 - Windows 10 专业版（22H2） - 192.168.56.14
• 域主机 - Win7 - Windows 7 旗舰版（SPK1） - 192.168.56.13
• Kali - 192.168.56.20
• 普通域用户 - user
• 域管理员用户 - admin

可以看到，在这个域环境中，主备域控均已开启 SMB 签名，而域主机均已关闭 SMB 签名。

注意：本实验中的所有 Windows 机器均未安装 CVE-2019-1040 漏洞的补丁，因此后文中 SMB 转 LDAP/HTTP 时 impacket-ntlmrelayx 工具的 --remove-mic 功能可被正常使用。

为了便于后文的说明，特需对各角色的称呼进行规范说明。例如：从 A 触发的认证凭证，经由 kali 转发被中继到了 B，那么 A 被称为触发者，B 被称为受害者，kali 则被称为攻击者。

2、SMB 转 SMB

在 NTLM 中继攻击的流程中，认证协议由 SMB 转 SMB 的成功，需要受害者机器的 SMB 签名处于关闭状态才行，而触发者机器的 SMB 签名状态开关与否都无所谓。

示例一：域主机触发去攻击域控

结果：失败！由于被攻击的域控主机（DC2012）的 SMB 签名处于开启状态，因此必定会失败。

示例二：域控触发去攻击域主机

结果：成功！由于被攻击的域主机（Win10）的 SMB 签名处于关闭状态，因此会成功。

注：如果对域控使用强制认证去攻击域主机，那么是否会成功呢？

测试实验未能成功，但认证提示的消息显示是成功的，只是会报 DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied 错误。该错误应该是权限不足的错误，而非服务不提供的错误。毕竟在上面示例二中使用诱导认证的时候是成功的，那说明 Win10 机器所提供的功能是有的，只是这个强制认证的账户（机器账户）权限太小。

个人猜测：在域环境下，只有机器自身的机器账户才拥有对自己机器的最高权限（SYSTEM），而其他机器账户哪怕是域控的机器账户，在非本机的机器看来，那就是一个普通的机器账户，不具备什么权限。【但主备域控之间好像比较特殊，互相的机器账户拥有对对方机器的最高权限。】

示例三：域控之间的触发和攻击

结果：失败！由于被攻击的域控主机（DC2012）的 SMB 签名处于开启状态，因此必定会失败。

示例四：域主机之间的触发和攻击

结果：成功！由于被攻击的域主机（Win10）的 SMB 签名处于关闭状态，因此必定会成功。

3、SMB 转 LDAP

在 NTLM 中继攻击的流程中，认证协议由 SMB 转 LDAP 的成功，与触发者和受害者机器上的 SMB 签名状态无关，但和目标机器是否安装了 CVE-2019-1040 漏洞的补丁息息相关，若未打补丁则此时只需在攻击者 kali 的 impacket-ntlmrelayx 命令中添加 --remove-mic 选项即可顺利进行中继。【出厂默认未安装此补丁的系统：Server 2016 及更早、部分 Win10 及更早】

示例一：域主机触发去攻击域控

可以看到，当在域主机（Win10）上分别以域管理员 admin 和普通域用户 user 的身份去触发中继认证时，admin 触发的攻击在域控上新建了一个特权账户，而 user 触发的攻击却只是在当前工作目录下转储了一些域中的信息。

结果：成功！

示例二：域控之间的触发和攻击

结果：成功！

4、SMB 转 HTTP

在 NTLM 中继攻击的流程中，认证协议由 SMB 转 HTTP 的成功，与触发者和受害者机器上的 SMB 签名状态无关，但和目标机器是否安装了 CVE-2019-1040 漏洞的补丁息息相关，若未打补丁则此时只需在攻击者 kali 的 impacket-ntlmrelayx 命令中添加 --remove-mic 选项即可顺利进行中继。【出厂默认未安装此补丁的系统：Server 2016 及更早、部分 Win10 及更早】

关于 SMB 转 HTTP 的示例，可参考《AD 提权-NTLM 中继攻击（强制认证）》这篇文章中有关“ADCS 证书申请”部分的利用。

5、HTTP 转 SMB

在 NTLM 中继攻击的流程中，认证协议由 HTTP 转 SMB 的成功，要求受害者机器上的 SMB 签名处于关闭状态才行，而触发者机器的 SMB 签名状态开关与否都无所谓。

示例一：域主机触发去攻击域控

浏览器访问网址所弹出的登录窗口，填写的是域用户的账户，也是被中继的凭证，该中继凭证和当前登录环境的用户无关。

结果：失败！由于被攻击的域控主机（DC2012）的 SMB 签名处于开启状态，因此必定会失败。

示例二：域控触发去攻击域主机

结果：成功！由于被攻击的域主机（Win10）的 SMB 签名处于关闭状态，因此会成功。

示例三：域控之间的触发和攻击

结果：失败！由于被攻击的域控主机（DC2012）的 SMB 签名处于开启状态，因此必定会失败。

示例四：域主机之间的触发和攻击

结果：成功！由于被攻击的域主机（Win10）的 SMB 签名处于关闭状态，因此会成功。

6、HTTP 转 LDAP

在 NTLM 中继攻击的流程中，认证协议由 HTTP 转 LDAP 可顺利进行，和 SMB 签名和 CVE-2019-1040 漏洞的补丁无关。

示例一：域主机触发去攻击域控

结果：成功！

示例二：域控之间的触发和攻击

结果：成功！

7、杂项

1. 被中继凭证的权限，决定了它是否可以在受害者机器上进行一些高权限的操作。例如，如果被中继的凭证只是个普通域用户，那么就自然不能够在域控上创建委派账户、转储用户哈希这些需要高权限才能做的事情。
2. 在 HTTP 转 SMB/LDAP 的中继过程中，浏览器中访问 kali 时，弹出的登录框中需要填写域用户的账户密码才行。
3. impacket-ntlmrelayx 的 --remove-mic 选项似乎只有在 SMB 转 LDAP/HTTP 时才会被用到，其它时候并不需要。
4. 通过 SMB/HTTP 转 LDAP 成功执行时会创建一个拥有 Replication-Get-Changes-All 特权的用户，利用该用户配合 impacket-secretsdump 可成功转储域中所有用户的哈希。
   
   
5. 机器账户只能新建机器账户，而域用户不仅可以创建机器账户也可以新建机器账户。这也就是为什么在 NTLM 中继攻击时，主动强制认证新建的特权账户都是机器账户而不是域用户的原因。因为主动强制认证所中继的凭证基本都是目标系统的系统机器账户，即带$的主机名同时也是 SYSTEM 账户。
6. 强制认证，所中继的账户都是机器账户，因此只能够利用其对一些机器账户进行委派或证书请求的功能；触发认证，所中继的账户一般都是域用户，所以其支持的攻击手法很多，基本上强制认证支持的它都支持。【当然所触发的域账户的权限也决定着此种中继方式可使用的攻击功能，如果触发的凭证是域管理员，那么此时可使用的功能也肯定很多。】