NTLM Realy Introduction

1. 什么是 NTLM 中继攻击？

NTLM Realy（有时也叫NTLM Reflection）与Oracle Session类似，也是一种中间人攻击MitM。

NTLM现在仍然很常见：虽然微软强烈建议升级到kerberos协议，不再使用NTLM协议，但现在仍然有很多使用NTLM协议的系统

  • 与旧系统兼容（很多遗留系统不支持kerberos协议）
  • Kerberos配置错误（错误的配置会回退到NTLM认证）
  • 服务器未加入到域中
  • 协议选择不支持Kerberos，仅支持NLMP（NT LAN Manager Protocol）

NTLMv2 与 NTLMv1 
尽管 NTLMv2 相较于 NTLMv1 和 LM 进行了多项安全改进，但所有 NTLM 系列的身份验证协议都存在一个核心的安全缺陷
缺乏双向验证（Mutual Authentication）的手段：

  • 客户端验证其是否正在向合法服务器进行身份验证
  • 服务器验证其是否正在对合法客户端进行身份验证
  • 会话安全 SSPI 通过使用 signing 来解决此问题

2. MitM NTLM 身份验证

在NTLM Relay攻击中，攻击者不仅伪造服务器也伪造客户端

  • 对客户端而言：攻击者伪装成一个合法的服务器（比如用户想要访问的文件共享服务器）
  • 对真实服务器而言：攻击者伪装成一个合法的客户端

消息传递：

  • 当客户端尝试发起身份验证时，它会将认证消息发给攻击者。
  • 攻击者并不破解这些消息，而是直接将其中继给真正的目标服务器。
  • 服务器返回的挑战（Challenge）消息也会被攻击者转发回客户端。
  • 这个过程往复进行，直到目标服务器认为身份验证已成功通过。
    Pasted image 20260310205607.png

对于工作站的身份验证也是如此
Pasted image 20260310205924.png

3. NTLM 中继攻击的各阶段

NTLM relay 攻击分为三个阶段： Pre-relay 、 Relay 和 Post-relay

3.1. 第一阶段：预中继

pre-relay 阶段侧重于诱导/强制客户端为服务器上的服务发起 NTLM 认证
Pasted image 20260310210813.png
常用技术：

  • poisoning 和 spoofing 攻击
  • Authentication Coercion

3.1.1. Poisoning and Spoofing

执行此类攻击通常需要伪装成合法的服务器并重定向流量，这类技术一般会产生较多的噪音

Windows 支持多种名称解析过程：

  • DNS
  • NetBIOS Name Resolution (NBT-NS)
  • Link-Local Multicast Name Resolution (LLMNR)
  • Peer Name Resolution (PNR)
  • Server Network Information Discovery (SNID)

3.1.2. LLMNR、NBT-NS 和 mDNS 投毒

相关的介绍可以参考LLMNR NBT-NS mDNS Response Spoofing

因为DNS 是一种单播协议，客户端直接向服务器请求名称解析，
但 LLMNR 、 NBT-NS 和 mDNS 是多播协议，客户端会通过广播网络，询问是否有人知道它正在寻找的名称。这给了我们进行攻击的可能。我们如果在此网络中，就可以回答随机的名称解析请求，并将客户端重定向到我们的攻击主机

最常用的利用工具是Responder和Inveigh 二者分别用于Linux和Windows

下面是一个经典的攻击例子
Pasted image 20260310212140.png

  • 客户端因为无法找到SERVERR，通过LLMNR协议向网络发送广播消息（这里还可能是Windows上的其他协议）
  • 攻击者通过Responder发送投毒响应，强制客户端向我们发起身份验证

Responder提供了-A参数，意为analyze模式，这个模式下我们不会响应任何的NBT-NS 、 browser 或 LLMNR 请求，主要做监听侦察，人们往往错误的输入主机名、url等,我们可以使用此点来进行中继攻击

我们可以使用下面的操作做一个测试

#开启监听模式
responder -I eth0 -v -A

Pasted image 20260310214004.png
然后可以收到我们的

Pasted image 20260310214248.png

我们也可以去掉-A选项，此时Responder将响应广播流量并毒化响应，使用户尝试对我们的攻击机进行身份验证

如果我们输入密码的话，就可以获取到我们的哈希

除了Responder之外，还有一个GO语言开发的攻具Pretender，它通过欺骗名称解析和 DHCPv6 DNS 相关接管攻击来获取中间人位置。
retender 可以在不响应任何名称解析的情况下使用 --dry 标志执行，这有助于分析环境中的广播流量，但注意：由于默认情况下会污染 DHCP 请求， pretender 可能对生产网络造成严重干扰

一些其他的投毒攻击

3.2. 第二阶段：中继

Relay 阶段的核心任务是将客户端的 NTLM 身份验证中继到目标服务器：
Pasted image 20260310214929.png

3.2.1. 寻找中继目标

我们需要满足条件的中继目标，比如我们需要一个SMB协议的的中继目标，则需要 SMB Signing 为 disabled，否则我们的SMB中继无法完成

我们可以使用自带的RunFinger工具来寻找未开启SMB签名的中继目标，它是Responder自带的，位于*/Responder/tools/ 中

python3 RunFinger.py -i 172.16.117.0/24

[SMB2]:['172.16.117.3', Os:'Windows 10/Server 2016/2019 (check build)', Build:'17763', Domain:'INLANEFREIGHT', Bootime: 'Unknown', Signing:'True', RDP:'True', SMB1:'False', MSSQL:'False']
<SNIP>

也可以使用nxc来进行枚举
https://www.netexec.wiki/smb-protocol/enumeration/smb-signing-not-required

nxc smb 192.168.1.0/24 --gen-relay-list relay_list.txt

SMB         192.168.1.101    445    DC2012A          [*] Windows Server 2012 R2 Standard 9600 x64 (name:DC2012A) (domain:OCEAN) (signing:True) (SMBv1:True)
SMB         192.168.1.102    445    DC2012B          [*] Windows Server 2012 R2 Standard 9600 x64 (name:DC2012B) (domain:EARTH) (signing:True) (SMBv1:True)
SMB         192.168.1.111    445    SERVER1          [*] Windows Server 2016 Standard Evaluation 14393 x64 (name:SERVER1) (domain:PACIFIC) (signing:False) (SMBv1:True)
SMB         192.168.1.117    445    WIN10DESK1       [*] WIN10DESK1 x64 (name:WIN10DESK1) (domain:OCEAN) (signing:False) (SMBv1:True)
...SNIP...

#~ cat relay_list.txt
192.168.1.111
192.168.1.117

3.3. 第三阶段：后中继

post-relay 阶段利用我们通过中继受害者 NTLM 身份验证获得的认证会话,并根据认证会话的协议执行特定的后中继攻击
Pasted image 20260310215704.png
nwodtuhs制作了一个思维导图展示了整个NTLM中继的三个阶段
Pasted image 20260310215813.png

Component 解释
Coercion Method 这些技术诱导/强制客户端执行身份验证，包括 MiTM 和身份验证强制。
Incoming NTLM auth over 这些是客户端用于执行 NTLM 身份验证的协议，包括 HTTP 和 SMB。
Client-side mitigation 这些是客户端可采取的缓解措施，用于防范 NTLM 中继攻击，具体取决于 Incoming NTLM auth over 组件中指定的协议。
Server-side mitigation 这些是服务器端可采取的缓解措施，用于防范 NTLM 中继攻击，具体取决于 Incoming NTLM auth over 组件中指定的协议。
Relayed NTLM auth over 这些是我们可中继客户端 NTLM 认证的协议，包括 HTTP、HTTPS、SMB、LDAP 和 LDAPs。
Post-relay attack 这些是我们可根据 Relayed NTLM auth over 组件协议执行的中继后攻击。

可以发现HTTP NTLM 身份验证可以通过所有协议进行中继，而无需中继目标存在可利用的漏洞（因为HTTP不支持会话签名），而支持会话签名的SMB协议就需要满足一些条件才能进行成功中继了

4. Drop the MIC & Drop the MIC 2

2019 年 6 月 11 日， Preempt Security 披露了 CVE-2019-1040，该漏洞被命名为 Drop the MIC ，它能够绕过应用程序协议强制实施的会话签名要求。

Drop the MIC 通过按以下顺序操纵 NTLM 消息来绕过MIC ：

  • 在 NEGOTIATE_MESSAGE 中取消设置 NTLMSSP_NEGOTIATE_ALWAYS_SIGN 和 NTLMSSP_NEGOTIATE_SIGN 签名标志
  • 从 AUTHENTICATE_MESSAGE 中移除 MIC 和 Version 字段。
  • 取消 AUTHENTICATE_MESSAGE 消息中的 NTLMSSP_NEGOTIATE_ALWAYS_SIGN 、 NTLMSSP_NEGOTIATE_SIGN 、 NEGOTIATE_KEY_EXCHANGE 、 NEGOTIATE_VERSION 标志

四个月后，在微软发布 Drop the MIC 更新后，Preempt Security 披露了 CVE-2019-1166，这是一个与 CVE-2019-1040 类似的漏洞，被称为 Drop the MIC 2 。

5. Your Session Key is my Session Key

CVE-2019-1019，被命名为Your Session Key is my Session Key，是由 Preempt Security 的研究人员发现的一个漏洞。它建立在 CVE-2015-0005（微软发布了 MS15-027 补丁来解决该漏洞）的基础之上。

我们在第一部分提到过，针对 NetrLogonSamLogonWithFlags 请求（其中包含 NETLOGON_NETWORK_INFO），域控制器（DC）会发送 NETLOGON_LOGON_IDENTITY_INFO，其中包含了供服务器使用的会话密钥。

然而，如果攻击者冒充服务器并发起同样的调用，从而获取某个 NTLM 会话的会话密钥，进而对消息进行签名和Seal，会发生什么呢？研究人员发现，攻击者可以向 DC 请求任何 NTLM 认证的任何会话密钥，并针对任何服务器建立一个经过签名的合法会话。

相关内容请看： https://www.youtube.com/watch?v=2L7JpcLZ05Q