A Walk Among the Credential Guards

This blog is the ninth part of the Endpoint security series. It will discuss implementing Credential Guard and provide some insights. While writing the blog, I added some more important stuff.

1. Credential Guard and his/her “predecessor” 

A long, long time ago, before there was Credential Guard (CG), there was some magical Local Security Authority (LSA) Protected Process Mode (PPM). (Does that sound like a movie intro?) LSA PPM provided additional security in Windows 8.1 for the credentials that the LSA stores and manages.  

Enabling LSA protection was really easy. Open the Registry Editor (RegEdit.exe), and navigate to the registry key that is located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. 

Configure the value of the registry key to “RunAsPPL”=dword:00000001. 

Did you notice the PPL? It stands for Protected Process Light. PP was originally designed for DRM (digital rights management). Later, it was adapted for security purposes to prevent normal applications, even those with administrator privileges, from accessing protected processes.

Combining Secure Boot and Runasppl is a great idea, as the setting will be stored in the firmware in a UEFI variable. With this setting stored in the firmware, deleting the registry key will have no effect. You will need an additional tool: Download Local Security Authority (LSA) Protected Process Opt-out from Official Microsoft Download Center 

But with the release of Windows 10, we now have Credential Guard. CG makes use of Hypervisor Code Integrity (HVCI) drivers and functions like virtualization-based security (VBS) to isolate secrets so that only privileged system software can access them.  

With the use of VBS, Windows NTLM and Kerberos-derived credentials and other secrets run in a virtual protected environment that is isolated from the running OS. This means it will protect your credentials from being lifted from the device. When you have implemented CG, it will help you reduce the impact of a pass-the-hash attack.   

CG works by moving the local security authority (LSA) into Isolated User Mode, the virtualized space created by virtual secure mode (VSM). VSM uses the Microsoft Hyper-V hypervisor, installed directly on the computer’s hardware, to run specific processes and store their data isolated from the operating system. 

Data stored by the isolated LSA process is protected by VBS and is not accessible to the rest of the operating system. 

Please Beware: When Windows Defender Credential Guard is enabled, neither Digest nor CredSSP has access to users’ login credentials. This implies no Single Sign-On use for these protocols 

And please make sure you have Windows 10 Enterprise or Education… when using Intune and the CSP’s

Also, other versions will not work even when you think it is! More on this later on 

2. Credential Guard vs. Device Guard vs. ASR Rules 

First some information about Device Guard and Credential Guard, both depend on Virtual Based Security (VBS) and are both using Hypervisor Code Integrity (HVCI) drivers. 

Virtualization is like segmentation. Take a look at what happens when you install Hyper-V and create 2 virtual machines. The processes of both virtual machines are totally separated from each other. You just implemented segmentation! So you could say virtualization is a security tool. 

2.1. Credential Guard  

Credential Guard uses virtualization-based security to isolate secrets (credentials) so that only privileged system software can access them. Unauthorized access to these secrets can lead to attack theft attacks.  

Credential Guard prevents these attacks by protecting password hashes for NT LAN Manager protocol (NTLM) and Kerberos ticket-granting tickets. Credential Guard uses virtualization-based security to isolate secrets so that only protected system software can access these files. Credential Guard does not depend on Device Guard. 

2.2. Device Guard  

Device Guard is a combination of security key features, designed to secure and protect a computer system against malware. Its focus is on preventing malicious code from running by ensuring only allowed and known good code can run. 

Device Guard consists of three key features: 

• Configurable Code Integrity (CCI) – Ensures that only trusted code runs from the boot loader onwards. 
• VSM Protected Code Integrity – Moves Kernel Mode Code Integrity (KMCI) and Hypervisor Code Integrity (HVCI) components into VSM, hardening them from attack. 
• Platform and UEFI Secure Boot – Ensuring the boot binaries and UEFI firmware are signed and have not been tampered with. 

