Abusing VBS Enclaves to Create Evasive Malware

Virtualization-based security (VBS) is one of the most fascinating recent security advancements. The ability to isolate critical components of the OS has enabled Microsoft to achieve substantial security improvements with features like Credential Guard and Hypervisor-Protected Code Integrity (HVCI).

One often overlooked feature that is enabled by VBS is VBS enclaves — a technology that allows the isolation of a region of a process, making it inaccessible to other processes, the process itself, and even the kernel. 

VBS enclaves can have a wide range of security applications, and Microsoft uses them to implement several notable services, including the controversial Recall feature. Moreover, Microsoft supports third-party development of VBS enclaves and actively promotes their adoption.

While enclaves can help secure systems, they can also be very appealing to attackers — a piece of malware that manages to run inside an enclave can be potentially invisible to memory-based detection and forensics.

We set out to explore VBS enclaves and understand how they could be used for malicious purposes, and this blog post will detail our key findings. We’ll dive into VBS enclaves by exploring previously undocumented behaviors, describing the different scenarios that can enable attackers to run malicious code inside them, and examining the various techniques “enclave malware” can use.

We’ll also introduce Mirage, a memory evasion technique based on a new approach that we dubbed “Bring your own vulnerable enclave.” We’ll explore how attackers can use old, vulnerable versions of legitimate enclaves to implement this stealthy evasion technique.

Windows traditionally relied on processor ring levels to prevent user applications from tampering with the OS. This hardware feature enables a separation of the OS from user applications — the kernel runs in ring0, isolated from the ring3 user mode applications. The problem with this approach is that it provides attackers with a relatively easy path to compromise the OS — kernel exploits.

The Windows kernel exposes a very rich attack surface. A huge list of third-party drivers, alongside a wide variety of services exposed by the kernel itself, leads to the development of a seemingly constant stream of kernel exploits. Using such an exploit, an attacker can potentially control every aspect of the OS. The boundary of user/kernel mode was proving to be insufficient.

To close this gap, Microsoft introduced an additional security boundary into the OS in the form of Virtual Trust Levels (VTLs). VTL privileges are based on memory access — each trust level provides entities running under it with different access permissions to physical memory. Among other things, these permissions ensure that lower VTLs cannot access the memory of higher ones.

Similar to the traditional processor ring architecture, VTLs separate the OS into different “modes” of execution, starting from VTL0 and ending at (potentially) VTL16. Unlike processor rings, where ring0 is the most privileged, higher VTLs are more privileged than lower ones.

Windows currently uses two main trust levels: VTL0 and VTL1 (VTL2 is also used, but is out of the scope of this blog post). VTL0 is used to run the traditional OS components, including the kernel and user mode applications. VTL1, which is more privileged than VTL0, creates two new execution modes: secure kernel mode and isolated user mode.

Secure kernel mode refers to the ring0 VTL1 execution mode. This mode is used to run the secure kernel — a kernel that runs in VTL1 and is, therefore, more privileged than the normal kernel. Using these privileges, the secure kernel can enforce policies on the normal kernel and restrict its access to sensitive memory regions.

As we noted, the kernel exposes a large attack surface and is susceptible to compromise. By stripping some privileges from the kernel and granting those privileges to the secure kernel instead, we can reduce the impact of a kernel compromise.

In theory, a compromise of the secure kernel can still allow an attacker to fully compromise the system. Despite that, this scenario is much less likely because the secure kernel is very narrow and does not support any third-party drivers, which creates a significantly reduced attack surface.

Because Microsoft aims to restrict access to VTL1 as much as possible, loading a DLL into an enclave requires it to be properly signed using a special Microsoft-issued certificate. Any attempt to load a module without such a signature will fail. The option to sign enclave modules is only delegated to trusted third parties. Interestingly, there are no restrictions on who can load these modules — as long as they are signed, any process can load arbitrary modules into an enclave.

Enclave modules are meant to serve as small “computational units,” which have a very limited ability to interact with or affect the system. Because of this, they are limited to using a minimal set of APIs, which prevents them from accessing most of the OS components.

APIs available inside enclaves are imported from dedicated libraries loaded into VTL1. For example, while normal processes rely on the ntdll.dll library to request services from the OS, enclave modules use vertdll.dll — a "substitute" ntdll that is used to communicate with the secure kernel through syscalls.

The concept of enclave malware can certainly be appealing to attackers, as it provides two significant advantages:

1. Running in an isolated memory region: The address space of enclaves is inaccessible to anything running in VTL0, including EDRs and analysis tools, making detection much more complex.

2. Untraceable API calls: API calls made from within an enclave can be invisible to EDRs. EDRs monitor APIs in user mode by placing hooks inside system libraries, and employ drivers to monitor activity in the kernel. API calls triggered from an enclave cannot be detected by these techniques, as enclave calls are performed from VTL1 and do not go through any of these “hooked” VTL0 components.

Figure 4 depicts this advantage: A normal process invoking a Windows API can be monitored through a hook inside NTDLL or the kernel itself. However, an enclave module goes through the VTL1-resident vertdll and invokes calls to the secure kernel — both inaccessible to EDRs.

Recognizing this potential, we set out to investigate the concept of enclave malware. To leverage enclaves for this purpose, two questions must be addressed:

1. How can attackers execute malicious code within an enclave?
2. What techniques can attackers employ once running inside an enclave?

As we previously stated, enclave modules have to be signed with a Microsoft-issued certificate to load, meaning that only entities approved by them should be able to execute their own code within an enclave. Despite that, attackers still have some options.

