SYSTEM 权限之上还有高手？深度拆解 Windows SmartScreen 飞地代码执行漏洞（CVE-2026-83498）

原创

Kit Chung
Kit Chung

安全圈动向

2026年10月15日 08:27
广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

大家好，做底层安全或者研究过 Windows 虚拟化安全（VBS）的朋友应该都知道，在现在的 Windows 11 架构里，哪怕攻击者已经拿下了普通内核、提权到了 SYSTEM，系统里依然有一块“净土”是碰不到的——那就是运行在 VTL1（虚拟信任级别 1） 里的 VBS Enclave（安全飞地）。

按理说，这是一道连内核都能防住的“铜墙铁壁”。但就在前天（10月13日），安全机构 Doyensec 披露了一个极其精彩的漏洞细节（CVE-2026-83498，CVSS 7.8，微软评级为 Critical 严重级提权漏洞）。研究人员仅凭一个看似鸡肋的 “4字节固定值写入” 配合一个 “时序竞态漏洞”，硬生生在 Windows SmartScreen 的安全飞地里跑起了自定义代码！

今天我就带大家一起扒一扒这个漏洞的底层逻辑，看看大佬们是怎么用“四两拨千斤”的手法，一步步把 VTL1 的隔离防线给撕开的。

一、 背景科普：什么是 VBS Enclave？这次挨打的又是谁？

在正式拆解利用链之前，我先用大白话跟大家捋一下这次的目标架构。

在开启了基于虚拟化的安全性（VBS）的 Windows 11 中，Hypervisor把系统切分成了不同的信任世界：

• VTL0（普通世界）：

我们平时跑的应用程序、甚至 NT 内核都待在这里。
* VTL1（隔离用户模式 / 安全世界）：

专门用来存放高度机密的数据和代码。

VBS Enclave（安全飞地） 本质上就是一个经过微软严格签名的 DLL 库。普通世界（VTL0）的程序可以加载它、调用它的接口，但一旦它跑起来，它的内存就被 Hypervisor 死死锁在了 VTL1 里。哪怕攻击者已经打穿了 VTL0 的内核、拿到了 SYSTEM 权限，也没法直接读取或篡改飞地里的半个字节。

那么，这次被攻破的飞地是干嘛的呢？
它的真身叫 SFAPE.dll，是 Microsoft Defender SmartScreen 增强型防钓鱼保护 的核心组件。

大家平时在记事本或者钓鱼网站里不小心输入自己的 Windows 登录密码时，系统之所以能弹窗警告你，全靠它：

1. 用户登录时，Windows 截获密码，把它转换成 Hash 值塞进 SFAPE.dll 飞地里保管。
2. 之后你每次敲键盘或粘贴文本，系统都会把内容发进飞地做比对。
3. 在 Windows 11 上，负责加载并调用这个飞地的宿主进程，正是鼎鼎大名的 lsass.exe（以 SYSTEM 权限运行）。

🎯 划重点：

这个漏洞不是远程 RCE，它需要攻击者已经在本地站稳了脚跟（比如拿到了能操作宿主进程 lsass.exe 的底层权限），然后以 VTL0 为跳板，跨界打穿平级的 VTL1“安全屋”。

二、 核心利用链拆解：从“鸡肋 Bug”到“任意代码执行”

说实话，我刚看到漏洞成因的第一步时，心里想的是：“就这？这也配叫漏洞？”但往下看完整个利用链，真的不得不服研究人员对内存布局和状态机的极致把控。整个过程可以分为“四步走”：

Step 1撕开口子：二次初始化引发的 4 字节越界写

漏洞的起点在 SFAPE.dll 飞地的 Initialize（初始化）函数上：

• 正常流程：

宿主程序第一次调用 Initialize 时，飞地会严格校验传入的内存地址，确保它属于外部宿主内存，防止越界覆盖飞地自己的内部数据。
* 漏洞触发：

当宿主程序第二次调用 Initialize 函数时，代码逻辑由于处理不当，直接跳过了地址安全检查，并向调用者控制的目标地址写入了一个固定的 4 字节错误码。

Doyensec 的研究人员自己都吐槽：如果管这叫“任意地址写”，那简直是吹牛过头了——毕竟你只能写死一个固定的 4 字节错误码。

Step 2精准打击：废掉飞地的“内存边界检查”

既然只能写固定的 4 个字节，怎么把它变成大杀器？答案是：打蛇打七寸。

飞地在运行过程中，之所以能分清“哪块内存是自己（VTL1）的，哪块内存是外部宿主（VTL0）的”，全靠内部维护的一个关键边界数值。研究人员在首次调用时精心构造参数，在第二次调用触发那 4 字节写入时，精准地把这 4 字节砸在了飞地用来区分自身内存与宿主内存的校验值上！

这一砸，直接把飞地的“敌我识别系统”给干废了。从此，飞地的地址安全检查彻底失灵，它会把飞地内部的高机密内存误认为是外部普通内存。

