KomuraSoft LLC
Contact
Menu

The Depths of Windows Virtualization (Part 2) — Memory Even the Kernel Cannot See: How VBS, HVCI, and Credential Guard Work

· · Windows, Virtualization, Security, VBS, HVCI, Credential Guard

There was a time when administrator privileges were the “goal” for an attacker on Windows. Load a kernel driver as administrator, dump the memory of the LSASS process, and you have password hashes and Kerberos tickets. From there it is just a matter of walking to another machine with the stolen hashes.

On current Windows 11 with Credential Guard running — the default state from 22H2 onward on devices that meet the license requirements such as Enterprise and Education, plus the hardware requirements — that playbook does not work. An attacker who has fully taken the kernel can search memory all they like, and the actual hashes of the protected domain credentials are not found “inside that OS”. If it is not running, the old danger remains, so read this together with the confirmation methods later in the article.

So where are they? The answer is “another world, created inside the same PC”. As we saw in Part 1, the host Windows runs in the root partition on top of the hypervisor (“Where Is Your Windows Actually Running?”). This article continues from there and follows one more boundary line the hypervisor draws inside the same partition.

The question Part 2 answers is just one.

Where does Windows put secrets that neither an administrator nor the kernel can read?

Intended readers are developers and operators who have seen words such as Core isolation, Memory integrity, and Credential Guard on a settings screen or in a troubleshooting case, and want to understand the real thing from the mechanism up. Prerequisites are x64 Windows 10/11 or current Windows Server (as in Part 1, the discussion of rings and SLAT assumes x64; Arm64 uses a different mechanism such as exception levels). Required background is the concepts of partitions and SLAT covered in Part 1. The difficulty is intermediate. The aim is an explanation of the structure, not a how-to for configuring the security features.

1. The Bottom Line First

Windows added an axis of privilege called VTL (Virtual Trust Level) and put the secrets in VTL1. Memory in VTL1 cannot be read from the ordinary kernel that runs in VTL0. What guards the boundary is not the kernel itself, but the hypervisor that holds the SLAT translation tables.

That is the skeleton of virtualization-based security (VBS). VBS uses the hypervisor to create an isolated environment and houses security features there. It is designed on the assumption that the isolated environment remains protected even if the kernel is compromised.1

The two worlds VBS createsVTL0 and VTL1 sit inside the same partition; VTL0 holds the ordinary kernel and apps, VTL1 holds the Secure Kernel and isolated security features, and the hypervisor guards the boundaryVTL1 (the isolated world)VTL0 (the ordinary world)Cannot readIsolated security featuresSecure KernelApps (ring 3)NT kernel and drivers (ring 0)Hypervisor (enforces the boundary via SLAT)

Figure 1: There are two worlds inside one Windows, and the VTL0 kernel cannot access VTL1 memory.

The important point is that this is not “standing up another VM”. VTL0 and VTL1 are inside the same partition, inside the same Windows. We will look in turn at how this split is realized.

2. The Limits of the Ring Model — The Guardian and the Guarded Sit at the Same Height

Traditional Windows security was built on the ladder of rings (privilege levels). User mode (ring 3) is guarded by kernel mode (ring 0). So who guards ring 0 — no one can. Ring 0 is the highest privilege.

This structure has two structural weaknesses.

  • The kernel is not a monolith. At ring 0, not only Windows itself but a large number of third-party drivers run. If any one of them has a vulnerability, an attacker obtains code execution at ring 0.
  • From ring 0, everything is visible. However much a user-mode process such as LSASS defends itself, its memory is free to read for an attacker who has taken the kernel. Protection attributes and page tables alike are managed by the kernel itself.
The credential-theft path in the traditional ring modelAn attacker who takes ring 0 through a vulnerable driver can read LSASS process memory with the kernel's full authority and obtain password hashesExploits a vulnerable driverAttacker codeTakes control of ring 0Can read all physical memoryObtains hashes from LSASS memoryAbused for lateral movement to other machines

Figure 2: Because the guardian (the kernel) and the guarded (the secrets) sit at the same height, the fundamental weakness is that if ring 0 falls, everything falls.

What is needed, then, is “a place higher than ring 0”. That place already appeared in Part 1. The hypervisor runs at a privilege higher than the kernel and monopolizes control of the CPU’s memory-access permissions (SLAT) early. An isolated region the hypervisor guards is protected even against access from ring-0 (supervisor-mode) OS software.2

3. VSM and VTLs — Adding One More Axis of Privilege

