Understanding Virtualization-Based Security
Administrator Privileges Had Traditionally Been Extremely Powerful
Windows separates ordinary applications from operating-system components through different privilege levels.
That separation provides important protection during normal operation. But malware that succeeds in reaching highly privileged execution can become much more dangerous because many traditional security boundaries exist inside the same operating system it has compromised.
The security problem changes when the attacker reaches the top of Windows.
The Operating System Was Protecting Secrets From Inside Itself
Traditional access controls can become more difficult to rely upon after malicious code reaches highly privileged parts of the operating system responsible for enforcing those controls.
The Most Privileged Windows Code Could Reach Almost Everything
The Windows kernel operates with privileges ordinary applications do not possess.
Device drivers and other kernel-mode components need substantial authority because they interact directly with hardware, memory, and fundamental operating-system services. That authority becomes dangerous when malicious or exploited code reaches the same level.
Kernel compromise can undermine boundaries above it.
A Security Check Is Only as Strong as the Component Enforcing It
If an attacker gains sufficient control over the operating-system layer responsible for enforcing access restrictions, protections implemented entirely within that same layer may become vulnerable to manipulation.
The Hypervisor Could Sit Beneath Windows
Hardware virtualization was commonly associated with running multiple operating systems on one physical computer.
But the same processor capabilities could be used for something different. A hypervisor could establish isolated memory and execution environments while Windows itself continued operating normally.
Virtualization could become a security mechanism.
Windows Did Not Have to Be the Highest Authority
When a hypervisor controls access to selected memory and execution environments, even highly privileged code inside the normal Windows operating system can face restrictions imposed from a layer beneath it.
Virtualization-Based Security Created an Isolated Environment
Windows 10 introduced an important architectural use of virtualization.
Virtualization-based security could use the Windows hypervisor and hardware virtualization features to establish an isolated environment separate from the ordinary operating system.
Sensitive security functions could operate inside that protected space.
The Hypervisor Became Part of Windows Security
Virtualization-based security uses hardware virtualization to create an isolated environment that can protect selected security functions and information from the normal Windows operating system.
One Physical Computer Could Contain Different Trust Environments
The machine still ran one visible Windows desktop.
Underneath that familiar environment, virtualization could establish a separate protected region commonly associated with Virtual Secure Mode. Sensitive components placed there did not need to share the same trust assumptions as ordinary Windows processes and kernel components.
The computer gained another internal boundary.
Isolation Did Not Require Another Visible Desktop
The purpose was not to give the user another virtual machine to operate but to create a protected execution environment for security functions behind the scenes.
Kernel Privilege Did Not Automatically Grant Access to Protected Memory
Memory contains some of the most valuable information on a running computer.
Authentication material, cryptographic information, and security decisions may need to exist somewhere while the system operates. If all of that information resides in memory directly accessible to the ordinary kernel, kernel compromise can expose it.
Virtualization changes who controls that access.
The Hypervisor Could Enforce the Memory Boundary
Selected memory associated with the isolated security environment can be protected so code running in the normal operating system does not simply receive unrestricted access because it has kernel-level privilege.
Windows Could Assume That Even Powerful Code Might Be Compromised
This represented an important change in defensive thinking.
Instead of assuming that reaching kernel mode meant a component should be trusted with every security-sensitive resource, virtualization-based security allowed Windows to place selected assets beyond that ordinary trust boundary.
Privilege and trust no longer had to be identical.
High Privilege Did Not Need to Mean Unlimited Trust
A driver or kernel component may require extensive access to perform its job without requiring direct access to every protected secret or security decision on the computer.
Authentication Secrets Could Move Outside Ordinary Windows Memory
One of the clearest uses of virtualization-based security was Credential Guard.
Windows authentication traditionally involved secrets available within the operating system’s security processes. Credential Guard changed that architecture by placing protected authentication material into an isolated environment backed by virtualization.
The normal operating system communicated with the protected component instead of directly owning all of its secrets.
Credential Guard Relied on VBS Isolation
Microsoft documents that Credential Guard uses virtualization-based security to isolate secrets such as NTLM password hashes and Kerberos Ticket Granting Tickets from the rest of the operating system.
The Authentication Process Could Ask an Isolated Component for Help
The Local Security Authority remains central to Windows authentication.
With Credential Guard, the normal LSA process can communicate with an isolated LSA component responsible for protecting sensitive secrets. The normal operating system can request necessary authentication operations without receiving unrestricted access to the protected material itself.
Communication replaces direct possession.
Using a Secret Is Different From Reading the Secret
A protected service can perform an operation on behalf of normal Windows without necessarily exposing the underlying credential material directly to the requesting operating-system component.
Owning the Account Did Not Automatically Mean Owning the Isolated Environment
Administrative malware remains extremely dangerous.
But virtualization-based isolation can prevent administrative privilege inside normal Windows from automatically becoming direct access to selected protected resources. The attacker may control much of the operating system while still facing a separate boundary around isolated secrets.
The attack requires another step.
Administrator Is Powerful, Not Omnipotent
Virtualization-based security was designed specifically to protect selected assets even from malware operating with privileges that would traditionally provide extensive control over the Windows environment.
A Malicious Driver Could Be Inside Windows but Outside the Protected World
Kernel-mode malware can operate at a privilege level unavailable to ordinary applications.
Without a stronger isolation boundary, that position may provide access to sensitive operating-system memory and security structures. VBS allows selected resources to exist somewhere the ordinary kernel is not intended to inspect directly.
The hypervisor separates the worlds.
The Boundary Exists Below the Driver
Because the hypervisor participates in enforcing isolation, malicious code executing as a normal Windows kernel driver does not automatically become equivalent to code operating inside the protected security environment.
The Decision About Trusted Kernel Code Could Receive Stronger Protection
Credentials were not the only security-sensitive asset.
Windows also needs to decide which code should be trusted to execute with powerful privileges. If malicious kernel code can simply alter the mechanism responsible for enforcing code integrity, the protection can defeat itself.
Virtualization could protect the decision maker.
Security Policy Can Be Stronger When Enforcement Is Isolated
Placing sensitive code-integrity functions behind a virtualization boundary can make it more difficult for ordinary kernel-mode malware to modify the rules determining which privileged code is trusted.
Application Control Could Depend on a Protected Trust Decision
Windows 10 Device Guard combined several technologies intended to restrict systems to trusted software.
Virtualization-based security could protect important code-integrity functionality from the ordinary Windows kernel, strengthening the enforcement behind application-control policies.
The architecture protected both information and decisions.
VBS Supported More Than Credential Protection
Microsoft used virtualization-based isolation as part of Windows security technologies designed to protect credential material and strengthen code-integrity enforcement against highly privileged compromise.
The Protected Environment Needed a Trustworthy Beginning
Isolation is much less valuable if an attacker can compromise the system before the hypervisor and security environment are established.
Secure Boot helps control which trusted startup components can execute during the boot process. That creates a stronger foundation from which virtualization-based protections can begin operating.
The security boundary starts early.
Runtime Isolation Depends on Startup Integrity
Protecting sensitive resources after Windows starts is stronger when the firmware, boot components, and virtualization environment responsible for creating that protection can themselves begin from a trusted state.
Firmware Was No Longer Merely Responsible for Starting the Computer
Modern Windows security increasingly depended on capabilities below the operating system.
UEFI firmware, Secure Boot, processor virtualization extensions, and other platform features could contribute to establishing the environment in which virtualization-based security operates.
The motherboard became part of the trust model.
Operating-System Security Could Begin in Firmware
Hardware-backed security depends on a chain of trust extending below Windows because the operating system cannot independently guarantee the integrity of everything that executes before it.
Technology Designed for Virtual Machines Could Protect One Operating System
Intel and AMD processors had long provided virtualization extensions used by hypervisors.
Windows 10 could use those capabilities even when the user’s goal was not to run conventional virtual machines. The processor could help create isolated execution contexts dedicated to protecting the host operating system itself.
Virtualization gained another purpose.
You Did Not Need to Run a Virtual Machine to Benefit From Virtualization
Hardware virtualization could operate behind the scenes as part of Windows security, establishing protected environments without requiring the user to create or interact with a traditional guest operating system.
Hyper-V Was No Longer Only About Consolidating Computers
Hypervisors were traditionally associated with servers, testing laboratories, and running multiple operating systems on the same hardware.
Using the hypervisor to isolate security-sensitive components changed its role. It could become part of the security architecture of an ordinary Windows installation.
The virtualization layer protected the host.
Virtualization Could Defend the System Running It
Windows could use hypervisor-enforced isolation internally, allowing virtualization technology to protect selected parts of the operating system rather than merely hosting separate guest machines.
Less Code Inside the Boundary Meant Less Code to Trust
A security environment becomes harder to defend as unnecessary components accumulate inside it.
The isolated environment used by virtualization-based security can therefore be designed to contain only the components necessary for protected operations rather than reproducing the entire normal Windows environment.
A smaller trusted base reduces exposure.
Isolation Works Better When the Protected Side Remains Limited
Keeping unnecessary drivers and ordinary applications outside the isolated security environment reduces the amount of privileged code that must be trusted within that boundary.
Hardware Access Was Deliberately Kept Outside
Device drivers are powerful and complicated.
They interact with hardware from many manufacturers and historically represent a large body of privileged code. Allowing ordinary drivers inside the isolated security environment would substantially increase its attack surface.
Separation protects the protected side.
Powerful Code Does Not Automatically Belong Inside the Trust Boundary
Microsoft’s Credential Guard architecture deliberately keeps device drivers out of the isolated LSA environment and limits the protected component to a small set of trusted binaries.
The Protected Environment Needed to Know What It Was Loading
Isolation would provide little benefit if arbitrary software could simply enter the protected environment.
Code operating inside sensitive security contexts can therefore be subject to strict trust requirements, including signature validation before protected binaries are allowed to execute.
The boundary controls entry as well as access.
Protected Memory Needs Protected Code
Keeping secrets inside an isolated environment is most useful when the software permitted to execute alongside those secrets is also tightly controlled.
Hardware Could Help Bind Protected Material to the Device
Some security information needs protection beyond a single running session.
A Trusted Platform Module can protect cryptographic material associated with the platform and contribute to hardware-backed trust. Combined with virtualization and firmware security, the TPM can strengthen protection for information that must persist across system states.
The hardware and hypervisor can work together.
Isolation Can Extend Beyond RAM
Where protected security information must persist, hardware-backed keys can help ensure that the material remains associated with an expected and trustworthy platform environment.
A Compromised Operating System Could Still Do Enormous Damage
Virtualization-based security protects selected resources, not every action occurring on the computer.
Malware controlling the normal operating system may still access information available to the active user, manipulate applications, interfere with network activity, capture input, or perform many other malicious operations.
The protected boundary has a defined purpose.
Isolation Does Not Replace Endpoint Security
VBS can protect selected secrets and security functions from direct access, but systems still require patching, malware protection, least privilege, application control, and other defensive layers.
Protected Services Still Needed to Communicate With Windows
An isolated component cannot perform useful work if nothing outside the boundary can interact with it.
Normal Windows therefore needs controlled communication paths to request operations from protected services. Those interfaces must themselves be carefully designed because attackers may attempt to abuse legitimate functionality rather than directly reading protected memory.
Isolation changes the attack surface rather than eliminating it.
A Secret Can Stay Hidden While Its Privileges Are Still Abused
Preventing malware from extracting protected credentials does not necessarily prevent malware already controlling the computer from attempting to use capabilities available through an authenticated session.
Not Every Windows 10 Computer Could Provide the Same Protection
Virtualization-based security depends on capabilities provided by the underlying platform.
Processor virtualization support, appropriate firmware, Secure Boot, and related hardware features influence whether the strongest isolation configurations can be established.
The operating system cannot manufacture missing hardware capabilities.
Security Features Can Depend on the Age of the Computer
Two systems running the same version of Windows may not support identical hardware-backed protections when their processors, firmware, and platform security capabilities differ.
Adding a Hypervisor Changes the Environment Beneath Windows
Enabling virtualization-based security changes how portions of the system execute and how memory is protected.
Drivers, virtualization software, and hardware that were designed around older assumptions may require compatibility testing. Security architecture cannot be separated completely from the platform on which it runs.
Deployment requires more than flipping a switch.
Stronger Isolation Can Expose Older Assumptions
Organizations adopting hardware-backed virtualization security need compatible firmware, processors, drivers, and software so the protection does not depend on components unable to operate correctly within the newer architecture.
The Kernel Was No Longer the Final Line
For decades, operating-system security largely depended on boundaries enforced by the kernel.
Virtualization-based security introduced another model. The kernel could itself become one side of a security boundary enforced by the hypervisor underneath it.
The hierarchy of trust had changed.
Windows Could Protect Something From Windows
The defining idea behind VBS is that selected security resources can be isolated from the ordinary operating system so compromise of that operating system does not automatically expose everything the machine needs to protect.
Security No Longer Needed to Assume the Kernel Would Always Remain Trustworthy
Strong defensive architecture considers what happens after something goes wrong.
If the entire security model assumes that highly privileged Windows code can never be compromised, one successful kernel exploit can undermine many protections at once. VBS introduces another boundary that can remain relevant after such a compromise.
The system prepares for partial failure.
Defense in Depth Can Exist Below the Operating System
Virtualization allows Windows to maintain selected security guarantees from a layer that ordinary kernel-mode code does not directly control.
Hardware-Backed Isolation Became a Larger Part of Windows Security
The architectural direction introduced with Windows 10 did not end with the first VBS features.
Later Windows security technologies continued building around hardware roots of trust, virtualization-backed isolation, protected code integrity, credential isolation, and stronger startup validation.
The boundary became part of the platform.
Virtualization Became Security Infrastructure
The long-term significance of VBS was not one individual feature but the ability to use hardware virtualization as a general security boundary for protecting sensitive Windows functions.
The Operating System Did Not Need to Guard Every Secret Alone
Traditional security placed enormous responsibility on the operating-system kernel.
Virtualization-based security distributed some of that responsibility to a lower layer. The hypervisor could help enforce memory and execution boundaries that ordinary Windows components were not permitted to cross.
Security gained another authority.
The most powerful code inside Windows did not have to be the most powerful code on the computer.
Virtualization Gave Windows a Security Boundary Beneath Its Own Kernel
Windows 10’s virtualization-based security architecture changed what hardware virtualization could mean on an ordinary computer. Instead of using the hypervisor only to host separate operating systems, Windows could use it internally to isolate selected security functions from the normal operating environment.
Credential Guard demonstrates the idea clearly. Microsoft documents that authentication secrets protected by Credential Guard are placed in an isolated environment using VBS and are not accessible to the rest of the operating system. The normal LSA process communicates with an isolated LSA component rather than directly storing every protected secret itself.
The larger architectural change was the security boundary itself. Administrator privileges and even kernel-level execution inside normal Windows no longer had to imply unrestricted access to every sensitive resource on the machine. By placing another enforcement layer beneath the operating system, virtualization could protect parts of Windows from Windows itself.
