VM Escape Triage Lab
“VM escape” sounds like one thing; in practice it is five. Work a queue of virtualization incidents and, for each, name the layer the problem actually lives in — a guest-only compromise that never crossed the boundary, a bug in an emulated device (the VENOM floppy controller, an emulated display adapter, a legacy NIC), a host-kernel / KVM flaw reachable from a guest, a rare bug in the hypervisor core itself, or a microarchitectural side-channel (L1TF, MDS, Spectre) that leaks across VMs without ever escaping control. Then pick the right first containment move. The lab exists to fix one instinct: most escapes are host-kernel or device-emulation — the hypervisor core is the minority.
The real job. More noise, a tighter clock.
Incident queue
For each incident, name the likely layer and the right first containment move. Both must be right to score.
#1 · KVM/QEMU, 40-tenant host
One VM is mining crypto
- ›Guest "web-07" pinned at 100% CPU; xmrig process inside the guest
- ›No host-side QEMU crash, no dmesg entries, neighbours idle
- ›Host memory and other guests completely unaffected
#2 · KVM/QEMU 2.x
QEMU segfaults on floppy I/O
- ›qemu-system-x86_64 (one VM) crashes; core dump shows an out-of-bounds write in the FDC (floppy disk controller)
- ›Trigger: the guest sent crafted FD_CMD byte sequences to the emulated floppy controller
- ›The floppy controller was present in the machine model even though no floppy drive was in use
#3 · Intel KVM, hyperthreading on
A tenant reads memory it should not
- ›Guest "analytics-03" reconstructs bytes that belong to another guest and to the host
- ›No crash anywhere; the leak is reconstructed from cache-access timing
- ›Vendor advisory references an L1 Terminal Fault in speculative execution
#4 · Linux host, vhost-net
Host kernel oops from guest traffic
- ›Host dmesg: kernel oops in the IPv4 receive / checksum path, triggered by packets a guest injected via vhost-net
- ›The fault corrupts host kernel memory — reachable from inside an unprivileged guest
- ›Multiple guests on the host are now at risk; the host itself is unstable
#5 · Xen, PV guest
Malicious hypercall corrupts the VMM
- ›A guest issues a crafted sequence of hypercalls that corrupts Xen hypervisor memory
- ›The flaw is in a Xen hypercall handler — the hypervisor's own code, not QEMU and not the Linux host
- ›A Xen Security Advisory (XSA) has been published with a hypervisor patch
#6 · KVM/QEMU, 40-tenant host
Ransomware inside a guest
- ›Guest "fileshare-02": its own filesystem is being encrypted; ransom note dropped in the guest
- ›QEMU process healthy, no host dmesg, neighbour guests unaffected, host storage pool intact
- ›The blast radius is exactly one virtual disk
#7 · Intel KVM, SMT enabled
Cross-VM store-buffer leak
- ›A guest recovers in-flight data from a sibling guest sharing the same physical core
- ›No crash; the data is sampled from microarchitectural store/line-fill/load buffers
- ›Advisory language: Microarchitectural Data Sampling (MDS) — RIDL / Fallout / ZombieLoad
#8 · Type-2 hypervisor, emulated SVGA
Guest->host via the display adapter
- ›A guest drives the emulated video/SVGA device with crafted commands and executes code in the host process
- ›The fault is in the display device model, reachable from a fully unprivileged guest user
- ›No host-kernel oops; the compromised component is the user-space device emulator
#9 · Linux/KVM
KVM ioctl triggers host memory corruption
- ›A guest issues a malformed KVM ioctl that corrupts memory inside the host kernel KVM module
- ›Host dmesg shows a KVM-module fault; the crash is in kvm.ko, not in QEMU and not in the hypervisor of another vendor
- ›Other guests on the host are now exposed
Triage progress
Call layer + action on each, then grade. So far 0/9 fully answered, 0/9 fully correct.
The lesson this lab teaches
Most “VM escapes” are host-kernel or device-emulation bugs — or a side-channel leak that never escapes control at all. A true hypervisor-core bug is the rare one.
Scoring needs BOTH the right layer and the right first move. Escalating a contained guest-only incident, or waving off a real escape, each takes an extra bite.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based VM-escape triage lab: work a queue of virtualization incidents, each with host/guest signals, and call the likely layer plus the right first containment move.
- The five layers: guest-only (not an escape), device-emulation (a QEMU device bug like VENOM), host-kernel/KVM, hypervisor-core (the VMM itself), and side-channel (L1TF, MDS, Spectre — a leak, not a control escape).
- It teaches the thing newcomers get backwards: most real "VM escapes" are host-kernel or device-emulation bugs, or microarchitectural leaks — a true hypervisor-core escape is the rare case.
- You are scored on getting BOTH the layer and the containment right, with extra penalties for over-reacting to a contained guest-only incident or waving off a genuine escape as guest-only.
- Every anchor is real (VENOM, Cloudburst, L1TF/Foreshadow, MDS/ZombieLoad, Spectre cross-VM, Xen XSAs) and after grading each incident explains why the right call is right.
Frequently asked questions
What is the VM Escape Triage Lab?
A free, in-browser exercise where you triage virtualization incidents. Each round gives you host-side and guest-side signals — crash dumps, dmesg lines, advisory wording, blast radius — and you decide which layer the problem actually lives in (guest-only, emulated device, host kernel/KVM, hypervisor core, or a CPU side-channel) and what the correct first containment move is. You are scored on how often you get both right.
Why does the layer matter so much?
Because the containment follows from it. A bug in an emulated device (like VENOM in QEMU's virtual floppy controller) is fixed by patching QEMU and dropping the device; a host-kernel/KVM bug needs you to drain guests and patch the host; a hypervisor-core bug needs the VMM vendor's advisory; a side-channel like L1TF or MDS needs microcode and SMT/core-scheduling discipline, not a software patch alone. Mis-naming the layer means the wrong first move.
Is this based on real vulnerabilities?
Yes. The incidents are built on real, established classes and events: VENOM (the QEMU virtual floppy disk controller out-of-bounds write), Cloudburst-style guest-to-host via an emulated display adapter, L1TF/Foreshadow, MDS/ZombieLoad, Spectre branch-target injection across VMs, Xen hypercall advisories (XSAs), and a 2026-class host-kernel network-path bug described by its class. Nothing runs or parses live telemetry — the signals are authored, deterministic snapshots so the exercise is stable.
Who is it for?
Virtualization and cloud engineers, incident responders who own hypervisor hosts, and security leaders who need an intuition for where "VM escape" risk actually concentrates. It is free, runs entirely in your browser, needs no account, and sends nothing anywhere.