3.1. Virtual Trust Levels (VTLs)

The family of hypervisor features that provide this isolation is called VSM (Virtual Secure Mode). VSM is the foundation for Device Guard, Credential Guard, a virtual TPM, and the like.2

The central concept of VSM is the VTL (Virtual Trust Level). The key points are as follows.2

  • VTLs are hierarchical, and the higher the number, the higher the privilege. VTL0 is the lowest; VTL1 is more privileged than VTL0.
  • Architecturally up to 16 levels are defined, but what is currently implemented is two: VTL0 and VTL1.
  • Each VTL has independent memory access protections. These protections are managed by the hypervisor against the partition’s physical address space, so system software inside the partition cannot change them.
  • A virtual processor has a separate register state and interrupt machinery per VTL, and a lower VTL cannot peek at a higher VTL’s state.
Three independences that make up VTL isolationMemory access protections, virtual-processor register state, and interrupt machinery are independent per VTL, and a lower VTL cannot touch any of them in a higher VTLWhat is independent per VTLMemory access protectionsVirtual processor register stateInterrupt machineryA lower VTL cannot touch a higher VTL

Figure 3: Making not only memory but also CPU state and interrupts a separate world is the three-piece set that leaves no peephole.

If rings (0 and 3) are the axis that separates “OS and apps”, VTLs are a second axis that separates “the ordinary world and the isolated world”. The two axes are orthogonal, and inside VTL1 there is kernel mode and user mode as well.

Four regions created by the two axes of rings and VTLsThe ring axis separates kernel mode and user mode, the VTL axis separates the ordinary world and the isolated world, and the combination produces four regions: ordinary apps, the NT kernel, IUM trustlets, and the Secure KernelVTL1 (isolated world)VTL0 (ordinary world)Ring 3: IUM (trustlets)Ring 0: Secure KernelRing 3: ordinary appsRing 0: NT kernel and drivers

Figure 4: There are now two axes of privilege, and “is it the kernel?” and “is it the isolated world?” became separate questions.

3.2. The Substance of the Boundary Is SLAT

In Part 1 we said that the second-level translation tables that map a guest physical address (GPA) onto actual RAM (SPA) — SLAT — are held by the hypervisor. VSM uses exactly this property. VTL isolation is created using the Hyper-V hypervisor and SLAT.3

When VTL1 declares “this memory is not to be shown to VTL0”, the hypervisor drops access permission to that page from VTL0’s translation tables. From then on, even if the VTL0 kernel tries to touch that address, it is denied at the CPU’s address-translation stage. It is useless for the kernel to rewrite its own page tables however it likes. The page tables (GVA→GPA) may belong to the kernel, but the translation beyond that (GPA→SPA) and the final access permission belong to the hypervisor.

The flow by which access from VTL0 to VTL1 memory is deniedWhen the VTL0 kernel tries to read VTL1 memory, it can pass its own page table but is denied by SLAT access protection, and control transfers to the hypervisorNot allowedAllowedVTL0 kernel tries to read a VTL1 pagePasses the kernel's own page tableDoes SLAT access protection allow it?Hypervisor intervenes and denies accessOrdinary memory accessProtected at a layer the kernel cannot change

Figure 5: The barrier sits outside the kernel, and SLAT protections cannot be changed by software inside the partition.

In Part 1 of the memory series we wrote that “VADs, PTEs, and protection attributes decide whether access is allowed”. In a VBS environment you can organize it as: after all of those have been passed, a SLAT checkpoint is still waiting.

3.3. The Secure Kernel and IUM

What runs inside VTL1 is not the ordinary NT kernel but a small kernel called the Secure Kernel. User mode in VTL1 is called IUM (Isolated User Mode), and the programs that run there are called trustlets (trusted processes).3

A trustlet cannot do everything the way an ordinary process can. Most system calls are marshalled to the NT kernel on the VTL0 side and the work is requested there.3 VTL1 is not an “upper world that can do anything”; it is built intentionally small, as a vault that holds secrets. The less code you can bring into the vault, the smaller the attack surface.

The flow of a trustlet's system callsA trustlet in VTL1 does not handle most system calls itself; it marshals them to the VTL0 NT kernel and receives only the result, which keeps VTL1 smallIn most casesTrustlet (IUM in VTL1)A system call is neededRequest is marshalled to the VTL0 NT kernelOnly the result comes backVTL1 stays small, shrinking the attack surface

Figure 6: The vault has no facilities of its own; it farms out the chores and keeps guarding only the secrets.

