What Is a Hypervisor (VMM)? Types and Security

One compromised host should expose one machine. On a virtualized server it can expose forty. A hypervisor is the software layer that runs many virtual machines on one piece of hardware, and it sits below all of them. The guest operating systems trust it completely. They have to, because it is the thing handing them their CPU, their memory, and their virtual disks. Take over the hypervisor and you own every VM it hosts, with none of the guests able to see you do it.

That is why the hypervisor matters to a defender even when nobody in the SOC ever logs into one directly. Every cloud workload you investigate, most of the servers in your data center, and the sandbox your malware analyst detonates samples in all run on top of one. It is the foundation the rest of the stack assumes is solid. This guide covers what a hypervisor is, the two types and where each is used, how the VMM actually works, and the attacks that target the layer underneath everything else.

What is a hypervisor (VMM)?

A hypervisor, also called a virtual machine monitor (VMM), is software that creates and runs virtual machines on a single physical host. It sits between the hardware and the guest operating systems, presenting each VM with what looks like its own dedicated CPU, memory, storage, and network, while the real hardware is shared underneath.

The job is resource arbitration and isolation. The hypervisor schedules physical CPU time across guests, partitions and allocates memory, maps virtual disks onto real storage, and keeps each VM walled off from the others so one guest cannot read another's memory or reach into its files. To the guest OS, the virtual hardware is indistinguishable from physical hardware. That illusion is the whole point: it lets one server run a dozen isolated workloads that each behave as if they had the machine to themselves.

This is the foundation of cloud computing. When you spin up an instance at a cloud provider, you are getting a VM scheduled by a hypervisor on hardware you share with other tenants. The same technology consolidates on-premises data centers, runs the desktops in a VDI deployment, and provides the disposable, isolated environments used for malware detonation. Wherever workloads need to be created fast, moved between hosts, snapshotted, and torn down, a hypervisor is doing the work.

Why virtualization runs on hypervisors

Before hypervisors, one application often meant one physical server, most of them idling at a fraction of their capacity. Virtualization changed the economics, and the hypervisor is what made it safe to pack multiple workloads onto shared hardware.

A few properties matter for defenders specifically:

• Consolidation and density. One physical host runs many VMs, which is why a single compromised hypervisor has such a large blast radius. The efficiency that makes virtualization attractive is the same thing that concentrates risk.
• Isolation. Each VM is sandboxed from the others. A compromise inside one guest should stay inside that guest. This is a security feature, and the attacks later in this guide are exactly the ones that try to break it.
• Snapshots. The hypervisor can capture a VM's full state at a point in time and roll it back later. For incident response this is powerful: you can preserve a compromised VM for forensics and restore a clean one in parallel.
• Live migration. A running VM can move between physical hosts with no downtime. Convenient for operations, but it also means the location of a workload is fluid, which complicates asset tracking.
• Rapid provisioning. VMs are created from templates in seconds. The same speed produces sprawl: workloads nobody inventoried, running on hosts nobody is watching.

Every one of these is an operational win and a security consideration at the same time. The hypervisor gives you the ability to move fast, and the discipline to track what you spun up has to come from somewhere else.

Type 1 vs Type 2 hypervisors

Hypervisors split into two architectures based on where they sit. The difference is not academic. It changes the attack surface, the performance, and where you find each one.

A Type 1 hypervisor, also called bare-metal, installs directly on the physical hardware and runs in place of a conventional operating system. There is no host OS underneath it. The hypervisor is the lowest software layer on the machine, and the guest VMs run on top of it. Because there is no general-purpose OS beneath the hypervisor, the attack surface is smaller and there are fewer unrelated services to exploit. This is what runs production data centers and cloud platforms. Named examples include VMware ESXi, Microsoft Hyper-V, Xen, and KVM.

A Type 2 hypervisor, also called hosted, installs as an application on top of an existing operating system, the same way any other program does. The host OS boots first, and the hypervisor runs as software within it, with the guest VMs another layer up. This is easier to set up and is what you run on a laptop or workstation. The tradeoff is a larger attack surface and higher latency: every guest operation passes through the host OS, and any vulnerability in that host OS is now underneath your VMs. Named examples include VMware Workstation, Oracle VirtualBox, and Parallels.

The line between the two is not always clean. KVM is a kernel module that turns a running Linux kernel into a hypervisor, which makes it behave as Type 1 even though Linux booted first. The useful question for a defender is not which label fits but what sits below the hypervisor: on a bare-metal deployment, nothing; on a hosted one, a full operating system that is now part of your trusted base.

Most of what a SOC investigates in the cloud runs on Type 1. Type 2 is what an analyst uses on their own machine, which is why a malware sample's ability to detect a hypervisor and behave differently matters: it is often trying to tell whether it landed in a Type 2 analysis sandbox.

How a hypervisor works

The mechanism that makes the hardware illusion possible is privilege. A CPU runs code at different privilege levels, and the hypervisor claims the most privileged one, more privileged than any guest operating system. The guests think they are in charge of the machine. They are not. The hypervisor is.

The core moves:

• Resource scheduling. The hypervisor decides which VM gets physical CPU time and for how long, the same way an OS scheduler arbitrates between processes, except the things being scheduled are entire operating systems.
• Memory partitioning. Each VM is given a range of memory it believes is the full physical address space. The hypervisor maps that virtual view onto real RAM and enforces that one VM cannot read or write another's pages.
• Device emulation and pass-through. Disks, network cards, and other peripherals are presented to the guest as virtual devices. The hypervisor translates the guest's hardware requests into operations on the real devices, or grants direct access to a physical device when performance demands it.
• Trapping privileged instructions. When a guest OS tries to execute an instruction only the real hardware owner should run, the CPU traps into the hypervisor, which handles it on the guest's behalf and returns control. Modern CPUs provide hardware virtualization extensions (Intel VT-x, AMD-V) that make this fast.

Isolation is enforced by that privilege gap and the memory mapping. A guest is supposed to have no way to address memory outside its allocation or to issue instructions the hypervisor does not mediate. The attacks that matter most against virtualization are the ones that defeat exactly this boundary.

Hypervisor security risks

The hypervisor concentrates trust, and that makes it a target worth real effort. Two risk shapes dominate, and they pull in opposite directions.

The first is the blast radius. Because one hypervisor hosts many VMs, compromising it compromises all of them at once, and it does so from below, where the guests' own security tools cannot see. An endpoint detection and response agent inside a guest watches that guest. It has no visibility into the layer underneath it. Code running in the hypervisor is invisible to everything it hosts.

The second is that isolation is also a defense. A compromise contained inside one VM stays inside that VM, as long as the boundary holds. The whole security model of multi-tenant cloud rests on that containment. The attacks below are the ones that try to break it.

• VM escape. An attacker who has compromised a guest VM exploits a vulnerability in the hypervisor or its device emulation to break out of the guest and execute code on the host or in the hypervisor itself. This is the worst case: it turns a single compromised tenant into control of the host and every other VM on it. VM escape bugs in widely used hypervisors are high-severity events precisely because of that reach.
• Hyperjacking. An attacker installs a malicious hypervisor underneath the running system, or subverts the existing one, so that the legitimate OS runs as a guest without knowing it. From that position the attacker can intercept everything the OS does while remaining nearly invisible to it. This is the stealth end of the threat: control of the layer below detection.
• Host compromise. On a Type 2 hypervisor, the host OS sits below the VMs, so any compromise of that host OS is a compromise of the foundation the guests run on. Type 1 narrows this by removing the general-purpose host OS, but the hypervisor's own management interfaces and any service it does expose remain in scope.
• Resource and side-channel attacks. Because VMs share physical hardware, a malicious tenant can attempt to infer data from a co-resident VM through timing or cache side channels, or degrade neighbors by exhausting shared resources. These are harder to pull off but break the assumption that sharing hardware is the same as isolation.
• Management plane abuse. The hypervisor's management console and APIs are an administrative path to every VM at once. Stolen admin credentials or an exposed management interface can hand an attacker the keys to the whole host without any exotic exploit.

The common thread: the hypervisor is below the guests, so guest-level defenses do not protect it, and a single failure there has multi-VM consequences.

How to secure a hypervisor

