This week is again back to Windows. This week is all about Windows Defender Credential Guard (Credential Guard). Credential Guard is definitely not something new, it’s actually available since the beginning of Windows 10, but it’s still a little unknown and still not always used. A little awareness is on its place. Credential Guard uses virtualization-based security to isolate secrets and to make sure that only privileged access is allowed. That helps with preventing unauthorized access that can lead to known credential theft attacks, like Pass-the-Hash and Pass-the-Ticket. Besides awareness, there is also another new configuration location within Microsoft Intune that might be interesting. This post will start with a quick introduction about Credential Guard, followed with the steps to configure Credential Guard by using an Account protection profile in Microsoft Intune. This post ends with verifying the configuration.
Introduction to Windows Defender Credential Guard
Credential Guard helps with preventing the mentioned credential theft attacks, by protecting the NTLM password hashes, the Kerberos Ticket Granting Tickets, and the credentials stored by applications as domain credentials. When Credential Guard is enabled it provides hardware assisted security that can be used to take advantage of the platform security features (like Secure Boot) and it provides virtualization-based security (VBS) that together can be used to protect credentials in an isolated environment.
These security features enable organizations to better protect against credential theft attacks. Malware running in the Operating System (OS) – with administrator privileges – won’t be able to extract secrets that are protected by VBS. All of that is achieved by how Credential Guard works. In previous versions of Windows, the secrets were stored (in memory) in the Local Security Authority (LSA). When using VBS, however, there will be a separate LSA process (LSASS) and an isolated LSA process (LSAIso). That isolated process is protected by VBS and only the LSASS process can access the LSAIso process. The rest of the OS can’t access the LSAIso process. That’s a nice protection layer for those stored secrets.
For a lot more details have a look at: Windows 10 Device Guard and Credential Guard Demystified.
Important: Credential Guard requires Windows 10 Enterprise or Windows 10 Education.
Configuration of Windows Defender Credential Guard with Microsoft Intune
The configuration of Credential Guard can actually be performed by using different profiles. One being an Endpoint protection profile and another one being an Account protection profile. The Account protection profile, is the latest configuration option and also the most logical configuration option for security related configurations. That profile type is part of the Account protection section in the Endpoint security node and contains the required Credential Guard settings (which is actually just one setting). The following eight steps walk through the required steps for configuring Credential Guard.
- Open the Microsoft Endpoint Manager admin center portal navigate to Endpoint security > Account protection to open the Endpoint security | Account protection blade
- On the Endpoint security | Account protection blade, click Create Policy to open the Create a profile page
- On the Create a profile page, provide the following information and click Create to open the Create profile wizard
- Platform: Select Windows 10 and later as value
- Profile: Select Account protection (preview) as value
- On the Basics page, provide the following information and click Next
- Name: Provide a name for the profile to distinguish it from other similar profiles
- Description: (Optional) Provide a description for the profile to further differentiate profiles
- Platform: (Pre-selected) Windows 10 and later
- On the Configuration settings page (as shown in Figure 1), provide the required configuration for the following settings and click Next
- Block Windows Hello for Business: Leave Not configured as value to make sure that this policy will not affect the current Windows Hello for Business configuration
- Enable to use security keys for sign-in: Leave Not configured as value to make sure that this policy will not affect the current security key usage configuration
- Turn on Credential Guard: Select Enable with UEFI lock as value to make sure that Credential Guard will be enabled and can’t be disabled remotely
Note: When using this configuration, the only method to disable Credential Guard is by setting this configuration to Disabled and physically clearing the UEFI information of the device.
- On the Scope tags page, configure the required scope tags click Next
- On the Assignments page, configure the assignment to the required users and/or devices and click Next
- On the Review + create page, verify the configuration and click Create
Important: This configuration is at the moment still preview and doesn’t seem to configure Enable Virtualization-based Security (VBS) nor Secure Boot with Directory Memory Access. That first setting is used to enable VBS – that uses the Windows Hypervisor to provide support for security services – and is turned on during the next reboot. That second setting turns on VBS with Secure Boot and direct memory access (DMA) protections.
Verify Windows Defender Credential Guard on the device
Tip: When using a VM for testing Credential Guard, make sure that the VM meets the minimal requirements and make sure to configure nested virtualization.
There are many locations to verify a successful configuration of Credential Guard. From MDM specific locations to Credential Guard specific locations. The Credential Guard specific locations provide the best explanation options. The Registry Editor, as shown below at the top of Figure 2, shows the required registry values in the DeviceGuard policy key. However, at this moment, only the LsaCfgFlags key is configured when using the provided configuration. The Event Viewer, as shown below on the bottom left of Figure 2, shows the DeviceGuard log information and Event ID 7000 shows the successful configuration. The Task Manager, as shown below on the bottom right of Figure 2, shows the running LSAIso process.
Important: The complete configuration required me, at this moment, to fall back to the Credential Guard configuration in the Microsoft Defender Credential Guard section of an Endpoint protection profile or to simply use the latest security baseline configurations.
Note: The device needs a restart for Credential Guard to be running on the device.
Besides verifying the configuration of Credential Guard, it’s maybe even more interesting to see it in action. Just to be sure. An easy method to achieve that is by using mimicatz. That tool can do a lot of awesome stuff, but it’s well known for extracting plaintexts passwords, hash, PIN code and kerberos tickets from memory. In other words, mimicatz is a great tool to show the basics of Credential Guard. Below an the left, in Figure 3, is an example of mimikatz before using Credential Guard. That example clearly shows a NTLM hash and a plaintext password. Below on the right, in Figure 4, is an example of mimicatz after using Credential Guard. That example clearly shows shows that the NTLM hash and the plaintext password are now LSA isolated data. Those examples showed that the relatively simple implementation of Credential Guard, at least made the locally stored credential a bit safer again.
For more information about Windows Defender Credential Guard and Microsoft Intune, refer to the following docs.
- Protect derived domain credentials with Windows Defender Credential Guard
- Manage Windows Defender Credential Guard
- Windows 10 Device Guard and Credential Guard Demystified
- Windows 10 (and later) settings to protect devices using Intune | Credential Guard
- Account protection policy settings for endpoint security in Intune