授权渗透实战：从 SMB 签名缺失到 NTLM 中继风险的验证、留痕与加固

发布于5小时前5小时

背景在 Windows 域内授权渗透中，SMB 签名未强制启用、LDAP 签名未要求以及 NTLM 仍可被广泛使用，往往会组合成一条现实的权限突破链路：攻击者接收到某台主机发起的 NTLM 网络认证后，将认证流量中继至另一项服务，并以受害账户的权限执行操作。本文讨论的是受控环境中的风险验证，不包含密码破解，也不建议在生产网络中主动诱发认证。验证目标是回答三个问题：哪些 SMB 服务未强制签名；域控制器是否要求 LDAP 签名和通道绑定；现有日志能否识别异常 NTLM 登录及后续权限变更。所有扫描、认证测试和配置调整都应纳入书面授权范围。生产环境优先使用只读检查；涉及中继工具的验证应放在隔离靶场，并使用专门创建的低权限测试账户。问题定位先明确几个容易混淆的点。SMB 支持签名不等于强制签名；只有服务端要求签名时，未签名会话才会被拒绝。LDAP 签名和 LDAPS 也不是同一概念：LDAPS 解决传输加密问题，LDAP 签名用于保证 SASL LDAP 会话完整性。LDAP 通道绑定则用于约束 TLS 通道与认证交换，降低凭据被跨通道转发的风险。检查项高风险状态主要影响SMB 服务端签名未强制可能成为 NTLM 中继目标域控制器 LDAP 签名None允许缺少完整性保护的 LDAP 绑定LDAP 通道绑定NeverLDAPS 对特定中继场景的约束不足NTLM 审计未启用难以确认业务依赖和异常来源高权限账户登录范围可登录普通终端认证暴露后影响显著放大第一步：只读枚举 SMB 签名状态在授权网段内，可以使用 Nmap 的 SMB 安全模式脚本检查签名策略。建议降低并发并保存原始结果，方便复核资产归属和误报。mkdir -p evidence
nmap -n -Pn -T3 --max-rate 100 \
-p445 --script smb2-security-mode \
-iL scope.txt -oA evidence/smb-signing

grep -B4 -A4 "not required" evidence/smb-signing.nmap典型高风险结果是 Message signing enabled but not required。若端口开放但脚本无结果，不应直接判断为安全，还需要排查 SMB 协议协商失败、主机防火墙以及扫描源地址限制。在 Windows 服务器本机，可通过 PowerShell 读取实际配置：Get-SmbServerConfiguration |
Select-Object EnableSecuritySignature, RequireSecuritySignature

Get-SmbClientConfiguration |
Select-Object EnableSecuritySignature, RequireSecuritySignature服务端 RequireSecuritySignature 为 False 表示未强制签名。客户端是否强制签名影响其访问其他 SMB 服务时的行为，但不能替代服务端加固。第二步：检查域控制器 LDAP 防护域控制器上的 LDAP 签名策略可从本地安全策略、组策略结果或注册表交叉确认。注册表值 LDAPServerIntegrity 中，2 表示要求签名；缺失或较低取值需要结合域策略继续核实。reg query "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v LDAPServerIntegrity

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

gpresult /h C:\Windows\Temp\dc-policy.html /scope computerLdapEnforceChannelBinding 常见取值为 0、1、2，分别对应从不、兼容模式和始终。直接设置为 2 可能导致旧版应用、打印设备或使用不兼容 LDAP 库的系统认证失败，因此更稳妥的顺序是先启用审计和兼容模式，识别不兼容客户端后再强制。第三步：在隔离靶场验证权限边界不要在生产网中通过 WebDAV、打印服务、快捷方式或 RPC 接口主动诱发认证。安全的验证方式是搭建两台成员服务器和一台域控制器，创建无业务权限的测试账户，并让测试客户端主动访问审计服务器。验证时应使用固定目标清单，避免工具自动将认证转发至授权范围外。仅验证身份是否可能被接受，不执行创建用户、修改组成员、写入计划任务或变更目录对象等持久化动作。工具侧建议启用只读或无命令模式；若工具不具备明确的安全限制，应停止验证，改用配置证据完成风险判定。可在测试客户端主动建立一次普通 SMB 连接，用于生成可追踪的测试事件：cmd /c "net use \\audit-smb.lab.local\validation /user:LAB\relay_test *"