First, an attacker can rely on an OS vulnerability. An example of this came with CVE-2024-49706, discovered by Alex Ionescu, (working for Winsider Seminars & Solutions) which could enable an attacker to load an unsigned module into an enclave. The vulnerability was patched by Microsoft, but motivated attackers may identify similar bugs in the future.

A second straightforward approach would be to obtain a legitimate signature — this could be possible since Microsoft exposes enclave signing to third parties through the Trusted Signing platform. While certainly not trivial, an advanced attacker may be able to obtain access to a Trusted Signing entity and sign their own enclaves.

In addition to these two options, we explored two additional techniques that might enable attackers to run code inside a VBS enclave — abusing debuggable enclaves and exploiting vulnerable enclaves.

The obvious problem from an attacker's perspective is that this is a double-edged sword — just as the attacker can access the enclave memory, an EDR can do so as well. Despite that, it does come with the upside of evading API monitoring — API calls performed by the enclave module will still go through VTL1 DLLs and the secure kernel, limiting the visibility of EDRs.

Overall, this method might be useful for creating a stealthy “semi-VTL1” implant, which capitalizes on some of the advantages obtained by running inside an enclave.

We have attempted to use VirusTotal and other sources to identify a debuggable signed enclave module, but as of the time of writing this, we have been unsuccessful. However, we believe it is safe to assume that given enough time, and wider adoption of the enclave technology, some are bound to leak eventually.

We have not found a method to bypass ACG within an enclave and load unsigned code into it. In theory, a full-ROP exploit is possible — potentially enabling attackers to invoke arbitrary APIs in VTL1, for example — but we have not pursued this direction. Despite that, we still managed to identify another interesting application for vulnerable enclaves, which we will discuss later in this post.

Understanding that enclaves can have a lot of potential for malicious activity, and that launching them might be possible for a motivated attacker, the next question that we addressed was which techniques could be available for this type of malware.

The most straightforward use would be to use enclaves how they were meant to be used. Just as an enclave can protect sensitive data from attackers, it can also be used by attackers to hide their own "secrets” from VTL0 entities.

This could be useful in many scenarios — by storing payloads out of the reach of EDRs, sealing encryption keys hidden away from analysts, or keeping sensitive malware configuration out of memory dumps.

As for more advanced options, many traditional malware techniques are impossible to implement within an enclave. Since enclaves are restricted to a limited subset of system APIs, they are prevented from interacting with key OS components such as files, the registry, networking, other processes, and more.

Despite this, there are still a number of techniques that are possible to perform from within an enclave that allow us to capitalize on the advantages gained from running in IUM.

By accessing the VTL0 user mode memory, we can implement various useful techniques. By loading a malicious enclave into a target process we can stealthily monitor and steal sensitive information, or patch values within the process to change its behavior.

Implementing these techniques using an enclave comes with a significant advantage — as we described earlier, triggering APIs from an enclave allows us to evade the monitoring of EDRs. As the memory access in these techniques is performed by an enclave, they can remain invisible.

By getting the user mode process to “act on their behalf,” enclaves can indirectly access the system in ways that are normally not possible for them. For example, an enclave can trigger a VTL0 routine that reads from a file, creates a socket, and so forth.

It is important to note that running user mode code this way doesn’t have an advantage in terms of evasion — as the code runs like any other user mode code, it can be visible to EDRs.

By moving critical parts of our code to an enclave alongside an anti-debugging check, we can make a piece of malware that is almost completely bulletproof to dynamic analysis.  The malware relies on the enclave to run properly, while the user mode process cannot patch the checks running inside it. Implemented correctly, this approach could only be defeated by debugging Hyper-V or the secure kernel.

This vulnerability provides an attacker with two capabilities (Figure 16).

1. Arbitrary write inside the enclave: An attacker can call SealSettings to encrypt arbitrary data, then call UnsealSettings to point to a destination address inside the enclave. This results in the original data being written to the enclave memory.

2. Arbitrary read inside the enclave: An attacker can call SealSettings, while supplying an address within the enclave as the source buffer pointer. This will cause the enclave to encrypt data from the enclave memory and write it to an attacker-controlled location. The attacker can then decrypt this data by calling UnsealSettings, enabling them to read arbitrary data from the enclave.

As of today, enclaves are used by a very limited number of applications. Even if they become more widely adopted, they will still only be loaded by specific processes, rather than by arbitrary ones. For example, calc.exe should probably never load a VBS enclave.

Because of this, anomalous enclave use can be a great detection opportunity. Defenders should capitalize on it by building a baseline of known, legitimate uses of VBS enclaves and by flagging any deviations from it. Enclave use can be identified in two ways: by monitoring enclave APIs and by detecting loaded enclave DLLs.

The following APIs are used to manage VBS enclaves by a hosting process, and will likely indicate that one is being loaded:

• CreateEnclave
• LoadEnclaveImageW
• InitializeEnclave
• CallEnclave
• DeleteEnclave
• TerminateEnclave

Another option to detect anomalous enclave use would be to detect the loading of environment DLLs that are typically used by them; that is, Vertdll.dll and ucrtbase_enclave.dll. As these DLLs should not be used by anything other than an enclave, their presence will indicate that the process likely uses one.

VBS enclaves provide an amazing tool for developers to protect sensitive sections of their applications, but — as we have just demonstrated — they can also be used by threat actors to “protect” their malware. Although this concept is mostly theoretical at this point, it is certainly possible that advanced threat actors will begin to use VBS enclaves for malicious purposes in the future.