Hey there, it has been a "little" while since I published my last post. After scrapping and rewriting multiple ideas, I decided to write something a bit different from my previous posts.
This post contains technical information, but I also wanted to share my thoughts after working on a hypervisor project for more than a year. I will cover the motivation behind the project, what I learned from building Nova, what I want it to become, and where I think hypervisor-based defense is heading.
If you have not already, grab a cup of coffee and let's look at the emerging world of hypervisor-based defense together.
Why Virtualization
Before looking at how virtualization works, or why it matters for defense, it is worth asking a simpler question: why do we even need virtualization in the first place? What does it give us that we cannot achieve without it, and why is it worth adding another layer of complexity to the system?
Virtualization Crash Course
Virtualization is a set of technologies that allows the division of physical computing resources into virtual machines. Historically, the idea goes back to IBM's CP/CMS work in the 1960s.
At a high level, there are two main entities: the hypervisor and the guest virtual machines. In hosted virtualization, the hypervisor runs on top of a host operating system. In both cases, the hypervisor is responsible for managing virtual machines and allocating resources to them. The virtual machine itself is a software representation of a physical computer that runs its own operating system and applications.
In simple terms, virtualization allows us to run multiple operating systems on a single physical machine, each inside its own isolated environment. That isolation is useful not only for infrastructure and cloud platforms, but also for security.
Types of Hypervisors
There are two main types of hypervisors:
▸
Type 1 hypervisors, also known as "bare-metal" hypervisors, run directly on the hardware. Examples include VMware ESXi, Microsoft Hyper-V, and Xen.
▸
Type 2 hypervisors, also known as "hosted" hypervisors, run on top of a host operating system. Examples include Oracle VirtualBox and VMware Workstation.
While Type 1 hypervisors are more commonly used for security purposes (as we will see later on in the VBS section), in this post, I focus mostly on the Type 2 model because that is the environment I used while building and testing Nova.
Virtualization Platforms
There are several hardware virtualization technologies that provide the foundation for modern hypervisors:
▸
Intel VT-x, Intel's hardware-assisted virtualization technology, introduced in 2005 and widely supported on modern Intel processors.
▸
AMD-V, AMD's counterpart to VT-x, also introduced in 2005 and widely supported on modern AMD processors.
▸
ARM virtualization extensions, which introduce EL2 (hypervisor mode) and stage-2 memory translation on ARM platforms.
These technologies are the backbone of platforms such as VMware, Hyper-V, and VirtualBox. Virtualization affects our lives not only from a security perspective, through mechanisms such as sandboxing and virtualization-based security, but also from an infrastructure perspective, since it enables cloud providers such as AWS, Azure, and Google Cloud to deliver virtualized resources at scale.
Basics of Virtualization
This is not meant to be a comprehensive guide. It is a high-level overview of the core concepts that are useful for understanding hypervisor-based defense. If you want to go deeper, I highly recommend Sina Karvandi's Hypervisor From Scratch series, along with the official vendor documentation for the platform you care about.
For simplicity, I focus on Intel VT-x. The same general ideas carry over to AMD-V and ARM, even though the implementation details differ.
Hypervisor Role and Architecture
If we break the hypervisor down to its essentials, it has two main responsibilities:
▸
Managing the virtual machines' state and resources, such as CPU, memory, and I/O devices.
▸
Providing an interface between the guests and the underlying physical hardware.
That sounds simple on paper, but in practice it is a complex job that requires careful handling of CPU state, memory translation, and event interception.
State Management
State management is one of the hypervisor's critical jobs. It involves tracking enough state to start, stop, resume, and switch virtual machines cleanly and securely. Several structures are central here, especially the VMCS, guest page tables, and EPT.
Virtual Machine Control Structure (VMCS)
The Virtual Machine Control Structure, or VMCS, is the data structure Intel uses to describe guest state, host state, and the controls that define how virtualization behaves. It tells the processor what state to restore on VM entry, what state to save on VM exit, and which events should transfer control back to the hypervisor.
Source: Hypervisor From Scratch - Part 1 | View source
The guest and host state areas share many structural similarities. They contain architectural state such as control registers, segment registers, debug registers, and descriptor-table information. Some of the fields that are especially relevant here are:
▸
CR3, which points to the root of the guest page tables and is central to virtual memory management.
▸
GDTR and IDTR, which describe the Global Descriptor Table and Interrupt Descriptor Table.
▸
CS and SS, which define the code and stack segments.
▸
DR7, which controls hardware breakpoints and is relevant for debugging and monitoring.
Source: Hypervisor From Scratch - Part 1 | View source
The control fields define which events cause VM exits. At a high level, they are usually discussed in terms of pin-based controls, primary processor-based controls, and secondary controls.
Examples include intercepting CPUID,INVLPG, control-register access, and EPT violations. These are the hooks that let a hypervisor observe or enforce behavior in a guest.
Extended Page Table (EPT)
EPT is Intel's implementation of second-level address translation, or SLAT. It gives the hypervisor its own layer of control over guest memory and is one of the main reasons modern hardware virtualization is practical from a performance standpoint.
Source: Hypervisor From Scratch - Part 4 | View source
Conceptually, the memory translation pipeline looks like this:
▸
Guest virtual addresses are translated to guest physical addresses through the guest page tables rooted at CR3.
▸
Guest physical addresses are then translated to host physical addresses through EPT, rooted at the EPT pointer stored in the VMCS.
That split is important. The guest still believes it owns its own memory mappings, but the hypervisor gets a second, independent layer of control over what physical memory is actually reachable and with what permissions.
Page Table Entries (PTE)
Guest page tables are still worth discussing because they remain the first stage in the translation pipeline. A page table entry maps a guest virtual address to a guest physical address and carries permissions such as read/write access, supervisor-only access, caching behavior, and software-defined bits.
The important point is not memorizing every bit, but understanding that guest page tables and EPT serve different roles. One controls the guest's view of memory; the other controls the hypervisor's view of the guest.
Communication Between Hypervisor and Guest
Hypervisors and guests communicate in a few main ways. Two of the most relevant are VMCALL instructions and VM exits.
▸
VMCALLs allow the guest to intentionally transfer control to the hypervisor, similar in spirit to a system call.
▸
VM exits occur when configured events happen, such as CPUID execution, control-register access, I/O instructions, or EPT violations.
When a VM exit occurs, the processor saves the relevant guest state defined in the VMCS, restores the relevant host state, and records the reason for the exit so the hypervisor can handle it correctly.
Nested Virtualization
Nested virtualization means running a hypervisor inside a virtual machine that is itself managed by another hypervisor. This is useful for research, testing, and development, but it also adds significant complexity because multiple layers now participate in the same virtualization flow.
Why Do We Even Need Hypervisor-Based Defense?
Now that the groundwork is in place, we can talk about what hypervisor-based defense actually is. In broad terms, it is a security approach that uses virtualization primitives to enforce protections from a higher privilege level than the guest kernel.
What Is Hypervisor-Based Defense?
Most major operating systems now expose some form of this idea:
▸
On Windows, it is most visible through Virtualization-Based Security (VBS).
▸
On Android, it appears through the Android Virtualization Framework (AVF).
▸
On Apple platforms, related ideas show up through secure execution environments and hardware-backed isolation mechanisms.
The details differ, but the common theme is the same: move security decisions into an isolated execution environment that a compromised kernel cannot easily tamper with.
Virtualization-Based Security (VBS)
On Windows, VBS uses the Windows hypervisor to create an isolated environment that becomes a higher-trust part of the operating system. Microsoft uses that environment to host security-critical logic that should remain protected even if the normal kernel is compromised.
At a high level, VBS is commonly discussed in three buckets:
▸
Memory-protection features such as Hypervisor-Enforced Code Integrity (HVCI).
▸
Virtual Trust Levels (VTLs), mainly VTL0 for the normal world and VTL1 for the secure world.
▸
VBS enclaves, which provide isolated execution environments for selected workloads.
Hypervisor-Enforced Code Integrity (HVCI)
HVCI, also known as Memory Integrity, is one of the most visible VBS features. Its job is to ensure that only trusted, validated code can execute in kernel mode.
Windows achieves this by combining the Windows hypervisor with the Secure Kernel, which runs in VTL1. The normal Windows kernel and user-mode processes run in VTL0, while security policy enforcement happens in the more isolated environment.
At a high level, HVCI combines code integrity policy, hypervisor memory enforcement, and second-stage address translation protections. Once a kernel page is validated, the hypervisor can enforce strict execution rules over it.
One of the most important results is the restriction of W→X transitions. Executable kernel pages should not become writable later, and writable pages should not become executable without going back through validation. That does not solve every exploitation technique, but it raises the bar considerably.
If you want a deeper Windows-specific dive, Connor McGarr's HVCI internals article is excellent.
Motivation Behind Nova
After spending time in both offensive and defensive research, I kept coming back to the same observation: the ecosystem is clearly moving toward virtualization-backed security, but most third-party security tooling still treats the kernel as the highest point of control.
Anyone who has worked on Windows kernel exploitation or rootkits in the last few years has felt the difference. The environment does not look like it did five years ago. That is good news for defenders, but it is also good for offensive research because it forces people to explore harder and more interesting problems.
That shift is what motivated Nova. I wanted to explore what a third-party, open-source, hypervisor-based defensive project could look like, especially one aimed at protecting security-critical components from a compromised kernel.
Threat Model
Nova is designed around the assumption that kernel compromise may already have happened. Concretely, the attacker may already have:
▸
Kernel code execution.
▸
The ability to load a vulnerable driver (BYOVD).
▸
The ability to modify kernel memory.
Under those assumptions, traditional kernel-resident protections may no longer be trustworthy. A hypervisor sits above the guest kernel and can therefore enforce policies from a higher privilege layer. That architectural advantage is what makes hypervisor-based defense attractive here.
Nova Architecture
My goal with Nova is to build a hypervisor-based defensive platform that is open-source, usable, and practical for both research and production-oriented experimentation. To get there, a few baseline requirements matter:
▸
Compatibility with modern Windows 10, Windows 11, and Windows Server versions.
▸
The ability to operate under VMware and Hyper-V, which are common both in research labs and production environments.
▸
A clean interface that can integrate into existing environments without too much friction.
▸
A design that aims for minimal performance overhead.
Nova architecture overview
At a high level, Nova manages the guest while delegating lower-level virtualization operations to the underlying hypervisor when needed. The interesting part is what happens on top of that: by using EPT hooks, Nova can treat sensitive memory ranges as policy-enforced objects rather than just bytes that the guest kernel is free to modify.
EPT Hooks
EPT hooks are one of the most useful primitives in this design. Instead of patching the guest kernel directly, the hypervisor changes EPT permissions so that specific accesses trigger EPT violations. That forces the processor to VM-exit and gives the hypervisor a chance to inspect the access and decide what to do next.
For example, if you want to watch a write to a sensitive region, you can remove write permission from the relevant EPT entry. The guest will continue running normally until it attempts that write. At that point, the hypervisor receives control and can evaluate the context, including which module performed the access and what memory was touched.
Unlike traditional kernel hooks, EPT hooks operate outside the guest operating system. That means they can remain effective even if the guest kernel is already compromised. For a deeper implementation walkthrough, memN0ps's article on EPT-based introspection is an excellent follow-up resource.
Hypervisor vs Kernel Level Threats
One of the most common ways attackers blind endpoint protections today is by using a vulnerable driver, a kernel exploit, or a rootkit to patch callbacks, remove hooks, tamper with ETW, or modify the product itself. If the attacker controls the kernel, software that lives only inside the kernel is in a very difficult position.
EPT-based enforcement changes that balance. A hypervisor can protect:
▸
Executable pages of an EPP driver or related process memory, preventing silent patching.
▸
Important ETW-related structures by making unauthorized writes fault into the hypervisor.
▸
Sensitive callback, callout, or routine lists by moving write authorization outside the guest kernel.
That does not make kernel attacks obsolete, but it does significantly raise the cost of using them to disable telemetry or blind security tooling.
To better understand how that works in practice, let's see the following scenario and how Nova helps to mitigate it:
Scenario: An attacker exploits a vulnerable driver to gain kernel R/W primitives to patch the callbacks list.
In this scenario, the attacker has already achieved kernel R/W primitives through a vulnerable driver. Their next step is to patch the callback list to remove the EPP callbacks. However, when the user uses Nova to protect the EPP driver address range, Nova monitors the callbacks list and when the attacker tries to patch it, Nova catches the write operation and denies it.
What Is Next?
This is a high level overview of what Nova has and what I want to achieve with it. As you can tell, the project is still in its early stages and there is a lot more to implement, and the versions might shift a bit from the current plan.
Nova's Roadmap
A high-level view of the milestones I want to achieve.
v1.0 | Initial Release
Completed
Hypervisor that works on Windows 10 and 11 versions, with support for VMware and minimal support of Hyper-V.
Features
EPT hooks
Communication interface for third-party components
Logging via ETW
Event injection
Supporting running under VMware
Basic support for running under Hyper-V
v1.0.1 | Hyper-V Fixes
Current Release
Fixing Hyper-V compatibility issues and fully supporting Hyper-V environments (excluding with VBS enabled).
Features
Added handling of more VM-exit reasons that are relevant in Hyper-V environments
Added handling of synthetic MSR accesses
Bugfixes
Fixed Hyper-V support issues
v1.1 | Enhanced Interface
Milestone
Make the interface more intuitive and easier to use for third-party defensive components, with a focus on improving the experience of writing EPT-based policies.
Features
Add an easy to use configuration system for EPT hooks
Better logging system
Automatically protect known sensitive structures such as ETW-related ones, callbacks lists
Add documentation and examples for writing EPT-based policies
Bugfixes
Add SAL annotations
v1.2 | Support More Platforms
Milestone
Expand support to VirtualBox, QEMU and KVM environments.
Features
Support VirtualBox
Support QEMU
Support KVM
Add a CI pipeline to automatically test compatibility with all supported platforms
v2.0 | AMD Support
Milestone
Creating a version of Nova that works on AMD-V platforms, which requires an almost complete rework of the virtualization layer.
Features
Support AMD-V
v2.1 | ARM Support
Milestone
Creating a version of Nova that works on ARM platforms, which requires an almost complete rework of the virtualization layer.
Features
Support ARM
v3.0 | VBS Compatibility
Milestone
Reworking Nova's architecture to be compatible with VBS-enabled environments, which likely requires a significant redesign of the current implementation.
Features
Full compatibility with VBS-enabled environments
Redesign of Nova architecture to work alongside the Windows hypervisor
Add VBS-aware features
Maintain support for Intel, AMD and ARM platforms
As you can tell, there is a lot more to be done. The current version, while it is stable and contains the core features it is far from being complete or where I want it to be. From the challenges of supporting different hypervisor platforms, to the architectural changes to support AMD-V, ARM and VBS there is so much to be done. With that being said, I still believe that the current version is a solid foundation to build on and to learn from its code.
Epilogue
This was intentionally a high-level overview of hypervisor-based defense. I wanted it to be detailed enough to explain the underlying ideas, while still remaining approachable for readers who are new to virtualization.
If this area interests you, I strongly encourage you to explore virtualization not only as an infrastructure primitive, but as a security one. Even if you are coming from an offensive background, asking how you can use virtualization to your advantage opens up a surprisingly rich research space.
Finally, I want to thank memN0ps for proof reading this article, to Matan Kotick for brainstorming with me about hypervisor based defense and its implications, Sina Karvandi, Connor McGarr, Satoshi Tandasat, Alex Ionescu and many others whose work helped greatly in shaping my understanding of this space.
