Credential Guard and the Protected Users Group: Hardening Against Credential Theft

What Are Credential Guard & Protected Users?

In traditional Windows environments, logging on to a workstation or server places your authentication materials directly into the user-mode address space of the Local Security Authority Subsystem Service (lsass.exe). This includes derived NTLM password hashes, Kerberos Ticket-Granting Tickets, and plaintext credentials cached for single sign-on. If an adversary compromises an endpoint and elevates privileges to local Administrator or NT AUTHORITY\SYSTEM, standard operating system protections fall away. The attacker reads LSASS process memory directly, extracts cached administrative tokens, and begins moving laterally across your network using Pass-the-Hash or Pass-the-Ticket techniques.

Think of your administrative credentials as high-value diamonds held inside a corporate branch office. In the default configuration, those diamonds are placed inside a wooden desk drawer in the manager’s office (the standard lsass.exe process). Anyone who acquires a master skeleton key to the office (local administrator privileges) can pry open the drawer and walk away with the prize.

Credential Guard solves this by moving the diamonds across town into an underground subterranean vault protected by independent armed security (Virtual Trust Level 1, running LSAIso.exe). When the office manager needs to sign a contract with a diamond’s seal, they submit the document through a secure pneumatic slot (an inter-process Remote Procedure Call). The guards inside the vault inspect the paperwork, apply the cryptographic stamp, and send back the result. Even if a hostile intruder demolishes the main office, the vault remains inaccessible.

Meanwhile, the Protected Users security group acts as an unbending corporate policy mandate: it dictates that the diamonds may never be transported in unarmoured vehicles (NTLM is prohibited), can never be entrusted to third-party couriers (Kerberos delegation is blocked), and any authorization badges issued for the diamonds automatically expire after four hours without extension.

How VBS Isolates LSASS

Credential Guard is built on Virtualization-Based Security (VBS), a core architectural capability of the Windows hypervisor. VBS partitions system memory into distinct virtual operating environments called Virtual Trust Levels (VTLs):

# Virtualization-Based Security (VBS) Memory Partitioning

  +-------------------------------------------------------------------------+
  |                        PHYSICAL HARDWARE LAYER                          |
  |  64-bit CPU (VT-x/AMD-V + SLAT)  |  IOMMU (VT-d)  |  UEFI Secure Boot   |
  +-------------------------------------------------------------------------+
                                       |
                                       v
  +-------------------------------------------------------------------------+
  |                          WINDOWS HYPERVISOR                             |
  +-------------------------------------------------------------------------+
            |                                                   |
            |                                                   |
            v                                                   v
  +-----------------------------------+   +---------------------------------+
  |      VTL 0: NORMAL WORLD          |   |     VTL 1: SECURE WORLD         |
  |  (Standard Windows OS Kernel)     |   |    (Isolated Secure Kernel)     |
  |                                   |   |                                 |
  |  - User applications              |   |  - Isolated LSA (LSAIso.exe)    |
  |  - Windows drivers                |   |  - Hypervisor Code Integrity    |
  |  - lsass.exe (Proxy process)      |   |  - Hardware-isolated secrets    |
  |                                   |   |    (NTLM hashes, Kerberos TGTs) |
  |       [lsass.exe]                 |   |          [LSAIso.exe]           |
  |            |                      |   |               ^                 |
  |            +------ Inter-VTL RPC -+---+---------------+                 |
  |                    Handshake      |   |                                 |
  +-----------------------------------+   +---------------------------------+

Under this architecture, the standard Windows kernel operates in Virtual Trust Level 0 (VTL 0). The isolated secure kernel, along with LSAIso.exe (Isolated LSA), runs in Virtual Trust Level 1 (VTL 1). Memory assigned to VTL 1 is protected using CPU Second Level Address Translation (SLAT) and Input-Output Memory Management Unit (IOMMU) hardware protections.

The consequence for offensive tooling is absolute: even code running in kernel mode (Ring 0) in VTL 0 cannot map, read, or manipulate memory belonging to VTL 1. When an attacker runs Mimikatz or invokes sekurlsa::logonpasswords on a Credential Guard-enabled host, the tool queries the proxy lsass.exe process in VTL 0 and encounters empty cryptographic structures. The actual master Kerberos session keys and NTLM password hashes never enter VTL 0 memory.

Protected Users Protocol Hardening

While Credential Guard hardens the local machine’s memory, attackers on the network can still attempt NTLM relaying, Kerberos ticket theft over long durations, or delegation hijacking if high-privilege users log in with standard domain account attributes.

The Protected Users security group (introduced in Windows Server 2012 R2 with schema object SID S-1-5-21-<Domain>-525) delivers domain-wide protocol hardening. Membership in this group activates non-configurable, immediate behavioural constraints across all domain-joined Windows endpoints and domain controllers:

Configuration: GUI & PowerShell

Deploying both defences requires configuring Virtualization-Based Security on your Windows endpoints and populating the Protected Users security group in Active Directory.

1. Enabling Credential Guard via Group Policy

In enterprise environments, enable Credential Guard across computer accounts using Group Policy:

1. Open the Group Policy Management Console (gpmc.msc) and edit or create a GPO targeting your administrative workstations and servers (e.g., GPO-Sec-CredentialGuard).
2. Navigate to: Computer Configuration > Administrative Templates > System > Device Guard.
3. Double-click Turn On Virtualization Based Security and set it to Enabled.
4. Under Select Platform Security Level, choose Secure Boot and DMA Protection (or Secure Boot if hardware DMA protection is absent).
5. Under Credential Guard Configuration, choose Enabled without lock (recommended for pilot rollouts) or Enabled with UEFI lock (maximum security; prevents tampering via registry or unauthorized firmware modification).
6. Under Secure Launch Configuration, select Enabled to utilize System Guard Secure Launch if supported by your silicon.

