Virtualized (In)Security: How Attackers Can Weaponize VBS Enclaves

Attackers are always seeking new ways to deliver and execute malware on a host without being detected. We researched some novel techniques for running malware inside a virtualization-based security (VBS) enclave and evaded common security safeguards. On August 8, 2025, I explored this attack surface in a presentation at DEF CON 33 in Las Vegas.

Part of Microsoft’s security implementation, VBS creates a virtual environment designed to isolate critical OS components. VBS enclaves enable the isolation of a region of a process, making it inaccessible to other processes, the process itself, and even the kernel. 

While VBS enclaves can improve security, they can also present enticing possibilities for attackers. That’s because malware running inside an enclave could be invisible to the memory-based detection and forensics commonly in use. We explored this idea and found a number of ways VBS enclaves could potentially be abused.

It’s important to understand the concept of Virtual Trust Levels (VTLs) underlying VBS enclaves. Each trust level provides entities running under it with different access permissions to physical memory. Lower VTLs cannot access the memory of higher ones. 

Windows currently uses two main trust levels:  VTL0, used to run traditional OS components, including the normal kernel and normal user execution modes; and VTL1, which is more privileged than VTL0, creating two new execution modes: secure kernel mode and isolated user mode.

• Secure kernel mode is used to run the secure kernel that runs in VTL1 and is, therefore, more privileged than the normal kernel. The secure kernel can enforce policies on the normal kernel and restrict its access to sensitive memory regions. Since the secure kernel is very narrow and does not support third-party drivers, it presents a significantly reduced attack surface.
• Isolated user mode is used to execute Secure Processes, a special type of user mode process that uses the memory isolation capabilities of VTL1. The memory inside isolated user mode cannot be accessed by any VTL0 code, including the normal kernel.

Together, VTL0 and VTL 1 creates four execution modes: 

• Ring0 VTL0 — Normal kernel mode
• Ring0 VTL1 — Secure kernel mode
• Ring3 VTL0 — Normal user mode
• Ring3 VTL1 — Isolated user mode

VBS enclaves create a section of a user mode process that resides in isolated user mode, into which we can load DLLs called “enclave modules.” These become a “trusted execution environment” with data and code that are inaccessible to anything running in VTL0. This facilitates isolating sensitive operations from attackers who are able to compromise the system.

Because access to VTL1 is restricted, 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. Although only trusted third parties can sign enclave modules, 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.

VBS enclaves are attractive to attackers for a couple of reasons. First, the address space of enclaves is inaccessible to anything running in VTL0 — including endpoint detection and response (EDR) and analysis tools. Second, API calls made from within an enclave can be invisible to EDRs.

Recognizing this, we investigated how attackers could execute malicious code within an enclave. In addition, we explored what techniques they could employ once their malware was running. This blog post will present what we discovered.

A VBS enclave module can be configured to be debuggable. Because enclave modules run in VTL1, debugging them is normally not possible because the debugger cannot access the enclave memory to retrieve data or place breakpoints. However, we found that when a debuggable enclave module is executed, it is still loaded into VTL1. 

To enable debugging, the secure kernel implements some exceptions that are applied to debuggable enclave modules. The memory permissions within a debuggable enclave module can also be modified by the VTL0 process. The data handled by the module can be easily exposed.

This effectively undermines the core purpose of VBS enclaves — to isolate a section of memory from VTL0. For this reason, Microsoft strongly urges developers to not ship debuggable enclave modules.

If an attacker obtains any debuggable signed enclave module they can achieve VTL1 code execution by performing a few steps that I outlined at DEF CON. This presents a risk to the attacker — just as the attacker can access the enclave memory, so can an EDR. However, the attack can evade API monitoring which can limit the visibility of an EDR solution.

This technique could be used for creating a stealthy “semi-VTL1” implant, which capitalizes on some of the advantages obtained by running inside an enclave.

We explored whether an attacker could use a version of the bring your own vulnerable driver (BYOVD) technique to run malware in a VBS enclave. This involves finding a signed enclave module with a vulnerability.

This led us to CVE-2023-36880, a VBS enclave module that is used by Microsoft Edge. Discovered by Alex Gough of the Chrome Platform Security Team, this vulnerability enables an attacker to read and write arbitrary data inside the enclave. 

We tried to abuse the read/write primitive to overwrite the enclave stack with a return-oriented programming (ROP) chain, which would eventually enable us to execute shellcode within the enclave. However, we found that enclaves are protected from unsigned code execution using arbitrary code guard (ACG), a security mitigation designed to block the execution of code created at runtime (Figure). 

We have not (yet) found a method to bypass ACG within an enclave and load unsigned code into it — though in theory, a full-ROP exploit is possible.

We explored a memory scanning evasion technique that we dubbed “Mirage,” which was inspired by Gargoyle, an evasion technique that creates a payload that continuously switches between a benign and a weaponized state. 

Mirage achieves this by transitioning between VTL1 and VTL0 memory. It stores shellcode in the VTL1 enclave memory, periodically transfers it back to VTL0 using the vulnerability, executes it, and then promptly erases it from VTL0 memory.

Because the payload spends most of the time hidden in VTL1, it is resilient to memory scans and dumps. During its dormant stage the payload is both stealthy and inaccessible. Also, the writing of the shellcode into VTL0 is performed by the enclave, outside the purview of EDR tools, making it difficult to detect through monitoring.

Another interesting application for enclave malware is anti-debugging. Code running within the enclave remains inaccessible to VTL0 applications, including debuggers, providing a significant advantage to malware.

We explored a number of approaches. Relying on the enclave’s access to the VTL0 address space of the process allows it to read the Process Environment Block (PEB) manually and check the value of the BeingDebugged flag. If a debugger is detected, the process can be terminated by the enclave.

We also looked at a time-based anti-debugging technique using processor clock cycles to measure the time spent between different enclave calls, and terminate the process if a significant delay is detected.

By moving critical parts of our code to an enclave alongside an anti-debugging check, we can create malware that is nearly bulletproof to dynamic analysis. Implemented correctly, this approach could only be defeated by debugging Hyper-V or the secure kernel.

At this point, enclaves are used by only a limited number of applications. That can make anomalous enclave use/abuse a great detection opportunity. To capitalize on that opportunity, defenders can focus on the following:

• Build a baseline of known, legitimate uses of VBS enclaves and flag any deviations
• Monitor enclave APIs for anomalies
• Monitor the loading of enclave DLLs, which can indicate a new process
• Make use of other security techniques designed to isolate critical systems and applications, such as microsegmentation

While VBS enclaves provide an effective tool for protecting sensitive sections of their applications, they can also be used by threat actors to “protect” their malware. As I explained in my DEF CON presentation, enclave attack strategies are largely theoretical at this point. However, we can be certain that advanced threat actors are doing their own research to find vulnerabilities that enable them to use VBS enclaves for malicious purposes. 

Getting a handle on enclave use within your environment is a great first step in getting ahead of this evolving threat.

Read my previous blog post, Abusing VBS Enclaves to Create Evasive Malware, to get the full technical explanation.