Nested Virtualization Risk Lab
Running a VM inside a VM sounds like a free convenience. It is not: nested virtualization exposes the hypervisor's VMX-emulation path to the guest, widening the surface for an L1-to-L0 escape that threatens the host and every co-tenant. The right posture is default-deny — so each round, decide whether this case actually needs it, and pick the follow-up that makes the call real. “Just in case” never clears the bar; a mandated security feature can.
The real job. More noise, a tighter clock.
Default-deny, then justify
Nested virtualization lets a VM run its own VMs — handy for CI, WSL2, VBS and malware sandboxes, but it hands the guest the L0 hypervisor's VMX-emulation code path as attack surface for an L1-to-L0 escape. The posture is default-deny: each round, decide whether this scenario truly needs it, then pick the right follow-up — the scoping and hardening when you enable it, or the alternative when you do not. Score 3 per round (2 for the call, 1 for the follow-up).
What this lab is
- A free, browser-based lab on nested virtualization — letting a VM run its own VMs — and the default-deny posture it deserves.
- The added risk is real: nested virt exposes the hardware-virtualization (VT-x/AMD-V, VMX) path to the guest, which the L0 hypervisor must emulate — a large, complex code path and extra attack surface for an L1-to-L0 escape.
- Each round is a scenario; you decide whether nested virt is genuinely needed, then pick the right follow-up: the scoping and hardening when you enable it, or the alternative when you do not.
- You are scored on holding default-deny while recognising the genuine needs — CI of a hypervisor, Windows VBS/Credential Guard, WSL2/Docker Desktop, malware sandboxes, a deliberate product capability — and never granting it on convenience or a vendor checklist.
- Fully client-side — no hypervisor runs, nothing is uploaded, no account; after each round you see why the call and the follow-up are right.
Frequently asked questions
What is the Nested Virtualization Risk Lab?
A free, in-browser decision drill. Each round presents a scenario where someone wants nested virtualization — running VMs inside a VM — and you make the call: enable it or deny it (the default), and then choose the right follow-up, such as scoping it to dedicated hosts and patching the L0 hypervisor, or denying it and keeping the attack surface off. You get immediate feedback and a graded debrief.
Why does nested virtualization add attack surface?
To let an L1 guest run its own L2 VMs, the host (L0) hypervisor must expose and emulate the CPU's hardware-virtualization instructions (Intel VT-x / AMD-V, the VMX instruction set) for that guest. That emulation is a large, intricate code path, and bugs in it can give a malicious L1 guest a path to escape to the L0 hypervisor — and from there to the host and any co-tenants. The capability is useful, but it is never free, which is why the posture is default-deny.
When is nested virtualization genuinely needed?
Real needs include: CI that builds or tests a hypervisor-based product (nested KVM), Windows Virtualization-Based Security and Credential Guard (which run a hypervisor inside the guest), developer tools like WSL2 and Docker Desktop in cloud Windows VMs, malware-analysis sandboxes that detonate samples in nested VMs, and cloud products that deliberately sell nested virt as a feature. In each case you enable it scoped to the hosts that need it, keep the L0 hypervisor patched, and avoid co-tenanting untrusted nested-virt guests with other workloads.
Does it run a hypervisor or need an install?
No. Nothing is executed, uploaded or installed. The scenarios are authored from the established facts of how nested virtualization works and where it adds risk, and the lab runs entirely in your browser with no account. It is a judgement drill for platform and security engineers.