Tomer Peled - Abusing VBS enclaves to create evasive malware

### Overview In this presentation, Tomer Peled presents joint research conducted with Ori David from the Akamai Security Group exploring Virtualization-Based Security (VBS) and VBS enclaves in Windows. Peled details how VBS relies on Hyper-V to create isolated Virtual Trust Levels (VTLs), moving beyond traditional ring 3 and ring 0 boundaries to counter kernel exploits and Bring Your Own Vulnerable Driver (BYOVD) tactics. While VBS enclaves are designed to protect sensitive process data and cryptographic routines inside an isolated user mode, Peled examines how attackers can abuse these same trust boundaries to evade Endpoint Detection and Response (EDR) systems.

### Key Topics - **Virtualization-Based Security (VBS) Architecture**: From Windows 11 onward, Windows runs above Hyper-V. The architecture separates normal execution (VTL0, containing ring 3 user mode and ring 0 kernel mode) from higher-privileged execution (VTL1, containing the secure kernel and isolated user mode). VTL0 cannot read or write to VTL1. - **VBS Enclaves**: Enclaves compile as DLLs and run inside VTL1's isolated user mode. Unlike normal processes that load `ntdll.dll` (which EDRs routinely hook in user and kernel mode), enclaves load `vertdll.dll` to interact with the secure kernel, meaning enclave API calls bypass EDR hooks entirely. - **Bypassing Microsoft Enclave Signing Constraints**: VBS enclaves must be signed by Microsoft. Peled explores four potential attack paths to navigate this barrier: acquiring valid signatures via stolen certificates or shell companies; exploiting the enclave loading mechanism (referencing Alex Ionescu's 2024 vulnerability); leveraging debuggable enclaves; and adopting a Bring Your Own Vulnerable Enclave (BYOVE) model. - **Debuggable Enclaves**: Debugging enclaves in VTL1 from VTL0 debuggers is enabled by a specific flag implemented via secure kernel exceptions. If an attacker obtains a debuggable enclave, they can load it, locate an enclave routine via `GetProcAddress`, adjust memory permissions using `VirtualProtect` to `PAGE_EXECUTE_READWRITE`, write shellcode, and invoke it directly in isolated user mode. - **Bring Your Own Vulnerable Enclave & Mirage**: Analyzing CVE-2023-36880 (an information disclosure issue in Microsoft Edge discovered by Alex Gao), the researchers found a proof-of-concept providing an arbitrary read/write primitive into an enclave. Because Arbitrary Code Guard (ACG) prevents dynamic code allocation inside the enclave itself, the researchers instead developed "Mirage," a sleep obfuscation technique and tool.

### Technical Details & Mirage Demonstration Mirage leverages the arbitrary read/write primitive between VTL0 and VTL1 to evade memory scanners: 1. A VTL0 process stages malicious shellcode by writing it directly into the enclave inside VTL1. 2. While dormant in the sleep phase, the VTL0 buffer is zeroed out, leaving no detectable artifacts in normal process memory for EDRs to scan. 3. When execution is required, the enclave writes the shellcode back into the VTL0 buffer. Because operations originating from VTL1 cannot be inspected or hooked by VTL0 EDRs, this write operation succeeds without interception. 4. The shellcode executes (demonstrated in the talk by launching `calc.exe`), after which the buffer is immediately overwritten with benign data (zeroes) and returns to sleep.

### Takeaways VBS enclaves offer significant security isolation benefits, but they also present a compelling, unmonitored attack surface. Because enclaves communicate through `vertdll.dll` directly to the secure kernel, security tools currently lack visibility into VTL1. As adoption of enclaves increases, mechanisms such as sleep obfuscation through vulnerable enclaves (BYOVE) or misplaced debuggable enclaves represent practical avenues for stealthy malware execution. Peled urges security practitioners and blue teams to keep a close eye on enclaves as adoption grows.