Forget vulnerable drivers – Admin is all you need

Introduction 介绍

Bring Your Own Vulnerable Driver (BYOVD) is an increasingly popular attacker technique wherein a threat actor brings a known-vulnerable signed driver alongside their malware, loads it into the kernel, then exploits it to perform some action within the kernel that they would not otherwise be able to do. After achieving kernel access, they may tamper with or disable security software, dump otherwise inaccessible credentials, or modify operating system behavior to hide their presence. Joe Desimone and I covered this in-depth, among other kernel mode threats, at Black Hat USA 2018. Employed by advanced threat actors for over a decade, BYOVD is becoming increasingly common in ransomware and commodity malware.
自带易受攻击的驱动程序 （BYOVD） 是一种越来越流行的攻击者技术，其中威胁参与者将已知易受攻击的签名驱动程序与其恶意软件一起，将其加载到内核中，然后利用它在内核中执行一些他们无法执行的操作。获得内核访问权限后，它们可能会篡改或禁用安全软件、转储无法访问的凭据或修改操作系统行为以隐藏其存在。Joe Desimone和我在Black Hat USA 2018上深入介绍了这种内核模式威胁。BYOVD 被高级威胁行为者使用十多年，在勒索软件和商品恶意软件中变得越来越普遍。

Driver Signing Enforcement (DSE), first deployed in 2007 by Windows Vista x64, was the first time that Microsoft attempted to limit the power of admins. With DSE in place, admins could no longer instantly load any code into the kernel. Admin restrictions grew over time with the rollout of Boot Guard, Secure Boot, and Trusted Boot to protect the boot chain from admin malware, which could previously install their own boot loaders / bootkits.
驱动程序签名强制 （DSE） 于 2007 年由 Windows Vista x64 首次部署，这是Microsoft首次尝试限制管理员的权力。有了 DSE，管理员就无法再立即将任何代码加载到内核中。随着启动保护、安全启动和受信任启动的推出，管理员限制随着时间的推移而增加，以保护启动链免受管理员恶意软件的侵害，这些恶意软件以前可以安装自己的启动加载程序/启动工具包。

Further limiting admins’ power, Microsoft recently deployed the Vulnerable Driver Blocklist by default, starting in Windows 11 22H2. This is a move in the right direction, making Windows 11 more secure by default. Unfortunately, the blocklist’s deployment model can be slow to adapt to new threats, with updates automatically deployed typically only once or twice a year. Users can manually update their blocklists, but such interventions bring us out of “secure by default” territory.
为了进一步限制管理员的权力，Microsoft最近默认部署了易受攻击的驱动程序阻止列表，从 Windows 11 22H2 开始。这是朝着正确方向迈出的一步，默认情况下使 Windows 11 更安全。不幸的是，阻止列表的部署模型在适应新威胁方面可能很慢，通常每年只自动部署一次或两次更新。用户可以手动更新他们的阻止列表，但这种干预使我们脱离了“默认安全”的领域。

Security boundaries 安全边界

When determining which vulnerabilities to fix, the Microsoft Security Response Center (MSRC) uses the concept of a security boundary, which it defines as follows:
在确定要修复的漏洞时，Microsoft安全响应中心 （MSRC） 使用安全边界的概念，它定义如下：

A security boundary provides a logical separation between the code and data of security domains with different levels of trust. For example, the separation between kernel mode and user mode is a classic and straightforward security boundary.
安全边界在具有不同信任级别的安全域的代码和数据之间提供逻辑分离。例如，内核模式和用户模式之间的分离是经典且直接的安全边界。

Based on this definition, one might be inclined to think that malware running in user mode should not be able to modify kernel memory. The boundary is “straightforward” after all. Logically, any violation of that boundary should be met with a remedial action such as a patch or blocklist update.
基于此定义，人们可能倾向于认为在用户模式下运行的恶意软件不应该能够修改内核内存。毕竟，边界是“直截了当”的。从逻辑上讲，任何违反该边界的行为都应通过补救措施来满足，例如补丁或阻止列表更新。

Unfortunately, the situation gets murkier from here. That document later states that administrator-to-kernel is not a security boundary, with the following explanation:
不幸的是，情况从这里变得更加模糊。该文档后来指出，管理员到内核不是安全边界，并附有以下解释：

