Credential Guard disabilitato dopo aggiornamento: verificare e correggere

Che cosa significa Credential Guard disabilitato dopo aggiornamento?

Credential Guard disabilitato dopo aggiornamento può essere una configurazione ereditata, anche su una versione di Windows che abilita la funzione per impostazione predefinita. Un aggiornamento idoneo non cancella una precedente decisione esplicita di disabilitarla. Prima di considerare un sistema operativo attuale come prova della protezione delle credenziali, verificate l'edizione del computer, la cronologia di distribuzione, i criteri e i servizi in esecuzione. La guida alla configurazione di Microsoft documenta questa eccezione persistente.

Credential Guard isola determinati segreti del dominio tramite la sicurezza basata sulla virtualizzazione (VBS). Il compito pratico consiste nello stabilire se tale isolamento è in esecuzione sui dispositivi in cui gli utenti del dominio accedono. Un criterio di distribuzione e un aggiornamento riuscito del sistema operativo rispondono a domande diverse rispetto a una verifica dello stato in esecuzione.

Questa guida riflette le pagine Microsoft Learn consultate il 3 ottobre 2026. Riguarda i dispositivi Windows 11 idonei dalla versione 22H2 e i membri del dominio Windows Server 2025 idonei. I comandi seguenti sono ripresi dalla documentazione; non sono stati eseguiti su un parco Windows per questo articolo. Non viene affermata alcuna prevalenza delle eccezioni ereditate.

Come funziona l'abilitazione predefinita

La panoramica di Credential Guard di Microsoft descrive l'abilitazione predefinita a partire da Windows 11 22H2 e Windows Server 2025. L'introduzione la inquadra nei sistemi idonei aggiunti a un dominio che non sono controller di dominio; le condizioni specifiche per Windows elencano licenze, idoneità hardware e software e assenza di una disabilitazione esplicita. Mantenete queste condizioni nella revisione di un parco AD.

Per il caso storico di Pro, Microsoft identifica HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\IsolatedCredentialsRootSecret come indicatore del registro da esaminare. Identifica tale cronologia; non è una misurazione dell'isolamento in esecuzione. La tabella delle licenze non concede a Pro, Pro Education o SE gli stessi diritti di Enterprise ed Education. Panoramica Microsoft

Va esaminata anche l'idoneità hardware. La panoramica elenca VBS e Secure Boot per la protezione e raccomanda TPM, senza renderlo un requisito universale di Credential Guard. Precisa separatamente che VBS può raggiungere uno stato di esecuzione senza Secure Boot. Conservate questa distinzione: un servizio VBS in esecuzione non certifica da solo le protezioni della piattaforma previste. La documentazione della piattaforma VBS descrive le estensioni di virtualizzazione, SLAT e i requisiti di firmware e DMA.

Perché una disabilitazione esplicita sopravvive all'aggiornamento

Microsoft afferma che i valori configurati esplicitamente prevalgono sull'abilitazione predefinita dopo il riavvio. Un dispositivo disabilitato esplicitamente prima di un aggiornamento resta disabilitato in seguito. L'aggiornamento è quindi un utile punto di controllo per l'audit, non una correzione di una vecchia eccezione. Configurare Credential Guard

Esaminate LsaCfgFlags sia in HKLM\SYSTEM\CurrentControlSet\Control\Lsa sia in HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard. Microsoft documenta 0 per la disabilitazione esplicita, 1 per l'abilitazione con blocco UEFI e 2 per l'abilitazione senza blocco. In GPO, esaminate Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security, inclusa la configurazione di Credential Guard contenuta al suo interno. Procedure Microsoft di configurazione e disabilitazione

Un'eccezione può essere stata introdotta per una dipendenza applicativa reale. I problemi noti di Microsoft trattano l'accesso Single Sign-On MS-CHAPv2/NTLMv1, le credenziali CredSSP salvate e la migrazione in tempo reale Hyper-V basata su CredSSP. Stabilite quale flusso di lavoro richiedeva inizialmente l'eccezione, se ne ha ancora bisogno e chi è responsabile della decisione. Evitate di presumere sia che l'eccezione resti necessaria sia che possa essere rimossa senza test.