4. HVCI — Verifying Kernel Code Integrity in the Vault

4.1. What Is Being Verified

The first representative feature that sits on VBS is Memory integrity — HVCI (hypervisor-protected code integrity). Windows has a code-integrity mechanism that inspects kernel-mode drivers and binaries before they start and does not load unsigned or untrusted ones. HVCI runs this verification inside VBS’s isolated environment.1

The reason for moving the verification logic itself into VTL1 is exactly the weakness in Section 2. If the verification code sits inside the VTL0 kernel, an attacker who has taken the kernel can swap the verification out. If it is in VTL1, the swapping hand cannot reach it.

The difference made by where the verification code livesIf the verification code sits inside the VTL0 kernel it can be disabled by taking the kernel, but if it is in VTL1 even an attacker who has taken the kernel cannot reach it and verification is protectedInside the VTL0 kernel (classic)Isolated environment in VTL1 (HVCI)Attacker who has taken the kernelWhere does code-integrity verification live?The verification logic can be swapped outThe swap is out of reachUnsigned code can run in the kernelVerification keeps working after the kernel is compromised

Figure 7: Do not put the checkpoint inside the side that might be breached — that relocation of the verification logic is the essence of HVCI.

4.2. The Rules for Executable Pages

HVCI’s effect is not limited to “inspection at startup”. It also constrains kernel-memory allocation.4

  • A kernel page becomes executable only after it has passed code-integrity verification.
  • An executable page does not become writable (so-called W^X).

When these two are in place, even if a vulnerability such as a buffer overflow lets you rewrite kernel memory, you cannot put the rewritten contents into execution. An executable page cannot be rewritten, and a page that can be rewritten cannot be executed.4 The final backing of execute permission is the execute right on the SLAT side, which the VTL0 kernel cannot manipulate.

Until a kernel page becomes executable in an HVCI environmentA driver-load request receives code-integrity verification in VBS's isolated environment; if it passes it is allowed as an executable, non-writable page, and if it fails it is blocked and recorded in the CodeIntegrity logPassFailRequest to load and execute kernel codeCode-integrity verification in the isolated environmentAllowed as an executable page (writes forbidden)Load is blockedRecorded in the CodeIntegrity Operational log (event ID 3087)Writable pages remain non-executable

Figure 8: Verification of the rule that does not let execute and write coexist is done on the VTL1 side, and the VTL0 kernel cannot overturn it.

Tracing this from an attacker’s point of view makes it clear how the rule takes effect.

The flow by which code injection fails in an HVCI environmentEven if a vulnerability lets you rewrite kernel memory, a page you could write is not executable, and an executable page cannot be rewritten in the first place, so the injected code cannot be put into executionA writable pageAn executable pageTry to tamper with kernel memory via a vulnerabilityWhich page is the target?The write succeedsThe write itself is impossibleBut that page is not executableThe injected code cannot be executed

Figure 9: The meaning of not crossing writable pages with runnable pages is that whichever entrance you take, you hit a dead end.

4.3. The Price in Driver Compatibility

This rule collides with older-design drivers. Ones that rewrite their own code at run time, have no signature, or demand memory that is both executable and writable — such drivers cannot be loaded in an HVCI environment. The fact of the block can be confirmed in Event Viewer under Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational (event ID 3087 is representative).5

“After I enabled Memory integrity, a peripheral stopped working” — in many cases, that is the real identity of the trouble. The proper response is to update to an HVCI-compatible driver; disabling Memory integrity should be thought of as a last resort that gives up the protection wholesale. If you are involved in this verification from a driver-development standpoint, see also the filter-driver article (“Windows Minifilter Drivers”).

Isolating the case where a peripheral stops working under Memory integrityIdentify the blocked driver in the CodeIntegrity Operational log; the proper response is to update to an HVCI-compatible version, ask the vendor if none exists, and treat disabling as a last resort you do not make permanentYesNoA device stops working after Memory integrity is enabledIdentify the blocked driver in the CodeIntegrity logIs there an HVCI-compatible driver?Update and resolve it while leaving HVCI onAsk the vendor for a compatible versionDisabling is a last resort, not a permanent setting

Figure 10: The first thing to look at is not the settings screen but the log, and event ID 3087 knows who blocked the load.

5. Credential Guard — The Hashes Are Inside LSAIso

5.1. LSASS and LSAIso

The second representative feature that sits on VBS is the answer to the opening mystery: Credential Guard.

