Advanced coming soon

Ring minus one: hypervisor exploitation on Windows

Execute code beneath the Windows kernel by piggybacking on Hyper-V. No driver. No signature. No mercy.

30 lessons ~22 hours Advanced

not out yet Lifetime access. Every future module included.

what you'll walk away with

Inject a payload into Hyper-V’s physical address space before the Windows kernel starts.
Intercept every VM-exit on every logical processor, with full register access.
Read and write arbitrary guest memory — any process, any address — with no kernel driver loaded.
Install invisible code hooks via EPT shadow pages that survive kernel integrity checks.
Enumerate and read EPROCESS structures from ring -1 to resolve any PID to a CR3.
Silence ETW Threat Intelligence providers, bypass AMSI, unlink kernel callbacks — all from below the OS.
Hide processes from NtQuerySystemInformation in a way that is invisible to kernel-mode scanners.
Identify VTL1 (Secure Kernel) VM-exits, read Credential Guard’s isolated process memory, and walk PE export tables inside an IUM process from ring -1.
Bypass HVCI by installing a split-page EPT hook in VTL1’s own SLAT on the code-integrity enforcement gate. New unsigned kernel modules load despite enforced code integrity.
Understand exactly what defenders see and where this technique breaks down.

Most hypervisor content falls into two camps: toy tutorials that stop at VMXON, and academic papers that assume you already know everything.

This course skips both.

The technique is piggybacking. Windows ships with Hyper-V. Hyper-V is a hypervisor. A hypervisor runs below the OS — at a privilege level that does not exist in the Intel manual as a named ring, but is commonly called ring minus one. If you can inject code into Hyper-V’s execution context before it starts, every VM-exit on every core calls your code first, before the OS kernel has a chance to react.

No VMXON. No standalone hypervisor. No signed driver. You reuse the hypervisor that is already there.

The course builds a complete implementation from scratch. By the end you have:

A UEFI application that installs as bootmgfw.efi, hijacks the three-layer boot chain (bootmgfw → winload → hvloader), loads a DLL into Hyper-V’s physical memory, and self-erases from the EFI partition before Windows starts.
A hypervisor attachment that intercepts VM-exits via a CPUID-based hypercall gate, reads and writes arbitrary guest memory using EPT walks, installs invisible code hooks via shadow pages, and sanitizes process lists from inside the hypervisor.
A usermode CLI that drives all of it with no kernel driver loaded at any point.

Every module produces working, tested code. Every technique is paired with the detection story. The code compiles on Intel and AMD with a single compile flag.

If you have written kernel drivers, reversed malware at the instruction level, and are ready to go one level deeper, this is the course.

who this is for

Red teamers who write kernel drivers and want to go deeper.
Malware researchers and reverse engineers who need to understand what ring -1 tooling actually does.
Blue teamers building detections against hypervisor-based implants.
Kernel engineers who want to understand VT-x and EPT from the inside out.

curriculum

01
Lab, threat model, and the boot chain free preview 2 lessons
Set up a nested-virtualization lab that can survive a BSOD. Understand what Hyper-V is actually doing during boot and where our injection point is. The first lesson is free.
- Lab setup
- What boots Windows (and where we break in)
02
Getting to ring -1: the boot chain hijack 3 lessons
Replace bootmgfw.efi with a UEFI application that intercepts the Windows boot chain across three layers — bootmgfw, winload, hvloader — and injects a DLL into Hyper-V's physical address space before the hypervisor starts. 14-byte code-cave trampolines, wildcard pattern scanners, and a one-shot hook chain that self-erases before the kernel loads.
03
The hypercall interface 3 lessons
Build a CPUID-based hypercall gate that works across Intel VMX and AMD SVM with no VMCALL, no kernel driver, and no shared memory. Ring 3 sends a 64-bit packed struct; ring -1 reads it, dispatches via a function pointer table, and writes back to the caller's RAX. Implement the VM-exit router and all 18 hypercall operations.
04
Memory introspection 3 lessons
Use phantom-core's physical memory window (0x1E0<<39 = 0xFFFFF00000000000, built at UEFI init time) to reach any host-physical page by pointer arithmetic. Walk 4-level guest page tables with 1 GB and 2 MB huge-page handling to translate any virtual address. Read and write arbitrary guest memory from ring -1, across any process boundary.
05
EPT hooks: invisible code modification 3 lessons
Install shadow-page hooks via EPT that survive kernel integrity checks. A read returns original bytes; an execute returns your patched version. Split 2 MB large pages into 4 KB entries, handle EPT violations with two-state EPTE flipping, and flush EPT caches atomically across all logical processors via NMI IPI.
06
Process introspection 3 lessons
Walk EPROCESS.ActiveProcessLinks from ring -1 to resolve any PID to a DirectoryTableBase. Read cross-process virtual memory with full 4-level page table translation. Find ntoskrnl by scanning backward from Hyper-V's guest RIP. Batch N reads and follow multi-level pointer chains in a single VM-exit.
07
Kernel sanitization and anti-forensics 3 lessons
Hook NtQuerySystemInformation with a pre/post CPUID bracket; sanitize the SYSTEM_PROCESS_INFORMATION list inside the hypervisor before it reaches the caller. Hook ntoskrnl's Pad2 section via shadow page — invisible to PatchGuard because reads still return zeros (note: Pad2 is DISCARDABLE; verify it remains mapped at runtime on the target build). Erase boot artifacts: delete phantom.dll from the ESP, restore original file timestamps, zero the EFI image in memory.
08
Advanced topics: NMI, AMD, self-hiding, and going further 7 lessons
NMI IPI mechanics for cross-LP EPT cache flushing (xAPIC and x2APIC paths). Ring buffer event log with usermode flush. Deferred heap self-hiding: after 10,000 VM-exits, remap phantom-core's own physical pages to a zero page in EPT. AMD SVM port: dual NPT trees, synthesised VMCB gadget, NPF violation handler. Minimal x64 instruction length decoder for stolen-byte relocation. Course finale: detection table, hard limits, and where to go next.
09
VTL1: the Secure Kernel from ring -1 3 lessons
VSM puts the Secure Kernel in VTL1. VTL1 is a guest inside Hyper-V. Its VM-exits already flow through phantom-core. Three lessons: identify VTL1 exits by CR3 and EPTP; locate lsaiso.exe in the Secure Kernel's process list and read its heap memory directly (bypassing Credential Guard's isolation boundary); walk lsaiso.exe's PE export directory to find credential function addresses (PDB-based lookup required on Win11 24H2 — lsaiso's EAT is essentially empty); install a split-page EPT hook in VTL1's own SLAT targeting the HVCI enforcement gate; patch the execute shadow page with XOR EAX,EAX; RET. HVCI is neutralised for the session. Unsigned kernel modules load.

who's teaching this

I’m Emil. I write dkom.dev and spend my days at the intersection of kernel exploitation and the defenses trying to stop it. This course is built on a real hypervisor attachment framework I spent months engineering and auditing. Every technique here has been compiled, run, and verified on Windows 11 24H2.

Read the free research on the blog to see how I work before you spend a krone.

questions

What do I need to know going in?

You need to be comfortable writing Windows kernel drivers in C/C++, understand virtual memory (page tables, TLB, CR3), and have read x64 assembly before. You do not need prior hypervisor knowledge — but you do need to be the kind of person who reads the Intel SDM for fun.

Is this a weaponised implant course?

No. Every technique is paired with the defender’s view: what telemetry fires, what a hypervisor detector would catch, and where the approach has limits. The goal is deep understanding, not a ready-made offensive tool.

Intel only?

Both Intel VT-x (EPT) and AMD SVM (nested paging) are covered. The code in the course compiles and runs on both platforms, with the platform differences isolated behind a single compile-time switch. All tests were run on Intel.

What about Secure Boot?

Secure Boot blocks UEFI bootkits — the replacement EFI application won’t have a valid Microsoft signature. This course requires Secure Boot disabled in the lab VM. Module 0 covers the lab configuration precisely. Understanding the Secure Boot barrier is part of the threat model discussion.

Does this require a signed driver or admin rights?

No signed driver at any point. The entire mechanism runs from a UEFI application that replaces bootmgfw.efi. Once installed, the hypervisor attachment is invisible — no driver entry in Device Manager, no service, nothing in Task Manager. Admin rights are needed to mount the ESP during installation.

What Windows versions are tested?

Windows 11 24H2 on Intel. The EPROCESS offsets (UniqueProcessId, ActiveProcessLinks, DirectoryTableBase) vary across versions — the lessons show how to find them yourself using WinDbg or the Vergilius Project, which documents kernel structures across every public Windows build.

Refunds?

The first module (lab setup and boot chain overview) is a free preview. If the paid content isn’t what I described, email me within 14 days and I’ll refund you.

not out yet Lifetime access. Every future module included.

already enrolled →

# what you'll walk away with

# who this is for

# curriculum

# who's teaching this

# questions

what you'll walk away with

who this is for

curriculum

who's teaching this

questions