# 验证结束后清理连接
cmd /c "net use \\audit-smb.lab.local\validation /delete /y"测试账户不得属于 Domain Admins、本地 Administrators、备份操作员或任何可修改目录对象的委派组。验证记录至少包括源地址、目标地址、测试账户、开始和结束时间、预期事件以及实际结果。日志留痕与关联分析中继行为在目标系统上通常表现为一次 NTLM 网络登录。单个 4624 事件不足以下结论，应将登录事件、NTLM 凭据验证、共享访问以及权限变更关联起来。4624：重点关注 Logon Type 3、Authentication Package 为 NTLM、源工作站名和源地址不符合日常访问路径。4625：可用于发现批量失败认证，但成功中继不一定伴随失败事件。4776：域控制器验证 NTLM 凭据的记录，关注 Workstation 与实际业务终端不一致。5140、5145：网络共享及具体对象访问，适合确认认证后的操作范围。4672：新登录被授予敏感特权；应与同一 Logon ID 的 4624 关联。4728、4732、4756：用户被加入全局、本地或通用安全组。5136：目录对象被修改，适合监控计算机对象、委派属性和证书相关对象变化。以下 PowerShell 示例用于快速筛选近两小时内的 NTLM 网络登录。生产环境中应将等价条件下沉到 SIEM，并结合资产角色、跳板机地址和服务账户基线降低误报。$start = (Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4624
StartTime = $start
} | ForEach-Object {
$xml = [xml]$_.ToXml()
$data = @{}
foreach ($item in $xml.Event.EventData.Data) {
$data[$item.Name] = $item.'#text'
}
if ($data.LogonType -eq '3' -and $data.AuthenticationPackageName -eq 'NTLM') {
[pscustomobject]@{
Time = $_.TimeCreated
User = "$($data.TargetDomainName)\$($data.TargetUserName)"
SourceIP = $data.IpAddress
Workstation = $data.WorkstationName
Process = $data.ProcessName
LogonId = $data.TargetLogonId
}
}
} | Sort-Object Time | Format-Table -AutoSize建议额外记录测试机地址，并验证日志中的 SourceIP 是否等于中继节点而不是原始客户端。如果同一账户短时间内在不同系统出现相同类型的 NTLM 网络登录，且源地址集中于非业务服务器，应进一步排查。修复步骤第一优先级是对域控制器、文件服务器、软件分发服务器和管理服务器强制 SMB 签名。域环境中应通过组策略统一设置，避免只修改单台机器后被后续策略覆盖。Microsoft network server: Digitally sign communications (always)：Enabled。Microsoft network client: Digitally sign communications (always)：对管理终端和高价值服务器启用。Domain controller: LDAP server signing requirements：Require signing。Domain controller: LDAP server channel binding token requirements：先 When supported，完成兼容性整改后再调整为 Always。可在维护窗口通过 PowerShell设置 SMB 服务端策略，但仍应以域组策略作为长期配置来源：Set-SmbServerConfiguration -RequireSecuritySignature $true -Force

