授权内网渗透中的 NTLM 中继面验证：SMB/LDAP 签名、日志留痕与修复

背景

在 Windows 域内渗透中，NTLM 中继仍是常见的权限边界突破点。它不等同于“抓到 NetNTLM 哈希再破解”，而是将客户端发起的认证实时转发给另一项服务。测试中经常遇到的入口包括 SMB、HTTP、WebDAV 和打印相关服务，目标则多为未强制签名的 SMB、未强制签名或通道绑定的 LDAP，以及未启用扩展保护的 IIS 服务。

本文以已获得书面授权的域内测试为前提，重点验证中继成立所需的配置条件、有效权限和日志证据。生产环境不应使用 LLMNR/NBT-NS 投毒、强制认证或批量扫描制造流量，验证应限定到指定测试主机和测试账号。

问题定位

一条 NTLM 中继链路通常需要同时满足以下条件：

• 存在可控的认证来源，例如测试客户端按约定访问指定服务。
• 攻击位置能够接收并转发该认证，网络路径和防火墙允许相关流量。
• 目标服务接受 NTLM，且未要求能够阻止中继的完整性保护。
• 被中继账号在目标上具有实际权限，例如本地管理员、共享写入权或可修改目录对象的 ACL。

发现 445 端口开放并不代表可中继；扫描结果显示“签名已启用但非强制”才是需要进一步核实的配置风险。反过来，关闭 SMBv1 也不能替代 SMB 签名。

SMB 签名面排查

先从目标清单中确认 SMB2/SMB3 的签名要求。建议使用明确的资产范围，不要直接扫描整个办公网段。

nmap -Pn -p445 --script smb2-security-mode 10.20.30.0/24 -oA smb-signing

# 重点关注类似结果：
# 3.1.1:
#   Message signing enabled but not required

“enabled but not required”表示服务端支持签名，但客户端没有提出要求时仍允许未签名会话。对于 SMB 到 SMB 的中继场景，这类主机应进入后续核查清单。域控制器通常应显示签名为 required；普通成员服务器则要结合业务兼容性检查。

在 Windows 目标本机可以直接查看生效配置：

Get-SmbServerConfiguration |
  Select-Object EnableSecuritySignature,RequireSecuritySignature,EnableSMB1Protocol,EnableSMB2Protocol

Get-SmbClientConfiguration |
  Select-Object EnableSecuritySignature,RequireSecuritySignature

需要同时区分客户端和服务端设置。服务端强制签名用于保护本机提供的共享，客户端强制签名用于限制本机连接不提供签名保护的远端 SMB 服务。

LDAP 签名与通道绑定检查

如果目标是域控制器，还需检查 LDAP signing 和 LDAP channel binding。仅部署 LDAPS 证书并不能证明安全，客户端仍可能使用 389 端口进行未签名 SASL 绑定，或者在 LDAPS 上缺少通道绑定校验。

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

• LDAPServerIntegrity 为 2：域控制器要求 LDAP 签名。
• LdapEnforceChannelBinding 为 0：不执行通道绑定。
• LdapEnforceChannelBinding 为 1：兼容模式，仅在客户端支持时执行。
• LdapEnforceChannelBinding 为 2：始终要求通道绑定。

注册表值应与组策略生效结果交叉确认，避免只检查策略模板而忽略覆盖关系。可以使用以下命令导出域控制器的结果策略：

gpresult /h C:\Windows\Temp\dc-policy.html /scope computer

受控验证步骤

生产域内不建议一上来执行自动化中继。更稳妥的验证顺序如下：

• 建立资产矩阵：记录主机角色、445/389/636 端口状态、SMB 签名、LDAP 签名和通道绑定状态。
• 使用专门创建的低权限域账号和隔离测试客户端，不使用管理员日常账号。
• 认证来源使用明确的 UNC 路径或测试 Web 服务触发，不做广播协议投毒，也不调用打印、EFSRPC 等强制认证接口。
• 中继目标只允许指定测试服务器，并在网络 ACL 中阻止访问其他域控和文件服务器。
• 验证目标应是无业务数据的空共享或测试目录对象，操作采用创建后立即删除的标记对象，不执行命令、不部署服务、不落地持久化。
• 同时在源主机、接收端和目标端开启抓包与事件审计，用日志闭环证明认证流向和权限结果。

