滥用 VBS Enclaves 创建规避恶意软件

介绍

基于虚拟化的安全性 (VBS) 是最近最令人着迷的安全进步之一。隔离操作系统关键组件的能力使 Microsoft 能够通过 Credential Guard 和 Hypervisor 保护的代码完整性 (HVCI) 等功能实现显着的安全性改进。

VBS 启用的一项经常被忽视的功能是VBS 区域- 一种允许隔离进程某个区域的技术，使其他进程、进程本身甚至内核都无法访问该区域。 

VBS 飞地可以有广泛的安全应用，微软利用它们实现了几个值得注意的服务，包括备受争议的召回功能。此外，微软支持第三方开发 VBS 飞地，并积极推动其采用。

虽然安全区有助于保护系统，但它们对攻击者来说也非常有吸引力——在安全区内运行的恶意软件可能会对基于内存的检测和取证不可见。

我们着手探索 VBS 安全区并了解它们如何被用于恶意目的，这篇博文将详细介绍我们的主要发现。我们将深入研究 VBS 安全区，探索以前未记录的行为，描述可让攻击者在其中运行恶意代码的不同场景，并研究“安全区恶意软件”可以使用的各种技术。

我们还将介绍Mirage，这是一项基于新方法的内存规避技术，我们称之为“自带易受攻击的安全区”。我们将探讨攻击者如何使用合法安全区的旧版本、易受攻击版本来实现这种隐秘的规避技术。

虚拟信任级别 

Windows 传统上依靠处理器环级别来防止用户应用程序篡改操作系统。此硬件功能可以将操作系统与用户应用程序分离 - 内核在 ring0 中运行，与 ring3 用户模式应用程序隔离。这种方法的问题在于，它为攻击者提供了一种相对容易的方法来破坏操作系统 - 内核漏洞。

Windows 内核暴露了非常丰富的攻击面。大量的第三方驱动程序以及内核本身暴露的各种服务导致内核漏洞不断涌现。利用此类漏洞，攻击者可以控制操作系统的各个方面。事实证明，用户/内核模式的边界是不够的。

为了弥补这一差距，微软以虚拟信任级别 (VTL) 的形式在操作系统中引入了额外的安全边界。VTL 权限基于内存访问 - 每个信任级别为在其下运行的实体提供对物理内存的不同访问权限。除其他外，这些权限确保较低的 VTL 无法访问较高 VTL 的内存。

与传统的处理器环架构类似，VTL 将操作系统分为不同的“执行模式”，从 VTL0 开始，到（可能）VTL16 结束。与处理器环（其中 ring0 具有最高权限）不同，较高的 VTL 比较低的 VTL 具有更高的权限。

Windows 目前使用两种主要的信任级别：VTL0 和 VTL1（VTL2 也被使用，但不在本博文的讨论范围内）。VTL0 用于运行传统的 OS 组件，包括内核和用户模式应用程序。VTL1 比 VTL0 具有更高的特权，它创建了两种新的执行模式：安全内核模式和隔离用户模式。

安全内核模式

安全内核模式是指 ring0 VTL1 执行模式。此模式用于运行安全内核 — 运行在 VTL1 中的内核，因此比普通内核具有更高的特权。利用这些特权，安全内核可以对普通内核实施策略并限制其对敏感内存区域的访问。

正如我们所说，内核暴露了很大的攻击面，很容易受到攻击。通过从内核中剥离一些权限并将这些权限授予安全内核，我们可以减少内核攻击的影响。

理论上，安全内核被攻破仍能让攻击者完全攻破系统。尽管如此，这种情况发生的可能性很小，因为安全内核非常狭窄，不支持任何第三方驱动程序，从而大大减少了攻击面。

隔离用户模式

VTL1 还创建了另一种有趣的执行模式，称为隔离用户模式 (IUM)，它指的是 ring3 VTL1 执行模式。IUM 用于执行安全进程——一种使用 VTL1 内存隔离功能的特殊类型的用户模式进程。任何 VTL0 代码（包括正常内核）都无法访问 IUM 内的内存。此执行模式是Credential Guard等基于隔离的功能的支柱。

总而言之，引入VTL0/1 产生了四种执行模式（图 1）。

