当AI成为黑客军火库，600美元成本如何撬动整个Windows驱动生态的安全根基？
前沿的大型语言模型在开源项目安全审计领域已经证明了其非凡价值。基于人工智能的研究人员发现了数十个（甚至可能数百个？）人类研究员多年来忽视的关键CVE漏洞。
我与Eyal Kraft有一个更深层的担忧：那些从未有人关注过的目标怎么办？全球数百万台设备上运行着TB级别的二进制文件，这些文件从未被任何人类研究人员审视过。很可能永远也不会有人去审查它们。
我们决定通过构建一个简单的测试框架，将智能体集群技术应用于大规模二进制零日漏洞研究中，以此来进行全面验证。我们的目标是Windows内核驱动程序。每一台OEM设备都预装了成千上万个来自第三方的 .sys 文件，这些文件均由其供应商和微软进行加密签名，但代码质量却令人担忧。
迄今为止，围绕Windows驱动程序的大部分安全研究和缓解措施都集中在故意恶意的或类似Rootkit的驱动程序上，这些二进制文件将不安全的API（如 MmMapIoSpace 或原始MSR/端口I/O）作为有意的后门暴露出来。微软的易受攻击驱动程序阻止列表和LOLDrivers等社区项目收录了这些已知的有害驱动程序，并阻止其加载。但这忽略了一整类漏洞：存在于其他合法驱动程序中的非故意内存损坏缺陷。这些不是后门，而是由合法厂商编写的常见软件缺陷。没有任何阻止列表能够捕获它们，因为从来没有人审计过它们的代码，阻止它们加载也就意味着用户将无法使用自己的GPU、键盘或网络摄像头。
为了以经济高效的方式完成这项工作，我们构建了一个自主平台。该平台从互联网各个角落抓取驱动程序，对其进行分类和标记，进行反编译，并利用智能体集群以最低的令牌消耗和最大程度的纯Python代码识别内存损坏漏洞。通过大量使用中小型语言模型进行分析，整个项目的成本仅为 600美元，平均每个分析目标约 3美元。
从一个包含 1,873 个二进制文件的数据集中，我们在来自数十家供应商的 158个 不同的驱动程序二进制文件中发现了 521处 潜在漏洞。其中，我们手动确认并向包括联想、富士通、IBM、英特尔、AMD、Silicom、英伟达和戴尔在内的供应商报告了15处漏洞。毫不意外，他们的反应普遍迟缓。尽管大多数供应商都确认漏洞存在（我们总是提供了截图和/或视频证明），但迄今为止，只有一个漏洞得到了修补并被分配了CVE编号（CVE-2025-65001，感谢富士通PSIRT对我们提交的处理）。
同样值得注意的是，没有一家PSIRT认为他们有责任向微软通报这些易受攻击的驱动程序，以便将其添加到易受攻击驱动程序阻止列表中或吊销其证书。
在所有提交的漏洞经过90多天的负责任等待期后仍无修复的情况下，我们决定发布完整的已分析驱动程序哈希值集合，以便防御者可以检查其环境中是否存在受影响的二进制文件。如果你是供应商、客户或安全专业人士，希望了解更多细节，欢迎通过 [email protected] 联系我们。
🛠️ 我们的方法论：五阶段自动化分析流水线
我们构建的流程运行一个五阶段的自动化流水线：
-
大规模抓取（Scrape）： 我们覆盖了微软更新目录、各大OEM厂商网站以及公共驱动程序资源库。总共收集了跨越 1,873个 独特二进制版本的 1,654个 不同的驱动程序。
-
智能预处理（Preprocess）： 包括CAB文件提取、PE元数据分析以及目录签名解析。此阶段计算哈希值、识别驱动程序入口点，并依据攻击面指标（IOCTL分发复杂性、设备对象数量、是否存在
METHOD_NEITHER处理程序）对目标进行优先级排序。为了聚焦分析，我们过滤掉了需要复杂设置（主要是非USB/PCIe设备）的驱动程序和旧版本（抱歉了，WinXP用户……）。 -
核心自动化分析（Analyze）： 流程核心环节。针对每个目标驱动，我们启动一个自动化审计框架（以今天的眼光看，我们很可能会直接使用集成了自定义技能的 ClaudeCode / OpenClaw 之类的智能体）。一个由LLM智能体组成的“委员会”开始迭代审计二进制文件：
- 反编译智能体： 重命名匿名函数，推断功能，修复动态调用，利用上下文推断以便审计者能够理解程序逻辑。
- 攻击面分析智能体： 根据反编译后的代码，识别值得审计的功能函数。
- 代码审计智能体： 检查每个目标函数是否存在内存损坏漏洞，遍历已修复的调用图以理解数据流。
发现的问题会以结构化的JSON格式记录，包含漏洞类型、严重性、置信度、影响评估以及触发漏洞的逆向代码路径。
我们通过OpenRouter混合使用多种模型，优化目标是“每令牌发现的漏洞数”而非单一模型的绝对精确度。平均而言，每个目标的API调用成本大约为3美元。
-
虚拟化环境与驱动加载（Virtualize）：（当我们积攒了100多个待验证的发现时，这成为了瓶颈）。我们创建了一个基于虚拟机的定制化测试框架，用于在由智能体控制的内核调试Windows机器上加载驱动程序。有些驱动程序需要特定的USB/PCIe物理设备，而我们显然没有。我们定制了QEMU来暴露虚拟设备，并使用LLM来虚拟化足够的初始化握手过程，以便驱动程序能够加载并暴露其IOCTL接口。
-
自动化验证与漏洞复现（Validate）： 利用我们的框架，我们可以针对每个发现迭代式地生成Python概念验证脚本，实质上进行定向模糊测试直到触发系统崩溃。随后分析蓝屏崩溃转储，以确认漏洞确实被正确触发（我们发现了许多AI“幻觉”生成的报告——模糊测试器成功导致了崩溃，但原因并非最初识别的漏洞，这造成需要人工调试的隐蔽假阳性）。
-
人工核验与报告提交（Report）： 我们手动验证了自动化报告，在“真实”的Windows 11机器上运行我们的PoC脚本，并确保漏洞描述全面且与事实相符。然后，我们自行将其提交给相关厂商的PSIRT。请注意，我们并未将大多数漏洞武器化为完整的本地提权漏洞利用，而是根据我们的经验评估其在真实场景中被利用的可能性。
在我们数据集的1,654个驱动中，基于预处理阶段的启发式规则，我们筛选出 202个高风险驱动 进行完整的分析。其余的驱动程序已排队等待未来的分析批次。
📊 令人震惊的分析结果
数据集概览
- 收集的二进制文件总数：1,873个
- 独立驱动程序总数：1,654个
- 已完成分析的二进制文件：202个
- 总发现数：521处
- 包含发现的独立二进制文件：158个
- 手动确认并上报的发现：15处
- 已通知的供应商数量：8家
- 已分配的CVE编号：1个（CVE-2025-65001）
- 项目总成本：约600美元
- 单目标分析成本：约3美元
- 单漏洞发现成本：约4美元
漏洞类型分布
- 任意内存读取：144处 (占27.6%)
- 堆溢出：111处 (占21.3%)
- 其他类型：82处 (占15.7%)
- 整数溢出：33处 (占6.3%)
- 栈溢出：26处 (占5.0%)
- 任意内存写入：92处 (占17.7%)
- 释放后使用：22处 (占4.2%)
- 类型混淆：11处 (占2.1%)
任意内存访问漏洞（读+写）占所有发现的 45.3%，鉴于IOCTL处理程序经常在用户和内核缓冲区之间复制数据且不进行边界检查，这个比例并不令人意外。这些漏洞大多源于堆缓冲区处理不当或有缺陷的反序列化逻辑。
严重性与置信度评级
- 严重：149处 (占28.6%)
- 高危：220处 (占42.2%)
- 中危：149处 (占28.6%)
- 低危：3处 (占0.6%)
智能体对每个发现给出了严重性和置信度评级。 70.8% 的发现被评为高危或严重级别，其中 78.7% 的发现具有高置信度，19.6%为中等置信度，仅1.7%为低置信度。
误报率估算
经过人工分析，我们估计在高/严重置信度的发现中，误报率约为60%。其中大多数是确实存在缺陷的代码模式，但利用起来不切实际（例如，一个只能泄露填充字节的越界读取，或一个需要特殊系统条件才能触发的写入）。根据此进行调整，我们估计在总共521个发现中，有超过100个发现代表了在当前的Windows 11 x64系统上真正可利用的、导致本地权限提升的漏洞。
典型漏洞模式分析
举个例子，AMD的Crash Defender驱动程序（amdfendr.sys）暴露了一个全局可写的设备对象，该设备支持使用专有操作码发送IOCTL请求。这些对设备的操作在访问内部传输队列描述符时未进行适当的长度验证，从而可能导致堆损坏。通过内存池精心布局，这可以成为实现任意内核数据访问，甚至内核代码执行的路径。即使不这样做，它也可以从任何用户账户可靠地触发系统蓝屏死机。
该驱动程序预装在Windows的AMD系统上，包括运行在AMD实例上的AWS EC2 Windows亚马逊机器镜像中。这意味着攻击面甚至延伸到了云端工作负载。
相同的常见二进制漏洞利用模式占据了发现的大多数。目前尚不清楚这是因为驱动程序开发团队完全跳过了现代安全工具的检测，还是因为WDK（Windows驱动开发工具包）和KMDF（内核模式驱动框架）高度多态的性质，使得前LLM时代的静态分析变得不可行。
已上报的漏洞情况
我们手动确认并向8家供应商报告了15处漏洞，所有漏洞的CVSS评分均在7分以上。所有这些漏洞的披露时间均已超过90天。
已上报发现的平均CVSS得分：8.2（高危）
大多数缺陷可从标准的、无特权的用户账户利用。大多数漏洞利用仅需要打开设备句柄（通常全局可访问）并发送一系列 DeviceIoControl 调用。Windows驱动程序都由微软签名，这意味着即使从未安装过相关产品，攻击者也可以通过“自带易受攻击驱动程序”技术在任意Windows机器上旁加载这些驱动（这需要管理员权限，因此此类本地提权攻击是更受限制的“管理员->内核”提权）。
🤝 来自厂商PSIRT的缓慢响应
来自供应商PSIRT的响应令人失望。尽管我们提供了包含视频概念验证演示的利用过程，但仍有几家供应商直接拒绝了我们的报告。其他一些供应商承认包含这些驱动程序的产品已进入生命终止阶段，但并未吊销驱动程序的签名证书，这使得“自带易受攻击驱动程序”的攻击面在所有Windows机器上依然存在。
迄今为止，只有富士通PSIRT成功地修补了漏洞并分配了CVE编号（CVE-2025-65001）。我们正在持续关注，如果有其他CVE编号被分配，我们将更新信息。
💡 核心结论与行业警示
-
AI辅助的二进制漏洞挖掘不仅可行，而且极其廉价。 花费600美元和几周时间，就构建了一个自动化循环系统。这套系统若要人类团队进行专注的逆向工程，可能需要数年时间。单漏洞4美元的成本意味着任何有动机的攻击者都能负担得起对整个Windows驱动程序生态系统进行扫描。
-
智能体流程需要“闭环”反馈。 尽管这项研究是在Opus-4.6和GPT-5.3等先进模型发布之前完成的，但最大性能提升的实现来自于“封闭循环”——通过我们基于虚拟机的内核调试框架，向智能体直接提供关于漏洞利用成功与否的反馈。那些能够反复尝试触发系统蓝屏的智能体，就是未来的模糊测试器。在足够的算力支持下，它们若落入不法之手，其危险性将是现在的百倍以上。
-
Windows内核驱动程序生态系统的状况比大多数人想象的更糟糕。 第三方内核驱动程序仍然是最后几个在核心模式下运行、且经过最少安全检查的C代码堡垒之一。代码签名仅保证真实性，不保证安全性。我们60%的误报率背后，依然意味着在AMD、英特尔、英伟达、戴尔、联想和IBM等主流供应商的驱动程序中，潜藏着超过100个很可能被利用的权限提升漏洞。
-
现有的PSIRT流程无法应对这种规模的漏洞报告量。 大多数供应商的安全团队其结构是为了处理来自人类研究人员的、每季度寥寥数份的报告而建立的。当一个自动化系统同时为多条产品线产生成几十上百个有效发现时，现有的接收和处理流程就会崩溃。报告会被拒绝、错误路由或被降低优先级。随着这些工具的不断改进，漏洞发现率与漏洞修复率之间的差距只会越拉越大。
-
我们正在发布哈希值列表，以帮助客户进行自我防护。 我们已经超过了负责任的漏洞披露时间窗口，因此我们正在以一种安全的方式公开发布我们的威胁指标。如果你是需要更多信息的PSIRT、CERT或安全团队，请通过[email protected]联系我们，我们将为你提供帮助。
⚠️ 防御建议与工具拓展
对于企业安全团队的防护建议
- 驱动程序审计清单化： 建立企业内部驱动程序许可清单，仅允许运行经过严格审查和必要安全测试的驱动程序。利用微软的驱动程序阻止列表功能，并考虑扩展自定义规则。
- 应用控制策略（如Windows Defender Application Control）： 实施应用程序控制策略，限制只有经过批准、有签名的内核驱动程序才能加载。这是防御BYOVD攻击最有效的方法之一。
- 驱动证书监控： 监控驱动程序签名证书的状态。如果供应商宣布产品EOL但未吊销证书，应在内部阻止列表中主动添加相关驱动的哈希值。
- 定期驱动资产评估： 使用工具定期扫描企业环境中的所有内核驱动，并与公开的漏洞数据库（如LOLDrivers项目）进行比对。也可以利用本文最后提供的双哈希计算方法进行内部检查。
对于安全研究员的工具与技术拓展
除了文章中提到的工具链，以下资源和工具可以进一步丰富驱动的自动化安全分析：
- 漏洞模式识别与验证工具：
- SLAKE：一个基于符号执行的自动化内核驱动漏洞挖掘框架，可以发现多种内存破坏漏洞。
- Dr. Checker：一个结合静态分析和动态符号执行的工具，专注于发现Windows和Linux内核驱动中的安全漏洞。
- DIFUZE：谷歌发布的针对Linux内核驱动模糊测试的工具，其设计思想值得借鉴。
- 高效的模糊测试平台：
- Boofuzz：一个开源的网络协议模糊测试框架，通过改造可以用于对驱动程序的IOCTL接口进行模糊测试。
- WinAFL：针对Windows二进制文件的AFL（模糊测试器）移植版本，可以用于对驱动用户态接口或内核模式回调进行模糊测试。
- 现代化驱动逆向工程辅助平台：
- Ghidra + 脚本化分析：美国国家安全局开源的Ghidra逆向工程工具，结合Python脚本可以实现驱动的自动化初步分析，如识别IOCTL分发函数、设备对象创建等。
- IDA Pro + 插件生态：利用IDAPython编写脚本，自动化提取驱动关键数据结构，或与动态调试工具（如Windbg）配合进行漏洞验证。
- 云端自动化分析服务探索：
- 随着云原生安全研究的发展，可考虑构建基于容器/Kubernetes的云端驱动分析集群，将抓取、反编译、智能体分析、安全沙盒验证等各个模块微服务化，实现大规模、高并发的驱动生态安全监控。
- 深入利用：从崩溃到提权
- 对于验证成功的漏洞，研究者可以继续使用内核调试器（WinDbg） 和专门的漏洞利用开发框架（如HEVD—— HackSys Extreme Vulnerable Driver 的利用练习环境）来深入理解漏洞原理并开发稳定的提权利用。关注池风水（Pool Feng Shui）、任意地址读写原语构建、令牌窃取（Token Stealing） 等高级利用技术，并思考在Windows 11最新安全缓解措施（如KASLR、kCFG、HVCI）下的绕过方法。
安全之路漫漫，攻防博弈不断升级。AI正在以前所未有的速度和规模重塑漏洞挖掘的版图。对于防御者而言，这既是严峻的挑战，也蕴含着通过AI技术提升自身防御自动化水平的巨大机遇。未雨绸缪，方能安如磐石。