判定结果时应分级：仅存在弱配置记为“中继前置条件”；已在隔离环境完成认证转发但无有效权限记为“可中继但影响受限”；只有在测试账号能够对授权目标完成预定写操作时，才记录为“已验证权限影响”。

日志留痕与取证

SMB 目标建议关注安全日志中的 4624、4776、5140 和 5145。典型现象是短时间内出现网络登录，认证包为 NTLM，源地址与正常客户端不一致，随后访问管理共享或敏感目录。5145 需要提前启用“详细文件共享”审计。

auditpol /get /category:*
auditpol /set /subcategory:"File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable /failure:enable

Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4624,4776,5140,5145
  StartTime=(Get-Date).AddHours(-4)
} | Select-Object TimeCreated,Id,MachineName,Message

不同语言版本的 Windows 可能无法识别英文审计子类别名称，执行前应通过 auditpol 列出本机名称，或统一通过域组策略下发高级审核策略。

LDAP 侧可利用域服务事件确认哪些客户端仍在进行不安全绑定。短期排查时，可提高 LDAP Interface Events 诊断级别：

reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" /v "16 LDAP Interface Events" /t REG_DWORD /d 2 /f

Get-WinEvent -FilterHashtable @{
  LogName='Directory Service'
  Id=2886,2887,2888,2889,3039,3040,3041
  StartTime=(Get-Date).AddDays(-7)
} | Select-Object TimeCreated,Id,Message

2887 可用于观察未签名 LDAP 绑定的汇总情况，2889 在诊断开启后能够提供客户端地址和账号信息。3039 至 3041 可辅助分析 LDAP 通道绑定问题。提高诊断级别会增加日志量，完成兼容性盘点后应恢复原配置。

还可以启用 NTLM Operational 日志，对异常 NTLM 使用进行关联：

wevtutil sl Microsoft-Windows-NTLM/Operational /e:true

Get-WinEvent -LogName Microsoft-Windows-NTLM/Operational -MaxEvents 200 |
  Select-Object TimeCreated,Id,Message

分析时不要只看单个事件。应将源 IP、目标主机、账号、登录类型、认证包、共享名和后续对象访问按时间线关联。若同一账号在数秒内从业务客户端向陌生中间地址认证，随后又由该地址访问服务器，应重点复核。

修复建议

• 通过组策略将 Microsoft network server: Digitally sign communications (always) 设置为 Enabled，强制 SMB 服务端签名。
• 在兼容性验证后，将 Microsoft network client: Digitally sign communications (always) 设置为 Enabled，减少客户端连接到恶意 SMB 服务的风险。
• 域控制器启用 Domain controller: LDAP server signing requirements，并设置为 Require signing。
• 先利用 2889 和 3039 至 3041 事件清理旧客户端，再逐步将 LDAP 通道绑定调整为 Always，避免直接切换导致业务认证中断。
• 对 IIS、AD CS Web Enrollment 等接受 Windows 集成认证的站点启用 HTTPS 和 Extended Protection for Authentication；不需要 NTLM 时直接禁用。
• 通过组策略关闭 LLMNR；确认无遗留依赖后关闭 NetBIOS over TCP/IP，并限制 WebDAV 和不必要的打印服务。
• 使用主机防火墙和网络 ACL 限制工作站之间的 445 流量。普通终端通常不需要横向提供 SMB 服务。
• 启用“限制 NTLM”策略前先进入审计模式，根据 NTLM Operational 日志识别兼容性依赖，再分业务组逐步收紧。
• 复核本地管理员组、共享 ACL 和目录对象 ACL。即使认证可被中继，最小权限仍能显著降低最终影响。

Windows 主机可以按以下方式强制 SMB 签名，生产环境建议通过域组策略统一配置，而不是逐台执行：

Set-SmbServerConfiguration -EnableSecuritySignature $true -RequireSecuritySignature $true -Force
Set-SmbClientConfiguration -EnableSecuritySignature $true -RequireSecuritySignature $true -Force

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

复测要点

• 重新运行 smb2-security-mode，确认目标由“enabled but not required”变为 required。
• 确认域控不再新增 2889 不安全绑定事件，业务 LDAP 客户端没有认证失败。
• 检查 NTLM Operational 日志，确认遗留 NTLM 调用量符合预期。
• 验证文件共享、备份、扫描设备和旧版中间件，避免签名策略造成隐性故障。
• 再次使用低权限测试账号执行受控验证，确认认证无法被转发，且目标没有产生预定写操作。

