授权内网测试中如何定位 NTLM Relay 链路，并区分可利用、误报与已缓解状态？

背景与提问在一次已获授权的 Windows 域内渗透测试中，扫描结果同时提示 SMB 签名未强制、LDAP 签名未强制，以及部分主机允许 NTLM。常见疑问是：这些配置能否直接判定存在 NTLM Relay？为什么中继工具有时显示认证成功，却没有获得预期权限？如何在不扩大影响的前提下完成验证，并给出能落地的修复建议？结论先说：NTLM Relay 不是由单个弱配置决定的。至少要同时确认认证来源、目标协议、签名或通道绑定要求、目标账户权限，以及认证是否被 EPA 等机制绑定到原始 TLS 通道。扫描器发现的是前置条件，不等于完整攻击链成立。问题定位：先把链路拆成五个检查点检查点需要回答的问题常见误判认证来源测试范围内是否存在能够触发或自然产生 NTLM 认证的客户端只有目标服务弱配置，但没有任何认证流量中继目标SMB、LDAP、LDAPS、HTTP 中哪种协议接受该认证把 SMB 未签名直接等同于 LDAP 可中继完整性保护SMB signing、LDAP signing、TLS channel binding 是否强制服务器支持签名，但并未要求签名身份权限被中继的用户或计算机账户在目标对象上有什么权限认证成功即被描述为域控失陷协议绑定EPA、CBT、SPN 校验是否阻断跨服务转发只检查端口开放，不检查服务端策略第一步：核实 SMB 签名状态优先使用配置查询和协议探测交叉验证。以下命令均应从授权测试主机执行；不要仅依赖一条扫描器结论。nmap -Pn -p445 --script smb2-security-mode,smb2-time 10.10.20.0/24

# 在 Windows 服务器本机核对服务端配置
Get-SmbServerConfiguration |
Select-Object EnableSecuritySignature,RequireSecuritySignature

# 在客户端核对出站 SMB 策略
Get-SmbClientConfiguration |
Select-Object EnableSecuritySignature,RequireSecuritySignature

# 域策略对应注册表项
reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v RequireSecuritySignature
reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters /v RequireSecuritySignature判断时要区分 EnableSecuritySignature 与 RequireSecuritySignature。前者表示支持，后者才表示强制。若目标 SMB 服务要求签名，传统 NTLM 到 SMB 的中继通常会在会话建立或树连接阶段失败。还要注意系统版本与补丁基线：不能仅根据注册表项推断最终协商结果，抓包中的 SMB2 NEGOTIATE SecurityMode 更可靠。第二步：核实 LDAP 签名与通道绑定LDAP 中继判断至少涉及两项策略：LDAP server signing requirements 与 LDAP channel binding。普通 LDAP 389、StartTLS 和 LDAPS 636 的行为并不相同。域控本机可查询以下配置：# LDAP 服务器签名要求：2 通常表示要求签名
reg query HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v LDAPServerIntegrity

# LDAP 通道绑定策略：0 从不，1 在支持时，2 始终
reg query HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v LdapEnforceChannelBinding

# 查看域控相关日志，重点关注 LDAP 未签名绑定与 CBT 兼容性事件
Get-WinEvent -FilterHashtable @{LogName='Directory Service'; Id=2886,2887,2888,2889,3039,3040,3041} |
Select-Object TimeCreated,Id,LevelDisplayName,Message -First 100事件 2887 常用于汇总未签名 LDAP 绑定，2889 可在启用相应诊断后帮助定位客户端。3039 至 3041 与通道绑定兼容性排查有关，但不同系统版本和补丁状态下记录条件可能有差异，应结合微软当前文档与实际事件内容解释。不要为了抓日志直接在生产域控上把策略从强制改为关闭。第三步：在隔离窗口做最小化验证验证目标不是获取更多权限，而是证明某个已知测试身份的认证能否被转发到指定服务，并记录服务端响应。建议准备专用低权限域用户、单台测试客户端和单台测试目标，限制网络访问控制列表，只允许测试机之间通信；禁止执行新增管理员、写入计划任务、修改组成员或写入目录对象等动作。先记录测试账户当前组成员关系及目标资源 ACL，确保它没有隐含管理权限。抓取测试机与目标之间的 445、389、636 流量，保留协商、认证和错误码。一次只验证一个目标协议，避免自动化工具遍历整个网段。使用仅认证或仅查询模式；成功标准是服务接受转发后的会话，而不是进行破坏性操作。验证结束后立即停止监听，清理测试产生的连接、临时文件和防火墙例外。# 在隔离测试机抓取必要协议，避免采集无关业务流量
sudo tcpdump -i eth0 -nn -s0 \
'host 10.10.20.15 and (port 445 or port 389 or port 636)' \
-w relay-validation.pcap