• Ring0 VTL0 — 正常内核模式

• Ring0 VTL1 — 安全内核模式

• Ring3 VTL0 — 普通用户模式

• Ring3 VTL1 — 隔离用户模式

什么是 VBS enclaves？

通过 IUM 启用的另一个功能是 VBS 安全区。VBS 安全区是驻留在 IUM 中的用户模式进程的一部分，我们可以将称为“安全区模块”的 DLL 加载到其中。

当模块加载到安全区时，它就变成了“可信执行环境”——安全区内的数据和代码对于在 VTL0 中运行的任何程序都无法访问，因此无法被篡改或窃取（图 2）。此功能可用于将敏感操作与能够破坏系统的攻击者隔离开来。

图 2：VBS 安全区内存布局。来源：https://learn.microsoft.com/en-us/windows/win32/trusted-execution/vbs-enclaves

用户模式进程可以调用专用的 Windows API来创建安全区、将模块加载到其中并初始化它。安全区模块以 DLL 的形式出现，该 DLL 是专门为此目的编译的。初始化安全区后，托管用户模式进程无法访问其内存，只能通过使用CallEnclave API 调用其模块导出的函数来与其交互。

图3是实现该过程的代码示例（Microsoft提供了更详细的示例）。

图 3：VBS 安全区创建代码示例

由于微软的目标是尽可能地限制对 VTL1 的访问，因此将 DLL 加载到飞地中需要使用微软颁发的特殊证书对其进行正确签名。任何试图加载没有此类签名的模块的行为都将失败。对飞地模块进行签名的选项仅委托给受信任的第三方。有趣的是，对于谁可以加载这些模块没有任何限制——只要它们经过签名，任何进程都可以将任意模块加载到飞地中。

安全区模块旨在充当小型“计算单元”，它们与系统交互或影响系统的能力非常有限。因此，它们只能使用一组最少的 API，这阻止它们访问大多数操作系统组件。

安全区内可用的 API 是从加载到 VTL1 的专用库导入的。例如，虽然正常进程依赖ntdll.dll库从操作系统请求服务，但安全区模块使用vertdll.dll — — 一种“替代”ntdll，用于通过系统调用与安全内核进行通信。

Enclave 恶意软件

飞地恶意软件的概念对于攻击者来说肯定很有吸引力，因为它提供了两个显著的优势：

在隔离内存区域中运行：在 VTL0 中运行的任何东西（包括 EDR 和分析工具）都无法访问 enclave 的地址空间，这使得检测变得更加复杂。

不可追踪的 API 调用：在安全区内进行的 API 调用对于 EDR 来说是不可见的。EDR 通过在系统库内放置钩子来监控用户模式下的 API，并使用驱动程序来监控内核中的活动。这些技术无法检测到从安全区触发的 API 调用，因为安全区调用是从 VTL1 执行的，不会经过任何这些“钩住的”VTL0 组件。

图 4 展示了这一优势：调用 Windows API 的正常进程可以通过NTDLL或内核本身的钩子进行监控。但是，安全区模块会通过驻留在 VTL1 中的vertdll并调用对安全内核的调用 — — 两者都无法被 EDR 访问。

图4：普通用户模式与IUM API调用过程的区别

认识到这种潜力后，我们开始研究飞地恶意软件的概念。要利用飞地实现这一目的，必须解决两个问题：

• 攻击者如何在安全区内执行恶意代码？

• 一旦攻击者进入安全区，可以采用哪些技术？

• 攻击者如何在安全区内执行恶意代码？

正如我们之前所说，enclave 模块必须使用 Microsoft 颁发的证书进行签名才能加载，这意味着只有经过 Microsoft 批准的实体才能在 enclave 内执行自己的代码。尽管如此，攻击者仍然有一些选择。

首先，攻击者可以依赖操作系统漏洞。一个例子是CVE-2024-49706，由 Alex Ionescu（为 Winsider Seminars & Solutions 工作）发现，它可以让攻击者将未签名的模块加载到 enclave 中。该漏洞已被 Microsoft 修补，但有动机的攻击者可能会在未来发现类似的错误。