Traditional Windows kept NTLM hashes and Kerberos tickets in the memory of the LSA process (lsass.exe). When Credential Guard is enabled, storage of the protected secrets among these — the NTLM hashes of domain credentials and Kerberos TGTs (Ticket Granting Tickets) — moves to LSAIso.exe, a trustlet that runs in IUM in VTL1.6

  • lsass.exe (VTL0) continues to run as the front desk for authentication processing, as before.
  • The actual secrets are held by LSAIso.exe (VTL1) and cannot be accessed from VTL0.
  • The two communicate via RPC (Remote Procedure Call).
  • LSAIso hosts no device drivers at all, and houses only the minimum of signed binaries. The signatures are verified with a certificate that VBS trusts.6
Where credentials sit when Credential Guard is enabledlsass in VTL0 communicates with LSAIso in VTL1 via RPC as the authentication front desk; the actual hashes and TGTs of protected domain credentials are held by LSAIso, so an attacker who obtains administrator privileges in VTL0 and dumps lsass still does not get the protected substanceVTL1VTL0RPCMemory dumpCannot reachLSAIso.exe (vault for secrets)lsass.exe (authentication front desk)Attacker (administrator privileges)

Figure 11: Because the front desk and the vault were separated, dumping lsass no longer yields the actual hashes of the protected domain credentials.

From Windows 11 version 22H2 onward, on devices that meet the license requirements (Enterprise E3/E5, Education A3/A5) and the hardware requirements, VBS and Credential Guard are enabled by default. On editions such as Pro, Credential Guard is not enabled automatically (there are exceptions, such as when a machine that was enabled under a qualifying license is later downgraded).7 “The playbook no longer works” at the opening is not a story about a special add-on product; it is the standard state of current Windows on the target editions.

The flow of credentials from sign-in to authenticationAfter sign-in the actual secrets are stored in LSAIso in VTL1; each time authentication is needed, lsass in VTL0 requests computation via RPC, and only the result of the authentication processing comes back to VTL0 without the protected long-term secrets themselves being returnedRequest computation via RPCReturns the result (does not return the secret)User signs inlsass handles it as the front deskThe actual secrets are stored in LSAIsoSubsequent authentication requests

Figure 12: The protected long-term secrets themselves never leave the vault; what returns to VTL0 is the result of authentication processing, such as a ticket.

5.2. Know Precisely What Is Not Protected

Credential Guard is not an all-purpose shield. What is protected is NTLM hashes of domain credentials, Kerberos TGTs (Ticket Granting Tickets), and things stored as domain credentials. The following are out of scope.8

  • Kerberos service tickets (TGTs are protected)
  • Credentials of local accounts and Microsoft accounts
  • Theft of input by a keylogger, and physical attacks
  • Credentials on paths that use NTLMv1, MS-CHAPv2, Digest, or CredSSP
  • The internals of third-party software that manages credentials on its own

Also, when Credential Guard is enabled, NTLMv1, unconstrained Kerberos delegation, and the like become unusable, so business systems that depend on legacy authentication need a compatibility check.8 Not “enable it and you are done”, but grasp what is inside and outside the defensive range and fill the rest with other controls — that is the correct way to use it in practice.

Credential Guard's defensive rangeDomain NTLM hashes and TGTs, and stored domain credentials, are protected, while service tickets, local accounts, keyloggers, physical attacks, and credentials stored privately by an app are out of scopeWhich side of the protection boundary is this secret on?Domain NTLM hashes and TGTsService tickets and local accountsProtected in LSAIsoNot protected (other controls are needed)Keystrokes, physical attacks, and app-private stores are also out of scope

Figure 13: The defensive range is drawn with a clear line, and the outside of the line is filled with multi-factor authentication and app-side design.

6. See It for Yourself

You can confirm the running state of VBS and each feature on your own machine.

Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus,
                  SecurityServicesConfigured,
                  SecurityServicesRunning

How to read it is as follows.9

  • If VirtualizationBasedSecurityStatus is 2, VBS is enabled and running.
  • If SecurityServicesRunning contains 1, Credential Guard is running; if it contains 2, Memory integrity (HVCI) is running.

To confirm the running state in the GUI, look at the “Virtualization-based security” field in msinfo32 (services that are running are listed, such as “Hypervisor enforced Code Integrity”). The “Memory integrity” toggle under “Device security > Core isolation” in the Windows Security app is a screen that reflects settings; it can look on even while HVCI is not actually running — waiting for a reboot right after enablement, or a compatibility problem at startup — so judge whether it is running from msinfo32 or from Win32_DeviceGuard’s SecurityServicesRunning.5