Step 3乾坤大挪移：利用时序漏洞劫持对象查找

废掉了边界检查后，还需要真正实现可控的读写。这时候，第二个漏洞——存在于另一个函数中的时序竞态漏洞登场了。

由于边界检查已经失效，研究人员利用这个 Timing Bug 触发了一次受控的内存清零。这次清零操作非常巧妙地篡改了飞地内部查找已存储对象的索引路径，相当于把飞地找东西的“路标”给转向了攻击者可控的区域。

Step 4终极收割：篡改代码执行表，实现飞地内代码执行

“路标”被劫持后，飞地在后续访问该对象时，就会顺着假路标产生完全受控的任意内存读写原语。

拿到任意读写之后，剩下的就是常规操作了：研究人员直接定位并替换掉了飞地内部用来决定“允许执行哪些代码”的函数跳转表（类似于虚表或分发路由表）。至此，防线彻底崩塌，攻击者成功在固若金汤的 VTL1 飞地内部执行了任意代码！

💡 补充说明：

Doyensec 的这项研究主要在实验室环境下作为 PoC 验证了“打破飞地隔离并执行代码”，并未直接演示还原或窃取用户的明文密码（毕竟里面存的是 Hash）。微软在安全公告中将其影响定性为“飞地内数据泄露或代码执行”。

三、 微软的补丁方案与一个细思极恐的“后门隐患”

微软在 2026年9月8日 发布的累积更新 KB5124008（针对 Windows 11 24H2 和 25H2）中修复了这个漏洞，并且表示微软内部安全团队也独立发现了该问题。

研究人员通过二进制 Diff 对比了补丁前后的 SFAPE.dll，发现微软做了三件事：

1. 修补写入校验：

在第一次写入发生前，强制加上了严格的地址边界检查。
2. 收紧竞态逻辑：

加固了那个被 Timing Bug 利用的函数。
3. 更新加载策略：

随补丁下发了一条新的安全策略，直接禁止系统加载旧版本的脆弱 SFAPE.dll（防降级攻击）。

但是！故事到这里还没有结束，真正让我觉得后背发凉的是最后一点：

大家应该都听说过 BYOVD（自带脆弱驱动攻击）——黑客随便找一个有微软合法签名、但存在历史漏洞的老旧驱动加载进系统，就能名正言顺地绕过内核保护。为此，微软专门维护了一个庞大的“脆弱驱动黑名单”。

而在 VBS 飞地领域，同样存在一种名为 BYOVE（自带脆弱飞地） 的高级攻击手法！此前 Akamai 和 Outflank 的安全研究员就曾演示过：利用带有微软合法签名但存在漏洞的旧版飞地 DLL，把恶意代码和数据藏进 VTL1 飞地里，由于连系统内核和顶尖的 EDR都无法窥探 VTL1 的内存，恶意软件直接实现了“降维隐身”！

Doyensec 指出，Windows 目前根本没有像封禁脆弱驱动那样，建立一套通用的“脆弱飞地全局黑名单机制”！

• 9月份的补丁策略，仅仅是“头疼医头”，单独拉黑了旧版的 SFAPE.dll。
• 早在 2023 年就被曝出存在类似读写漏洞的旧版 Microsoft Edge 飞地（CVE-2023-36880），直到今天依然被允许在最新的 Windows 系统上正常加载！

至于微软这是有意为之（怕影响兼容性）还是单纯的疏漏，目前还不得而知。但只要这些带签名的“老病号”飞地还能被随便加载，BYOVE（自带脆弱飞地隐身术） 这扇大门就依然向高级攻击者敞开着。

四、 总结与防范建议

最后给大家简单总结一下：

1. 技术启示：

在高度隔离的架构（如 VBS Enclave、SGX、TrustZone）中，跨界接口（Marshaller/ECALL）的状态机管理与指针边界校验是命门。哪怕是一个固定值的 4 字节越界写，只要落点在元数据或边界基址上，就能引发雪崩效应。
2. 排查与修复：

此漏洞没有临时缓解措施（Workaround），唯一方案就是打补丁。请各位运维和安全同行检查手头的 Windows 11 24H2 / 25H2 机器，确保已安装 2026年9月累积更新（KB5124008） 或更新版本的补丁。
3. 防守新思路：

对于做蓝队和 EDR 研发的朋友来说，既然微软还没搞定全局的脆弱飞地黑名单，我们在做主机监控时，不妨重点审计一下宿主进程异常加载历史遗留 Enclave DLL（如存在 CVE-2023-36880 的组件）的行为，提前防一手 BYOVE 攻击。

💬 互动话题：大家对这次 VBS 飞地被破防有什么看法？你们觉得 BYOVE 会成为接下来免杀和对抗的新主流吗？欢迎在评论区一起交流！觉得文章有干货的话，别忘了点个 “赞” 和 “转发” 支持一下~