Device Guard goes beyond Credential Guard by providing code integrity policies, which prevent unauthorized code from running on your devices, like malware/ransomware. Deploying Device Guard will significantly increase the security of your devices than when implementing Credential Guard. It’s fine to implement Credential Guard now and Device Guard later if that works best for your company. 

If you want to read more about Microsoft Defender Application Guard, I created a blog about this some time ago. 

https://call4cloud.nl/2021/06/wdac-or-the-unexpected-virtue-of-ignorance

2.3 ASR Rules 

It’s not really a part of this blog but I need to mention it when we are talking about credential protection. When protecting credentials, you also could configure an ASR rule.  “block credential stealing from the Windows local security authority subsystem” 

This rule prevents untrusted processes from having direct access to LSASS memory. Just like with the RunasPPL, whenever you want to access LSASS, you will need to call OpenProcess and specify the PROCESS_VM_READ access flag. So, you could say an ASR rule and the RunasPPL are doing the same, but both use their own mechanism. But beware, enabling this ASR can give you some false alerts! 

3. Enable CG with Intune Endpoint Security 

Open Intune and start creating a new Endpoint Security Account Protection Policy. 

It’s very easy to turn it on with Intune, you only need to configure the settings as I show below: 

Looking at the settings like shown above UEFI without lock, means that someone could turn off Credential Guard remotely by switching off the feature via the registry. So please enable with UEFI lock.  

4. Enable CG with Intune Settings Catalog

You could also turn on Credential Guard with a Settings Catalog when you don’t want to configure CG from an Endpoint Security Account protection policy.

As shown below, just search for

• Credential Guard
• Enable Virtualization Based Security

And turn them on as shown below!

5. Enable CG with PowerShell  

When we choose to enable CG with PowerShell, we have got 2 options 

Option 1: Ps readiness tool: 

Use this tool to see if your hardware is ready for Device Guard and Credential Guard. The nice thing about this wonderful tool, you could also use it to enable Device Guard or Credential Guard. 

Set-executionpolicy unrestricted -force 
$ReadinessToolsURL = 'https://download.microsoft.com/download/B/D/8/BD821B1F-05F2-4A7E-AA03-DF6C4F687B07/dgreadiness_v3.6.zip' 
$DGreadinessFolder = (Split-Path $ReadinessToolsURL -Leaf).Replace('.zip','') 
$DownloadPath = "$env:USERPROFILE\Downloads" 
$OutFileName = 'DGReadiness.zip' 
$DestinationUnzipPath = 'C:\AdminTools\' 
$OutFile = (Join-Path -Path $DownloadPath -ChildPath $OutFileName) 
Invoke-WebRequest -UseBasicParsing -Uri $ReadinessToolsURL -OutFile $OutFile 
Expand-Archive -Path $OutFile -DestinationPath $DestinationUnzipPath -force 
$file = Get-ChildItem -Path (Join-Path -Path $DestinationUnzipPath -ChildPath $DGreadinessFolder) -Filter "*.ps1" | Select-Object -ExpandProperty FullName 
Start-Process powershell.exe -Verb RunAs -ArgumentList "$file -enable -cg" -Wait 

