AD域应急-NTLM Relay攻击狩猎

在 Active Directory 环境中，NTLM Relay 是一种非常经典、同时也极具现实威胁性的横向移动技术。它并不依赖漏洞利用，而是滥用了 NTLM 认证协议本身的设计缺陷。在实际应急响应中，这类攻击往往隐藏在“看似正常的登录行为”之中，如果没有针对性的检测思路，很容易被忽略。

NTLM Relay 攻击原理

NTLM Relay 的核心思想并不复杂：攻击者并不破解密码，而是转发认证。

当一台主机向另一台主机发起 NTLM 认证请求时，如果中间存在一个恶意节点，这个节点可以充当“中继”，将客户端发起的认证请求原封不动地转发给真正的目标主机，从而在无需知道明文密码的情况下完成身份认证。

这一攻击能够成立，根本原因在于 NTLM 协议并不会校验对端是否是真正的目标主机。只要目标系统接受 NTLM 认证，并且没有强制启用 SMB Signing，攻击者就有机会完成中继。

在默认配置下：

• 工作站通常 启用了 SMB Signing，但并不要求必须启用
• 域控通常 启用了并强制要求 SMB Signing

这也是为什么 NTLM Relay 更常被用于工作站之间的横向移动，而不是直接攻击域控。

攻击前置条件

在真实攻击中，攻击者首先会做一件事：确认哪些主机未强制 SMB Signing。

nmap --script=smb2-security-mode.nse -p445 192.168.3.0/24

这一过程可以通过自动化扫描完成，例如使用 Nmap 的内置脚本扫描 445 端口，枚举 SMB 安全模式。扫描结果可以快速区分出：

• 哪些主机完全未启用 SMB Signing
• 哪些主机启用了但未强制
• 哪些主机强制要求 SMB Signing（通常是域控）

从攻击角度来看，只要目标主机 “启用但不强制”，就已经足够危险。

模拟真实的攻击触发场景

NTLM Relay 攻击并不依赖复杂的用户行为，反而往往源于一些极其常见的操作失误。

例如，一名域内的普通用户在访问 SMB 共享时，误输入了错误的域名not-exist-domain。域名不存在，DNS 解析失败，此时 Windows 会自动回退使用 LLMNR / NetBIOS 进行名称解析。

responder -I eth0 -dwv

如果此时内网中存在攻击者运行的工具（如 Responder），攻击者就可以伪装成“合法的名称解析响应者”，诱使受害主机将 NTLM 认证请求发送给攻击者。

用户触发访问后，responder就能拿到用户的ntlm hash。

攻击执行过程

在完整的攻击链路中，攻击者通常会配合使用两类工具：

第一类工具负责拦截认证请求。
Responder 就是其中的典型代表，它会监听 LLMNR、NBT-NS 等协议，充当中间人。

第二类工具负责转发认证并执行利用。

impacket-ntlmrelayx -t 192.168.3.235  -smb2support 

攻击者会使用 ntlmrelayx，将捕获到的 NTLM 认证请求，转发到事先选定的目标主机。

一旦中继成功，攻击者可以在目标主机上：

• 执行认证
• 转储本地凭据
• 为后续横向移动或权限提升奠定基础

值得注意的是：
攻击者最初只控制了一台普通工作站，但通过 NTLM Relay，成功获得了另一台工作站的访问权限。

这正是应急响应中最危险、也最容易被低估的地方。

应急响应视角下的检测重点

在检测 NTLM Relay 时，一个常见误区是：只盯着域控日志。事实上，真正关键的日志往往出现在 被中继攻击的目标主机上。

关键事件：Event ID 4624

在 Windows 安全日志中，Event ID 4624 表示一次成功的登录事件。在 NTLM Relay 场景下，该事件会呈现出一个非常典型的异常特征：

• 工作站名称显示为某一台合法终端
• 源 IP 地址却并不属于该工作站

这是因为：

• 实际登录请求是由攻击者主机发起的
• 但身份是被中继的合法用户

从日志表面看，这是一次“正常登录”；但从网络拓扑和资产信息来看，却存在明显的不一致。

NTLM中继攻击排查思路

核心思路只有一句话：

校验“主机名 — IP 地址”的一致性

在真实环境中，可以通过多种方式实现这一点：

• 利用 EDR 上报的资产信息，定期维护主机名与 IP 的映射关系
• 从域内频繁出现的计算机认证事件中，动态学习主机与 IP 的对应关系
• 将 NTLM 登录事件与上述资产数据进行自动化比对

一旦发现登录事件中的 IP 与主机名不匹配，就需要进一步分析是否存在 NTLM Relay 或类似的中继行为。

需要注意的是，这种方法并非没有误报。例如：

• 经过代理或负载均衡的认证流量
• 合法的中间设备转发请求

这些场景需要通过白名单进行剔除，避免干扰告警质量。

缓解与防护建议

从防守角度来看，NTLM Relay 并不难防，但往往被“历史兼容性”拖累。

几个最有效、也是最直接的措施包括：

• 在所有终端上强制启用 SMB Signing
• 逐步禁用 NTLM，优先使用 Kerberos
• 禁用不必要的 LLMNR / NetBIOS 名称解析
• 对 NTLM 认证行为进行集中监控与基线分析

在成熟的企业环境中，NTLM 应当被视为“过渡协议”，而不是长期依赖的认证方案。

赞赏

微信赞赏支付宝赞赏