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. . Dies ist eine Technologie, die die Isolierung eines Bereichs eines Prozesses ermöglicht, sodass dieser für andere Prozesse, den Prozess selbst und sogar den Kernel unzugänglich ist. 

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 verwendet derzeit zwei Hauptvertrauensebenen: 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.

• Dieser Modus wird zur Ausführung des sicheren Kernels verwendet. Dies ist ein Kernel, der in VTL1 ausgeführt wird und daher mehr Berechtigungen als der normale Kernel hat. Mit diesen Berechtigungen kann der sichere Kernel Richtlinien auf dem normalen Kernel erzwingen und dessen Zugriff auf sensible Speicherbereiche einschränken. Since the secure kernel is very narrow and does not support third-party drivers, it presents a significantly reduced attack surface.
• IUM wird zur Ausführung sicherer Prozesse verwendet – ein spezieller Nutzermodusprozess, der die Speicherisolierungsfunktionen von VTL1 nutzt. Auf den Speicher im IUM kann mit keinem VTL0-Code zugegriffen werden. Dies schließt den normalen Kernel ein.

Together, VTL0 and VTL 1 creates four execution modes: 

• Ring 0 VTL0 – normaler Kernelmodus
• Ring 0 VTL1 – sicherer Kernel-Modus
• Ring 3 VTL0 – normaler Nutzermodus
• Ring 3 VTL1 – isolierter Nutzermodus

Eine VBS-Enklave ist ein Bereich eines Nutzermodusprozesses in VTL1, in den wir DLLs laden können, die als „Enklavenmodule“ bezeichnet werden. These become a “trusted execution environment” with data and code that are inaccessible to anything running in VTL0. Diese Funktion ist nützlich, um sensible Vorgänge gegenüber Angreifern zu isolieren, die das System kompromittieren könnten.

Da Microsoft den Zugriff auf VTL1 so weit wie möglich einschränken möchte, muss eine DLL, die in eine Enklave geladen wird, mit einem speziellen, von Microsoft ausgestellten Zertifikat ordnungsgemäß signiert werden. Jeder Versuch, ein Modul ohne eine solche Signatur zu laden, schlägt fehl. 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. API-Aufrufe innerhalb einer Enklave können für EDRs unsichtbar sein.

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. 

Um das Debuggen zu ermöglichen, implementiert der sichere Kernel einige Ausnahmen, die auf debugfähige Enklavenmodule angewendet werden. 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.

Insgesamt könnte diese Methode nützlich sein, um ein unauffälliges „Semi-VTL1“-Implantat zu entwickeln, das einige der Vorteile nutzt, die sich durch die Ausführung innerhalb einer Enklave ergeben.

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.

, einer Schwachstelle in einem VBS-Enklavenmodul, das von Microsoft Edge genutzt wird. 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. Mirage speichert Shellcode im VTL1-Enklavenspeicher, überträgt ihn regelmäßig über die Sicherheitslücke zurück an VTL0, führt den Shellcode aus und löscht ihn dann umgehend aus dem VTL0-Speicher (Abbildung 18).

Erstens ist die Nutzlast resistent gegen Speicherscans und -auszügen, da sie die meiste Zeit in VTL1 verborgen ist. 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.

Eine weitere interessante Anwendung für Enklaven-Malware ist das 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. Erstens können wir uns auf den Zugriff der Enklave auf den VTL0-Prozessadressbereich verlassen, was es ihr ermöglicht, den Prozess-PEB manuell zu lesen und den Wert des Flags BeingDebugged zu überprüfen. Wird ein Debugger erkannt, kann der Prozess von der Enklave beendet werden.

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.

Indem wir kritische Teile unseres Codes in eine Enklave verschieben und eine Anti-Debugging-Prüfung durchführen, sind wir in der Lage, eine Malware zu erstellen, die für dynamische Analysen nahezu unangreifbar ist.  Richtig implementiert könnte dieser Ansatz nur durch das Debuggen von Hyper-V oder des sicheren Kernels umgangen werden.

Aktuell werden Enklaven nur von einer sehr begrenzten Anzahl von Anwendungen genutzt. 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

VBS-Enklaven bieten Entwicklern ein großartiges Tool für den Schutz sensibler Bereiche ihrer Anwendungen. Wie wir gerade gezeigt haben, können sie aber auch von Bedrohungsakteuren zum „Schutz“ ihrer Malware verwendet werden. 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.