There is also a trace on Task Manager’s Details tab. On a machine where VBS is running you will see a process called “Secure System”. LsaIso.exe is the process that appears when the Isolated LSA service is hosted in VTL1, and it does not normally appear in a configuration where only HVCI is enabled. The presence or absence of a process is only a trace, though, so judge whether Credential Guard is running from SecurityServicesRunning (whether it contains 1), as above. Both are windows visible from VTL0 that correspond to the VTL1-side world.

How to check that VBS-related features are runningConfirm that VBS is running by querying Win32_DeviceGuard, judge Credential Guard and HVCI from the SecurityServicesRunning values, and look at the CodeIntegrity log for driver problemsNoYes12Win32_DeviceGuardVBS Status 2?VBS is not runningContains 1 or 2?Credential Guard onHVCI onCodeIntegrity 3087

Figure 14: State confirmation proceeds in three stages: VBS itself, each service on top of it, and the log when a problem occurs.

7. Three Misreadings to Avoid in Practice

7.1. “Protecting administrator privileges is enough. VBS is a server-side story”

What Credential Guard prevents is damage spreading after administrator privileges have been taken (hash exfiltration and lateral movement). In other words VBS is one layer of defense-in-depth that assumes compromise, and it is on client PCs that it is effective. On Windows 11 that meets the requirements, enabled-by-default is the standard, so the right posture is not “this has nothing to do with us” but “manage compatibility on the assumption that it is already running”.

Stages of compromise and where VBS takes effectInitial access is covered by other controls such as multi-factor authentication and training; HVCI blocks code injection into the kernel after privilege escalation; Credential Guard blocks theft of protected domain secrets and lateral movement, but does not reach secrets outside its scopeInitial access (phishing and the like)Privilege escalationCode injection into the kernelTheft of protected domain secrets and lateral movementMFA, training, and EDR cover thisHVCI blocks this stepCredential Guard blocks this (protected secrets only)

Figure 15: VBS is not a “don’t let them in” technology; it is a “don’t let them win after they are in” technology, and the stage it guards is different.

7.2. “If Memory integrity causes a problem, just turn it off”

Turning it off will make things work for the moment, but it takes down the barrier against code injection into the kernel wholesale. The proper response is first to identify the blocked driver in the CodeIntegrity log and apply the vendor’s updated version. Even if you disable it temporarily for validation, we recommend an operation that does not make that a permanent setting.

7.3. “With Credential Guard, passwords cannot be stolen”

That is overconfidence from mixing up the defensive range. Service tickets, local accounts, keystrokes themselves, and credentials stored privately by an app are out of scope.8 Phishing and keyloggers need other controls (multi-factor authentication, Windows Hello, and a review of credential management on the app side).

8. Summary

  • VBS uses the hypervisor to create an isolated environment and protects security features on the assumption that the kernel can be compromised.1
  • The unit of isolation is the VTL; currently two levels are implemented, VTL0 (the ordinary world) and VTL1 (the Secure Kernel and IUM).2
  • The substance of the boundary is SLAT memory access protection, which software inside the partition — including the kernel — cannot change.2
  • HVCI runs code-integrity verification in the isolated environment and enforces “not executable until verification passes” and “an executable page is not writable”.4 The price is that you have to manage driver compatibility.5
  • Credential Guard isolates NTLM hashes of domain credentials and TGTs into LSAIso in VTL1. From Windows 11 22H2 onward it is enabled by default on devices that meet the license requirements (Enterprise, Education) and the hardware requirements (use this together with a check of the running state).67
  • You can confirm the running state from Win32_DeviceGuard’s SecurityServicesRunning (1 = Credential Guard, 2 = HVCI).9

Continued in Part 3, “Virtual Machines That Boot in Seconds — WSL2, Windows Sandbox, and Containers”.

So far we have looked at virtualization from the “strength of isolation” side. The final instalment looks from the opposite, “lightness” side, and follows where the lightweight VMs that discarded the weight of a full VM are cutting corners.

KomuraSoft LLC handles compatibility investigations between Windows applications and security features, analysis of driver-caused failures, and technical validation of in-house PC environments.

