Foreword

Starting in Windows 11, 22H2 and Windows Server 2025, Credential Guard is enabled by default on devices which meet the requirements.

So this is important for Clients below Windows 11 and Servers below Windows Server 2025.

If a device has Credential Guard explicitly turned off before updating to a newer version of Windows where Credential Guard is enabled by default, it will remain disabled even after the update.

Credential Guard should be enabled before a device is joined to a domain or before a domain user signs in for the first time. If Credential Guard is enabled after domain join, the user and device secrets may already be compromised.

Kerberos, NTLM, and Credential Manager isolate secrets by using Virtualization-based security (VBS). Previous versions of Windows stored secrets in its process memory, in the Local Security Authority (LSA) process lsass.exe.

With Credential Guard enabled, the LSA process in the operating system talks to a component called the isolated LSA process that stores and protects those secrets, LSAIso.exe. Data stored by the isolated LSA process is protected using VBS and isn’t accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process.

For security reasons, the isolated LSA process doesn’t host any device drivers. Instead, it only hosts a small subset of operating system binaries that are needed for security and nothing else. All the binaries are signed with a certificate that VBS trusts, and the signatures are validated before launching the file in the protected environment.

Warning

Enabling Credential Guard on domain controllers isn’t recommended. Credential Guard doesn’t provide any added security to domain controllers, and can cause application compatibility issues on domain controllers.

Applications break if they require:

• Kerberos DES encryption support
• Kerberos unconstrained delegation
• Kerberos TGT extraction
• NTLMv1
  
  

Prerequisites

Virtualization Based Security needs to be enabled on virtual machines that are hosted on VMware. You can enable it in the settings of each VM.

You can also see it in the VM overview under the “Guest OS” tab.

Credential Guard Disabled

When Credential Guard is disabled, attackers can use tools such as Mimikatz to extract the NTLM-Hash.

Enable Credential Guard

Create GPO

Open the Group Policy Managment Console.

Right-click on the “Group Policy Objects” folder and select “New”.

Choose a name for the GPO.

Right-click the newly created GPO and select “Edit”.

Navigate to the following path:

Computer Configuration -> Policies -> Administrative Templates -> System -> Device Guard

Do a right-click on the “Turn On Virtualization Based Security” policy and select “Edit”.

You should see the following window.

Enabled with UEFI Lock

Enable the policy. Select “Secure Boot and DMA Protection” for the Platform Security Level.

There are two important configuration options for the “Credential Guard Configuration” dropdown. The first one is “Enabled with UEFI lock”. The advantage of it is: Attackers can’t just disable Credential Guard with GPO or Registry. If you want to disable it, you will need to confirm the deactivation at the reboot of the computer or virtual machine. So an attacker needs to be in front of the Computer or need to have access to the Hypervisor.

Enabled without Lock

The other option is “Enabled without lock”. Attackers could disable Credential Guard with GPO or Registry. However, it can be easier for administrators to manage, as they do not have to stand in front of the computer to manually deactivate it during a reboot.

Link the GPO

Link the GPO to an OU in which you want to activate Credential Guard. In my example, it is the “Computers” OU. Do a right-click on the OU and select “Link an Existing GPO…”.

Select the newly created GPO.

It should look like this.

Check if it’s working

If Credential Guard has been successfully activated, a new process exists in the Task Manager. This is called “Lsalso.exe” with the description “Credential Guard & Key Guard”.

Attackers can no longer extract the NTLM hash with Mimikatz, for example, as the hash is now protected by Credential Guard. Mimikatz displays the information “LSA Isolated Data: NtlmHash”.

Disable Credential Guard

Disable with UEFI Lock

To disable Credential Guard with the UEFI Lock configuration, you will need to set the GPO you created before to the option “Not Configured” or “Disabled”.

After that, you will need to enter the following commands into an administrative CMD.

1
2
3
4
5
6
7
8

mountvol X: /s
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
mountvol X: /d

When you reboot the Computer or Server, you will need to confirm the deactivation of Credential Guard with the Windows key or F3 key.

If you press one of the keys, Credential Guard got successfully disabled.

Disable without Lock

To disable Credential Guard without the UEFI Lock configuration, you will just need to set the GPO you created before to the option “Not Configured” or “Disabled”. Reboot your Computer or Server afterwards.

Conclusion

Your environment is now better protected against credential theft attacks. NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs) and credentials stored by applications as domain credentials are now secured by Credential Guard.

If you would also like to secure computer accounts with Credential Guard, you can view the following blog entry from me: https://theadmincafe.ch/p/configure-credential-guard-computer-accounts/