2. Enabling Credential Guard via PowerShell & Registry

For standalone servers, automated VM templates, or automated configuration baselines, you can enable Virtualization-Based Security directly through the registry:

# 1. Enable Virtualization-Based Security
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" `
  -Name "EnableVirtualizationBasedSecurity" -Value 1 -Type DWord

# 2. Configure VBS Platform Security (1 = Secure Boot, 2 = Secure Boot + DMA)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" `
  -Name "RequirePlatformSecurityFeatures" -Value 2 -Type DWord

# 3. Enable Credential Guard (1 = Enabled without lock, 2 = Enabled with UEFI lock)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
  -Name "LsaCfgFlags" -Value 1 -Type DWord

3. Adding Tier-0 and Tier-1 Admins to Protected Users

Active Directory accounts representing human administrators should be placed into the Protected Users security group. Use the Active Directory PowerShell module:

# 4. Enumerate current members of Protected Users
Get-ADGroupMember -Identity "Protected Users" |
Select-Object Name, SamAccountName, ObjectClass

# 5. Add a privileged administrative account to Protected Users
Add-ADGroupMember -Identity "Protected Users" -Members "admin-jdoe"

# 6. Verify that the user cannot be delegated
Get-ADUser -Identity "admin-jdoe" -Properties DoesNotRequirePreAuth, msDS-User-Account-Control-Computed

Operational Verification Commands

After applying configuration and restarting endpoints, use the following operational commands to confirm that Credential Guard is active and that the Protected Users policies are taking effect:

# 1. Query Win32_DeviceGuard for running virtualization security services
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
Select-Object @{N="VBS_Status";E={$_.VirtualizationBasedSecurityStatus}},
              @{N="Configured_Services";E={$_.SecurityServicesConfigured -join ','}},
              @{N="Running_Services";E={$_.SecurityServicesRunning -join ','}} |
Format-List

# Note: In Running_Services, '1' indicates Credential Guard is active, '2' indicates HVCI.

# 2. Verify Credential Guard status via systeminfo / msinfo32
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LsaCfgFlags"

# 3. Verify Kerberos Ticket-Granting Ticket lifetime for the current user
klist tickets

# 4. Check for NTLM authentication block events in the Security event log (Event ID 4625)
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id      = 4625
} -MaxEvents 10 |
Where-Object { $_.Message -match "0xc000006e|0xc0000413" } |
Format-Table TimeCreated, Message -Wrap

# 5. Check Kerberos TGT issuance in the Security event log on Domain Controllers (Event ID 4768)
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id      = 4768
} -MaxEvents 10 |
Format-List TimeCreated, Message

When inspecting klist tickets for a Protected Users account, observe the End Time of the krbtgt ticket: it will be exactly 4 hours from the Start Time, with Renew Time showing the exact same timestamp (indicating renewal is blocked).

Gotchas & Administrative Traps

Deploying Credential Guard and Protected Users without operational planning can cause unexpected service disruptions. Keep the following operational boundaries in mind:

1. Never Add Service Accounts or Computer Accounts

The most destructive mistake in enterprise administration is placing managed service accounts, computer accounts, or service identities into the Protected Users security group. Applications running background services, scheduled tasks, SQL Server engines, or IIS application pools often rely on Kerberos delegation, long-lived service tickets, or NTLM fallback when communicating across untrusted boundaries. Capping ticket lifetime to 4 hours with no renewal causes services to collapse once their initial ticket expires.

2. Maintain Separate Break-Glass Emergency Accounts

Every Active Directory forest requires emergency “break-glass” accounts for disaster recovery scenarios when domain controllers are degraded or offline. Do not place break-glass accounts into the Protected Users group. Because members cannot cache credentials or authenticate using offline credential stores, an administrator using a Protected Users account will be unable to log on to local server consoles if network connectivity to a domain controller is interrupted.

3. NTLM Legacy Fallback Failures

If your administrative staff access internal web applications, network management appliances, or storage appliances that do not support Kerberos (lacking Service Principal Names or operating on IP address URLs), authentication will fail completely for Protected Users accounts. Ensure that all administrative jump boxes and management interfaces have proper DNS names, registered SPNs, and negotiate Kerberos before enforcing group membership.

4. Windows 11 22H2+ Default Behavior

Starting with Windows 11 Enterprise version 22H2, Credential Guard is enabled by default on all systems that meet minimum hardware requirements. While this provides out-of-the-box protection, organizations migrating to Windows 11 must verify third-party security agents, smart card drivers, and custom security support providers (SSPs) for compatibility with Virtual Trust Level 1 isolation.

Troubleshooting Cheat Sheet

Use this reference table to resolve common operational failures encountered during Credential Guard and Protected Users deployments:

Final Thoughts

Securing enterprise identity requires abandoning the outdated assumption that physical administrative workstations can be defended by conventional operating system permissions alone. When an attacker gains administrator rights on an endpoint, software-only defenses fail. Credential Guard changes the equation by enlisting the CPU hypervisor as an uncompromising cryptographic barrier, ensuring that LSASS secrets remain isolated in hardware.

Coupled with the Protected Users security group, which strips away legacy protocols and limits ticket lifetimes at the domain boundary, you establish a resilient defense-in-depth posture. By applying these capabilities to Tier-0 and Tier-1 human administrators, you shut down lateral movement pathways and neutralize pass-the-hash attacks before they begin.