第二种直接的方法是获取合法签名——这是可能的，因为微软通过可信签名平台向第三方公开了安全区签名。虽然这肯定不是一件容易的事，但高级攻击者可能能够获得对可信签名实体的访问权限并签署他们自己的安全区。

除了这两个选项之外，我们还探索了另外两种可能使攻击者能够在 VBS 区域内运行代码的技术——滥用可调试区域和利用易受攻击的区域。

滥用可调试的 enclave 模块

创建 VBS 安全区模块时，开发人员可以将其配置为可调试。使用此设置编译模块可以对其进行调试。由于安全区模块在 VTL1 中运行，因此通常无法对其进行调试，因为调试器无法访问安全区内存来检索数据或设置断点。图 5 显示了调试器无法从安全区内的内存地址读取的示例。

图 5：尝试读取不可调试的 VBS 安全区模块的内存

有趣的是，当执行可调试的 enclave 模块时，它仍会加载到 VTL1 中。为了启用调试，安全内核实现了一些适用于可调试 enclave 模块的异常。例如，当尝试从此类模块的内存中读取时，正常内核会发出对SkmmDebugReadWriteMemory安全内核调用的调用，该调用在执行请求的操作之前验证目标模块确实可调试。

图 6 中可以看到一个示例——加载可调试的 enclave 模块后，调试器可以成功地从 enclave 内存中读取。

图 6：当 enclave 模块可调试时，成功从与图 5 相同的地址读取

以类似的方式，可调试 enclave 模块内的内存权限也可以通过 VTL0 进程进行修改（ SkmmDebugProtectVirtualMemory安全内核调用中实现的异常）。

微软强烈敦促开发人员不要发布可调试的 enclave 模块，因为这样做会破坏 enclave 的核心目的——将一部分内存与 VTL0 隔离开来（图 7）。使用可调试模块意味着它处理的数据很容易被泄露。

图 7：微软关于可调试 enclave 模块的建议。来源：https://learn.microsoft.com/en-us/windows/win32/trusted-execution/vbs-enclaves-dev-guide#:~:text=Step%204%3A%20Debugging%20VBS%20enclaves

生产应用程序运行可调试的 enclave 模块的风险是显而易见的，但攻击者实际上可以将其用于其他目的 - 在 VTL1 中执行未签名的代码。如果攻击者获得任何可调试的签名 enclave 模块，他们可以通过执行以下四个步骤来实现 VTL1 代码执行：

1. 使用GetProcAddress获取 enclave 模块内例程的地址

2. 将常规内存保护更改为 RWX

3. 使用任意 shellcode 覆盖例程代码

4. 使用CallEnclave触发例程

图 8 描述了实现此过程的代码。

图 8：在安全区内执行未签名的 shellcode 的示例代码

从攻击者的角度来看，显而易见的问题是，这是一把双刃剑——正如攻击者可以访问安全区内存一样，EDR 也可以这样做。尽管如此，它确实具有逃避 API 监控的好处——安全区模块执行的 API 调用仍将通过 VTL1 DLL 和安全内核，从而限制了 EDR 的可见性。

总的来说，这种方法可能有助于创建隐秘的“半 VTL1”植入物，它利用了在飞地内运行所获得的一些优势。

我们曾尝试使用 VirusTotal 和其他来源来识别可调试的签名安全区模块，但截至撰写本文时，我们仍未成功。不过，我们相信，只要有足够的时间，以及安全区技术的广泛采用，一些模块最终必定会泄露。

带上你自己的脆弱区域

正如我们所讨论的，Windows 使用签名来防止将不受信任的 enclave 加载到 VTL1 中。这种方法并非 enclave 所独有——这一概念是通过驱动程序签名强制(DSE) 出现的，它可以防止不受信任的驱动程序在 Windows 内核中运行。

为了突破这一强制措施，攻击者开始使用自带易受攻击的驱动程序(BYOVD) 技术 — 也就是说，攻击者无法加载自己的驱动程序，因此他们改为加载具有已知漏洞的合法签名驱动程序。然后他们可以利用此漏洞在内核中运行未签名的代码。

我们希望在安全区环境中探索这种方法：我们可以滥用易受攻击的签名安全区模块在 IUM 中执行代码吗？

