Virtualization-Based Security and Credential Guard Explained
How Windows uses hardware virtualization to carve out a memory region even a fully compromised kernel can't touch, and why that specifically matters for protecting credentials from pass-the-hash attacks.
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.
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.