As already described in the Windows Hello section, the PtH vulnerability has become a very common threat. Hacker tools such as Mimikatz can dump the system memory and debug your LSASS.exe, containing all the currently active credentials, including hashes. When PtH was weaponized, Windows 7 was already mainstream, and the design of Windows 8.0 was also completed. They could not react/redesign their kernel to prevent this memory dump. Every service was able to dump your Local Security Authority Subsystem (LSASS). With Windows 8.1, a new protected process level (PPL) was introduced. When RunAsPPL was activated, the LSASS process would run with a higher protection level (system level) and therefore no longer be accessible by illegal/corrupt services. But Mimikatz evolved and found a weak spot with device drivers. Even when running in the PPL, LSASS could be accessed by corrupted device drivers. A more disruptive security element was needed. Since Windows 8.0, the client OS is also capable of the Hyper-V feature. Hyper-V protects the memory contents of its guests. The idea of a second virtual OS, Virtualization-based security, was born.

To better protect VBS against known attack vectors such as using corrupt device drivers, the VBS OS does not support device drivers at all. The binaries inside the VBS are protected by Code Integrity (signed binaries) and CFG (a table of all possible states of a executable). So even in the unlikely event that malware is capable of entering VBS, the malware/infected binaries are identified by Code Integrity and will not be executed. And even if they should be capable of fooling the Code Integrity, the different jump behavior of executables will be detected by the control flow guard and the executable will be terminated.

Credential Guard uses VBS to isolate Windows authentication from the Windows operating system. In the VBS protected system, the high-level OS and the VBS OS communicate with remote procedure calls (RPCs). When activating Credential Guard, you will see in addition to the well-known LSASS a new process called LSAISO. This LSAISO is not the LSAISO running inside VBS, but an additional LSAISO running inside the high-level OS to help the communication of LSASS between the two environments.

The high-level-OS LSASS only contains a reference GUID for the credential. Only the VBS LSASS contains the hash.

Malware could try to get the GUID, but the LSASS/LSAISO processes will only communicate with its counterparts, so the GUID could be known to the malware without it doing any harm.

Credential Guard only protects domain accounts. Local accounts and Microsoft accounts are currently not protected. Local accounts should be protected by setting individual passwords on each device. Look up LAPS for protecting local admin accounts in enterprise environments. Microsoft accounts should be protected by two-factor authentication. Software that manages credentials outside of Windows is also not protected by Credential Guard.

Unfortunately, Credential Guard is referenced inside the GPO and inside Msinfo32 also as Device Guard. To activate Credential Guard on your system, your system needs to be capable of running the VBS OS, and the VBS feature needs to be active/running.

To check your hardware for compatibility, you can use the Device Guard and Credential Guard hardware readiness tool (for more information visit https://www.microsoft.com/en-us/download/details.aspx?id=53337).

Credential Guard can be controlled by GPO or MDM. You will find the related GPO in the machine GPO section under System | Device Guard.

Select the Turn On Virtualization Based Security entry and configure it to Enabled. For platform security level, select Secure Boot at minimum, or better, select Secure Boot and DMA Protection.

Some devices will run into an endless boot loop when activating Secure Boot and DMA Protection. This is due to outdated/incompatible UEFI firmware. This can only be fixed by a UEFI firmware update. Fixed firmware is available for most devices. It is best to update to the latest UEFI firmware to be able to run the higher security level of Secure Boot and DMA Protection. Test your hardware before rolling out to production.

Next, you need to configure the Credential Guard configuration to Enabled without lock or Enabled with UEFI lock. A reboot is required after the policy is applied to activate Credential Guard:

Be careful with selecting Enabled with UEFI lock. Once you've selected this UEFI lock, the element can no longer disabled by GPO and is protected by a physical UEFI lock. To disable Credential Guard or Device Guard protected by UEFI lock, you need to set the GPO to Disabled and additionally execute a script on the device and press a key during next reboot to disable the feature. Test first without lock and activate the UEFI lock feature later in production when all settings are fixed and the unlock script has been tested.

To check whether VBS and Credential Guard are up and running, you can check your task manager. If you see a process called LsaIso.exe, it indicates Credential Guard is running:

Alternatively, you could use MSINFO32.exe and look at the system summary entries for Device Guard: Virtualization-based security should be Running, and Virtualization-based security Services Running should be set to Credential Guard:

If Credential Guard cannot be activated on your device, check compatibility with Device Guard and Credential Guard hardware readiness tool or event viewer for an error event ID.

In addition to the Credential Guard configuration, there is the Virtualization-based protection of Code Integrity, a.k.a. Device Guard, which will be covered next.