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 签名处于开启状态，因此必定会失败。