第一步是找到这样的安全区，这很快让我们找到了CVE-2023-36880 — Microsoft Edge 使用的 VBS 安全区模块中的一个漏洞。该漏洞使攻击者能够读取和写入安全区内的任意数据。虽然微软将该漏洞标记为信息泄露漏洞，但说明还指出它可能导致有限的代码执行（图 9）。

图 9：Microsoft 针对 CVE-2023-36880 的补丁说明表明该漏洞可能导致代码执行

Chrome 安全团队的 Alex Gough 发现了该漏洞，并分享了利用该漏洞的概念验证。我们在 VirusTotal 中发现此安全区的易受攻击版本后，便开始尝试利用它来实现代码执行。

我们的想法是滥用读/写原语，用 ROP 链覆盖安全区堆栈，最终使我们能够在安全区内执行 shellcode。在探索这个选项时，我们发现了一个有趣的事实——使用任意代码保护 (ACG)保护安全区免受未签名代码执行的侵害。

ACG 是一种安全缓解措施，旨在阻止动态生成代码（运行时创建的代码，而不是原始进程可执行文件或其 DLL 的一部分）的执行。ACG 通过强制执行两条规则来实现：

1. 进程初次加载后无法生成新的可执行页面

2. 已经可执行的页面无法变为可写

ACG 在普通内核上默认强制执行，但在用户模式下，它仅适用于配置为使用它的进程。我们的研究表明，对于包含 enclave 的 IUM 进程，ACG 似乎会自动应用，就像在普通内核上一样。

我们可以尝试使用 VirtualAlloc 在 enclave 内分配新的 RWX 页面来观察这一点——操作失败，错误代码为 0x677，STATUS_DYNAMIC_CODE_BLOCKED（图 10）。尝试使用 VirtualProtect 修改可执行页面权限或将页面变为可执行文件将导致相同的结果。

图 10：尝试在 enclave 内分配 RWX 页面

为了了解此行为，我们可以检查SecureKernel!NtAllocateVirtualMemoryEx，这是处理 IUM 中动态内存分配的安全内核函数。该函数评估请求的保护掩码，如果请求可执行页面，则返回 ACG 错误STATUS_DYNAMIC_CODE_BLOCKED 。在SkmmProtectVirtualMemory中实现了类似的检查，以防止对现有 IUM 页面进行更改（图 11）。

图11：NtAllocateVirtualMemoryEx 的代码拒绝可执行内存分配

我们还没有找到绕过安全区内的 ACG 并将未签名的代码加载到其中的方法。理论上，完全 ROP 漏洞是可能的——例如，可能使攻击者能够调用 VTL1 中的任意 API——但我们没有朝这个方向努力。尽管如此，我们仍然设法为易受攻击的安全区确定了另一个有趣的应用程序，我们将在本文后面讨论。

一旦攻击者进入安全区，可以采用哪些技术？

了解到安全区有很大潜力用于恶意活动，并且有动机的攻击者可能会启动它们，我们要解决的下一个问题是，哪些技术可以用于此类恶意软件。

最直接的用途是按照安全区原本的用途来使用它们。正如安全区可以保护敏感数据免受攻击者攻击一样，攻击者也可以使用它来向 VTL0 实体隐藏自己的“秘密”。

这在许多情况下都很有用——将有效载荷存储在 EDR 无法触及的地方、将加密密钥密封起来不让分析师发现，或者将敏感的恶意软件配置置于内存转储之外。

至于更高级的选项，许多传统的恶意软件技术无法在安全区内实施。由于安全区仅限于有限的系统 API 子集，因此无法与文件、注册表、网络、其他进程等关键操作系统组件进行交互。

尽管如此，仍然有许多技术可以在飞地内执行，使我们能够利用在 IUM 中运行所获得的优势。

访问 VTL0 用户模式内存

尽管对系统的访问权限有限，但安全区仍然可以访问一项关键资源：进程内存。安全区可以在整个进程地址空间（包括 VTL0）内执行读/写操作。

这种访问有一些限制 — 在安全区内运行的代码必须遵守内存权限，并且不能更改这些权限。这意味着安全区将无法写入不可写内存，也无法将不可执行内存变为可执行内存。图 12 描述了在安全区内运行的代码，并演示了这些不同的可能性和限制。