Administrative processes and users are considered part of the Trusted Computing Base (TCB) for Windows and are therefore not strong [sic] isolated from the kernel boundary.
管理进程和用户被视为 Windows 可信计算库 （TCB） 的一部分，因此与内核边界隔离并不强 [原文如此]。

At this point, we have two seemingly conflicting viewpoints. On one hand, MSRC states that admin-to-kernel is an indefensible boundary and not worth fixing. On the other hand, Microsoft is attempting to defend this boundary with mechanisms such as Driver Signing Enforcement, Secure Boot, and the Vulnerable Driver Blocklist. Because the defense is incomplete, MSRC instead calls them “defense-in-depth security features.”
在这一点上，我们有两种看似相互冲突的观点。一方面，MSRC指出，管理员到内核是一个站不住脚的边界，不值得修复。另一方面，Microsoft 尝试使用驱动程序签名强制、安全启动和易受攻击的驱动程序阻止列表等机制来捍卫此边界。由于防御不完整，MSRC 将其称为“深度防御安全功能”。

MSRC similarly does not consider admin-to-PPL a security boundary, instead classifying it as a defense-in-depth security feature. More on this in the next section.
同样，MSRC 不会将管理员到 PPL 视为安全边界，而是将其归类为深度防御安全功能。下一节将对此进行详细介绍。

The rest of this article will refer to MSRC and Microsoft separately. While MSRC is part of Microsoft, Microsoft is a much larger entity than MSRC; they shouldn’t be equated.
本文的其余部分将分别引用 MSRC 和Microsoft。虽然 MSRC 是 Microsoft 的一部分，但Microsoft是一个比 MSRC 大得多的实体;它们不应该被等同起来。

Exploiting vulnerabilities
利用漏洞

In September 2022, I filed VULN-074311 with MSRC, notifying them of two zero-day vulnerabilities in Windows: one admin-to-PPL and one PPL-to-kernel. I provided source code for both exploits. The response concisely indicated that they understood the vulnerabilities and declined to take any further action, as stated below:
2022 年 9 月，我向 MSRC 提交了 VULN-074311，通知他们 Windows 中存在两个零日漏洞：一个是管理员到 PPL 漏洞，另一个是 PPL 到内核漏洞。我为这两个漏洞提供了源代码。答复简明扼要地表明，他们了解这些漏洞，并拒绝采取任何进一步行动，如下所述：

The research describes a multi-step attack that leverages a PPL bypass to gain kernel code execution. Note that all of the proposed attacks do require administrative privileges to perform and thus the reported issue does not meet our bar for immediate servicing. We do not expect any further action and will proceed with closing out the case.
该研究描述了一种多步骤攻击，该攻击利用PPL绕过来获得内核代码执行。请注意，所有建议的攻击都需要管理权限才能执行，因此报告的问题不符合我们的立即服务标准。我们预计不会采取任何进一步行动，并将继续结案。

In this parlance, “servicing” means “patching.” Their response is consistent with the aforementioned policy and their historical treatment of the admin-to-kernel boundary. Their behavior is consistent too – it’s been over 11 months and they still haven’t patched either vulnerability. I find it fascinating that Microsoft is willing to block drivers that can modify kernel memory but MSRC is unwilling to service vulnerabilities that can do the same.
在这种说法中，“服务”意味着“修补”。他们的响应与上述策略以及他们对管理员到内核边界的历史处理一致。他们的行为也是一致的 – 已经超过11个月了，他们仍然没有修补任何一个漏洞。我发现有趣的是，Microsoft愿意阻止可以修改内核内存的驱动程序，但 MSRC 不愿意为可以修改内核内存的漏洞提供服务。

When I announced my Black Hat Asia 2023 talk, PPLdump Is Dead. Long Live PPLdump, on Twitter five months after the MSRC report, the Windows Defender team quickly reached out to learn more. It seems that MSRC closed the case without telling the Defender team, whose products rely on PPL to protect hundreds of millions of Windows machines, about a PPL bypass. This type of miscommunication mustn’t be allowed to continue.
当我宣布我的黑帽亚洲 2023 演讲时，PPLdump 已死。PPLdump万岁，在MSRC报告发布五个月后，Windows Defender团队迅速联系以了解更多信息。MSRC似乎在没有告诉Defender团队的情况下结案，该团队的产品依靠PPL来保护数亿台Windows机器，关于PPL绕过。不能允许这种沟通不畅继续下去。

Turnkey tooling 交钥匙模具