# 服务端同步查看 SMB 会话与开放文件
Get-SmbSession | Select-Object ClientComputerName,ClientUserName,NumOpens
Get-SmbOpenFile | Select-Object ClientComputerName,ClientUserName,Path

# 查询认证日志；根据环境调整时间范围
$start=(Get-Date).AddMinutes(-15)
Get-WinEvent -FilterHashtable @{LogName='Security'; StartTime=$start; Id=4624,4625,4648,4672} |
Select-Object TimeCreated,Id,MachineName,Message如何解释“认证成功但没有权限”这通常不是工具故障，而是身份权限与协议能力不匹配。NTLM 验证成功只证明目标接受了凭据响应，后续操作仍受 ACL、共享权限、目录对象权限和用户权利分配控制。例如，低权限域用户被中继到 SMB 后可能只能建立 IPC 会话，不能访问 ADMIN$；普通计算机账户被中继到 LDAP 后，也不必然拥有修改任意目录对象的权限。报告中应分别记录三个层次：第一，认证是否被目标接受；第二，目标协议是否要求签名或绑定；第三，测试身份在目标资源上是否存在可产生安全影响的权限。只有三者组成可重复链路，才适合给出明确的可利用性结论。日志留痕与证据关联Windows 安全日志中，4624 表示成功登录，4625 表示失败登录，4648 表示显式凭据使用，4672 表示为新登录分配敏感特权。网络登录常见 Logon Type 为 3，但不能仅凭事件编号断言发生中继。应关联 Source Network Address、Workstation Name、Authentication Package、TargetUserName、目标服务日志以及抓包时间线。SMB 场景还可检查 Microsoft-Windows-SMBServer 下的 Operational、Audit 与 Security 日志；LDAP 场景应结合 Directory Service 日志。若中继节点地址出现在目标的网络登录来源中，而用户实际发起认证的客户端是另一地址，这种地址差异是重要线索，但代理、负载均衡和跳板机也会产生类似现象。常见误报排查扫描显示 SMB signing enabled：确认到底是 enabled 还是 required，并查看实际 SMB2 协商。目标开放 636：开放 LDAPS 不代表可中继；继续检查 CBT、证书链、EPA 和目标认证方式。工具输出 authenticated：检查后续 LDAP resultCode 或 SMB NTSTATUS，区分认证成功与授权失败。使用本地账户测试：注意同名本地账户、UAC 远程限制及账户作用域，不能直接外推为域风险。使用机器账户测试：机器账户权限与用户账户不同，应核对具体目录对象 ACL，不要按账户类型猜测。只看到 4624：Kerberos、正常 NTLM 登录和运维代理同样会产生该事件，必须补充来源地址与协议证据。风险分级建议情况建议结论仅发现 NTLM 可用，目标均强制签名或绑定记录为攻击面或加固项，不应直接定为可利用漏洞目标不强制保护，但测试身份无敏感权限存在中继条件，影响受当前 ACL 限制；仍需评估权限变化后的风险可中继到管理接口，且测试身份具备目标管理权限高风险，应提供完整时间线、目标范围和非破坏性证据可修改关键目录对象或获得等效高权限严重风险；停止扩大验证，立即通知授权方并保全日志修复建议与实施顺序在兼容性评估后，对服务器和客户端强制 SMB 签名。先通过审计和分批策略识别旧设备，避免一次性全域切换导致业务中断。对域控要求 LDAP 签名，并逐步将 LDAP channel binding 调整为强制。先处理仍使用简单绑定、未签名 SASL 或不支持 CBT 的旧客户端。对 IIS、AD CS Web Enrollment 等 HTTP 服务启用 HTTPS、Extended Protection for Authentication，并核对内核模式认证、反向代理和 SPN 配置。减少 NTLM 使用，通过 NTLM 审计策略定位依赖方，再按服务器或账户逐步限制；不要在未知依赖下直接全域禁用。限制工作站到服务器管理端口的横向访问，尤其是 445、5985、5986 和管理型 HTTP 接口，仅允许管理网段或受控跳板机访问。清理高权限账户在普通终端上的登录路径，使用分层管理、受保护用户和专用管理工作站，降低高价值认证被诱导的概率。检查目录对象与共享 ACL，移除普通用户、机器账户或过宽组对敏感对象的写权限。协议加固不能替代权限治理。总结在问答排障中，最容易出现的问题是把“允许 NTLM”“未强制签名”和“可取得高权限”混成一个结论。可靠的验证应按认证来源、目标协议、完整性保护、身份权限和日志证据逐项闭环。测试时使用专用低权限身份和单目标白名单，以认证和只读查询为上限；报告则明确区分配置弱点、认证可转发、授权可操作和最终业务影响。这样既能减少误报，也便于运维团队按 SMB 签名、LDAP 签名、CBT、EPA、网络隔离和 ACL 治理的顺序完成修复。