图 12：示例代码演示了从 enclave 访问 VTL0 内存的场景

通过访问 VTL0 用户模式内存，我们可以实现各种有用的技术。通过将恶意 enclave 加载到目标进程中，我们可以秘密监视和窃取敏感信息，或修补进程内的值以改变其行为。

使用安全区实现这些技术具有显著的优势——正如我们之前所述，从安全区触发 API 使我们能够逃避 EDR 的监控。由于这些技术中的内存访问是由安全区执行的，因此它们可以保持不可见。

执行VTL0用户模式代码

尽管在获得适当权限的情况下，enclave 可以从 VTL0 用户模式内存中读取/写入，但存储在 VTL0 中的代码永远无法在 enclave 内执行 — — 即使它具有执行权限。

尽管无法在安全区内运行 VTL0 代码，但安全区可以选择“远程”触发它。通过使用带有VTL0 地址的CallEnclave API，安全区可以在普通用户模式线程中触发 VTL0 代码的执行（图 13）。

图 13：示例代码演示了无法执行 VTL0 代码的 enclave

通过让用户模式进程“代表它们行动”，飞地可以以通常不可能的方式间接访问系统。例如，飞地可以触发 VTL0 例程，从文件中读取数据、创建套接字等。

值得注意的是，以这种方式运行用户模式代码在逃避方面没有优势——因为代码像任何其他用户模式代码一样运行，所以它可以被 EDR 看到。

反调试

安全区恶意软件的另一个有趣应用是反调试。安全区内运行的代码无法被 VTL0 应用程序（包括调试器）访问，这一事实为恶意软件提供了显著的优势。

暴露给安全区的 API 减少意味着并非所有传统的反调试技术都可以从安全区使用。例如，NtQueryInformationProcess或IsDebuggerPresent API 以及所有日期和时间 API 都不可用于安全区。尽管如此，我们仍然有一些选择。

首先，我们可以依靠 enclave 对进程 VTL0 地址空间的访问，允许它手动读取进程 PEB 并检查“ BeingDebugged ”标志的值。如果检测到调试器，enclave 可以终止该进程。

另一种方法是实施基于时间的反调试技术（图 14）。尽管 enclave 无法使用日期和时间 API，但它们仍然可以使用rdtsc汇编指令。此指令返回自启动以来的处理器时钟周期数。使用它，我们可以测量不同 enclave 调用之间所花费的时间，并在检测到明显延迟时终止该过程。

图 14：使用 rdtsc 汇编指令在安全区内进行基于时间的反调试

通过将代码的关键部分移至安全区并进行反调试检查，我们可以制作出几乎完全不受动态分析影响的恶意软件。恶意软件依靠安全区正常运行，而用户模式进程无法修补其中运行的检查。正确实施后，只有通过调试 Hyper-V 或安全内核才能击败这种方法。

BYOVE — 第 2 轮

在上一节中，我们尝试利用易受攻击的安全区模块在 IUM 中实现代码执行。当我们意识到这可能行不通时，我们想看看 BYOVE 的概念是否可以有其他应用，并决定进一步探索易受攻击的安全区模块。

该漏洞 (CVE-2023-36880) 源自enclave 模块导出的SealSettings和UnsealSettings函数。SealSettings函数接收指向数据缓冲区的指针，对其进行加密，然后将结果写入调用者提供的目标地址。UnsealSettings的工作方式类似，解密提供的缓冲区并将其写入指定的地址。

这两个函数的问题在于，它们不验证目标地址或源缓冲区地址，从而允许它们指向进程内的任何地址，包括安全区本身内的地址。图 15 描述了存在漏洞的代码，显示 UnsealSettings对用户提供的任意地址执行memcpy 。

图 15：UnsealSettings 函数中的易受攻击的代码

此漏洞为攻击者提供了两种能力（图16）。

图 16：利用 CVE-2023-36880 在安全区内读取/写入任意数据

1. 在安全区内任意写入：攻击者可以调用SealSettings加密任意数据，然后调用UnsealSettings指向安全区内的目标地址。这会导致原始数据被写入安全区内存。

