Credential Guard è una funzionalità che ha l’obbiettivo di impedire attacchi finalizzati al di furto di credenziali proteggendo gli hash delle password NTLM, i ticket di concessione di ticket Kerberos e le credenziali archiviate dalle applicazioni come credenziali di dominio.
In estrema sintesi Credential Guard usa la Virtualization-based Security (VBS) per isolare i secrets in modo che solo il software di sistema possa accedervi.
Per approfondire come funziona Credential Guard si veda How Credential Guard works | Microsoft Learn:
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.
In linea generale a partire da Windows 11 22H2 e Windows Server 2025, Credential Guard è abilitato per impostazione predefinita nei sistemi che soddisfano i requisiti hardware, ma occorre fare alcune precisazioni per definire meglio quando Credential Guard viene abilitato per default, come riportato in Considerations and known issues when using Credential Guard | Microsoft Learn:
Starting in Windows 11, version 22H2, and Windows Server 2025, eligible devices that didn’t disable Credential Guard, have it enabled by default. This affects all devices on Enterprise (E3 and E5) and Education licenses, and some Pro licenses, as long as they meet the minimum hardware requirements.
All Windows Pro devices that previously ran Credential Guard on an eligible license and later downgraded to Pro, and which still meet the minimum hardware requirements, receive default enablement.
Devices running Windows 11 Pro/Pro Edu 22H2 or later may have Virtualization-based Security (VBS) and/or Credential Guard automatically enabled if they meet the other requirements for default enablement, and have previously run Credential Guard. For example if Credential Guard was enabled on an Enterprise device that later downgraded to Pro.
To determine whether the Pro device is in this state, check if the following registry key exists: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\IsolatedCredentialsRootSecret.
Per informazioni sui requisiti hardware di Credential Guard si veda Credential Guard overview | Microsoft Learn:
Credential Guard requires the features:
- Virtualization-based security (VBS)
- Secure Boot
While not required, the following features are recommended to provide additional protections:
- Trusted Platform Module (TPM), as it provides binding to hardware. TPM versions 1.2 and 2.0 are supported, either discrete or firmware
- UEFI lock, as it prevents attackers from disabling Credential Guard with a registry key change
L’abilitazione di Credential Guard, come indicato in Considerations and known issues when using Credential Guard | Microsoft Learn, comporta l’impossibilità di connettersi automaticamente ad endpoint WiFi che utilizzano il protocollo MSCHAPv2 a causa dell’impossibilità di utilizzare l’NTLM classic authentication (NTLMv1) per la single-sign-on (SSO), come ad esempio la connessione wifi tramite l’account computer:
Wi-fi and VPN considerations
When Credential Guard is enabled, you can no longer use NTLM classic authentication (NTLMv1) for single-sign-on (SSO). You’ll be forced to enter your credentials to use these protocols and can’t save the credentials for future use.
If you’re using WiFi and VPN endpoints that are based on MS-CHAPv2, they’re subject to similar attacks as for NTLMv1.
For WiFi and VPN connections, it’s recommended to move from MSCHAPv2-based connections (such as PEAP-MSCHAPv2 and EAP-MSCHAPv2), to certificate-based authentication (such as PEAP-TLS or EAP-TLS).
Single sign-on for Network services breaks after upgrading to Windows 11, version 22H2 or Windows Server 2025
Devices that use 802.1x wireless or wired network, RDP, or VPN connections that rely on insecure protocols with password-based authentication are unable to use SSO to sign in and are forced to manually reauthenticate in every new Windows session when Credential Guard is running.
Applications and services are affected by the issue when they rely on insecure protocols that use password-based authentication. Such protocols are considered insecure because they can lead to password disclosure on the client or the server, and Credential Guard blocks them. Affected protocols include:
– Kerberos unconstrained delegation (both SSO and supplied credentials are blocked)
– Kerberos when PKINIT uses RSA encryption instead of Diffie-Hellman (both SSO and supplied credentials are blocked)
– MS-CHAP (only SSO is blocked)
– WDigest (only SSO is blocked)
– NTLM v1 (only SSO is blocked)Note: Since only SSO is blocked for MS-CHAP, WDigest, and NTLM v1, these protocols can still be used by prompting the user to supply credentials.
Quindi se si riscontrano problemi di connessione al WiFi in Windows 11 per capire se potrebbero essere correlati all’abilitazione di Credential Guard è possibile fare le verifiche suggerite in Considerations and known issues when using Credential Guard | Microsoft Learn:
MS-CHAP and NTLMv1 are relevant to the SSO breakage after the Windows 11, version 22H2 update. To confirm if Credential Guard is blocking MS-CHAP or NTLMv1, open the Event Viewer (eventvwr.exe) and go to Application and Services Logs\Microsoft\Windows\NTLM\Operational. Check the following logs:
Event ID (type) 4013 (Warning)
Description
<string
id=”NTLMv1BlockedByCredGuard”
value=”Attempt to use NTLMv1 failed.
Target server: %1%nSupplied user: %2%nSupplied domain: %3%nPID
of client process: %4%nName
of client process: %5%nLUID
of client process: %6%nUser identity
of client process: %7%nDomain name
of user identity of client process: %8%nMechanism OID: 9%n%n
This device doesn’t support NTLMv1.
/>Event ID (type) 4014 (Error)
Description
<string
id=”NTLMGetCredentialKeyBlockedByCredGuard”
value=”Attempt to get credential key by call package blocked by Credential Guard.%n%n
Calling Process Name: %1%nService Host Tag: %2″
/>
Io ho riscontrato l’issue in sistemi Windows 11 Enterprise LTSC versione 24H2.
Come indicato da Microsoft l’approccio più corretto per risolvere il problema è configurare l’endpoint WiFi per l’utilizzo dell’autenticazione basata su certificato abbandonando quindi PEAP-MSCHAPv2 e EAP-MSCHAPv2 per protocolli di autenticazione come PEAP-TLS o EAP-TLS.
Se però nell’immediato non è possibile modificare i protocolli di autenticazione dell’endpoint WiFi l’alternativa temporanea è quella di disabilitare la funzionalità Credential Guard.
Per disabilitare Credential Guard, come riportato in Configure Credential Guard | Microsoft Learn, è possibile utilizzare la group policy Configurazione computer\Modelli amministrativi\Sistema\Device Guard\Attivare la Sicurezza basata sulla virtualizzazione.
Si noti che la GPO permette di configurare la sicurezza basata su virtualizzazione (VBS) di cui Credential Guard è una componente e, come indicato in Considerations and known issues when using Credential Guard | Microsoft Learn, Credential Guard non ha policy per protocollo o per applicazione e quindi può solo essere attivato o disattivato.
Di seguito come impostare la GPO in modo da disabilitare esclusiavamente Credential Guard lasciando le altre funzionalità relative alla sicurezza basata su virtualizzazione (VBS) ai valori di default. Si noti che dopo l’applicazione della GPO il sistema deve essere riavviato affichè la disabilitazione della funzionalità Credential Guard abbia effetto.
Dai test che ho effettuato occorre fare alcune considerazioni sul fatto che tale GPO è di tipo “tattooing” ovvero se rimossa non riporta il sistema alle condizioni inziali. Questo è dovuto al fatto che applicando la GPO vengono impostate chiavi in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard che verranno rimosse quando la GPO viene rimossa, ma vengono anche fatte impostazioni in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa e HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\KeyGuard\Status che non vengono rimosse quando la GPO non viene più applicata.
Questo è un aspetto di cui tenere conto se la disabilitazione della funzionalità Credential Guard è temporanea come dovrebbe essere. Rimuovendo l’applicazione della GPO la funzionalità Credential Guard non tornerà attiva a meno di non intervenire sulla chiavi di registro che non sono state ripristinate nello stato in cui erano per default prima dell’applicazione della GPO.
Di seguito le chiavi di registro che confrontando due sistemi Windows 11 Enterprise LTSC versione 24H2, uno a cui la GPO era applica e poi rimossa e l’altro su cui non è mai stata applicata la GPO, risultano modificate o aggiunte anche quando la GPO non è più applicata.
- Viene aggiunta nella chiave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa il valore REG_DWORD LsaCfgFlags impostato al valore 0.
- Sempre nella chiave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa il valore REG_DWORD LsaCfgFlagsDefault viene impostato a 0, mentre il valore originale era 2.
- Nella chiave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\KeyGuard\Status il valore REG_DWORD CredGuardEnabled viene impostato a 0, mentre il valore originale era 1.
Per verificare se Credential Guard è attivo è possibile utilizzare 3 modi come indicato in Configure Credential Guard | Microsoft Learn.
Il primo è quello di utilizzare l’applicazione System Information (msinfo32.exe), di seguito come appare l’output dell’applicazione su un sistema Windows 11 Enterprise LTSC versione 24H2 in cui la sicurezza basata su virtualizzazione (VBS) è impostata ai valori di default e quindi Credential Guard risulta abilitata confrontato con l’output dell’applicazione di un sistema Windows 11 Enterprise LTSC versione 24H2 su cui è stata applicata la GPO descritta precedentemente per disabilitare Credential Guard.
Il secondo modo per verificare se Credential Guard risulta abilitato è quello di ricorre a query Powershell. Per ottenere informazioni su Device Guard in generale è possibile usare la seguente query:
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
Per ottenere informazioni sulle funzionalità di Device Guard in esecuzione è possibile usare, invece, la seguente query, se Credential Guard è in esecuzione la query deve ritornare il valore 1:
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
Per l’interpretazione dei valori si veda Enable memory integrity | Microsoft Learn.
Di seguito l’output delle query powershell eseguite su su un sistema Windows 11 Enterprise LTSC versione 24H2 in cui la sicurezza basata su virtualizzazione (VBS) è impostata ai valori di default e quindi Credential Guard risulta abilitata.
Di seguito, invece, l’output delle query powershell eseguite su su un sistema Windows 11 Enterprise LTSC versione 24H2 su cui è stata applicata la GPO descritta precedentemente per disabilitare Credential Guard.
Il terzo modo per controllare o meno se Credential Guard risulta abilitato e in esecuzione è quello di verificare la presenza di specifici eventi nel log di sistema, per il dettaglio degli eventi da verificare si veda Configure Credential Guard | Microsoft Learn.
La verifica nel Task Manager che il processo LsaIso.exe sia in esecuzione non è un metodo raccomandato da Microsoft come indicato in Configure Credential Guard | Microsoft Learn:
Checking Task Manager if LsaIso.exe is running isn’t a recommended method for determining whether Credential Guard is running. Instead, use one of the following methods:
- System Information
- PowerShell
- Event Viewer
Conclusioni
Come detto precentemente la disabilitazione di Credential Guard dovrebbe essere usata solo temporaneamente in particolar modo se la problematica è legata all’uso di NTLMv1 in quando NTLM è stato deprecato nel Giugno 2024, a riguardo dsi vedano:
- Deprecated features in the Windows client | Microsoft Learn
- Resources for deprecated features in the Windows client | Microsoft Learn
- Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025 | Microsoft Support
Per ulteriori approfondimenti si veda anche l’articolo Credential Guard, Virtualization-based security (VBS) e Windows Defender Application Control (WDAC) pubblicato su ICTPower.
Nel caso Credential Guard sia abilitato con UEFI Lock non è possibile disabilitarlo applicando la GPO descritta, ma occorre seguire la procedura descritta in Configure Credential Guard | Microsoft Learn.