# 复核生效状态
Get-SmbServerConfiguration |
Select-Object EnableSecuritySignature, RequireSecuritySignature第二优先级是减少 NTLM 暴露。先开启审计，梳理仍依赖 NTLM 的设备和应用，再分阶段限制。直接全域拒绝 NTLM 容易造成旧应用、NAS、扫描仪和非域设备中断。启用 Restrict NTLM: Audit NTLM authentication in this domain。启用 Network security: Restrict NTLM: Audit Incoming NTLM Traffic。优先将应用改为 Kerberos，并为服务账户正确配置 SPN。禁止域管理员登录普通办公终端，采用分层管理账户和专用管理工作站。对管理协议实施网络隔离，仅允许跳板机访问 SMB、WinRM、RDP 和 LDAP 管理接口。关闭不需要的 WebClient 服务，减少 WebDAV 相关认证暴露面。修复后的复测复测不能只看组策略控制台显示成功。应同时确认终端实际配置、协议行为和业务兼容性：重新运行 smb2-security-mode，确认关键资产不再出现 signing not required。使用 gpresult 或 Resultant Set of Policy 确认策略没有被低层级 GPO 覆盖。检查 SMB 客户端连接、文件共享、备份和软件分发任务是否正常。检查域控制器目录服务日志和 NTLM 审计日志，定位仍使用不兼容绑定的客户端。重复隔离靶场测试，确认未签名会话或不满足通道绑定要求的认证被拒绝。总结SMB 签名缺失本身不等于已经失陷，但它与 NTLM 暴露、LDAP 防护不足及高权限账户登录范围过大组合后，会形成实际可利用的内网权限突破条件。授权渗透中应优先采用配置检查、低速扫描和低权限靶场验证，避免在生产环境主动诱发认证。修复时则应按审计、兼容性整改、逐步强制、日志复测的顺序推进，既关闭中继路径，也保留可验证的检测能力。

3小时前3小时

这里建议把“SMB 签名缺失”和“可完成 NTLM 中继”分开验证。前者只是必要条件之一，不能直接等同于漏洞可利用。至少还要确认：目标接受 NTLM、目标端未强制签名，以及认证来源能够被诱导或由受控测试机主动发起。

资产侧可以先做无侵入核查：

nmap -Pn -p445 --script smb2-security-mode,smb2-time 10.10.10.0/24

Get-SmbServerConfiguration |
  Select-Object EnableSecuritySignature,RequireSecuritySignature

Get-SmbClientConfiguration |
  Select-Object EnableSecuritySignature,RequireSecuritySignature

重点看 Message signing enabled but not required。另外，较新的 Windows 客户端通常会协商签名，因此扫描结果最好和实际协商流量交叉验证；抓包可使用过滤条件：

tcp.port == 445 && smb2.cmd == 1

在 SMB2 Session Setup 响应的 Security Mode 中确认签名是否为 required。不要仅凭 445 端口开放或工具的一行输出下结论。

授权验证时，建议使用隔离测试账号和专用共享，仅证明“认证能否被中继”，不要执行命令、转储凭据或访问业务文件。中继端可以先采用只列目标能力的方式：

ntlmrelayx.py -tf targets.txt -smb2support --no-dump --no-da --no-acl

然后从受控 Windows 测试机向中继机访问一个不存在的 UNC 路径：

dir \\10.10.10.50\probe

证据链建议至少保留：测试源 IP、测试账号、精确时间、目标 IP、SMB 协商包，以及中继工具日志。报告中应区分“签名未强制”“收到 NTLM 认证”“中继成功访问受控资源”三个层级，避免把配置弱项写成已完成横向移动。

留痕方面，目标 Windows 主机可重点检查：

Security 4624：登录类型 3、认证包 NTLM、来源地址是否为中继机；
Security 5140/5145：共享及对象访问；
Microsoft-Windows-SMBServer/Audit：未签名访问相关事件；
Microsoft-Windows-NTLM/Operational：NTLM 使用情况，需提前启用审计策略。

加固时服务端和客户端都应检查，域内可以通过 GPO 统一下发：

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

# 核验最终状态
Get-SmbServerConfiguration |
  Select-Object EnableSecuritySignature,RequireSecuritySignature
Get-SmbClientConfiguration |
  Select-Object EnableSecuritySignature,RequireSecuritySignature

上线前要先排查 NAS、打印设备、旧版 Windows 和第三方 SMB 实现，强制签名可能直接造成兼容性故障。若测试范围还包含 LDAP/HTTP 中继，只修 SMB 签名并不完整，还应同步核查 LDAP signing、LDAP channel binding、HTTP Extended Protection，以及通过 NTLM 审计逐步收敛域内 NTLM。修复复测也不应只看注册表或 GPO，应重新抓取协商包，并确认原测试链路已经失败。