EDRSandBlast is a tool that weaponizes vulnerable drivers to bypass AV & EDR software. It can modify kernel memory to remove hooks installed by AV & EDR, temporarily or permanently blinding them to malicious activity on the system.
EDRSandBlast是一种工具，它将易受攻击的驱动程序武器化以绕过AV和EDR软件。它可以修改内核内存以删除AV和EDR安装的钩子，暂时或永久地使它们对系统上的恶意活动视而不见。

As I discussed in my Black Hat Asia talk, MSRC has de-facto shown that they are unwilling to service admin-to-PPL and admin-to-kernel vulnerabilities and that it requires the existence of turnkey tooling on GitHub to motivate Microsoft to action. This led me to release the admin-to-PPL exploit PPLFault and admin-to-kernel exploit chain GodFault as easy-to-use tools on GitHub. For brevity, below we’ll call them “PPL vulnerability” and “kernel vulnerability”, respectively.
正如我在黑帽亚洲演讲中所讨论的那样，MSRC 事实上已经表明他们不愿意为管理员到 PPL 和管理员到内核漏洞提供服务，并且它需要在 GitHub 上存在交钥匙工具来激励Microsoft采取行动。这促使我在GitHub上发布了admin-to-PPL漏洞利用PPLFault和admin-to-kernel 漏洞利用链GodFault作为易于使用的工具。为简洁起见，下面我们分别称它们为“PPL 漏洞”和“内核漏洞”。

In this same “turnkey tooling” spirit, to highlight the inconsistency of blocking known-vulnerable drivers while simultaneously refusing to patch admin-to-kernel exploit chains, I am releasing a version of EDRSandBlast that integrates PPLFault to demonstrate the same result, sans vulnerable drivers. You can see it here disabling the Windows Defender driver. My goal in releasing this is to motivate MSRC to treat both PPL and kernel vulnerabilities with greater urgency.
本着同样的“交钥匙工具”精神，为了强调阻止已知易受攻击的驱动程序的不一致，同时拒绝修补管理员到内核漏洞链，我发布了一个集成 PPLFault 的 EDRSandBlast 版本，以演示相同的结果，没有易受攻击的驱动程序。你可以在这里看到它禁用Windows Defender驱动程序。我发布此版本的目的是激励 MSRC 更紧急地处理 PPL 和内核漏洞。

Mitigation 缓解

I released a small kernel driver alongside PPLFault and GodFault called NoFault which breaks the PPL exploit. Until Windows is fixed, anti-malware vendors can employ this code to mitigate the PPL vulnerability. We’ve incorporated NoFault’s protection into the latest version of Elastic Endpoint/Defend – please update to 8.9.0+ if you haven’t already. One comprehensive fix could be to have the memory manager enforce page hashes for all executable images loaded into PPL, a feature already employed for full Protected Processes.
我发布了一个小型内核驱动程序以及PPLFault和GodFault，称为NoFault，它破坏了PPL漏洞。在修复 Windows 之前，反恶意软件供应商可以使用此代码来缓解 PPL 漏洞。我们已将 NoFault 的保护功能整合到最新版本的 Elastic Endpoint/Defend 中 – 如果您尚未更新到 8.9.0+，请更新到 8.9.0+。一个全面的修复可能是让内存管理器对加载到 PPL 中的所有可执行映像强制执行页面哈希，该功能已用于完全受保护的进程。

GodFault is not the first tool to exploit the kernel vulnerability. ANGRYORCHARD first used it with the now-patched KnownDLLs PPL vulnerability. The PPL vulnerability has since been fixed, but the kernel one was not. I was able to easily reuse the kernel vulnerability in GodFault – it’s only a few lines of code. If this is not patched, then any future PPL exploits will immediately be chainable to the kernel. Note that NoFault breaks the kernel exploit chain by preventing its requisite PPL code execution, but does not fix the kernel vulnerability itself.
GodFault并不是第一个利用内核漏洞的工具。ANGRYORCHARD 首先将它与现已修补的 KnownDLLs PPL 漏洞一起使用。PPL 漏洞已得到修复，但内核漏洞尚未修复。我能够轻松地在GodFault中重用内核漏洞 – 它只有几行代码。如果未对此进行修补，则任何未来的 PPL 攻击都将立即链接到内核。请注意，NoFault 通过阻止其必要的 PPL 代码执行来破坏内核漏洞利用链，但不会修复内核漏洞本身。

Discussion 讨论