The controls follow from the risks. The goal is to keep the layer that everything trusts small, patched, and tightly accessed.

Minimize the host's role and attack surface. A Type 1 hypervisor host should do one thing: run VMs. Strip every service, agent, and role that is not required to operate the hypervisor. The smaller the footprint, the fewer the ways in. This is the bare-metal advantage; do not undo it by installing extras on the host.

Patch the hypervisor on its own urgency. VM escape and other hypervisor vulnerabilities are high-severity by definition, because one bug reaches every guest. Patch the hypervisor and its management components promptly, and do not let the difficulty of scheduling host maintenance push these fixes to the back of the queue.

Lock down the management plane. The management console and APIs are a path to every VM. Put them on a separate, restricted management network, never expose them to the internet, require multi-factor authentication, and apply access control so that administrative privileges go only to the few who need them. Treat hypervisor admin access the way you treat domain admin.

Apply least privilege and zero trust. Limit who and what can talk to the hypervisor and its management interfaces. Assume the network around it is hostile and verify every access rather than trusting location.

Encrypt and segment. Encrypt VM data at rest and in transit, and segment the network so a compromised guest cannot reach the management plane or pivot freely to other hosts.

Get telemetry from the host, not just the guests. Guest-level agents are blind to the hypervisor. Collect logs from the hypervisor and its management plane and forward them into the same monitoring pipeline you use for everything else, so a SOC has something to hunt in below the guest layer. Watch for unexpected admin logins, configuration changes, snapshot or export activity, and VM creation outside normal change windows.

None of these is exotic. They are the same disciplines applied to ordinary servers, aimed at the one layer whose compromise is worth the most to an attacker.

Frequently Asked Questions

What is a hypervisor in simple terms?

A hypervisor is software that lets one physical computer run several separate virtual machines at the same time. It sits between the hardware and those virtual machines, giving each one a slice of the CPU, memory, and storage while keeping them isolated from each other. It is also called a virtual machine monitor, or VMM.

What is the difference between a Type 1 and Type 2 hypervisor?

A Type 1 hypervisor runs directly on the hardware with no operating system beneath it, which is faster and has a smaller attack surface. It runs data centers and cloud platforms. A Type 2 hypervisor runs as an application on top of an existing operating system, which is easier to set up and is what you use on a laptop, but it inherits the security flaws of the host OS underneath it.

Is a hypervisor the same as a virtual machine?

No. The hypervisor is the software that creates and runs virtual machines. A virtual machine is one of the isolated guest environments the hypervisor hosts. One hypervisor typically runs many virtual machines on a single physical host.

What is VM escape?

VM escape is an attack where code running inside a guest virtual machine exploits a vulnerability in the hypervisor to break out of its isolation and execute on the host or in the hypervisor itself. It is among the most serious virtualization attacks because it turns control of one VM into control of the host and every other VM running on it.

What is hyperjacking?

Hyperjacking is an attack in which an adversary installs a malicious hypervisor beneath the running system, or subverts the legitimate one, so the real operating system runs as a guest without realizing it. From that position the attacker can monitor and control the system while staying nearly invisible to the OS and its security tools, because they are running at a lower layer than the defenses.

Why is hypervisor security important?

Because a hypervisor hosts many virtual machines and sits below all of them, compromising it exposes every VM it runs, and it does so from a layer the guests' own security tools cannot see. One hypervisor vulnerability can have a blast radius of every workload on the host, which is why hypervisor patching, management-plane lockdown, and least privilege carry outsized weight.

The bottom line

A hypervisor is the software that runs virtual machines on shared hardware, and it sits below every guest it hosts. That position is its value and its risk: it lets one server run many isolated workloads, and it means a single compromise of that layer reaches all of them, from a place the guests cannot see.

Type 1 runs the cloud and the data center on bare metal with a small attack surface; Type 2 runs on a host OS on workstations and in analysis sandboxes. The attacks that matter, VM escape and hyperjacking, both aim at the isolation boundary that the whole model depends on. Defend the layer accordingly: keep the host minimal, patch the hypervisor on its own urgency, lock down the management plane, and get telemetry from below the guests, because that is the one place guest-level tooling will never look.