诊断事件变提权通道：Windows whesvc 缺失认证直通 SYSTEM（CVE-2026-85884·附PoC）

原创

赤霄攻防实验室
赤霄攻防实验室

赤霄攻防实验室

2026年10月17日 17:20
河北

去阅读

▲ 封面｜漏洞情报（制图：赤霄攻防实验室）

TL;DR

是什么：Windows「健康与优化体验服务」（whesvc）缺失关键函数认证——低权限代码经伪造的诊断 ETW 事件，让 LocalSystem 服务加载攻击者 Lua 模块（CVE-2026-85884，7.8 分）

有多糟：Windows 11 多个构建已被研究者完整复现（whoami 金丝雀直出 SYSTEM），触发型 PoC 公开可跑

怎么修：2026-10 安全更新已修复，无官方 workaround——升级是唯一解

看点：ETW 这个「排查工具」反向变成提权通道——诊断管道的信任边界错位，是系统组件设计课的典型案例

▲ 漏洞档案卡（制图：赤霄攻防实验室）

whesvc：藏在后台的健康管家

Windows「健康与优化体验服务」（Windows Health and Optimized Experiences Service，whesvc）是 Windows 11 引入的较新系统服务，以 LocalSystem 最高权限运行，配合诊断 Lua 引擎（WinDiag）做系统健康检查与体验优化。它的工作模式里有一个关键组件：服务会消费诊断类 ETW 事件，并根据事件内容动态加载 Lua 模块执行——本意是让健康检查逻辑可以灵活下发。

设计者可能没意识到，这个「灵活」恰恰埋下了祸根：ETW 事件的生产者没有任何认证机制，任何低权限进程（甚至 WPAD LPAC 沙箱内的代码）都能写出携带自定义 Lua 模块路径的事件。安全研究员（GitHub 用户 Beardhammer）在 Windows 11 x64 构建 26200.8457 与 29617.1000 上完整复现了从低权限到 SYSTEM 的全过程。

攻击链拆解：五个字节不到的信任错位

完整链条分五步：低权限代码伪造一条 Microsoft.Windows.Diagnostics.Lua ETW 事件，事件中携带攻击者控制的 Lua 模块路径；以 LocalSystem 运行的 whesvc 消费该事件时，既不验证事件生产者身份，也不限制模块必须位于受信目录，直接通过 WinDiag 引擎加载执行——Lua 模块内的代码由此获得 SYSTEM 权限。研究者的演示极为克制：让特权进程执行查询当前用户，输出 nt authority\system 并写入金丝雀文件作为证据。

两个工程细节值得注意：其一，该工作流有最小追踪间隔，完整演示需 35 秒以上——说明利用是「异步触发」型，攻击者需要耐心而非速度；其二，研究者验证了低权限用户与 WPAD LPAC 两条入口，后者意味着部分沙箱逃逸场景同样可达。MSRC 评级 7.8（High），已在 2026 年 10 月安全更新中修复，但官方未提供 workaround。

▲ 攻击链：ETW 事件变成提权通道（制图：赤霄攻防实验室）

为什么 ETW 会成为攻击面

ETW（Event Tracing for Windows）在安全行业的印象是「排查工具」——日志采集、威胁检测、EDR 遥测都靠它。但这次事件展示了它的另一面：当系统服务把 ETW 事件当作「可信指令输入」来消费时，事件管道就从观测通道变成了命令通道。信任边界错位的核心在于两件事叠加：事件生产者无认证 + 消费者会加载代码。

这类「诊断组件执行外部内容」的设计并非孤例——打印后台服务（Print Spooler）家族的多次提权、各种「帮助中心」「诊断向导」的历史漏洞，模式高度相似。给系统组件设计者的教训是一致的：诊断逻辑可以动态，但执行权必须静态——宁可让合法功能多一次显式确认，也不能让伪造事件的成本低于一次登录。

▲ 自测与处置清单（制图：赤霄攻防实验室）

▲ 研究者公开 PoC 仓库（来源：GitHub）

防御视角：四步处置

1. 立即安装 2026 年 10 月安全更新

MSRC 已在月度更新中修复该问题，无官方 workaround——补丁是唯一完整解。更新后重启确认 whesvc 服务状态正常。

2. 监控 Lua 模块加载与异常 ETW 写入

针对未打补丁的存量机器：监控 WinDiag 相关目录的 Lua 模块文件创建、whesvc 服务的异常子进程派生，以及低完整性进程高频写入诊断类 ETW 会话的行为——三者的组合是这次攻击链的指纹。

3. 排查利用痕迹

研究者 PoC 会在本地留下特征文件（金丝雀文本与临时 Lua 模块），公开利用代码的扩散让「已被本地测试过」的机器可能比想象中多。目录排查应纳入取证清单。

4. 审计「诊断组件」的执行面

对自研与企业内组件做一次专项审计：凡是「根据外部输入动态加载并执行代码」的诊断/健康检查/遥测逻辑，都要回答两个问题——生产者是谁、代码从哪来。答不出来，就是下一个 whesvc。

▲ NVD 漏洞详情页（来源：nvd.nist.gov）

参考来源

1. MSRC：CVE-2026-85884（2026-10 安全更新已修复）
2. NVD：CVE-2026-85884
3. 研究者 PoC 仓库：github.com/Beardhammer/CVE-2026-85884
4. 本号只读检测脚本（指纹判定，非完整验证）：https://github.com/Rubby2001/CVE-POCS/tree/main/CVE-2026-85884

免责声明：本文仅用于安全研究与防御交流；触发型 PoC 请仅在你拥有或获授权的测试机上使用。