DEF CON 33 - Virtualization Based Insecurity: Weaponizing VBS Enclaves - Ori David

Based on the feedback and the raw transcript, here's a revised summary that accurately reflects the presentation's content and structure:

Revised Summary:

VBS (Virtualization-Based Security) introduces Virtual Trust Levels (VTLs), creating a new security boundary in Windows. VTL0 contains the normal OS (user mode/kernel mode), while VTL1 (more privileged) runs isolated components like the Secure Kernel and Isolated User Mode (IUM). This isolation prevents compromised VTL0 systems from accessing VTL1 resources [Transcript].

VBS Enclaves: Security & Abuse Potential
VBS enclaves are isolated memory regions within a process, running in VTL1. The host process (VTL0) cannot read/write enclave memory but can invoke exported enclave functions via the call enclave API. Enclaves protect sensitive data (e.g., secrets) from OS compromises, as code/data within them is inaccessible to attackers controlling the host process [Transcript].

Attack Techniques Demonstrated:

1. Abusing Debuggable Enclaves:
   Enclaves can be signed with a "debuggable" flag, allowing debuggers to access their memory via exceptions in the Secure Kernel. Attackers can obtain such signed enclaves, overwrite exported functions with shellcode, and execute it in VTL1. While EDRs can theoretically scan debuggable enclaves, this technique offers:

   • Unusual code execution paths evading current detection.
   • API calls routed through VTL1 (bypassing VTL0 hooks).
     Caveat: No publicly available signed debuggable enclaves exist yet, but increased adoption may expose them [Transcript].

2. Exploiting Vulnerable Enclaves (CVE-2023-36880):
   A signed Microsoft Edge enclave contains an arbitrary read/write vulnerability. Attackers can:

   • Store shellcode/malware securely in VTL1 during dormant periods.
   • Use "Mirage": Temporarily copy shellcode from VTL1 to VTL0 for execution, then overwrite it with benign data. This creates intermittent, undetectable code