HVCI and VBS

TL;DR: VBS isolates the kernel inside a Hyper-V VTL1 enclave; HVCI uses the hypervisor’s Second Level Address Translation to enforce W^X on kernel pages — so attackers cannot mark shellcode executable or patch read-only code even with full ring-0 control.

What it is

Virtualization-Based Security (VBS) runs Windows on top of a thin Hyper-V using Virtual Trust Levels: the normal kernel lives in VTL0, while a “secure kernel” (securekernel.exe) lives in VTL1 and owns identity, credential isolation, and memory-integrity policy. Hypervisor-Enforced Code Integrity (HVCI) is the policy that all kernel-mode pages must be either writable XOR executable, enforced via SLAT (EPT/NPT) tables that VTL0 cannot edit. Code Integrity signing checks are evaluated in VTL1 before SLAT marks any kernel page executable.

Preconditions / where it applies

Windows 10 1607+ / 11 / Server 2019+ with VBS prerequisites: SLAT, IOMMU, secure boot, TPM 2.0, mode-based execute control
HVCI default-on Windows 11 22H2 on compatible hardware; opt-in via Group Policy or DeviceGuard registry keys
Bypasses generally require either (a) a VTL1 bug, (b) a signed-vulnerable-driver to read/write physical memory below the SLAT, or (c) data-only kernel exploits that never need new RX pages

Technique

What HVCI breaks for the attacker:

Allocating a kernel pool and marking it executable — MmAllocateContiguousNodeMemory returns RW; promoting to RX requires VTL1 CI approval
Patching ntoskrnl.exe (PatchGuard + HVCI together make this a kernel boot fail rather than a runtime trap)
Hooking SSDT, IDT, or driver dispatch tables that live on RX pages
Stack pivot into a sprayed RWX kernel pool — there are no RWX kernel pages

What still works under HVCI:

Data-only attacks. Token swap into SYSTEM (see token-stealing-payloads) writes data, not code — HVCI does not block it
Read primitives → KASLR bypass. SLAT does not hide kernel addresses; info leaks via uninitialised pool (uninitialised-memory-disclosures) remain
Bring-your-own-vulnerable-driver. A WHQL-signed driver with an arbitrary write primitive can corrupt VTL0 state but cannot turn off HVCI from within VTL0 — Microsoft Vulnerable Driver Blocklist closes known ones
VTL1 attack surface. Bugs in securekernel.exe, the IUM trustlets, or hypercall handlers are the high-impact research target

Check VBS / HVCI state:
  msinfo32   → "Virtualization-based security"
  Get-CimInstance -ClassName Win32_DeviceGuard

Detection and defence

Enable VBS + HVCI + Memory Integrity in production fleets; enable the Microsoft Vulnerable Driver Blocklist
Pair HVCI with Smart App Control + Credential Guard for full VBS deployment
Pair with kpti-meltdown-implications mitigations, kernel CFG (cfg-cet-kernel), and SMEP/SMAP (smep-smap-overview)
Hunt for unexpected CHANGE_NOTIFICATION events on driver loads and BYOVD signatures via WDAC policy

References

Microsoft: VBS and HVCI internals — official docs
Connor McGarr: HVCI and VBS — practical exploit-author perspective
Saar Amar: Windows kernel mitigations — research on what still works under HVCI