HyperVinject: Making Virtual Machine Code Injections as Simple as Process Injections

HyperVinject: Making Virtual Machine Code Injections as Simple as Process Injections

Speakers: Andrei Lutas, Security Researcher, Bitdefender

Conference: REcon 2025

YouTube: https://www.youtube.com/watch?v=hpmRQZ6T7YM

Overview

Security researcher Andrei Lutas from Bitdefender presented HyperVinject, a novel technique that enables code injection from a Hyper-V root partition directly into running child virtual machines. This research demonstrates how traditional process injection techniques can be extended across hypervisor boundaries, allowing injection from the host system into any process running within a guest VM. The technique leverages undocumented Hyper-V virtualization infrastructure APIs and represents the first practical method for cross-VM code injection on Microsoft's hypervisor platform.

Background

▶ Watch: Introduction: HyperVinject — first tool for code injection into Hyper-V guest... (1:45)

Code injection techniques have been a cornerstone of both malware and legitimate security research for decades. Traditional methods like CreateRemoteThread, DLL injection, and more exotic variants such as process hollowing, atom bombing, and process doppelgänging all share common primitives: allocate space for shellcode, deploy the payload, and execute it. However, these techniques are constrained to operating within the same privilege domain.

Hyper-V's architecture presents an interesting challenge for extending these techniques. The hypervisor runs as a bare-metal Type 1 hypervisor with a root partition hosting the management OS and multiple child partitions running guest operating systems. Each child partition is managed by a Virtual Machine Worker Process (VMWP) in the root partition, which communicates with the hypervisor through the Virtualization Infrastructure Driver (VID) stack.

Previous work in this area has been limited. While researchers demonstrated VM code injection on VMware at Black Hat 2009, and projects like HVMI from Bitdefender accomplished similar goals on Xen and KVM, HyperVinject represents the first practical implementation specifically targeting Microsoft's Hyper-V platform using its proprietary APIs.

Key Findings

▶ Watch: Hyper-V internals: Root Partition, VMBus, and partition memory model (13:11)

Lutas demonstrated that it's possible to achieve reliable code injection from the Hyper-V root partition into running child partitions by exploiting several key insights:

• VID API Access: The undocumented VID.DLL APIs can be leveraged to read, write, and monitor virtual machine memory and processor states
• Memory Translation: Physical memory access combined with CR3 register values enables virtual-to-physical address translation within guest VMs
• Slack Space Utilization: Unused space at the end of PE sections provides reliable injection targets without memory allocation
• System Call Hooking: The IA32_LSTAR register points to kernel system call handlers, providing predictable execution triggers

The technique successfully bypasses traditional detection mechanisms because it operates from a more privileged domain than the target VM, making it invisible to guest-based security solutions.

Technical Deep Dive

▶ Watch: HyperVinject technique: novel injection primitive across partition boundary (19:20)

Introspection Phase

The injection process begins with gaining access to the target VM through the Virtualization Infrastructure Driver (VID) APIs. Key APIs include:

• VidGetVirtualProcessorState: Queries virtual processor registers and state
• VidReadMemoryBlockPageRange/VidWriteMemoryBlockPageRange: Provides physical memory read/write access
• VidSetVirtualProcessorState: Modifies virtual processor state

The first challenge involves identifying which VMWP process controls the target VM. HyperVinject accomplishes this by scanning the memory space of all VMWP processes for the target VM's name string. Once the correct process is identified, code injection into the VMWP enables access to the VID APIs.

Critical parameters for the VID APIs include:

• Partition Handle: Each child partition has a unique handle that must be brute-forced by incrementally testing handle values
• Memory Blocks: VM memory is segmented into blocks, with the first 4GB typically in one block and additional memory in subsequent blocks
• Processor State Codes: Each CPU register and state element has a specific code for querying/modification

Memory Translation

Physical memory access requires translation from virtual addresses used by the guest OS. HyperVinject implements this by:

1. Querying the current CR3 register value from virtual processor state
2. Implementing four-level page table walking for x86-64 address translation
3. Falling back to system CR3 (kernel page table) when current CR3 becomes invalid

The system CR3 is located by scanning the first few megabytes of physical memory for valid page table structures, providing a reliable translation base that persists throughout the VM's lifetime.

Injection Target Location

Rather than allocating new memory (impossible from outside the VM), HyperVinject leverages slack space - unused bytes at the end of PE sections. This technique:

• Identifies the kernel image location using the IA32_LSTAR register value
• Scans backward to find the ntoskrnl.exe base address via PE header validation
• Locates executable sections with sufficient trailing unused space
• Typically finds 3KB+ of available space in the .text section alone

Execution Trigger

