Intro Abstract HyperVenom is a hypervisor injection and attachment framework that leverages Microsoft’s Hyper-V for memory introspection. Taking advantage of Microsoft’s Virtualization-Based Security (VBS) on Windows 11, the framework intercepts VM-exits directly inside the hypervisor, allowing for code execution at the hypervisor priviledge level. HyperVenom demonstrates how a lightweight, symbiotic payload can bypass Ring 0 visibility without causing timing or performance issues that would be picked up by telemetry. Background: Hypervisors and VBS A hypervisor, also known as a virtual machine monitor (VMM), is software that manages virtual operating systems on a physical host machine. Hyper-V is Window’s built in hypervisor. VBS (Virtualization-Based Security), a Microsoft security feature, is enabled by default on most modern Windows 11 systems and it uses hardware virtualization to isolate sensitive security features from normally accesible kernel code. It raises the cost of kernel exploitation and prevents malware from affecting the hardware and achieving persistence. Some features, like HVCI (Hypervisor-protected Code Integrity) and Credential Guard, rely on this isolation model. On VBS-enabled systems, Hyper-V boots first and owns the real hardware translation path. To the user, Windows seems like the host machine, but under the hood, it is treated like a managed guest partition under the hypervisor. Memory access on a VBS-enabled system is mediated by two translation layers. The operating system first resolves a Guest Virtual Address to a Guest Physical Address through its own page tables and, from the kernel’s perspective, appears to be modifying hardware memory directly. That Guest Physical Address, however, is not the final hardware destination. Hyper-V then performs a second translation to the underlying Machine Address (MA). This PA -> MA indirection enables the hypervisor to enforce isolation and maintain authoritative control over memory visibility. Code executing at Ring -1 therefore sits at the control boundary beneath Ring 0 and can observe, constrain, or redirect mappings that the kernel cannot directly govern. The Approach: Symbiosis The goal isn’t to replace the hypervisor, but to live inside of it. Microsoft’s Hyper-V already controls the hardware, manages page tables, and handles VM-exits. Fighting that infrastructure is a losing battle. What made this project possible was to be symbiotic, rather than adversarial. Unlike previous approaches that attempt to build entirely custom hypervisors from scratch (like Illusion-rs), rely on active dual-EPT switching (like noahware/hyper-reV), or destroy SLAT memory protections entirely (like Ring-1.io), acting as a parasite inside the existing infrastructure avoids state collisions. This repeatedly got me past the biggest hurdles, where everything I did would triple fault. Instead, I use native APIs and inject just enough code to intercept the events I care about and hand everything else back to Microsoft untouched. Project Architecture The project is broken down into three primary parts: Part 1: The Bootloader (Injector): A UEFI boot application that runs before bootmgfw.efi to hijack execution flow and inject the attachment into Hyper-V as it loads. Part 2: The Attachment (Payload): This code sits inside the hypervisor, intercepts VM-exits, manipulates hardware page tables, and performs memory introspection. Part 3: The Usermode Interface(s): This usermode hypercall library acts as a communication channel, enabling a standard Ring 3 guest application to pass discrete messages into Ring -1. Technical Deep Dive Part 1 - The Bootloader In the normal Windows boot sequence, the boot manager bootmgfw.efi loads the boot application winload.efi . Winload, as the name suggests, loads the Windows kernel. Under VBS, it also stages the Hyper-V environment through hvloader.dll and the hypervisor binary hvix64.exe (on Intel systems). The bootloader follows the execution flow through this process, intercepting the hypervisor launch function hv_launch . Subsequently, it maps the payload into the hypervisor’s page tables. I break this process into four phases: Phase 1: UefiMain This first phase loads the bootloader, prepares it for future phases, and hooks the ImgpLoadPEImage function, which loads the winload executable into memory. The application’s base address is saved for later persistence (GetMemoryMap). Then, the attachment EFI\HyperVenom\HyperVenomAttachment.efi is loaded into memory (as EfiRuntimeServicesData for persistence). Here the hypervisor heap ( EfiRuntimeServicesCode ) and the log buffer are also loaded. Finally a hook is planted on GetMemoryMap . GetMemoryMap: winload calls this to get a map of the system’s physical RAM from the motherboard. At this point, standard UEFI applications be marked to be overwritten. GetMemoryMap is intercepted, and the original function is called to get the true memory layout. This layout is modified to protect th...