Windows 11 – Credential Guard

Come funziona, come verificarlo e configurarlo, e quali scenari smettono di funzionare quando è attivo

Credential Guard è la funzionalità di Windows che protegge le credenziali di dominio dal furto: gli hash NTLM, i Ticket Granting Ticket (TGT) Kerberos e le credenziali di dominio salvate dalle applicazioni vengono spostati in un ambiente isolato, irraggiungibile anche da un malware con privilegi di amministratore. Da Windows 11 22H2 è attivo per impostazione predefinita sui dispositivi idonei, e proprio per questo è importante sapere come verificarlo, come configurarlo e quali scenari smettono di funzionare quando è attivo.

Indice

• 1. Come funziona Credential Guard
  • 1.1 Sicurezza basata sulla virtualizzazione (VBS)
  • 1.2 LSA e LSA isolato (LsaIso.exe)
  • 1.3 Protezioni VSM e TPM
• 2. Requisiti e attivazione predefinita
  • 2.1 Requisiti
  • 2.2 Abilitazione predefinita
• 3. Configurare Credential Guard
  • 3.1 Tramite criteri di gruppo
  • 3.2 Tramite registro di sistema
• 4. Verificare se Credential Guard è attivo
  • 4.1 Informazioni di sistema
  • 4.2 PowerShell
  • 4.3 Visualizzatore eventi
• 5. Impatti e scenari non supportati
  • 5.1 Protocolli non compatibili con il Single Sign-On
  • 5.2 Wi-Fi e VPN
  • 5.3 Kerberos e delega
  • 5.4 Security Support Provider non Microsoft
  • 5.5 Credenziali salvate in Gestione credenziali
  • 5.6 Cancellazione del TPM
  • 5.7 Chiave pubblica dei dispositivi di dominio
• 6. Limiti della protezione
• 7. Riepilogo e risoluzione dei problemi
  • 7.1 Strumenti e impostazioni
  • 7.2 Problemi comuni
• 8. Link utili

1. Come funziona Credential Guard

Credential Guard previene il furto di credenziali proteggendo:

• gli hash delle password NTLM;
• i Kerberos Ticket Granting Ticket (TGT);
• le credenziali di dominio memorizzate dalle applicazioni (ad esempio in Gestione credenziali).

L'accesso non autorizzato a questi segreti consentirebbe attacchi di tipo pass-the-hash o pass-the-ticket, in cui l'attaccante si autentica su altri computer della rete riutilizzando l'hash o il ticket rubato, senza conoscere la password.

1.1 Sicurezza basata sulla virtualizzazione (VBS)

Credential Guard si basa sulla Virtualization-based Security (VBS): l'hypervisor di Windows crea una regione di memoria isolata dal resto del sistema operativo, nella quale viene eseguito solo software di sistema privilegiato e firmato. I benefici principali:

1.2 LSA e LSA isolato (LsaIso.exe)

Nelle versioni precedenti di Windows i segreti venivano conservati nella memoria del processo Local Security Authority (lsass.exe), da cui strumenti di attacco come i dumper di memoria potevano estrarli. Con Credential Guard attivo, il processo LSA del sistema operativo comunica con un componente chiamato LSA isolato (LsaIso.exe), incaricato di memorizzare e proteggere queste informazioni. I dati gestiti dall'LSA isolato sono protetti tramite VBS e non sono accessibili al resto del sistema operativo; la comunicazione tra LSA e LSA isolato avviene tramite chiamate di procedura remota (RPC).

Per motivi di sicurezza l'LSA isolato non ospita alcun driver di dispositivo: contiene solo l'insieme minimo di componenti del sistema operativo indispensabili per le funzioni di sicurezza. Tutti questi file binari sono firmati con certificati considerati attendibili da VBS, e le firme vengono verificate prima che i file vengano eseguiti nell'ambiente protetto.

1.3 Protezioni VSM e TPM

Le credenziali protette da Credential Guard vengono custodite in memoria e isolate a runtime dall'hypervisor tramite la Virtual Secure Mode (VSM). Sull'hardware recente che supporta TPM 2.0, i dati VSM persistenti sono protetti da una chiave specifica, la VSM master key, a sua volta protetta dal TPM: in questo modo la chiave e i segreti custoditi da Credential Guard sono accessibili solo in un ambiente considerato attendibile.

In genere Credential Guard non conserva in modo persistente i dati di autenticazione come hash NTLM e TGT: queste informazioni vanno perse a ogni riavvio e vengono rigenerate quando l'utente accede di nuovo. La loro protezione quindi non dipende dalla VSM master key né dal TPM. Dipendono invece dalla VSM master key i dati persistenti, come le credenziali di dominio salvate in Gestione credenziali (vedi cancellazione del TPM).