References

  1. Microsoft Learn, Virtualization-based Security (VBS). On VBS using hardware virtualization and the Windows hypervisor to create an isolated environment and treating that as the OS’s root of trust on the assumption that the kernel can be compromised; Memory integrity running kernel-mode code-integrity verification inside that isolated environment; and SLAT being a hard requirement for VBS. ↩ ↩2 ↩3

  2. Microsoft Learn, Virtual Secure Mode. On VSM being the foundation for Device Guard, Credential Guard, a virtual TPM, and the like; access to isolated regions being controlled only through the hypervisor and protected even from ring-0 OS software; VTLs being hierarchical with 2 of a maximum of 16 levels implemented; and per-VTL memory access protections being unchangeable by system software inside the partition. ↩ ↩2 ↩3 ↩4 ↩5

  3. Microsoft Learn, Isolated User Mode (IUM) Processes. On VSM creating VTLs using the Hyper-V hypervisor and SLAT; the Secure Kernel and IUM running in VTL1; trustlets marshalling system calls to the VTL0 kernel; and LSAIso running in VTL1 and communicating with lsass via RPC. ↩ ↩2 ↩3

  4. Microsoft Learn, Memory integrity and virtualization-based security. On Memory integrity (HVCI) running code-integrity verification in an isolated environment, and on kernel memory pages becoming executable only after passing verification and executable pages not becoming writable. ↩ ↩2 ↩3

  5. Microsoft Learn, Memory integrity and VBS enablement. On Memory integrity being enabled by default on a clean install of Windows 11 if the hardware is compatible; confirming state in msinfo32 and the Windows Security app; and confirming a blocked driver via event ID 3087 in the CodeIntegrity Operational log. ↩ ↩2 ↩3

  6. Microsoft Learn, How Credential Guard works. On the LSA communicating with an Isolated LSA process (LSAIso.exe) to store secrets when Credential Guard is enabled; the stored data being protected by VBS and inaccessible from the rest of the OS; and the Isolated LSA process hosting no device drivers and housing only a minimum of signature-verified binaries. ↩ ↩2 ↩3

  7. Microsoft Learn, Credential Guard overview. On Credential Guard being enabled by default from Windows 11 version 22H2 onward on devices that meet the license, hardware, and software requirements and have not been explicitly disabled; the qualifying editions/licenses being Enterprise (E3/E5) and Education (A3/A5), with Pro out of scope; and a Pro machine that was previously enabled under a qualifying license remaining a default-enabled target after a downgrade. ↩ ↩2

  8. Microsoft Learn, Credential Guard protection limits. On service tickets, local accounts, keyloggers, physical attacks, and the like being out of Credential Guard’s protection scope; TGTs being protected while service tickets are not; and NTLMv1 and unconstrained delegation becoming unusable when it is enabled. ↩ ↩2 ↩3

  9. Microsoft Learn, Enable virtualization-based protection of code integrity. On how to confirm the state of VBS and Memory integrity via the Win32_DeviceGuard class, and on the meaning of SecurityServicesRunning values (1 is Credential Guard, 2 is Memory integrity). ↩ ↩2

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Are VBS (virtualization-based security) and Core isolation the same thing?
Strictly speaking, they are different. VBS is the foundational technology that creates an isolated environment with the hypervisor, and "Core isolation" in the Windows Security app is the name of a screen that groups several protections built on VBS. The representative one is "Memory integrity", which refers to HVCI (hypervisor-protected code integrity). Confirm the running state of each service by querying Win32_DeviceGuard, not from the screen display.
Can VTL1 memory really not be read, even with administrator privileges or from a kernel driver?
It cannot. Per-VTL memory access protections are managed by the hypervisor against the partition's physical address space, and software running inside the partition cannot change them. Even code that runs in the kernel (ring 0) is not permitted to access VTL1 memory from VTL0.
Why can enabling Memory integrity (HVCI) stop a driver from working?
In an HVCI environment, a kernel page becomes executable only after it has passed integrity verification, and writes to executable pages are not permitted. An unsigned driver, or an older-design driver that rewrites executable memory, cannot satisfy this constraint and its load is blocked. You can confirm the block in the CodeIntegrity Operational log (event ID 3087 and the like).
What does Credential Guard protect, and what does it not protect?
It protects NTLM password hashes of domain credentials, Kerberos TGTs, and things an app stored as domain credentials, in an isolated environment. Kerberos service tickets, credentials of local accounts and Microsoft accounts, theft of input by a keylogger, and physical attacks are out of scope.
Where can I check whether VBS is running?
Look at the "Virtualization-based security" field in msinfo32, or query the Win32_DeviceGuard class in the root/Microsoft/Windows/DeviceGuard namespace from PowerShell. If SecurityServicesRunning contains 1, Credential Guard is running; if it contains 2, Memory integrity (HVCI) is running.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.

Contact
Back to the Blog