Virtualization-Based Security and Credential Guard Explained

Virtualization-Based Security (VBS) uses the same hardware virtualization extensions that power Hyper-V to create an isolated memory region that’s protected from the rest of the operating system — including, critically, from a fully compromised kernel — and Credential Guard is the specific security feature built on top of that isolation to protect domain credentials from a particularly damaging class of attack.

The problem Credential Guard specifically addresses

Windows historically cached derived credential material (NTLM password hashes, Kerberos ticket-granting tickets) in the LSASS (Local Security Authority Subsystem Service) process’s memory, to avoid requiring the user to re-authenticate constantly. This caching is what makes “pass-the-hash” and “pass-the-ticket” attacks possible: an attacker who achieves administrative code execution on a machine can dump LSASS’s memory and extract these cached credentials directly, then reuse them to authenticate as that user on other machines in the network — without ever needing to know the actual plaintext password. This attack pattern has historically been one of the most effective ways ransomware and other attackers move laterally across a compromised network once they’ve gained an initial foothold.

Why ordinary kernel-level protection isn’t sufficient here

The core difficulty is that an attacker who has achieved kernel-level code execution (via a driver vulnerability, or simply by having obtained local administrator rights, which grants the ability to load arbitrary kernel drivers) has, under the traditional Windows security model, essentially unlimited access to any memory on the system — including LSASS’s memory, regardless of what process-level protections exist. Ordinary process isolation, running as a different user account, or even kernel-mode anti-tampering protections don’t help here, because the attacker in this scenario already has kernel-equivalent privilege.

What VBS actually does to solve this

VBS uses the CPU’s hardware virtualization extensions (Intel VT-x/EPT or AMD-V/NPT) to create a genuinely separate, hypervisor-enforced memory region — sometimes referred to as the “secure kernel” or Isolated User Mode — that sits at a privilege level the normal operating system kernel itself cannot directly access, even with full kernel privilege. This is a meaningfully different boundary than ordinary kernel/user-mode separation: the hypervisor itself, not the main Windows kernel, is what enforces this isolation, and even a completely compromised main OS kernel has no direct way to read or write into VBS-protected memory, because that enforcement happens below and outside the main kernel’s own privilege level entirely.

How Credential Guard uses this isolation specifically

With Credential Guard enabled, the actual derived credential material — the NTLM hashes and Kerberos tickets that pass-the-hash/pass-the-ticket attacks target — is stored inside this VBS-protected region rather than directly in LSASS’s ordinary process memory. LSASS still handles authentication requests, but it does so by communicating with a separate, isolated component running inside the protected VBS environment, rather than holding the sensitive credential material directly accessible in its own regular memory space. An attacker who fully compromises the main OS kernel and dumps LSASS’s ordinary process memory no longer finds usable, reusable credential material there at all — the actual sensitive material simply isn’t stored in a location that level of compromise can reach.

What this requires, and why it isn’t universally deployed by default

VBS and Credential Guard require hardware virtualization support, UEFI (with Secure Boot), and — for full protection — the CPU’s IOMMU-equivalent capabilities (Intel VT-d/AMD-Vi) to properly isolate the protected region from certain classes of hardware-level attack (DMA attacks in particular). This is why Credential Guard isn’t universally enabled by default on all Windows hardware: older machines lacking the necessary virtualization and firmware capabilities simply cannot support it, and even on capable hardware, there are compatibility considerations — certain legacy authentication methods and some third-party security software have historically had compatibility issues with VBS’s memory isolation model.

The Virtual Trust Level terminology behind “secure kernel”

Microsoft’s own documentation and tooling refer to the two isolation levels VBS creates as Virtual Trust Levels: VTL0 is the normal world, where the ordinary Windows kernel, drivers, and every regular application (including LSASS itself) run exactly as they always have; VTL1 is the secure world the hypervisor carves out and protects, hosting the secure kernel and any Isolated User Mode (IUM) processes — Credential Guard’s own protected component runs there as a specific IUM process named LsaIso.exe. The access relationship between the two levels is deliberately one-directional: VTL1 can inspect VTL0’s memory when it needs to, but VTL0 — including a fully compromised VTL0 kernel — has no mechanism to read or write VTL1’s memory at all, which is the actual hardware-enforced boundary that makes Credential Guard’s guarantee hold even against kernel-level compromise. Credential Guard first shipped with Windows 10 and Windows Server 2016 in 2015, as one of several features originally bundled under the broader Device Guard umbrella branding before Microsoft split VBS-based protections into their own more specifically-named features.

Why this specific defense matters so much for enterprise networks

Credential Guard directly targets what has historically been one of the most effective and common lateral-movement techniques in real-world enterprise breaches — an attacker compromising one workstation and using cached credentials to move to increasingly privileged systems across the network. Removing the ability to extract reusable credential material from a compromised machine’s memory, even under full kernel compromise, closes off a specific, high-value attack path that many other security controls (endpoint detection, network segmentation) don’t directly address, since those controls are generally aimed at preventing or detecting the initial compromise rather than limiting what an attacker can do with credentials once that compromise has already happened.

Related:

Sources: