Credential Guard bypass

Theory

What Credential Guard is

Credential Guard (CG) is a Virtualization-based Security (VBS) feature that moves the most sensitive authentication secrets out of the reach of the normal operating system. On a VBS-enabled host, the Windows hypervisor splits execution into two Virtual Trust Levels:

• VTL0 - the "normal world": the ordinary Windows kernel and every user-mode process, including the lsass.exe you can see in Task Manager.
• VTL1 - the "secure world" (Isolated User Mode, IUM): a small, separately-signed set of processes called trustlets, isolated from VTL0 by the hypervisor using SLAT/EPT memory partitioning. Even a fully-compromised VTL0 kernel cannot read VTL1 memory.

When Credential Guard is active, LSASS is split in two:

• lsass.exe in VTL0 - the broker you can see and open a handle to. It still orchestrates authentication, but it no longer holds the derived secrets. A dashed-outline LsaIso.exe placeholder process is visible in VTL0, but it is just a stub - the real code and data live in VTL1.
• LsaIso.exe in VTL1 (the Isolated LSA) - the trustlet that actually stores and uses the secrets. It communicates with the VTL0 LSASS over a secure, hypervisor-mediated channel.

At the crypto level, when VTL0 lsass.exe receives a user's password, it forwards it to the LsaIso.exe trustlet in VTL1. The trustlet calls EncryptPassword(), then DoCrypto() which uses cryptographic keys sealed to the TPM by the secure kernel. Only an opaque blob - useless outside VTL1 - flows back to VTL0. The NT hash, the Kerberos keys and the plaintext never touch VTL0 memory at rest.

What Credential Guard does and does not protect

This distinction is the hinge for every technique on this page.

Protected - derived secrets at rest in the isolated store:

• NTLM password hashes (NT/NtOwfPassword)
• Kerberos long-term keys and TGT session keys
• Cached domain logon verifiers (domain-cached credentials)

With CG on, these never materialise in VTL0 lsass.exe memory. A conventional LSASS dump (comsvcs.dll, ProcDump, MiniDumpWriteDump, mimikatz sekurlsa::logonpasswords) therefore comes back with the secret fields blanked - the attacker only recovers encrypted proxy blobs that are useless outside VTL1.

Not protected - because CG was never designed to hide them:

• Plaintext credentials in transit at authentication time. A Security Support Provider (SSP) loaded into the VTL0 LSASS still sees the cleartext as it flows through the logon path. CG protects the stored, derived secret, not the credential while it is being presented.
• Secrets for logons that happen while CG is off. Isolation is enforced at the moment the secret is created. Anything created before CG was enabled, or after it is torn down, lives in VTL0.
• Local SAM secrets, DPAPI-protected material, browser/credential-manager stores, and network authentication exchanges (which can still be relayed, roasted, or captured).

Because of this, "bypassing Credential Guard" splits into two distinct goals: disabling it so the secrets fall back into VTL0, or circumventing it by capturing credentials on a path it does not cover.

The runtime-teardown primitive

Classically, turning Credential Guard off meant changing configuration (LsaCfgFlags, UEFI variables, Device Guard policy) and rebooting - persistent, but slow and loud.

Research published in the CredGuardRuntimeShutdown PoC (Win11 24H2, build 26200) demonstrates a reboot-less, driver-less teardown. Inside the LsaIso.exe trustlet runs a thread, DisableCredGuardWaitThread, that blocks waiting on a named kernel event object:

\LSA_ISO_DISABLE_CREDENTIAL_GUARD

Signalling that event wakes the thread, which tears down the Credential Guard credential provider at runtime. No kernel driver and no reboot are involved - the OS simply stops isolating new credentials for the remainder of the boot.

Two properties make this an attacker primitive rather than a mere curiosity:

Practice

Enumeration

Before attempting any bypass, verify whether Credential Guard is actually active on the target.

# Check VBS and Credential Guard status
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object -Property SecurityServicesRunning, VirtualizationBasedSecurityStatus

Runtime teardown (reboot-less)

The runtime teardown disables Credential Guard on the fly by signaling the \LSA_ISO_DISABLE_CREDENTIAL_GUARD kernel event as SYSTEM. No driver, no reboot. Credentials from sessions created after the teardown materialise in plain VTL0 LSASS memory and can be dumped normally.

# Compile (MinGW)
gcc -o credguard_poc.exe credguard_poc.c -lntdll -lwincrypt -ldbghelp

# Run from a high-integrity admin shell
# <user> <domain> <password> - account must exist on the target
credguard_poc.exe sshuser . password

# Offline analysis of the minidump
pypykatz lsa minidump C:\Windows\Temp\lsass_post.dmp

# Or with Mimikatz on the live process
sekurlsa::logonpasswords

Persistent disable (reboot required)

The classic approach removes the Credential Guard configuration so it does not start on the next boot. This requires a reboot, which is louder but persistent across boots.

# Disable Credential Guard
reg add "HKLM\SYSTEM\CurrentControlSet\Control\LSA" /v LsaCfgFlags /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard" /v LsaCfgFlags /t REG_DWORD /d 0 /f

# Reboot
shutdown /r /t 0

Circumventing Credential Guard (without disabling it)

Credential Guard only protects derived secrets at rest in VTL1. Credentials can still be captured on paths it was never designed to cover.

In-memory SSP injection

A malicious Security Support Provider loaded into the VTL0 lsass.exe sees plaintext credentials as they flow through the logon path, before they ever reach VTL1.

privilege::debug
misc::memssp

Other credential capture paths

Credential Guard does not protect these vectors, which can be used to harvest credentials even while VTL1 isolation is fully active:

• Keylogging / credential prompts - capture passwords at the UI layer before they reach LSASS.
• Network authentication capture - NTLM relay, Kerberoasting, AS-REP roasting and coerced authentication sidestep the isolated store entirely.
• DPAPI and SAM/LSA secrets are not protected by Credential Guard.

Detection

Resources