2. 在安全区内任意读取：攻击者可以调用SealSettings，同时提供安全区内的地址作为源缓冲区指针。这将导致安全区加密来自安全区内存的数据并将其写入攻击者控制的位置。然后，攻击者可以通过调用UnsealSettings解密此数据，从而使他们能够从安全区读取任意数据。

Mirage——基于VTL1的内存逃避

虽然它不允许我们在 VTL1 中执行代码，但任意写入原语确实提供了两种独特的能力： 

1. 将任意数据存储在 VTL1 中，而 VTL0 实体无法访问该数据

2. 从VTL1向正常进程地址空间（VTL0）写入任意数据，从而阻止 VTL0 实体监视此操作

此外，由于这些功能是通过加载已签名的安全区模块来实现的，因此任何攻击者都可以使用它们，而无需他们自己签署任何内容。

为了展示这些功能的潜力，我们提出了一种内存扫描规避技术，我们称之为“Mirage”。Mirage 的灵感来自于Gargoyle，这是一种规避技术，可以创建一个在良性状态和武器化状态之间不断切换的有效载荷（图 17）。

图 17：Mirage 内存逃避

Gargoyle 通过在可执行和不可执行内存之间切换来实现这一点，而 Mirage 旨在通过在 VTL1 和 VTL0 内存之间转换来实现类似的结果 - 它将 shellcode 存储在 VTL1 隔离区内存中，定期使用漏洞将其传输回 VTL0，执行它，然后迅速将其从 VTL0 内存中删除（图 18）。

图 18：Mirage 逃避攻击的进程生命周期

这种方法有两个主要优点。首先，由于有效载荷大部分时间都隐藏在 VTL1 中，因此它对内存扫描和转储具有弹性。这比 Gargoyle 技术更有优势，因为在休眠阶段，我们的有效载荷不仅“隐秘”，而且无法访问。

第二个优点是 shellcode 写入 VTL0 的操作由 enclave 执行。如前所述，EDR 无法监控在 VTL1 中执行的代码，这意味着典型的 EDR 钩子无法在 shellcode 写入内存时拦截它。

我们为 Mirage 开发了一个 PoC-https://github.com/akamai/Mirage（图 19）。该 PoC 仅用于演示该技术背后的想法，因此并未完全武器化。

图 19：Mirage 执行演示

检测

截至目前，只有极少数应用程序使用安全区。即使它们得到更广泛的采用，它们仍将仅由特定进程加载，而不是由任意进程加载。例如，calc.exe可能永远不会加载 VBS 安全区。

因此，异常的 enclave 使用可能是一个很好的检测机会。防御者应该利用它，通过建立 VBS enclave 的已知合法使用基线并标记任何偏离它的情况。可以通过两种方式识别 enclave 使用：通过监控 enclave API 和通过检测已加载的 enclave DLL。

安全区 APIEnclave API

以下 API 用于通过托管进程管理 VBS 区域，并且可能会指示正在加载一个 VBS 区域：

• 创建Enclave

• 加载EnclaveImage

• 初始化Enclave

• 呼叫中心

• 删除Enclave

• 终止Enclave

已加载的安全区 DLL

检测异常安全区使用的另一种方法是检测它们通常使用的环境 DLL 的加载情况；即Vertdll.dll和ucrtbase_enclave.dll。由于这些 DLL 不应由安全区以外的任何对象使用，因此它们的存在将表明该进程可能使用了一个安全区。

结论

VBS 安全区为开发人员提供了出色的工具来保护其应用程序的敏感部分，但正如我们刚刚展示的那样，威胁行为者也可以使用它们来“保护”他们的恶意软件。虽然目前这个概念主要是理论上的，但高级威胁行为者将来肯定会开始将 VBS 安全区用于恶意目的。 

致谢

我们非常感谢 Offsec 的 Matteo Malvica 和 Outflank 的 Cedric Van Bockhaven 所做的工作，他们最近进行了一项与此非常相似的研究项目。请查看他们两部分系列中的第一篇博客文章，并继续关注将在 Insomni'Hack 2025 之后发布的第二部分。

感谢您抽出

.

.

来阅读本文

点它，分享点赞在看都在这里