这类问题建议不要先按“某台机器开了 NTLM”下结论，而是把 Relay 拆成四个独立条件验证：

1. 入口：是否确实能诱发或自然产生目标账户的 NTLM 认证；
2. 传输：认证是否到达测试节点，中间是否被 Kerberos、代理或防火墙改变；
3. 落点：目标服务是否接受该认证，且未强制签名、EPA 或通道绑定；
4. 权限：被转发身份在落点上是否能产生实际安全影响。

只有四项形成同一条有时间关联的证据链，才建议标为“可利用”。单独看到 445/389/636 开放、NTLM Type 1/2/3，或者扫描器报“SMB signing not required”，最多只能说明存在前置条件。

先做服务端配置盘点

SMB 重点区分“客户端愿意签名”和“服务端强制签名”。在目标 Windows 主机上可直接核对：

Get-SmbServerConfiguration |
  Select-Object EnableSecuritySignature,RequireSecuritySignature
Get-SmbClientConfiguration |
  Select-Object EnableSecuritySignature,RequireSecuritySignature

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters' |
  Select-Object EnableSecuritySignature,RequireSecuritySignature

RequireSecuritySignature=True 才是服务端对未签名 SMB 会话的硬性拒绝。注意 Samba、NAS、打印设备要在设备侧单独确认，不能用 Windows 域策略结果代替。

LDAP/LDAPS 则同时检查 LDAP signing、channel binding 和证书实际绑定状态：

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' |
  Select-Object LDAPServerIntegrity,LdapEnforceChannelBinding

reg query HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v LDAPServerIntegrity
reg query HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v LdapEnforceChannelBinding

通常 LDAPServerIntegrity=2 表示要求 LDAP 签名；LdapEnforceChannelBinding=2 表示强制 CBT。值为 1 往往只是兼容或审计过渡状态，不能直接写成“已缓解”。另外，LDAP signing 能阻断的是相应的未签名 LDAP SASL 会话，不等于所有基于 TLS 的转发场景都自动安全；LDAPS 要结合 CBT/EPA 与实测拒绝结果判断。

用协议证据确认链路停在哪一段

建议在入口测试节点和落点服务器两侧同时抓包，并统一时钟。Wireshark 可先用以下过滤器缩小范围：

ntlmssp || smb2 || ldap || tls

ntlmssp.auth.username != ""
smb2.cmd == 1
ldap.bindRequest

记录同一次测试的源地址、目标地址、时间戳、账户、NTLM challenge，以及落点返回状态。判断时重点看：

• 只有 Type 1/Type 2，没有 Type 3：认证链未完成，不应算可利用；
• 完整 NTLMSSP 认证到达，但 SMB 返回签名相关失败，或 LDAP bind 因 signing/CBT 被拒绝：属于“已阻断”；
• 认证成功但账号在目标上无可产生影响的权限：属于“链路成立但当前权限不可利用”，不要误写成彻底缓解；
• 扫描结果来自负载均衡地址，而抓包落到另一后端：先逐节点复核，常见于配置漂移；
• 实际协商为 Kerberos，而不是 NTLM：不能拿这次成功登录证明 NTLM Relay 链路成立。

结合日志做闭环

Windows 侧可以围绕测试时间窗检索 4624/4625，并关注 Authentication Package、Logon Process、Source Network Address 和 Logon Type：

$start = (Get-Date).AddMinutes(-15)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625; StartTime=$start} |
  Select-Object TimeCreated,Id,MachineName,Message

域控还应查看 Directory Service 日志中的 LDAP signing/channel binding 相关事件。常用观察点包括 2887/2889，以及启用相应审计后的 3039、3040、3041。事件编号和字段会受系统版本、补丁及审计配置影响，所以报告里应附原始事件内容，不要只写“未发现事件”。没有日志也可能只是审计未开启。

建议的状态判定

复测报告最好按“认证来源 → 协议 → 落点 → 阻断点/影响”画一条链，并分别保留配置快照、PCAP、事件日志和测试账户权限快照。这样即使最终结论是“已缓解”，也能说明究竟是 SMB signing、LDAP signing、CBT/EPA，还是权限边界在起作用，避免把环境偶然不可达当成修复完成。