Making EDRSandBlast driverless is just one example of the things you can do with such exploits. Admin-to-kernel exploits enable a whole menu of malware capabilities that are normally impossible from user mode, including:
使EDRSandBlast无人驾驶只是您可以使用此类漏洞做的事情的一个例子。管理员到内核漏洞利用启用了用户模式通常无法实现的一整套恶意软件功能，包括：

• Disable kernel mode telemetry including process, thread, object manager, filesystem, and registry callbacks. EDRSandBlast does some of these.
  禁用内核模式遥测，包括进程、线程、对象管理器、文件系统和注册表回调。EDRSandBlast做了其中的一些。
• Disable kernel ETW loggers
  禁用内核 ETW 记录器
• Terminate and/or inject malware into PPL anti-malware processes
  终止和/或将恶意软件注入 PPL 反恶意软件进程
• Bypass LSA RunAsPPL to dump credentials or tamper with Credential Guard
  绕过 LSA RunAsPPL 以转储凭据或篡改凭据保护
• Read/write the memory of shielded VM worker processes, which run as PPL
  读/写受防护的虚拟机工作进程的内存，这些进程以 PPL 形式运行
• Run malware with greater privilege than anti-malware, such that it can’t be scanned or terminated from user mode
  以比反恶意软件更高的权限运行恶意软件，使其无法从用户模式扫描或终止
• Implement rootkit behavior such as hiding processes, files, and registry keys
  实现 rootkit 行为，例如隐藏进程、文件和注册表项
• Gain full read-write access to physical memory
  获得对物理内存的完全读写访问权限

Such kernel-driven capabilities, often enabled by BYOVD, are regularly used by criminals to defeat and degrade security products, empowering them to hurt people and businesses. PPL and kernel vulnerabilities enable these same capabilities, so MSRC needs to service them proactively before threat actors abuse them, not after.
这种内核驱动的功能通常由 BYOVD 启用，经常被犯罪分子用来击败和降级安全产品，从而使他们能够伤害人员和企业。PPL 和内核漏洞支持这些相同的功能，因此 MSRC 需要在威胁参与者滥用它们之前主动为它们提供服务，而不是之后。

I don’t want to understate the difficulty of the problem – defending the kernel against admins is hard and will require continual effort as new bypasses are found. It will not be solved, but rather a difficult and ongoing arms race. Fortunately, Microsoft recently adopted a new philosophy of “no longer avoiding the hard things” (timestamped link). Addressing these types of vulnerabilities is a “hard thing” affecting Windows security today that Microsoft can do something about while simultaneously moving towards their vision of an Adminless future. They’re a large well-funded company filled with smart people, capable of addressing multiple issues at once.
我不想低估问题的难度 – 保护内核免受管理员的攻击是困难的，并且随着发现新的绕过，需要不断的努力。它不会得到解决，而是一场艰难和持续的军备竞赛。幸运的是，Microsoft最近采用了“不再回避困难”（时间戳链接）的新理念。解决这些类型的漏洞是影响当今Windows安全性的“困难”，Microsoft可以做一些事情，同时朝着无管理员未来的愿景迈进。他们是一家资金雄厚的大型公司，充满了聪明的人，能够同时解决多个问题。

Conclusion 结论

Microsoft created the Vulnerable Driver Blocklist to stop admins from tampering with the kernel, but they’ve done nothing about an admin-to-kernel exploit chain that was reported over 11 months ago. By removing the vulnerable driver requirement from EDRSandBlast via GodFault, I hope to prove that admin-to-kernel exploits can be just as dangerous as vulnerable drivers and that MSRC needs to take them seriously. Given Windows 11’s goal of default security and the fact that the Vulnerable Driver Blocklist is now enabled by default, MSRC needs to reconsider its policy of indifference towards PPL and kernel exploits.
Microsoft创建了易受攻击的驱动程序阻止列表来阻止管理员篡改内核，但他们对 11 个月前报告的管理员到内核漏洞利用链没有采取任何措施。通过 GodFault 从 EDRSandBlast 中删除易受攻击的驱动程序要求，我希望证明管理员到内核漏洞可能与易受攻击的驱动程序一样危险，MSRC 需要认真对待它们。鉴于 Windows 11 的默认安全目标以及现在默认启用易受攻击的驱动程序阻止列表的事实，MSRC 需要重新考虑其对 PPL 和内核漏洞的漠不关心政策。