Option 2: Just a PowerShell Script and some registry changes 

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "EnableVirtualizationBasedSecurity" -PropertyType "DWORD" -Value 1 -Force 
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "RequirePlatformSecurityFeatures" -PropertyType "DWORD" -Value 1 -Force 
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "Locked" -PropertyType "DWORD" -Value 1 -Force 
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "Unlocked" -PropertyType "DWORD" -Value 0 -Force 
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "HypervisorEnforcedCodeIntegrity" -PropertyType "DWORD" -Value 1 -Force 
If (!(Test-Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity")) { 
  New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" -Force 
} 
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" -Name "Enabled" -PropertyType "DWORD" -Value 1 -Force 
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" -Name "Locked" -PropertyType "DWORD" -Value 1 -Force 
 
New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\LSA" -Name "LsaCfgFlags" -PropertyType "DWORD" -Value 1 -Force 

6. What is Remote Credential Guard?

Remote Credential Guard sort of extends the current Credential Guard, so I guess I also need to add RCG to this blog. Remote Credential Guard will ensure the authentication tickets are protected when you connect to Remote Desktop Session Hosts. Windows Defender Remote Credential Guard helps you protect your credentials over a Remote Desktop connection by redirecting Kerberos requests back to the device that’s requesting the connection.  

It also provides single sign-on experiences for Remote Desktop sessions. But beware, Windows Defender Remote Credential Guard will be using Kerberos for authentication. This means you must connect to the hostname of the Remote Desktop Host server instead of the Ip address 

Remote desktop connections with and without remote credential guard enabled 

Looking at the picture above, you will notice that the Windows Defender Remote Credential Guard blocks NTLM (allowing only Kerberos), prevents Pass-the-Hash (PtH) attacks, and prevents the use of credentials after disconnection. So you need to make sure the server and client authenticate using Kerberos! 

Enabling this feature is a lot easier than enabling Credential Guard itself. The only thing you need to launch this Powershell script on the remote host – – equals positive 

$Params = @{
 Path = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa";
 Name = "DisableRestrictedAdmin";
 PropertyType;= "DWORD";
 Value = 0;
}

New-ItemProperty @Params -Force 

Looking at the script, you will notice it will disable it, and disabling disabled settings would just enable it! Something like – – equals positive! 

When you want to start connecting to the Remote desktop host server, The only thing you need to do is add a parameter to mstsc.exe: 

mstsc.exe /remoteGuard 

Or change this Group policy setting: Configuration -> Administrative Templates -> System -> Credentials Delegation 

Restrict delegation of credentials to remote servers to Require Remote Credential Guard  

7. The Problem:  

In one of my earlier blogs in the Endpoint Security series, I showed you how to implement Device application guard. However, I guess I forgot to “recycle” the VM itself, so there were some leftovers in the registry, which caused the enabling of Credential guard to fail. 

When I first turned it on with Intune it looked like everything was good to go. All was green and succeeded.

But it wasn’t, so I also created a custom policy (CSP), hoping to get some more information…. Again, everything succeeded!  But still, it wasn’t working.  

So I decided to also run the PowerShell option 1 I mentioned earlier: readiness tool. And after a few seconds, it was working as it should.  

8. Results when Credential Guard should be working 

We have got multiple options to choose from when we want to determine if CG is working as it should. 

Registry: 

HKLM\System\CurrentControlSet\Control\Deviceguard

Powershell: 

Launch a new PowerShell session and type this command: 

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard 

Looking at the output above, there are 2 important settings we need to keep in mind.

Task Manager 

You could open Process Explorer or Task Manager to determine if CG is running. There should be a process called: Lsalso.exe 

But opening/double-clicking the process will not give you much information because there is invalid access. 

Msinfo32 

Of course, the information about CG is also found when you open MSinfo32.exe 

DgReadiness Tool 

With this tool, you can enable Credential Guard, and of course, you could check if it’s enabled. So let’s use the tool again but this time with the -ready switch 

Mimikatz 

I will dedicate a whole part to this one because the only method you could be 100% sure credential guard is working is to test it with Mimikatz. Do you know why? In the past, If you had Windows 10 pro devices instead of Enterprise devices, you could enable Credential Guard just like I have shown you. All of the other tests will tell you it’s working but when you have windows 10 devices it’s not!!!! The only way to tell is with mimikatz. 

If you have enabled Credential Guard and your passwords are still showing as plain text, there is definitely something wrong!

In Windows 10  Enterprise Credential guard encrypts the credentials and therefore, not readable by mimikatz (LSA Isolated Data) 

Before 2021, In Windows 10 Pro, however, the NTLM hash was not encrypted and can therefore be stolen and abused for lateral movement. Luckily, that is fixed, but the Readiness tool I showed you earlier still mentions you will need to have an Enterprise version.

9. Testing Credential Guard with Mimikatz 

But I really wanted to show you how you could test it with MimiKatz, so I created a new VM.  

First, I downloaded Mimikatz on a brand new device 

https://github.com/gentilkiwi/mimikatz/releases/download/2.2.0-20210709/mimikatz_trunk.zip

For this test, I obviously disabled Windows Defender. Otherwise, there is nothing to test with. 

After disabling Windows Defender, I opened an administrative PowerShell session and launched Mimi Katz 

You will need some debug privilege, so make sure you request them first with privilege::debug. 

Now let’s show the logonpassword without Credential Guard enabled! 

I opened a file share and entered my credentials. As shown below, the password is visible in plain text   

Let’s enable Credential Guard as I have shown earlier, and test it again 

Let’s fire up mimikatz again and let’s see if we get some other results now! 

That’s more like it! A nice encrypted password

If you want to make it more difficult for the attacker to extract some hashes just remove the administrator’s group from debug program privilege with ntrights (SeDebugPrivilege) 

NTrights – User Privileges – Windows CMD – SS64.com 

But beware! Some programs (SQL installations will need it!) I tried an administrative template to change this privilege, but I guess it was not meant to remove users’ groups.  

10. Disabling Credential Guard 

Disabling CG is very easy when it has not been enabled with UEFI lock. In the same policy, you can change the setting from enabled to disabled. 

When you configured  “with UEFI lock” option, you need to beware when removing Credential Guard, you also need to update the BCDStore.  You can do this with this PowerShell script

Start-Process -FilePath "mountvol.exe" -ArgumentList "x: /s" -PassThru -Wait

Copy-Item -Path "$env:systemroot\System32\SecConfig.efi" -Destination "X:\EFI\Microsoft\Boot\SecConfig.efi" -Force
Start-Process -FilePath "bcdedit.exe" -ArgumentList'/create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /applicationosloader' -PassThru -Wait
Start-process -FilePath "bcdedit.exe" -ArgumentList'/set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"' -PassThru -Wait
Start-Process -FilePath "bcdedit.exe" -ArgumentList'/set {bootmgr}bootsequence{0cb3b571-2f2e-4343-a879-d86a476d7215}' -PassThru -Wait
Start-Process -FilePath "bcdedit.exe" -ArgumentList'/set {0cb3b571-2f2e-4343-a879-d86a476d7215}loadoptionsDISABLE-LSA-ISO,DISABLE-VBS' -PassThru -Wait
Start-Process -FilePath "bcdedit.exe" -ArgumentList'/set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:' -PassThru -Wait
Start-Process -FilePath "bcdedit.exe" -ArgumentList'/sethypervisorlaunchtypeoff' -PassThru -Wait
Start-Process -FilePath "mountvol.exe" -ArgumentList"x: /d" -PassThru -Wait

Conclusion 

Even when properly configured and implemented,  Credential Guard has its downsides as it does not protect you against attack strategies where administrative permissions are obtained. With mimikatz and his own security support provider (SSP) you can intercept the credentials at user logon. But not implementing credential guard is of course not the best practice! Wouldn’t it be cool to combine some of the options?  

Please ensure all your devices are Windows 10 Enterprise before enabling Credential Guard. It’s madness. Just like with Applocker… you can enable it but it’s not going to be enforced!  

If you are interested in my other blogs about the endpoint security

Endpoint Security Series – Call4Cloud

And if you are not interested in the endpoint security series, I also write some other stuff:

• Troubleshooting the Properties Catalog Error 2147749902:
• Life is like a box of Device Inventory Properties.
• Under the hoods of the Windows Device Inventory Agent
• The 0x80072F9A We Start From
• Fixing Time Zone Issues in Windows Autopilot