- What: New techniques to bypass Credential Guard in Windows
- Impact: Potential for credential theft and lateral movement in enterprise environments
Microsoft introduced Credential Guard in Windows 10 (2015) and Windows Server 2016 to prevent credential harvesting from the LSASS process that was abused for years by threat actors. Microsoft used Virtualization Based Security (VBS) to isolate and protect credentials from the rest of the operating system. Credential material is stored in a protected environment to prevent theft techniques such as LSASS dumping and to restrict lateral movement, particularly in enterprise environments where privileged accounts are frequent targets. Starting from Windows 11 22H2 and Windows Server 2025, Microsoft enabled credential guard by default if hardware requirements are met. Credential Guard is a key control in the Microsoft ecosystem due to the sensitive secrets it protects. Offensive security research has pushed the barrier and since 2020 four different techniques related to Credential Guard have been disclosed in the public domain. Some ransomware threat actors such as Akira and Qlin, have used in their campaigns one of these techniques to re-enable the credential storage in the memory of the LSASS process. However, these cases are limited and might not be as widely recognized as other techniques. As a result, they can easily beneath the radar of cyber defence teams or de-prioritized by detection engineering teams. Playbook Mature organizations are running control validation programmes, but their scope includes mostly 3rd party controls and not controls that are embedded within the operating system. It is recommended to expand the scope to other controls to correctly articulate the risk. Various techniques have been disclosed in the public domain associated with abuse of Credential Guard. Some techniques share similarities; thus, the credential guard playbook includes four main techniques. These techniques are related to: Patching Pass the Challenge Downgrade SSP Negotiation The diagram below visualizes the timeline of Credential Guard attack vectors: Credential Guard – Attack Vectors Timeline Microsoft have mitigated the Patching and Downgrade techniques. However, the Pass the Challenge and SSP Negotiation still remain unresolved. Purple team operations should cover all applicable techniques to ensure adequate alerting coverage allowing organizations to detect and respond effectively. Patching Once Credential Guard is enabled, two processes relate to LSASS: LSASS.exe and LsaIso.exe . The process LsaIso is running inside a Hyper-V virtual machine and accessing the sensitive information stored on this process requires breaking the Hypervisor. The diagram below visualizes the high-level architecture differences between these two processes: Virtualization-Based Security Back in 2020, Team Hydra released an evasion technique related to Credential Guard that attempts to patch global state variables of the wdigest.dll in order to re-enable the caching of credential in LSASS. Specifically, the module wdigest.dll that is loaded by the LSASS process maintains several global state variables that influence how authentication is handled. Two are considered the most important because they directly control whether WDigest stores or returns clear-text credentials. These are: g_IsCredGuardEnabled g_fParameter_UseLogonCredential The g_IsCredGuardEnabled variable tracks whether Credential Guard is enabled or not on the system. If g_IsCredGuardEnabled == True , WDigest doesn’t store clear-text passwords in LSASS memory. The g_fParameter_UseLogonCredential controls whether WDigest should cache the user’s clear-text password after interactive logon. When the g_fParameter_UseLogonCredential == True , WDigest stores the user’s plain-text password in LSASS memory, and the password can be recovered via SSP calls. If the value is set to FALSE , WDigest doesn’t store plain-text credentials and only hashes and tokens remain in memory. The key below controls the state of the variable: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential The table below shows when credentials are stored or not stored in LSASS: Action g_IsCredGuardEnabled g_fParameter_UseLogonCredential Result WDigest Enabled FALSE TRUE Creds Stored Credential Guard Enabled TRUE ANY Creds not Stored Tampering the values of these variables, a threat actor could trick the WDigest module to store the clear-text value of the password in memory on the next user authentication. An offensive security researcher has released a proof of concept called BypassCredGuard that implements this method and could be used to simulate the technique: BypassCredGuard.exe BypassCredGuard Execution of Mimikatz will verify that credentials are cached in WDigest. mimikatz.exe "privilege::debug" "sekurlsa::wdigest" exit Mimikatz – WDigest Pass the Challenge The LsaIso process exposes cryptographic methods back to the LSASS, such as the NtlmIumCalculateNtResponse . Threat actors could abuse LsaIso functions to compute a challenge-response and attempt to crack offline the weak N...