In this post, my colleague Derek Granito and I will share how you can use Windows Defender Credential Guard in conjunction with Windows technologies like protected processes and Hypervisor-protected code integrity (HVCI) to build comprehensive protection for credentials.
Windows Defender Credential Guard
Windows Defender Credential Guard is a Windows security feature that makes it difficult for attackers to steal user credentials on domain-joined systems by relying on virtualization-based security. In essence, it protects your Windows credentials by storing them in an isolated virtual machine that malware can’t touch.
The goal of Windows Defender Credential Guard is to make it incredibly difficult for malware to move laterally in an enterprise network and gain higher privileges. The theory is simple: prevent malware from stealing passwords, hopping boxes, and elevating privileges. An attacker is dead in the water if they can’t get credentials in the first place.
Figure 1. Example of a credential access attack
Credential Guard protects credentials by making sure that the credentials can’t leave the secure world of the isolated virtual machine. Any operation that relies on a Windows credential, such as passwords, NTLM hashes, or Kerberos ticket-granting-tickets (TGTs), occurs within the virtualized secure world so that credentials are never leaked to attackers. Software like Mimikatz can read the local security authority (LSA) process memory, but since credentials are stored in Credential Guard, there’s nothing to steal out of the LSA anymore.
Figure 2. Example of how an application can access and read the LSA, but won’t see the password
To turn on Credential Guard, you will need to configure Group Policy to enable Credential Guard. Credential Guard settings are located in the Group Policy Management Console under Computer Configuration -> Administrative Templates -> System -> Device Guard. For step-by-step instructions, see Enable Windows Defender Credential Guard.
Figure 3. Credential Guard settings in the Group Policy Management Console
There are two ways to tell if Credential Guard is running. The first, and most reliable, way is to use the System Information (MSINFO32) command-line tool. If it is running, you will see Virtualization-based security Services Running: Credential Guard listed in the System Summary.
Figure 4. System Information shows that Credential Guard is running
Alternatively, you can check Process Explorer to see if the LsaIso.exe process is running. This isn’t as reliable because it doesn’t guarantee Credential Guard itself is running, just that the host process is running. LsaIso.exe also hosts a feature called Key Guard.
If you run Process Explorer, you’ll notice it’s not like any other process and you can’t see any details about its execution. This is because it’s running in an isolated virtual machine (VM).
Figure 5. Lsalso.exe properties
LSA as protected process
There’s a brief period of time when the user must enter their password into the machine to sign in. This means that credentials necessarily flow through processes that malware can observe or intercept. In addition, some credentials can’t be protected by Credential Guard because of how they’re used by apps on the machine. Getting access to these credentials isn’t necessarily a high risk, but it can lead to gaps you may not be aware of or monitoring for.
Windows can block these sorts of attacks through a technology called protected processes. This prevents malware from being able to attach to and read the memory of the LSA.
To turn on LSA protected process mode, you’ll need to open the Registry Editor (RegEdit.exe) and navigate to the registry key located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, then set the value of the registry key to “RunAsPPL”=dword:00000001. For step-by-step instructions on how to do this, or how to enable LSA protect using Group Policy, see How to configure additional LSA protection of credentials.
Figure 6. Lsass.exe running as a protected process (as seen in the Registry Editor)
In the image above, the Protected: PsProtectedSignLsa-Light label indicates that the lsass.exe process is running as a protected process. There are no privileges in user mode that allow other processes to inject code or read the memory of a protected process. That means applications like Mimikatz can’t get a foothold on LSA and kick off other attacks like SSP module injection or memory inspection.
This is a powerful security feature, but it has some compatibility caveats. Third-party extensions and security providers will not be loaded into the LSA unless they’re signed by the Microsoft Windows Hardware Quality Labs (WHQL) process. Consequently, before turning on LSA protected process mode, you should run it through auditing mode to find out if there are any compatibility issues in your environment. Common issues customers have run into include incompatibility with third-party smart card middleware and third-party security providers for single sign-on (SSO). If this is an issue for you, it would be worth investigating whether Windows Hello for Business is an option.
Hypervisor-protected code integrity (HVCI)
Protected processes are a kernel construct; malware running in the kernel can modify the structures necessary to mark a process as protected and, well, unprotect them. Historically, the kernel has been the system security boundary – once you got into it, anything goes. So even if you had Credential Guard running and had LSA configured as a protected process, an attacker could manipulate process execution from within the kernel.
That’s not strictly true anymore with the introduction of Hypervisor-protected code integrity (HVCI), which is specifically designed to protect the kernel against tampering. HVCI works by adding a degree of separation and moving control of the system’s memory to a secure runtime environment created by the hypervisor.
Hypervisor-protected code integrity introduces a new rule that no kernel memory pages are both writeable and executable, which eliminates an entire category of attacks that dynamically generate code. Additionally, HVCI comes enabled with a code integrity security policy that blocks drivers known to be used in kernel tampering, including Mimikatz, the old vulnerable VBox driver, and the Capcom driver commonly used in rootkits. Ultimately, HVCI provides optimal protection for the kernel against tampering and escalation of privilege attacks.
Turning HVCI on is a matter of turning on the Memory integrity setting in the Windows Security Center. This will scan your device for any known incompatible drivers and enable if your device is clean.
Figure 7. Memory integrity settings in the Windows Security Center
Alternatively, this feature can also be enabled and managed through Group Policy.
With HVCI enabled, attempts to modify the process structures will fail, preventing the protected process flag from being removed, which prevents process memory inspection or module injection into LSA.
Conclusion
Protecting credentials is key to mitigating cyberattacks. In addition to industry-leading detection capabilities in security solutions like Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP), we continue to transform the Windows 10 platform to prevent credential theft. Innovating at the platform level allows us to address entire classes of attacks. We encourage enterprises to take full advantage of security technologies like Windows Defender Credential Guard and HVCI to harden their environments against cyberattacks.
Microsoft
