Breaking VSM by Attacking SecureKernel

Overview: Saar Amar and Daniel King, security researchers from the Microsoft Security Response Center (MSRC), present research on the internals and attack surface of Windows 10 Virtual Secure Mode (VSM) and the Secure Kernel. The presentation examines the security boundaries established by Hyper-V between normal world (VTL 0) and secure world (VTL 1) contexts. The authors demonstrate how fuzzing and code auditing revealed critical memory corruption vulnerabilities within the Secure Kernel, allowing full ring 0 VTL 1 compromise from an assumed VTL 0 kernel compromise.

Key Topics: - Windows Virtual Secure Mode (VSM) architecture and Virtual Trust Levels (VTL 0 vs. VTL 1) - Hyper-V hypercall and Secure Call communication mechanisms - Absence of SLAT/EPT enforcement and control-flow integrity in VTL 1 - Fuzzing secure calls using Hypersid and auditing Transfer MDL vulnerabilities in SkmiObtainHotPatchUndoTable

Technical Details: Windows Virtual Secure Mode (VSM) leverages Hyper-V virtualization to partition the OS into Virtual Trust Levels: VTL 0 (normal world NTOS kernel and user space) and VTL 1 (secure world securekernel.exe and isolated user mode for Credential Guard). Under the VSM threat model, an attacker is assumed to possess arbitrary read/write primitives in the VTL 0 kernel. Hyper-V enforces Second Level Address Translation (SLAT/EPT) on lower VTLs to protect higher VTLs, powering mitigations like Hypervisor-Protected Code Integrity (HVCI). However, because VTL 1 is the highest trust level, Hyper-V does not enforce EPT restrictions against VTL 1; its Page Table Entries (PTEs) have the final say.

The Secure Kernel lacked several standard defenses: it contained hardcoded virtual addresses, lacked Control Flow Guard (CFG), and omitted shadow stack enforcement. Because VTL 1 PTEs lack EPT enforcement, an arbitrary write primitive allows modifying fixed-base PTEs to create RWX memory without needing an information leak. Furthermore, a 1-to-1 shared page mapping from VTL 0 to a fixed virtual address in VTL 1 gives attackers controlled content at a known address. Researchers also identified four memory locations in VTL 1 mistakenly marked as both writable and executable in PTEs.

To find vulnerabilities, the researchers adapted Hypersid—a fuzzer originally designed for Hyper-V hypercalls—to target Secure Calls, discovering five bugs bridging VTL 0 to VTL 1. In particular, they analyzed two vulnerabilities in SkmiObtainHotPatchUndoTable, which handles hotpatch undo data transferred via caller-controlled Transfer Memory Descriptor Lists (MDLs). The first bug was an out-of-bounds write found by Hypersid: untrusted ByteCount values from VTL 0 were used directly as allocation lengths for newly mapped MDL structures. The second vulnerability involved improper MDL mapping and cleanup logic identified during source code audit.

Key Takeaways: Virtualization-based security boundaries depend on the internal hardening of the secure kernel and rigorous validation of inter-VTL interfaces. Because the highest trust level lacks hypervisor-enforced EPT protections over its own memory space, memory corruption in secure call handlers can lead directly to arbitrary code execution, bypassing HVCI and Credential Guard. Defending isolated enclaves requires strict input sanitization on all cross-VTL data structures and backporting modern exploit mitigations into secure kernel binaries.

(AI summary — Gemini Flash)