Credential Guard: Protect Windows from pass-the-hash and pass-the-ticket attacks

on
Credential Guard is a component of Microsoft's Virtualization-based Security Suite (VBS). With the help of the hypervisor, it protects the hashes of the credentials cached in RAM from attackers. And it is super simple to enable using Intune or Group Policy!



So how does Credential Guard work?

After successfully logging on to Active Directory, Windows stores the hash of the credentials in the Local Security Authority's memory (LSA). If a user accesses a network resource, they are automatically authenticated with it, and a new password entry can be omitted.

However, attackers can use tools like Mimikatz to take advantage of this mechanism by reading the hash from memory and thus gaining access to network systems.

When you enable Credential Guard, the operating system's LSA no longer holds the secrets. Rather, the LSA is contained in an additional lightweight Windows kernel that performs this task.

This runs in a virtual machine with a higher trust level, so direct access to its memory from the actual OS is not possible. As a result, the local LSA must use Remote Procedure Calls to communicate with its secure counterpart (RPCs).

Why enable Credential Guard?

Let's start off with describing what a pass-the-hash (PTH) attack is. PTH is when an attacker obtains a password hash rather than the password itself (characters) in order to gain access to networked systems (authentication).

PTH differs from pass-the-ticket (PTT) attacks in that the attacker gains lateral movement inside an environment using stolen Kerberos tickets, thereby evading normal system access controls. PTT is a Kerberos ticket-based way of authenticating to a system without having access to an account's password. Kerberos authentication can be used as the first step in moving from one system to another.

No SSO with insecure protocols 

After activating Credential Guard, single sign-on with NTLMv1, MS-CHAPv2, Digest, and CredSSP is no longer possible. Applications that require authentication via these protocols will then prompt users to re-enter their identifier in a login dialog. 

Another limitation of Credential Guard is that it does not support Unconstrained Kerberos delegation or DES encryption. As a result, before implementing this feature on a large scale, you should investigate whether the associated restrictions could cause issues with your existing applications.

Requirements

Before activating Credential Guard, you should make sure that the respective devices meet the necessary requirements. These are:
  • 64-bit version of Windows 10 or 11 or 8 Windows Server 2016 or later
  • UEFI firmware with Secure Boot 10 enabled.
  • CPU with virtualization extensions 12 Intel VT-x or AMD-V with SLAT support
  • TPM v 1.2 or 2.0

Microsoft provides a hardware readiness tool in the form of a PowerShell script that checks these conditions.

So let me show you how to do this in Intune and or with a Group Policy!


Enable Credential Guard with Intune

The feature can be activated in several ways in Intune. As well as being part of Intune Security Baselines, you can accomplish this by creating a device configuration profile. 

Star by navigating to Devices > Configuration Profiles > + Create profile > Select Windows 10 and later (under platform) > Templates > Endpoint protection


There are four options for configuring Credential Guard:
  • Deactivated
  • Enabled with UEFI lock
  • Not configured
  • Enabled without lock

When UEFI lock is enabled, the setting is permanently saved in the firmware. As a result, resetting Group Policy will not remove it. Instead, you must physically disable them on each PC. When activated without a lock, however, you can change the setting via GPO (see the next section).


Enable Credential Guard with Group Policy

The feature can be activated in several ways. The most common procedure is likely to remain Group Policy. Intune or the direct setting of a registry key are also possible. If you opt for a GPO, you can find the responsible setting under 

Computer Configuration à Policies à Administrative Templates à System à Device Guard.

It is called Turn-On Virtualization-Based Security and controls several VBS functions at the same time.

There are four options to configure Credential Guard:

  • Deactivated
  • Enabled with UEFI lock
  • Not configured
  • Enabled without lock

When UEFI lock is enabled, the setting is permanently saved in the firmware. As a result, resetting Group Policy will not remove it. Instead, you must physically disable them on each PC. When activated without a lock, however, you can change the setting via GPO.

When the group policy is applied to the target computers, you can use msinfo32.exe to see if the feature has been activated.

Alternatively, you can check if a process called LsaIso is running. However, this is always available as soon as even one VBS feature is active.


Credential Guard in VMs

Credential Guard can also be used to protect the guest OS in a virtual machine. With its virtual hardware, it must meet the same requirements as a physical computer. Therefore, only Generation 2 VMs are eligible. For these you have to activate Secure Boot and a virtual TPM.

In addition, you have to make sure that vmSecurity does not have the VirtualizationBasedSecurityOptOut property set to $true. This can be queried with

Get-VMSecurity -VMName <Name-der-VM>

If necessary, you can change this setting with

Get-VMSecurity -VMName <Name-der-VM> -VirtualizationBasedSecurityOptOut $false

Enabling Credential Guard for a VM is done using the same methods as for a physical machine, such as Group Policy mentioned above.