LLMNR 为什么是投毒面
LLMNR 让主机在 DNS 解析失败时发起组播名称查询。这个机制可以被 Responder 这类工具投毒：攻击者在同一广播域内抢先应答，冒充目标主机并诱使受害机向它提交认证哈希。域环境里的名称解析本来就依赖 DNS，因此全量关闭 LLMNR 属于低成本高收益的收敛动作。
基本信息
| 注册表项 | HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient 下的 EnableMulticast |
|---|---|
| 基线值 | 0（关闭） |
| 适用平台 | Windows Server 与 Windows 10 及以上 |
| 风险等级 | 中 |
| 下发方式 | 组策略优先于本地注册表 |
典型使用场景
- 域内投毒面收敛的基础项
- 排查认证哈希被截获的路径
- 与 NBT-NS、mDNS 一起做统一收敛
- 通过组策略批量下发到所有主机
- 排查改了注册表却不生效的策略来源
关闭与核查
关闭与核查
$k='HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient'
New-Item -Path $k -Force | Out-Null # 策略键不存在时先创建
Set-ItemProperty $k -Name EnableMulticast -Value 0 -Type DWord # 关闭 LLMNR 多播
Get-ItemProperty $k -Name EnableMulticast # 复核取值
gpresult /h C:\gp.html # 排查策略的实际来源检查项与判读
| 检查项 | 含义 | 判读 |
|---|---|---|
| EnableMulticast | LLMNR 是否启用 | 取 0 表示已关闭 |
| 策略来源 | 组策略还是本地注册表 | 组策略优先级更高 |
| NBT-NS 状态 | 另一套名称解析机制 | 独立配置，需一起收敛 |
| mDNS 状态 | 与 LLMNR 并行的解析方式 | 同样可被投毒 |
| 事件日志 | 是否出现名称解析异常 | 关闭后的兼容性信号 |
没有 DNS 的小型网络依赖 LLMNR 做名称解析，关闭之后互访可能失败；域环境走 DNS 不受影响。
组策略推送优先于本地注册表：排查改了不生效时，先用 gpresult 看清策略的实际来源。
LLMNR、NBT-NS 与 mDNS 是三个独立的投毒面，只关其中一个作用有限，收敛时要一起评估。
关闭之后可以从主机侧再验证一次：在客户端做名称解析测试，确认解析走的是 DNS 而不是组播；配合抓包确认网络上不再出现 LLMNR 的组播查询。
如果暂时无法全量关闭，至少先在核心网段与服务器网段推行：投毒工具要在同一广播域内才有效，缩小广播域本身也能降低被投毒的概率。