Code execution is achieved by hooking the system call handler at a carefully chosen location:

The hook is placed after the STI instruction to ensure complete kernel transition and safe execution context. This guarantees that:

• User-mode data has been properly saved
• Kernel data structures are initialized
• Interrupts are enabled for safe API calling
• The system is in a stable state for code execution

Shellcode Implementation

The kernel shellcode includes several sophisticated features:

Execution Control: Uses unused fields in the Kernel Processor Control Region (KPCR) to implement execution flags, ensuring the payload runs only when intended rather than on every system call.

API Resolution: Resolves required kernel APIs using system call numbers and service descriptor tables, requiring only four functions:

• PsLookupProcessByProcessId
• ZwAllocateVirtualMemory
• ZwWriteVirtualMemory
• PsCreateSystemThread

User-Mode Injection: Performs traditional process injection from kernel context to achieve the ultimate goal of spawning a calculator in the target process.

Demo / Proof of Concept

▶ Watch: Security impact: bypassing guest-side EDR detection via hypervisor injection (30:45)

Lutas successfully demonstrated HyperVinject during the presentation, injecting code into a Windows 11 24H2 virtual machine from the Hyper-V host. The demo showed:

1. Target VM running with Process Explorer displaying process ID 8832
2. HyperVinject execution with VM name "Windows1124H2" and target PID
3. Successful calculator spawn within the guest VM
4. Custom "Hello REcon" message injection proving arbitrary code execution

The demonstration confirmed reliable operation across multiple configurations:

• Host OS: Windows 10/11, Windows Server
• Guest OS: Windows 8.1, Windows 10, Windows 11
• Architecture: 64-bit systems exclusively
• Special Cases: Windows Sandbox compatibility confirmed

Defensive Implications

▶ Watch: Mitigations and Microsoft's response to HyperVinject disclosure (37:21)

Detection Challenges

HyperVinject presents significant detection challenges because it operates from a more privileged domain than traditional security tools:

• Invisibility: Guest-based EDR and AV solutions cannot observe root partition activities
• Legitimate APIs: Uses documented (though undocumented) hypervisor management interfaces
• Minimal Footprint: Short-lived modifications avoid triggering Kernel Patch Protection (PatchGuard)
• Clean Cleanup: Restores original memory state after injection completion

Potential Mitigations

Several defensive measures can reduce HyperVinject's effectiveness:

Shielded VMs: Enables Protected Process Light (PPL) for VMWP processes, significantly raising the bar for initial code injection. While not insurmountable, this mitigation requires additional techniques like vulnerable driver exploitation.

Memory Encryption: Technologies like Intel TXT Trust Domain Extensions and AMD Secure Encrypted Virtualization (SEV) with Secure Nested Paging encrypt VM memory, preventing hypervisor-level plaintext access. This represents the most effective mitigation as it eliminates the fundamental requirement for memory introspection.

VBS Integration: Virtualization-Based Security can provide additional isolation, though the research noted that VTL1 secure kernel contexts are sometimes visible, potentially expanding the attack surface.

Legitimate Use Cases

The technique has potential defensive applications:

• Agentless VM Monitoring: Security products could monitor child partitions without installing guest agents
• Incident Response: Forensic analysis of compromised VMs from the hypervisor level
• Sandbox Analysis: Enhanced malware analysis capabilities in Windows Sandbox environments

Key Takeaways

• Hypervisor-agnostic method: While implemented for Hyper-V, the core technique applies to any hypervisor with equivalent memory access APIs
• Not a vulnerability: Microsoft confirmed this doesn't cross security boundaries, as hypervisors are expected to have complete control over guest VMs
• Research implications: Opens possibilities for secure kernel injection, virtualization event interception, and defensive hypervisor applications
• Mitigation reality: Effective defenses exist but require advanced hardware features like memory encryption
• Tool availability: HyperVinject will be open-sourced for educational and research purposes

The research fundamentally demonstrates that virtualization boundaries, while providing isolation between guest VMs, do not prevent sophisticated attacks originating from privileged hypervisor contexts. As virtualization becomes increasingly central to enterprise security architectures, understanding these cross-VM attack vectors becomes critical for proper risk assessment and defense planning.

About the Speaker(s)

Andrei Lutas is a security researcher at Bitdefender with a PhD in Computer Science and extensive experience in low-level security research. He previously led the R&D team responsible for Bitdefender's Hypervisor Memory Introspection (HVMI) project and currently leads advanced memory protection detection initiatives. His research focuses on hypervisor security, kernel-level protections, and virtualization technologies. Lutas has deep expertise in Windows internals, x86 architecture, and hypervisor development, making him uniquely qualified to explore the intersection of virtualization and security.