NTLM 中继攻击的几种非主流玩法

在企业组织中的常见的一种安全风险是凭证重用，当攻击者攻击 NT LAN Manager 身份验证协议(以下简称 NTLM 身份验证)时就会出现这样的风险，而这个协议通常会在 微软的 活动目录 中默认启用。

NTLM 认证中的不安全性已经被安全研究人员发现超过15年了。该协议可以被滥用，通过一个称为“中继”的过程劫持受害者的会话，该过程通过将受害者的凭证转发到与预期不同的服务来滥用受害者的凭证。在许多情况下，NTLM身份验证仍然受到默认的支持和启用，尽管它已经被更安全的Kerberos取代，成为默认的身份验证方法。

在本博文中，我们将演示如何使用NTLMrelayx将凭证中继到LDAP、IMAP和MSSQL，NTLMrelayx是著名的smbrelayx工具。为了抵御这种攻击，你可以执行以下措施:

·如果可能，在组织中完全禁用 NTLM 并切换到 Kerberos。

·如果无法禁用 NTLM ，请参考本博客文章中讨论的设置和指导原则章节，以降低凭证重用的风险。

NTLM 中继攻击解释

NTLM 身份验证流程

NTLM身份验证协议有三个步骤:

1.协商身份验证:NTLM身份验证的第一步是协议的协商，以及客户端支持哪些特性。在此阶段，客户端向服务器发送身份验证请求，包括客户端接受的NTLM版本。

2.服务器挑战:服务器用自己的消息进行响应，表明它接受哪个NTLM版本，以及它想使用哪个特性。此消息还包含一个“挑战”值，这在身份验证中非常重要。

3.身份验证响应:客户端根据挑战发送回响应，并包含密码所属的用户名和域。

在交换了这3条消息之后，服务器将返回一条消息，表明身份验证成功，或者身份验证失败。根据使用的协议，客户端与服务器之间的会话现在经过了身份验证。这个过程如下图所示:

滥用 NTLM

作为攻击者，如果能够说服客户端连接到攻击者，则此过程可能会被滥用。下一节将解释如何做到这一点。一旦攻击者拥有一个愿意进行身份验证的已连接的客户端，那么他们就可以轻松地在客户端和服务器之间将这3条消息转发给服务器，直到挑战-响应周期结束。

在对连接进行身份验证时，攻击者可以简单地向客户端发送错误消息，或者删除连接。然后，攻击者可以使用会话从中继身份验证的用户的上下文与服务器交互。

交叉协议的中继攻击

NTLM 身份验证被封装在其他协议中，但是无论覆盖的协议是什么，消息都是相同的。这允许在其他协议中使用 NTLM 消息。例如，使用 HTTP 进行身份验证的客户端会在“ Authorization”标头中发送 NTLM 身份验证消息。攻击者可以从 HTTP 头中提取这些消息，并在其他协议中使用它们，比如 SMB。

NTLM支持多种协议，例如SMB、HTTP(S)、LDAP、IMAP、SMTP、POP3和MSSQL。

获取流量

还有一点还没有解释，那就是如何让客户端连接到攻击者而不是真正的服务器。有几种方法可以获得中继的通信流量:

·以不安全方式解析IP的主机的流量

·滥用自动发现协议产生的流量

·通过中间人攻击获得的流量

不安全的名称解析协议

我们会经常遇到使用不安全协议的名称解析通信流量。通常将工作站或服务器配置为联系网络中不存在的主机，以及主机名无法使用DNS解析的主机。当这种情况发生时，Windows 工作站会退回到名称解析协议，如 NBNS 和 LLMNR，它们依赖广播流量要求同一网络中的主机将主机名解析为 IP 地址。因为这个流量可以被同一网段中的所有主机查看(取决于防火墙配置) ，所以任何主机都可以回复请求。这使得攻击者有机会伪造请求名称的地址。这个过程如下图所示。

自动发现协议

也许在过去的几年里，对于黑客们来说，最臭名昭著的功能恐怕是 Windows 代理自动检测(WPAD)功能。这个特性将通过DNS查找一个名为WPAD的主机名，如果不能通过上面描述的LLMNR和NBNS成功查找到，则连接到它能找到的第一个主机。滥用这一特性变得更加容易，因为当提示进行身份验证时，工作站会自动尝试使用 NTLM 身份验证进行身份验证，然后可以被攻击者执行中继攻击。微软在2016年6月已经对其中的几个方面进行了修补，但有时我们仍然会在网络中遇到这种问题。

中间人攻击

中间人攻击(man-in-middle attack，即攻击者接管受害者的流量)，这种攻击在企业网络中常常具有破坏性，尤其是在使用 ARP 欺骗等技术时。然而，当企业设备连接到不受信任的网络(例如公共 WiFi 网络)时，攻击者可以攻击受害者并截获不受 TLS 保护的流量，将其重定向到受害者工作站受信任的位置。然后，受害者将自动验证是否启用了自动内部网检测(这是默认的设置)。

使用 ntlmrelayx 在任何地方中继 NTLM

有几个工具可以滥用 NTLM 身份验证。其中之一就是 smbrelayx，它是 Core Security 的 impacket 库的一部分。NTLMrelayx 是由我们团队开发的 smbrelayx 工具的扩展和部分重写。它具有广泛的协议中继功能。该工具接受多个目标，循环遍历每个目标以找到需要验证的系统。该工具提供了一个 SMB 和 HTTP 服务器，它可以从这些服务器中继 NTLM 身份验证到 SMB、 HTTP、 IMAP、 LDAP 和 MSSQL。

