发布于21小时前21小时 背景：近期内网攻击情报为何仍在关注 NTLM Relay近期公开威胁情报和多起企业内网事件复盘显示，攻击者不一定依赖新的高危漏洞，而是继续利用名称解析投毒、强制认证与服务端签名缺失，把普通域用户或计算机账户的 NTLM 身份转发到 SMB、LDAP、AD CS Web Enrollment 等服务。微软持续收紧 NTLM、LDAP 签名和通道绑定相关默认策略，但存量域、旧版设备及兼容性例外仍会形成可利用窗口。这类事件的新闻价值不在于某个单一工具更新，而在于攻击链发生了变化：直接抓取口令散列后的离线破解正在减少，认证转发、证书身份持久化和低噪声横向移动更常见。对蓝队而言，单看登录失败或恶意文件已不足以确认风险，需要同时核对协议配置、网络流量和域控日志。以下操作仅用于已授权测试。建议在隔离测试网先验证，生产环境优先采用配置审计与日志关联，避免主动触发业务账户认证。问题定位：先确认攻击链是否具备三个条件典型链路需要同时满足：攻击者能够诱导目标发起 NTLM 认证；中继目标接受 NTLM；目标服务未强制校验签名、通道绑定或目标名称。任何一环被阻断，攻击链都会失效。检查对象高风险表现优先证据SMB服务器未要求 SMB Signing注册表、组策略、网络协商报文LDAP未要求 LDAP Signing，未执行 Channel Binding域控事件 2886、2887、2888、2889AD CS启用 HTTP Web Enrollment 且允许 NTLMIIS 日志、证书服务事件 4886、4887名称解析终端仍启用 LLMNR 或 NetBIOS over TCP/IPUDP 5355、UDP 137 流量和终端配置认证来源工作站账户突然访问不相关服务器4624、4648、4768、4769 及 SMB 日志技术分析：不同中继目标的权限边界SMB 中继是否能产生实际影响，取决于被中继身份在目标主机上的权限。普通域用户通常只能访问其原有共享；本地管理员或具备远程管理权限的账户可能导致服务创建、计划任务执行或远程注册表访问。这里应区分“认证成功”和“获得代码执行”，不能仅凭一次 4624 就判定主机失陷。LDAP 中继的风险更依赖目录权限。如果被中继主体拥有修改计算机对象、组成员关系、资源型约束委派或证书模板属性的权限，攻击者可能完成权限提升。AD CS 场景则要重点检查 Web Enrollment、证书模板的 EKU、申请者身份约束及是否允许计算机账户申请可用于客户端认证的证书。Channel Binding Token 用于把上层认证绑定到 TLS 通道；Extended Protection for Authentication 还可校验服务主体名称。它们与 LDAP Signing、SMB Signing 解决的问题并不完全相同，修复时不应只开启其中一个选项。授权环境中的配置审计步骤第一步，在域控或管理终端读取组策略结果，确认策略是否真正下发，而不是只检查 GPO 控制台。第二步，抽样检查成员服务器和旧设备，特别是文件服务器、扫描设备、备份系统及证书服务。第三步，利用域控审计事件定位仍在使用不安全 LDAP 绑定的客户端，再分批整改。# 在目标 Windows 服务器本地以管理员 PowerShell 执行，仅做配置读取 Get-SmbServerConfiguration | Select-Object EnableSecuritySignature,RequireSecuritySignature Get-SmbClientConfiguration | Select-Object EnableSecuritySignature,RequireSecuritySignature # 核对对应注册表值；1 表示服务器要求 SMB 签名 Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters' | Select-Object RequireSecuritySignature,EnableSecuritySignature # 导出当前计算机实际生效的组策略 New-Item -ItemType Directory -Force C:\Temp | Out-Null gpresult /scope computer /h C:\Temp\computer-gpo.html # 域控 LDAP 签名策略：2 表示要求签名 Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' | Select-Object LDAPServerIntegrity,LdapEnforceChannelBinding # 检查是否存在 LLMNR 禁用策略；EnableMulticast=0 表示禁用 Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' | Select-Object EnableMulticast # 查询最近 24 小时域控上的 LDAP 非安全绑定统计和明细 $start=(Get-Date).AddHours(-24) Get-WinEvent -FilterHashtable @{LogName='Directory Service';Id=2887,2889;StartTime=$start} | Select-Object TimeCreated,Id,MachineName,MessageLDAP Channel Binding 的注册表状态需要结合系统版本和补丁水平解释，不能把“键不存在”直接等同于安全或不安全。变更前应先查明兼容性基线，并通过事件日志识别不支持签名或通道绑定的业务客户端。日志留痕：如何识别中继而不是普通登录建议围绕时间窗做关联，而不是孤立匹配事件号。可疑模式包括：同一账户在数秒内从终端访问陌生服务器；4624 显示 LogonType 3、AuthenticationPackageName 为 NTLM；来源地址与用户常用终端不一致；随后出现共享访问、服务安装、目录对象修改或证书签发。域成员主机：关注 4624、4625、4648、4672、4688、4697、5140、5145。域控：关注 4768、4769、4776、5136、5141，以及 Directory Service 日志中的 2886 至 2889。AD CS：关注 4886、4887、4888；若部署 Web Enrollment，同步检查 IIS 的 cs-username、c-ip、cs-uri-stem、sc-status 和 User-Agent。网络侧：筛选 UDP 5355、UDP 137、TCP 445、TCP 389、TCP 636，以及到证书服务 HTTP 端点的 NTLM 认证。# 从安全日志筛选网络型 NTLM 登录，并保留来源 IP 与工作站字段 $start=(Get-Date).AddHours(-6) Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624;StartTime=$start} | Where-Object { $_.Properties[8].Value -eq 3 -and $_.Properties[10].Value -eq 'NTLM' } | Select-Object TimeCreated, @{n='Account';e={$_.Properties[5].Value}}, @{n='Workstation';e={$_.Properties[11].Value}}, @{n='SourceIP';e={$_.Properties[18].Value}}, @{n='Process';e={$_.Properties[17].Value}} # 检查服务安装事件，和前述 4624 按主机、账户及 5 分钟窗口关联 Get-WinEvent -FilterHashtable @{LogName='System';Id=7045;StartTime=$start} | Select-Object TimeCreated,MachineName,Message事件 4624 的 Properties 下标会因事件版本和采集方式存在差异。生产环境更稳妥的做法是由 SIEM 按 XML 字段名解析，例如 TargetUserName、IpAddress、WorkstationName、AuthenticationPackageName 和 LogonType。AD CS 专项排查若环境部署了证书服务，应确认是否安装 Web Enrollment 或 CES/CEP，并检查 IIS 是否允许 Windows Authentication 中的 NTLM。证书签发日志中，如果计算机账户在异常来源 IP 上短时间申请带 Client Authentication 或 Smart Card Logon 用途的证书，需要立即核实。# 在 CA 服务器查看角色服务与 IIS 身份验证配置 Get-WindowsFeature ADCS*,Web-WebServer,Web-Windows-Auth | Where-Object Installed Import-Module WebAdministration Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' ` -Filter 'system.webServer/security/authentication/windowsAuthentication' ` -Name enabled # 导出近期证书申请记录，便于核对 RequesterName 与模板 certutil -view -restrict 服务器、云资产与权限边界梳理示意 安全动态、影响面和处置建议示意
21小时前21小时 这个主题里最容易产生误判的一点，是把“Windows 默认策略收紧”直接等同于“NTLM Relay 已失效”。实际要按协议和落点分别验证：SMB 签名、LDAP 签名/通道绑定、HTTP EPA，以及 NTLM 是否仍可被强制触发，缺一项都不能下结论。尤其混合版本域、旧模板创建的 AD CS 站点、第三方 NAS/打印服务，通常不会随系统升级自动补齐。 建议先做一轮只读基线，不要一上来跑利用工具。SMB 两端配置可直接盘点： Get-SmbServerConfiguration | Select EnableSecuritySignature,RequireSecuritySignature Get-SmbClientConfiguration | Select EnableSecuritySignature,RequireSecuritySignature # 批量查看目标 445 是否开放；开放不代表可中继，仍要结合签名要求 Test-NetConnection fileserver01 -Port 445 # 域策略落地结果 reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v RequireSecuritySignature reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters /v RequireSecuritySignature gpresult /h C:\Windows\Temp\gpo.html LDAP/LDAPS 侧重点看 DC，而不是只看发起认证的客户端。先启用审计，再根据事件逐步收紧；Directory Service 日志中的 2887/2889 可用于定位未签名 LDAP 绑定，3039/3040/3041 可辅助判断通道绑定问题。不要直接全域强制后再排障，旧 Java、Linux LDAP 客户端和设备账号很容易被打断。 # 查看相关事件（需先按微软文档启用对应诊断日志） Get-WinEvent -FilterHashtable @{LogName='Directory Service'; Id=2887,2889,3039,3040,3041} | Select TimeCreated,Id,Message | Format-List # 查看域控实际策略结果 reg query HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v LDAPServerIntegrity reg query HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v LdapEnforceChannelBinding 如果环境有 AD CS，建议单独核对 Web Enrollment/CES。仅启用 HTTPS 不足以阻止 HTTP Relay，还要确认 IIS Windows Authentication 的 Extended Protection，不接受明文 HTTP，并检查反向代理是否破坏 CBT。修复后可用 IIS 配置和日志双向确认： %windir%\system32\inetsrv\appcmd.exe list config "Default Web Site/CertSrv" /section:system.webServer/security/authentication/windowsAuthentication # 查找仍访问 certsrv 的明文 HTTP 请求及 NTLM 认证痕迹 Get-ChildItem C:\inetpub\logs\LogFiles -Recurse -Filter *.log | Select-String -Pattern '/certsrv','401','NTLM' 验证攻击链时建议放在隔离网段，使用专用低权限测试账号和不可用于生产的证书模板，只确认“认证是否被转发、目标是否拒绝”，不要申请可登录证书或执行远程命令。一次验证应同时留存：源端网络流量、目标服务日志、DC 日志和测试机时间线。否则只能证明工具报了成功，不能证明具体哪项控制失效。 留痕上可重点关联以下信号： Security 4624：Logon Type 3、Authentication Package 为 NTLM，源地址与实际用户工作站不匹配； Microsoft-Windows-NTLM/Operational 8001–8004：定位仍在使用 NTLM 的主机、账号和目标服务； Directory Service 2889：未签名 LDAP 客户端的 IP 和身份； IIS 日志：短时间内对 /certsrv/ 的 401→200、异常来源地址和机器账号认证； 同一机器账号在很短窗口内先访问中继主机、随后又出现在 DC/证书服务日志中。 # 快速筛选近 24 小时 NTLM 网络登录 $start = (Get-Date).AddDays(-1) Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=$start} | Where-Object { $_.Message -match 'Logon Type:\s+3' -and $_.Message -match 'NTLM' } | Select TimeCreated,MachineName,Message 修复优先级建议按“堵住可中继目标 → 降低强制认证面 → 淘汰 NTLM”推进：先强制 SMB 签名；DC 分阶段启用 LDAP signing 和 channel binding；AD CS/IIS 启用 EPA、仅保留 HTTPS；关闭不需要的 WebClient 服务，并限制打印、EFSRPC 等远程 RPC 暴露；最后用 NTLM 审计清单逐项迁移到 Kerberos。不要把“禁用 LLMNR/NBNS”当成完整修复，它主要减少名称解析诱导，对 RPC 强制认证和已有 NTLM 服务并不能兜底。 验收时应重新采集事件，而不是只看注册表值：策略可能未刷新，IIS 子应用也可能覆盖父级配置。比较稳妥的通过标准是：测试认证在目标端被签名/EPA/CBT 明确拒绝，同时业务客户端能正常使用 Kerberos，且 NTLM 审计量在观察期内持续下降。
.thumb.jpg.9937ff1dc1dae46f3630361a862e0b90.jpg)