CVE-2026-124194 解析：Outlook 零日泄露 NTLM 哈希，CISA 确认在野利用

导语：11 月 10 日，微软给 Outlook 的一个”欺骗”漏洞打上中危标签，同一天 CISA 就把它塞进了在野利用清单。用户在 Outlook 里双击打开一个特制的消息文件，客户端连上攻击者的服务器时，那个平时会跳出来的外部内容警告框不见了——NTLMv2 哈希就这么被送了出去。

漏洞本体：6.5 分，中危，但微软自己标了”已检测到利用”

CVE-2026-124194，官方标题是 Microsoft Outlook Spoofing Vulnerability（微软 Outlook 欺骗漏洞），CWE-356——产品界面没有对危险行为发出警告。

CVSS 3.1 打 6.5 分，向量是 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N。分数低在两处：不需要权限、攻击复杂度低；影响面只算机密性高，完整性可用性都是无。真正要命的是 C:H。微软在 FAQ 里写得很直白：这个漏洞会把用户的 NTLMv2 哈希泄露给攻击者，对方可以拿它来冒充用户。

11 月补丁月一共修了一千多个漏洞，这是微软唯一标注 Exploitation Detected 的一个。CISA 当天入库，联邦机构的整改期限是 11 月 24 日。

攻击链：三个动作，零代码

第一，投递。未认证攻击者发出一个特制的消息文件，.msg、.oft 都算，再想办法骗用户点开。邮件附件还是下载链接，微软没说。

第二，触发。用户双击打开，Outlook 会去连接攻击者控制的网络位置，但平时那个”是否加载外部内容”的警告框不弹。这就是 CWE-356 的含义——不是不需要交互，是交互提示被吞掉了，界面装作什么都没发生。

第三，收割。Windows 对远端服务器发来的 NTLM challenge，用当前登录账号的 NTLMv2 响应签了名，响应就过去了。攻击者拿到的是哈希，不是明文密码。

预览窗格不是攻击面，微软明确说了，用户必须真的把文件打开。

链路细节决定了防护优先级：Windows 上连远程路径默认走 SMB 的 TCP 445，445 走不通而 WebClient 服务在运行，就自动回落到 WebDAV（HTTP/HTTPS）。两条路都会把 NTLM 凭据主动递出去。

手法和 2023 年的 CVE-2023-23397 是一个模子刻出来的，那次走日历提醒，连点都不用点。这次要用户点一下，分数就低一档，性质完全相同。

拿到哈希之后，攻击者有两条路

离线爆破。 NTLMv2 响应不是密码，但弱口令和中等长度口令打下来很快。密码一旦还原，哪里都能登，包括同步到 Entra ID 的 Microsoft 365 账号。

实时转发（relay）。 把这份认证原封不动转给另一台服务器，直接以用户身份登录。对不做签名、不做通道绑定的服务有效：不强制 SMB 签名的服务器、不强制签名和 channel binding 的 LDAP、AD CS 的 Web Enrollment（没开 EPA）、Exchange 没开 Extended Protection for Authentication。

最坏的情况是域管或 helpdesk 账号的哈希。relay 到 AD CS 的 Web Enrollment，可以换出一张证书，域管密码改了证书照样能用——这是把一次凭据泄露放大成长期后门。

谁在暴露面里

按优先级排：

在管理机上收邮件的高权限账号，域管、helpdesk、IT 服务账号；
允许出网 445 的网络，封了 445 但留着 WebDAV 的同样中招；
域里没有 relay 防护：AD CS Web Enrollment 没开 EPA、LDAP 没签名、SMB 没强制签名；
没收到 11 月 Office 更新的机器，Semi-Annual Enterprise 通道被更新策略按住的、手工打补丁的批量授权版；
Office 2016 和 2019，不在修复清单里，2025 年 10 月已经停止支持，属于躺着挨打。

不受影响的：新版 Outlook for Windows、网页版 Outlook、Mac 版和移动端。

修复版本：Microsoft 365 Apps 当前通道 2610 build 20527.20196，月度企业通道 20527.20194，半年企业通道 20527.20192；Office LTSC 2024 为 16.0.17932.21140，LTSC 2021 为 16.0.14334.21048。走的是 Office 更新通道，不是 Windows Update，Windows Update 那边不会替你装。

顺手辟个谣：昨天那次宕机不是攻击

11 月 12 日，微软 365 大面积宕机，Outlook、Teams、Copilot、SharePoint 全趴，Downdetector 峰值超过 13 万条报告。推特评论区一堆人在问”是不是被打了”。微软最初归因于多区域负载偏高，后来查清了：不是流量涨的，是一批服务器意外下线，把剩下的基础设施压垮。目前没有证据说这次宕机和这个零日有关。

该修的补丁还是要修，但别拿宕机当借口拖。

防守：从最疼的那一刀开始

先打补丁，再把更新截止策略配死，别给用户推迟的余地。然后按这个顺序切：

边界防火墙和主机防火墙同时封出网 445、139，笔记本用外网 Wi-Fi 时的本地防火墙也别放过。
限制对外 NTLM。组策略里 “Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers” 先设成 Audit all，看清事件再改成 Deny all 并给必要的服务器开例外。注册表位置 HKLMSYSTEMCurrentControlSetControlLsaMSV1_0 下的 RestrictSendingNTLMTraffic，1 是审计，2 是拒绝。
高权限账号放进 Protected Users 组。该组成员不能用 NTLM 认证，哈希压根就不会外发。
断掉 relay 路径。域控强制 LDAP 签名和 channel binding，AD CS Web Enrollment 和 Exchange 打开 EPA。
停掉不需要的 WebClient 服务，堵住 445 之后的 HTTP 回落。
在邮件网关拦下外部发件人的 .msg、.oft 附件，或者用 Defender for Office 365 的附件策略兜住。这条是第三方研究者的建议，不是微软的临时方案。

狩猎方向很明确，微软这次一个 IOC 都没公布，只能自己查：

// Outlook 主动连公网 SMB，正常情况下不该有
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName =~ "outlook.exe"
| where RemotePort in (445, 139) and RemoteIPType == "Public"
| project Timestamp, DeviceName, AccountName, RemoteIP, RemotePort

// 445 被封时的 WebDAV 回落特征
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "rundll32.exe"
| where ProcessCommandLine has "davclnt.dll" and ProcessCommandLine has "DavSetCookie"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine

再往上一层，用 Defender 的 DeviceTvmSoftwareVulnerabilities 按 CveId == "CVE-2026-124194" 拉出还没修的机器；用安全日志里的 4624 事件筛 LogonType 3 且认证包为 NTLM 的登录，对比过去 30 天的基线，账号突然出现在没用过的机器或 IP 上，基本就是哈希被用了。