La master key di VBS potrebbe non essere protetta dal TPM quando:

• Secure Boot è disattivato;
• nel firmware non è disponibile un TPM.

2. Requisiti e attivazione predefinita

2.1 Requisiti

Perché Credential Guard possa essere eseguito, il dispositivo deve supportare la sicurezza basata sulla virtualizzazione:

• processore a 64 bit con estensioni di virtualizzazione (Intel VT-x o AMD-V) e SLAT, abilitate nel firmware;
• firmware UEFI con Secure Boot (fortemente consigliato);
• TPM 1.2 o 2.0, discreto o firmware, per legare la master key di VBS all'hardware, come descritto in sezione 1.3 (consigliato);
• edizione di Windows che include Credential Guard: Enterprise o Education, con licenza Enterprise E3/E5 o Education A3/A5. Non è disponibile su Windows Pro e Pro Education/SE;
• nelle macchine virtuali Hyper-V, VM di seconda generazione.

2.2 Abilitazione predefinita

A partire da Windows 11 versione 22H2 e da Windows Server 2025, Credential Guard è abilitato per impostazione predefinita sui dispositivi uniti a un dominio che soddisfano i requisiti di licenza, hardware e software e che non sono domain controller. L'abilitazione predefinita attiva automaticamente anche VBS. L'abilitazione predefinita avviene senza blocco UEFI: può quindi essere disattivata da remoto tramite criteri di gruppo o registro (vedi sezione 3).

• Le configurazioni esplicite (GPO, registro, MDM) hanno la priorità sullo stato predefinito e vengono applicate dopo il riavvio.
• Se prima dell'aggiornamento Credential Guard era stato disattivato manualmente, resta disattivato anche dopo l'aggiornamento a una versione in cui è attivo di default.

3. Configurare Credential Guard

Puoi abilitare o disabilitare Credential Guard con i criteri di gruppo (consigliato per i dispositivi in dominio) oppure tramite registro. In entrambi i casi la modifica diventa effettiva dopo il riavvio; verifica poi lo stato come descritto in sezione 4.

3.1 Tramite criteri di gruppo

Per configurare un singolo dispositivo usa l'Editor Criteri di gruppo locali (gpedit.msc). Per più dispositivi uniti ad Active Directory crea o modifica una GPO collegata alla OU dei computer, con questa impostazione:

Le opzioni del menu Credential Guard Configuration:

Nella stessa impostazione, il campo Select Platform Security Level consente di richiedere Secure Boot oppure Secure Boot and DMA Protection.

3.2 Tramite registro di sistema

Su un PC non gestito da GPO puoi usare tre valori DWORD:

Abilitazione senza blocco con Secure Boot, da un prompt dei comandi con privilegi elevati:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v RequirePlatformSecurityFeatures /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 2 /f

Riavvia il PC per applicare la modifica.

Disattivazione (solo se Credential Guard è attivo senza blocco UEFI e non è gestito da GPO): imposta LsaCfgFlags a 0 sia nella chiave Lsa sia nella chiave dei criteri, poi riavvia:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard" /v LsaCfgFlags /t REG_DWORD /d 0 /f

Per controllare il valore impostato:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags

4. Verificare se Credential Guard è attivo

Controllare in Gestione attività se LsaIso.exe è in esecuzione non è un metodo affidabile per stabilire se Credential Guard protegge le credenziali. Usa invece uno degli strumenti seguenti.

4.1 Informazioni di sistema

1. Premi Start, digita msinfo32.exe e apri Informazioni di sistema.
2. Seleziona Risorse di sistema (System Summary).
3. Controlla che alla voce Servizi di sicurezza basata su virtualizzazione in esecuzione (Virtualization-based security Services Running) compaia Credential Guard.

4.2 PowerShell

Apri PowerShell con privilegi elevati ed esegui:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

Il comando restituisce l'elenco dei servizi VBS in esecuzione:

Se nell'output compare 1, Credential Guard è attivo. Per una visione più completa, che include anche i servizi configurati e lo stato di VBS:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object SecurityServicesConfigured, SecurityServicesRunning, VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatus vale 0 se VBS non è abilitata, 1 se è abilitata ma non in esecuzione, 2 se è abilitata e in esecuzione. Credential Guard configurato (valore 1 in SecurityServicesConfigured) ma non in esecuzione indica di solito un requisito mancante: vedi sezione 2.1 e gli eventi 15–17.

4.3 Visualizzatore eventi

Per controlli periodici su più dispositivi puoi usare i criteri di controllo o query WMI. Sul singolo PC:

1. Apri il Visualizzatore eventi (eventvwr.exe).
2. Vai in Registri di Windows > Sistema.
3. Filtra per origine WinInit.

5. Impatti e scenari non supportati