总结

NTLM 中继风险不能只靠端口扫描下结论。可靠的渗透验证应同时覆盖认证来源、协议完整性、账号权限和事件日志，并明确区分“存在前置条件”和“已形成有效权限影响”。修复时优先强制 SMB/LDAP 签名、启用 LDAP 通道绑定和 EPA，再结合 NTLM 收敛、网络隔离与最小权限处理认证来源。这样既能关闭具体攻击链，也能保留可复核的日志证据。

这类验证建议把“是否可中继”和“是否已经被阻断”分开做，重点留存三类证据：协商能力、实际认证日志、策略生效状态。不要只以扫描器返回的“可能存在 NTLM Relay”作为结论。

1. 先确认 SMB 客户端和服务端的签名状态

Get-SmbServerConfiguration |
    Select-Object EnableSecuritySignature, RequireSecuritySignature

Get-SmbClientConfiguration |
    Select-Object EnableSecuritySignature, RequireSecuritySignature

域控、文件服务器和发起认证的工作站都要分别检查。实际测试中经常遇到“服务器要求签名，但客户端只协商签名”的误判，或者只检查了域控，遗漏了普通文件服务器。

从远程侧可以做非侵入式确认：

nmap -Pn -p445 --script smb2-security-mode <target>

如果结果显示 SMB2/3 仅支持 signing、但不是 required，仍应按风险项处理。修复后的验证重点是服务端和客户端两端都显示 RequireSecuritySignature=True，并且通过组策略刷新后重新取证，而不是只看策略编辑器里的配置。

2. LDAP 不要只检查 389 端口是否开放

在域控上检查 LDAP 签名和通道绑定相关配置：

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

常见取值可以按下面理解：

• LDAPServerIntegrity=1：协商签名；2：要求签名。
• LdapEnforceChannelBinding=1：支持时使用；2：要求通道绑定。

建议通过组策略统一配置，而不是逐台改注册表。对应路径通常是：

计算机配置
  └─ Windows 设置
      └─ 安全设置
          └─ 本地策略
              └─ 安全选项
                  ├─ Domain controller: LDAP server signing requirements
                  └─ Domain controller: LDAP server channel binding token requirements

通道绑定策略需要结合系统版本和补丁基线验证，直接切到“要求”前应先确认现有应用是否仍使用简单绑定或不带 CBT 的 LDAPS，否则可能把业务一起切断。

3. 日志建议按“认证源—目标—协议”关联

域控和目标服务器上重点看：

• 4624：目标主机上的网络登录，关注 LogonType=3、AuthenticationPackageName=NTLM、源地址和账户。
• 4776：域控对 NTLM 凭据的验证，适合与 4624 的时间、账户和源主机交叉核对。
• 8004：开启 NTLM 审核后记录的 NTLM 使用情况，可用于发现仍在使用 NTLM 的主机和服务。
• 5140/5145：SMB 共享访问记录，用来判断认证是否实际到达文件共享。
• 目录服务日志中的 2887/2888：LDAP 未签名绑定统计和拒绝情况；通道绑定失败还要结合目录服务相关事件检查。

建议把一次验证的时间窗口缩短到几分钟，并记录测试源 IP、目标 IP、测试账户、时间戳。这样可以区分“扫描器探测到协议能力”和“确实发生了一次 NTLM 网络认证”。如果只出现 4624 而没有对应的 4776，通常还要检查认证是否由本机账户、缓存凭据或其他本地路径完成。

4. 修复顺序

1. 先开启 NTLM 审核，按源主机和服务识别遗留依赖，不要直接全网禁用。
2. 优先对域控和高价值文件服务器强制 SMB 签名。
3. 对 LDAP 先启用签名审计，再要求签名；随后单独评估并启用通道绑定。
4. 对无法升级的旧设备建立明确例外，限制其网络范围和账户权限，并设置退出时间。
5. 刷新组策略后，用 gpresult /h、注册表及实际协议协商结果三方确认策略已经生效。

最终报告里最好分别给出“SMB 未强制签名”“LDAP 允许未签名绑定”“仍有 NTLM 使用”三个结论。它们的修复措施和误报来源不同，合并成一个“存在 NTLM Relay 风险”会让后续整改难以落地。