Catena di attacco: cosa cambia quando manca l'isolamento

Senza l'isolamento di Credential Guard, una compromissione locale con privilegi sufficienti può rendere più accessibili al furto da LSASS i segreti del dominio presenti sull'host. Quando Credential Guard è in esecuzione, i segreti protetti vengono invece gestiti tramite un componente LSA isolato. Furto e riutilizzo dipendono comunque dai segreti presenti, dai privilegi dell'attaccante e da un percorso di autenticazione disponibile; un controllo disabilitato non comporta automaticamente la compromissione del dominio. Come funziona Credential Guard

Il nostro articolo sul Pass-the-Hash in Active Directory spiega come materiale NTLM rubato possa consentire il movimento laterale quando la destinazione accetta NTLM e l'account dispone di diritti utili. Già descrive Credential Guard come mitigazione. Questa guida aggiunge l'indagine sulla disabilitazione ereditata e la verifica in esecuzione necessarie per stabilire se tale mitigazione è effettivamente presente.

Credential Guard ha limiti anche quando è attivo: account locali/Microsoft, ticket di servizio Kerberos, credenziali NTLM fornite manualmente, keylogger e abuso dei privilegi di una sessione esistente restano rischi rilevanti. Inoltre, i verificatori di accesso al dominio memorizzati nella cache non sono hash NTLM che si possono semplicemente presentare a un altro computer. Limiti di protezione secondo Microsoft

Rilevamento: misurare il servizio in esecuzione

Sul dispositivo Windows di destinazione, usate una sessione PowerShell con privilegi elevati e il comando esatto fornito da Microsoft in Verificare se Credential Guard è abilitato:

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

Interpretate il risultato come un insieme di identificatori di servizi. La presenza di 1 indica che Credential Guard è in esecuzione; 2 indica l'integrità della memoria. Un risultato contenente sia 1 sia 2 include Credential Guard. SecurityServicesConfigured descrive la configurazione, mentre SecurityServicesRunning descrive l'esecuzione; VirtualizationBasedSecurityStatus descrive VBS. Sono osservazioni separate. Riferimento Microsoft delle proprietà di Win32_DeviceGuard

In alternativa, aprite msinfo32.exe, selezionate System Summary e cercate Credential Guard in Virtualization-based Security Services Running. Microsoft sconsiglia di usare la presenza di LsaIso.exe in Gestione attività come metodo di verifica. Guida di verifica Microsoft

Quando configurazione ed esecuzione differiscono, esaminate Windows Logs → System, origine WinInit. Microsoft documenta questi segnali di avvio nella stessa pagina di configurazione:

Questi eventi descrivono lo stato di protezione, non dimostrano che siano state rubate credenziali. Una raccolta fallita significa sconosciuto, non disabilitato. Registrate host, ora della raccolta e contesto del riavvio affinché un vecchio evento o un endpoint inaccessibile non venga scambiato per la copertura attuale.

Correzione: sostituire l'eccezione e verificare dopo il riavvio (Remediation)

1. Creare un inventario delle eccezioni

Per ogni candidato, registrate versione, edizione e licenze, idoneità della piattaforma, ruolo nel dominio o di DC, impostazioni esplicite locali e gestite e risultato in esecuzione. Separate i dispositivi confermati come privi del servizio in esecuzione dagli host che non è stato possibile misurare. Date priorità all'indagine dove vengono usate credenziali del dominio, mantenendo le esclusioni documentate sopra.

2. Testare la dipendenza che giustificava la disabilitazione

Usate dispositivi rappresentativi e i flussi di autenticazione reali. Microsoft raccomanda l'autenticazione Wi-Fi/VPN basata su certificati al posto di MS-CHAPv2 e Kerberos Constrained Delegation o Resource-Based Kerberos Constrained Delegation per i flussi di migrazione Hyper-V interessati. Questi cambiamenti affrontano la dipendenza invece di perpetuare la disabilitazione. Registrate un responsabile e una data di revisione per le eccezioni che devono restare. Guida di compatibilità Microsoft