中继到 SMB

中继到 SMB 是一种典型的攻击手法，这已经是 smbrelayx 中的一部分功能。这种攻击会中继到 SMB 允许攻击者在禁用 SMB 签名的主机上执行文件，如果被中继的用户在该主机上具有管理特权。对于非管理员用户，ntlmrelayx 添加了启动 smbclient shell 的选项，该选项允许攻击者与共享进行交互，例如下载或上传文件。这种攻击可以通过交互式标志(- i)来完成，它将生成一个本地 TCP shell，可以与例如 netcat 进行连接。

中继到 LDAP

中继到 LDAP 是 ntlmrelayx 中的一个新增功能。LDAP 是一个有趣的协议，因为它用于直接查询目录，目录中包含许多对攻击者来说有趣的信息。更有趣的是，在默认情况下，域中的所有帐户(包括计算机帐户)都可以读取大多数此类信息。这就是 ntlmrelayx 与我们团队开发的另一个工具 ldapdomaindump 集成的地方。这个工具试图从域内收集尽可能多的信息，包括用户、他们的组成员、域计算机和域策略。

除了收集信息之外，还可以通过 LDAP 写入目录。如果 ntlmrelayx 遇到具有域管理员权限的用户，它将创建一个新的域管理员帐户，这将立即让攻击者完全控制域:

中继到 IMAP

在现代版本的 Exchange 中，默认情况下不启用 NTLM 身份验证，但许多组织会通过其 Exchange 服务器上的 IMAP 支持 NTLM 身份验证。这允许中继到 IMAP，让攻击者直接访问受害者的电子邮件。当中继到 IMAP 时，ntlmrelayx 可以选择在电子邮件中搜索关键字，或者只是下载用户指定收件箱中的所有最新电子邮件。

中继到 MSSQL

中继到 MSSQL 目前只是作为一个概念证明存在，但是可以在命令行上指定查询，这将在数据库中的受害者上下文中执行。

缓解

那么，企业组织该如何应对这些攻击呢？上述所有攻击都滥用了 NLTM 身份验证协议，因此唯一完整的解决方案是完全禁用 NTLM 并切换到 Kerberos。然而，许多组织的遗留产品或操作系统不支持 Kerberos 身份验证，因此禁用NTLM会对业务产生很大的影响。作为一个缓解因素，有几个设置可以进行启用，以最大限度地减少继电保护的风险。

·启用 SMB 签名: SMB 签名将通过要求所有流量都进行签名来防止中继到 SMB。签名需要用户密码来验证消息，因此中继连接的攻击者不能发送任何将被服务器接受的流量，因为攻击者没有受害者的密码。

·启用 LDAP 签名: 与 SMB 签名类似，LDAP 签名可以防止中继到 LDAP 的无签名连接。应该注意的是，通过 TLS 连接到 LDAP 被认为是有签名的，因此此设置不能防止通过 TLS 对 LDAP 的中继攻击。

·启用扩展的身份验证保护: 扩展的身份验证保护有助于防止一些中继攻击，确保用于连接到服务器的 TLS 通道与客户端验证时使用的通道相同。此设置主要适用于 IIS。

·启用 SPN 目标名称验证: SPN 目标名称验证是另一个缓解措施，它通过验证客户端认为正在对其进行身份验证的目标名称来防止中继到SMB。如果名称与服务器不匹配，则拒绝身份验证。

·确保内部网站使用 HTTPS: 当内部网站通过不安全的 HTTP 协议访问时，用户无法验证连接的真实性。通过强制所有内部网站只能使用 HTTPS，中继服务的效率就会大大降低。

防止中继攻击的常规安全加固措施

除了这些特定的服务器端测量之外，以下常规加固可以防止NTLM中继攻击:

·禁用内部网络自动检测: 如果域中需要 NTLM 认证，请确保浏览器(主要是 Internet Explorer)只自动认证到可信任的网站。通过组策略，可以禁用自动内部网络检测，并且只能自动认证到应该应用自动认证的内部网站白名单。正如前面提到的，这里强烈建议只使用 HTTPS 网站。

·禁用 Windows 代理自动检测: 虽然 WPAD 的安全问题已经大部分由微软 MS16-077 安全更新解决，但仍然建议通过组策略禁用 WPAD。

·禁用 LLMNR/NBNS:: 在配置良好的网络中通常不需要这些不安全的名称解析协议。禁用它们会减少攻击者进行名称解析欺骗的可能性，从而使攻击者更难欺骗受害者连接到攻击者的服务器。

如何获得 ntlmrelayx

NTLMrelayx 已经提交到了 Impacket 代码仓库，你可以在 Impacket 示例目录中找到。

更多资源

我们在尝试理解NTLM时的大部分研究都是在以下资源的帮助下进行的:

·http://ubiqx.org/cifs/SMB.html#SMB.8.5(和上面那篇文章类似)

·https://msdn.microsoft.com/en-us/library/cc236621.aspx(官方协议说明文档，非常专业)

·https://technet.microsoft.com/en-us/library/2006.08.securitywatch.aspx(介绍 LMCompatibilityLevel 的好文章)

本文翻译自：https://www.fox-it.com/en/insights/blogs/blog/inside-windows-network/