Con l'evoluzione di Credential Guard le versioni più recenti di Windows possono interrompere scenari che prima funzionavano. Testa gli scenari operativi prima di aggiornare o abilitare Credential Guard su larga scala.

5.1 Protocolli non compatibili con il Single Sign-On

Con Credential Guard attivo, NTLMv1, MS-CHAPv2, Digest e CredSSP non possono utilizzare le credenziali della sessione: il Single Sign-On con questi protocolli non funziona. Le applicazioni possono comunque chiedere le credenziali all'utente o recuperarle dal Windows Vault, ma in quel caso le credenziali non sono protette da Credential Guard.

5.2 Wi-Fi e VPN

• Le connessioni Wi-Fi e VPN basate su MS-CHAPv2 (PEAP-MSCHAPv2, EAP-MSCHAPv2) non possono più usare le credenziali di accesso a Windows: l'utente deve digitare le credenziali, senza poterle salvare per gli accessi successivi.
• MS-CHAPv2 presenta rischi simili a NTLMv1: la soluzione consigliata è migrare all'autenticazione basata su certificati (PEAP-TLS o EAP-TLS).

5.3 Kerberos e delega

• I ticket di servizio Kerberos non sono protetti; il TGT sì.
• Con Credential Guard attivo, Kerberos non consente la delega non vincolata (unconstrained delegation) né la crittografia DES, indipendentemente dal tipo di credenziali (di sessione, salvate o richieste).
• CredSSP non può usare credenziali salvate o SSO: richiede le credenziali in chiaro sul dispositivo di destinazione. L'uso di CredSSP per la delega non è raccomandato.
• Usa Kerberos o Negotiate per l'autenticazione e la delega vincolata Kerberos (Kerberos Constrained Delegation) o la delega vincolata basata sulle risorse (Resource-Based Kerberos Constrained Delegation) per la delega: sono compatibili con Credential Guard e più sicure.

5.4 Security Support Provider non Microsoft

• Alcuni SSP/AP (Security Support Provider / Authentication Package) non Microsoft potrebbero non essere compatibili, perché non possono richiedere a LSA gli hash delle password.
• Le credenziali vengono comunque comunicate al momento dell'accesso o del cambio password.
• L'uso di API non documentate negli SSP/AP personalizzati non è supportato (es. KerbQuerySupplementalCredentialsMessage).
• Testa le implementazioni personalizzate prima di usarle in ambienti protetti da Credential Guard.

5.5 Credenziali salvate in Gestione credenziali

Gestione credenziali supporta tre tipi di credenziali: credenziali Windows, credenziali basate su certificato e credenziali generiche.

• Le credenziali di dominio salvate sono protette da Credential Guard.
• Le credenziali generiche (es. nome utente e password di siti web) non sono protette, perché le applicazioni richiedono la password in chiaro.
• Le credenziali Windows salvate dal client Desktop remoto non possono essere inviate agli host remoti.
• Le applicazioni che estraggono credenziali Windows non funzionano.
• Le credenziali di cui si esegue il backup dopo l'attivazione di Credential Guard non possono essere ripristinate: il backup va fatto prima dell'abilitazione.

5.6 Cancellazione del TPM

VBS usa il TPM per proteggere la propria chiave di cifratura (vedi sezione 1.3). Cancellando il TPM, la chiave e i dati salvati da VBS vengono persi definitivamente.

• Gestione credenziali non può più decifrare le credenziali Windows salvate: vengono eliminate e le applicazioni devono richiederle di nuovo.
• Le credenziali salvate nuovamente sono protette da Credential Guard.

5.7 Chiave pubblica dei dispositivi di dominio

• I dispositivi uniti ad Active Directory ricevono automaticamente una chiave pubblica vincolata.
• Credential Guard non può decifrare la chiave privata protetta: Windows usa la password dell'account computer per autenticarsi al dominio.
• Se un dispositivo è configurato per usare solo l'autenticazione con chiave pubblica, non potrà autenticarsi con password finché il criterio non viene disattivato.
• Alcuni controlli di accesso basati sui SID noti KEY TRUST IDENTITY e FRESH PUBLIC KEY IDENTITY potrebbero non funzionare.

6. Limiti della protezione

Credential Guard non protegge tutto. In questi scenari le credenziali restano esposte:

7. Riepilogo e risoluzione dei problemi

7.1 Strumenti e impostazioni

7.2 Problemi comuni

8. Link utili

• Microsoft Learn – How Credential Guard works
• Microsoft Learn – Credential Guard overview
• Microsoft Learn – Credential Guard: considerations and known issues
• Microsoft Learn – Configure Credential Guard (include la procedura per rimuovere il blocco UEFI)
• Windows Server – EAP-TLS User Certificate 802.1x Wireless Network