引言
自带易受攻击的驱动程序 (BYOVD) 是一种越来越流行的攻击者技术，威胁行动者将已知易受攻击的签名驱动程序与其恶意软件一起带入，将其加载到内核中，然后利用它在内核中执行一些他们原本无法执行的操作。获得内核访问权限后，他们可能会篡改或禁用安全软件、转储原本无法访问的凭据或修改操作系统行为以隐藏其存在。 Joe Desimone 和我曾在 2018 年的 Black Hat USA 上深入探讨了这一点以及其他内核模式威胁。 BYOVD 已被高级威胁行动者使用十多年，在勒索软件和商品恶意软件中正变得越来越普遍。
驱动程序签名强制 (DSE) 于 2007 年首次在 Windows Vista x64 中部署，这是微软首次尝试限制管理员的权限。在 DSE 实施后，管理员无法再立即将任何代码加载到内核中。随着 Boot Guard、安全启动和受信任启动的推出，对管理员的限制也在不断增加，以保护引导链免受管理员恶意软件的侵害，此类恶意软件以前可以安装自己的引导加载程序/引导工具包。
为了进一步限制管理员的权限，微软最近默认部署了易受攻击的驱动程序阻止列表，从 Windows 11 22H2 开始。 这是朝着正确方向迈出的一步，使 Windows 11 默认更安全。 不幸的是，阻止列表的部署模型可能难以快速适应新的威胁，通常每年只自动部署一次或两次更新。 用户可以手动更新其阻止列表，但此类干预会使我们脱离“默认安全”的领域。
安全边界
在确定要修复哪些漏洞时，微软安全响应中心 (MSRC) 使用安全边界的概念，其定义如下
安全边界在具有不同信任级别的安全域的代码和数据之间提供逻辑分离。 例如，内核模式和用户模式之间的分离是一个经典而直接的安全边界。
根据此定义，人们可能会认为在用户模式下运行的恶意软件不应该能够修改内核内存。 毕竟，边界是“直接的”。 从逻辑上讲，任何违反该边界的行为都应采取补救措施，例如补丁或阻止列表更新。
不幸的是，情况从这里开始变得更加模糊。 该文档后来指出，管理员到内核不是安全边界，并提供以下解释
管理进程和用户被认为是 Windows 受信任计算库 (TCB) 的一部分，因此与内核边界没有强隔离 [原文如此]。
此时，我们有两种看似冲突的观点。 一方面，MSRC 声称管理员到内核是无法防御的边界，不值得修复。 另一方面，微软正在尝试使用驱动程序签名强制、安全启动和易受攻击的驱动程序阻止列表等机制来防御此边界。 由于防御不完整，MSRC 反而称它们为“深度防御安全功能”。
MSRC 同样不认为管理员到 PPL 是安全边界，而是将其归类为深度防御安全功能。 下一部分将详细介绍。
本文的其余部分将分别提及 MSRC 和微软。 虽然 MSRC 是微软的一部分，但微软是一个比 MSRC 大得多的实体；不应将它们等同起来。
利用漏洞
2022 年 9 月，我向 MSRC 提交了 VULN-074311，通知他们 Windows 中的两个 零日漏洞：一个管理员到 PPL，一个 PPL 到内核。 我提供了这两个漏洞利用的源代码。 回应简洁地表明，他们理解了这些漏洞，并拒绝采取任何进一步的行动，如下所述
该研究描述了一种多步骤攻击，该攻击利用 PPL 绕过来获得内核代码执行权限。 请注意，所有提议的攻击都需要管理员权限才能执行，因此所报告的问题不符合我们立即提供服务的标准。 我们预计不会采取任何进一步的行动，并将继续结束此案例。
在此术语中，“服务”表示“修补”。 他们的回应与上述政策及其对管理员到内核边界的历史处理一致。 他们的行为也一致 - 已经超过 11 个月了，他们仍然没有修补任何一个漏洞。 我发现微软愿意阻止可以修改内核内存的驱动程序，但 MSRC 不愿意为可以执行相同操作的漏洞提供服务，这非常令人着迷。
在我宣布我于 MSRC 报告五个月后在 Twitter 上举行的 Black Hat Asia 2023 演讲PPLdump 已死。PPLdump 万岁时，Windows Defender 团队迅速联系我们以了解更多信息。 似乎 MSRC 关闭了此案例，而没有告诉 Defender 团队，该团队的产品依靠 PPL 来保护数亿台 Windows 机器，有关 PPL 绕过的信息。 绝不能允许这种类型的沟通不畅继续下去。
交钥匙工具
EDRSandBlast 是一款利用易受攻击的驱动程序来绕过 AV 和 EDR 软件的工具。 它可以修改内核内存以删除 AV 和 EDR 安装的挂钩，从而暂时或永久地使它们对系统上的恶意活动视而不见。
正如我在 Black Hat Asia 演讲中所讨论的那样，MSRC 事实上表明他们不愿为管理员到 PPL 和管理员到内核的漏洞提供服务，并且需要 GitHub 上存在交钥匙工具来推动微软采取行动。 这促使我发布管理员到 PPL 漏洞利用PPLFault 和管理员到内核漏洞利用链GodFault，作为 GitHub 上易于使用的工具。 为了简洁起见，我们在下面分别将它们称为“PPL 漏洞”和“内核漏洞”。
本着同样的“交钥匙工具”精神，为了强调阻止已知易受攻击的驱动程序同时拒绝修补管理员到内核漏洞利用链的不一致性，我正在发布一个集成 PPLFault 的 EDRSandBlast 版本，以演示相同的结果，无需使用易受攻击的驱动程序。 您可以在此处看到它禁用 Windows Defender 驱动程序。 我发布此内容的目的是为了促使 MSRC 更为紧急地处理 PPL 和内核漏洞。
缓解措施
我随 PPLFault 和 GodFault 一起发布了一个名为 NoFault 的小型内核驱动程序，该驱动程序破坏了 PPL 漏洞利用。 在 Windows 修复之前，反恶意软件供应商可以使用此代码来缓解 PPL 漏洞。 我们已将 NoFault 的保护纳入最新版本的 Elastic Endpoint/Defend 中 - 如果您尚未更新，请更新到 8.9.0+。 一个全面的修复方法可能是让内存管理器为加载到 PPL 中的所有可执行映像强制执行页面哈希，这是已用于完整受保护进程的一项功能。
GodFault 并非第一个利用内核漏洞的工具。 ANGRYORCHARD 首先将其与现在已修复的 KnownDLLs PPL 漏洞一起使用。PPL 漏洞已被修复，但内核漏洞仍然存在。我能够在 GodFault 中轻松重用内核漏洞 - 它只需要几行代码。如果此漏洞未被修复，那么未来任何 PPL 漏洞都将立即与内核链接。请注意，NoFault 通过阻止其所需的 PPL 代码执行来打破内核利用链，但它本身并没有修复内核漏洞。
讨论
使 EDRSandBlast 无需驱动程序只是利用此类漏洞可以做的事情的一个例子。从管理员到内核的漏洞利用使恶意软件能够实现一系列通常在用户模式下不可能实现的功能，包括
- 禁用内核模式遥测，包括进程、线程、对象管理器、文件系统和注册表回调。EDRSandBlast 实现了其中一些。
- 禁用内核 ETW 记录器
- 终止和/或将恶意软件注入PPL 反恶意软件进程
- 绕过 LSA RunAsPPL 以转储凭据或篡改凭据保护
- 读取/写入受保护的 VM 工作进程的内存，这些进程以 PPL 运行
- 以比反恶意软件更高的权限运行恶意软件，使其无法从用户模式扫描或终止
- 实施 rootkit 行为，例如隐藏进程、文件和注册表项
- 获得对物理内存的完全读写访问权限
这种内核驱动的功能，通常由 BYOVD 启用，经常被使用，被犯罪分子用来击败和降级安全产品，使他们能够伤害个人和企业。PPL 和内核漏洞也能实现这些相同的功能，因此 MSRC 需要在威胁行为者滥用它们之前主动处理它们，而不是之后。
我不想低估这个问题的难度 - 保护内核免受管理员攻击是很困难的，需要不断努力，因为会发现新的绕过方法。这不会被解决，而是一场艰难且持续的军备竞赛。幸运的是，微软最近采取了一种新的理念，即“不再回避难题”（带时间戳的链接）。解决这些类型的漏洞是当今影响 Windows 安全的“难题”，微软可以做一些事情，同时朝着他们无管理员未来的愿景迈进。他们是一家资金充足的大公司，拥有聪明的人才，能够同时解决多个问题。
结论
微软创建了易受攻击的驱动程序阻止列表，以阻止管理员篡改内核，但他们对于 11 个月前报告的管理员到内核的利用链却没有任何作为。通过通过 GodFault 从 EDRSandBlast 中删除易受攻击的驱动程序要求，我希望证明管理员到内核的漏洞利用可能与易受攻击的驱动程序一样危险，并且 MSRC 需要认真对待它们。鉴于 Windows 11 的默认安全目标以及易受攻击的驱动程序阻止列表现在默认启用，MSRC 需要重新考虑其对 PPL 和内核漏洞漠不关心的政策。