3. Impostare una configurazione esplicita supportata

Per i dispositivi gestiti dal dominio, seguite la procedura GPO di Microsoft: abilitate Turn On Virtualization Based Security in Computer Configuration → Administrative Templates → System → Device Guard, quindi scegliete Enabled with UEFI lock o Enabled without lock in Credential Guard Configuration. Definite l'ambito e testate la distribuzione prima di estenderla su larga scala. Riavviate dopo l'applicazione dei criteri. Anche Intune offre queste opzioni di Credential Guard. Istruzioni di distribuzione Microsoft

L'alternativa documentata tramite registro usa EnableVirtualizationBasedSecurity=1 in HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard, con LsaCfgFlags=1 o 2 in HKLM\SYSTEM\CurrentControlSet\Control\Lsa. RequirePlatformSecurityFeatures nel percorso DeviceGuard seleziona Secure Boot (1) o Secure Boot con protezione DMA (3). Seguite l'intera procedura documentata e risolvete le configurazioni gestite in conflitto. Impostazioni del registro Microsoft

Scegliete il blocco consapevolmente. L'abilitazione predefinita è senza blocco UEFI; rimuovere una configurazione bloccata tramite UEFI richiede la procedura firmware di Microsoft e una conferma fisica. Una modifica al registro da sola non rimuove tale stato del firmware. Documentate la capacità di ripristino prima di scegliere il blocco. Procedura Microsoft per il blocco UEFI

4. Verificare e conservare le prove

Dopo il riavvio, ripetete il comando CIM documentato o la verifica con msinfo32.exe ed esaminate gli errori WinInit. Chiudete la correzione quando il servizio previsto è in esecuzione e i flussi richiesti superano i test, non semplicemente quando esiste una GPO. Mantenete i dispositivi irrisolti nell'inventario con le prove effettive e l'azione successiva.

Questa verifica in esecuzione non stabilisce se le credenziali siano state esposte prima dell'avvio della protezione. Microsoft raccomanda di abilitare Credential Guard prima dell'aggiunta al dominio o del primo accesso di un utente del dominio, perché i segreti usati in precedenza potrebbero già essere stati compromessi. Guida di distribuzione Microsoft

Esaminate anche le esposizioni correlate delle credenziali. Il nostro articolo su WDigest abilitato spiega come UseLogonCredential ed eccezioni obsolete possano aumentare il materiale di credenziali esposto in LSASS. È una revisione complementare dell'archiviazione delle credenziali, non un sostituto della misurazione dell'isolamento di Credential Guard.

Come EtcSec rileva questo problema

L'etc-collector di EtcSec include CREDENTIAL_GUARD_DISABLED, un controllo di configurazione GPO di gravità media. Il suo metodo Detect() legge i criteri GPO raccolti e cerca un valore VBS di 1 e un valore LsaCfgFlags di Credential Guard di 1 o 2. Se manca una delle condizioni, registra un riscontro di configurazione.

La ricerca prende la prima impostazione trovata in Default DC Policy, Default Domain Policy e poi nelle altre GPO; i due valori possono provenire da criteri diversi. Non calcola i criteri risultanti di ogni endpoint, non interroga lo stato CIM di ciascun host e non identifica l'abilitazione automatica su ogni computer. La configurazione GPO non è lo stato effettivo in esecuzione. Un valore GPO assente può coesistere con un servizio in esecuzione abilitato per impostazione predefinita; un'impostazione presente non dimostra l'esecuzione su tutto il parco.

Usate il riscontro per avviare l'indagine sulla configurazione, poi allegate le misurazioni a livello di host al registro della correzione. La catena di prove utile comprende idoneità, impostazioni esplicite, configurazione applicata, riavvio e verifica in esecuzione. Mantenete visibili i risultati sconosciuti affinché la copertura della configurazione non venga presentata come protezione misurata.