Credential Guard desativado após atualização: verificar e corrigir

Credential Guard desativado após atualização: o que significa?

Se o Credential Guard estiver desativado após uma atualização, a causa pode ser uma configuração herdada, mesmo numa versão do Windows que ativa a funcionalidade por predefinição. Uma atualização elegível não elimina uma decisão explícita anterior de a desativar. Antes de considerar um sistema operativo atual como prova de proteção das credenciais, verifique a edição, o histórico de implementação, a política e os serviços em execução da máquina. A orientação de configuração da Microsoft documenta esta exceção persistente.

O Credential Guard isola determinados segredos de domínio através da segurança baseada em virtualização (VBS). A tarefa prática é determinar se esse isolamento está em execução nos dispositivos onde os utilizadores de domínio iniciam sessão. Uma política de implementação e uma atualização bem-sucedida do sistema operativo respondem a perguntas diferentes das de uma verificação em tempo de execução.

Este guia reflete as páginas do Microsoft Learn verificadas em 3 de outubro de 2026. Abrange dispositivos Windows 11 elegíveis a partir da versão 22H2 e membros de domínio Windows Server 2025 elegíveis. Os comandos abaixo são reproduzidos da documentação; não foram executados num parque Windows para este artigo. Não se afirma qualquer prevalência de exceções herdadas.

Como funciona a ativação por predefinição

A visão geral do Credential Guard da Microsoft descreve a ativação por predefinição a partir do Windows 11 22H2 e do Windows Server 2025. A introdução enquadra-a em sistemas elegíveis associados a um domínio que não são controladores de domínio; as condições específicas do Windows enumeram o licenciamento, a elegibilidade de hardware/software e a ausência de uma desativação explícita. Mantenha estas condições ao analisar um parque AD.

Para o caso histórico Pro, a Microsoft identifica HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\IsolatedCredentialsRootSecret como o indicador do registo a inspecionar. Identifica esse histórico; não é uma medição do isolamento em execução. A tabela de licenciamento não atribui ao Pro, Pro Education ou SE os mesmos direitos que ao Enterprise e Education. Visão geral da Microsoft

A elegibilidade do hardware também deve ser analisada. A visão geral enumera VBS e Secure Boot para a proteção e recomenda TPM, sem fazer do TPM um requisito universal do Credential Guard. Indica separadamente que a VBS pode atingir um estado de execução sem Secure Boot. Preserve esta distinção: um serviço VBS em execução, por si só, não certifica as proteções de plataforma pretendidas. A documentação da plataforma VBS detalha as extensões de virtualização, SLAT e os requisitos de firmware/DMA.

Porque uma desativação explícita persiste após a atualização

A Microsoft afirma que os valores configurados explicitamente prevalecem sobre a ativação por predefinição após o reinício. Um dispositivo explicitamente desativado antes de uma atualização permanece desativado depois. A atualização é, portanto, um ponto útil para auditoria, não uma correção de uma exceção antiga. Configurar o Credential Guard

Analise LsaCfgFlags em HKLM\SYSTEM\CurrentControlSet\Control\Lsa e em HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard. A Microsoft documenta 0 para desativação explícita, 1 para ativação com bloqueio UEFI e 2 para ativação sem bloqueio. Na GPO, analise Configuração do Computador → Modelos Administrativos → Sistema → Device Guard → Ativar Segurança Baseada em Virtualização, incluindo a configuração do Credential Guard contida nessa definição. Procedimentos de configuração e desativação da Microsoft

Uma exceção pode ter sido introduzida devido a uma dependência real de uma aplicação. Os problemas conhecidos da Microsoft abordam o início de sessão único com MS-CHAPv2/NTLMv1, as credenciais CredSSP guardadas e a migração em direto do Hyper-V baseada em CredSSP. Determine que fluxo de trabalho exigiu originalmente a exceção, se ainda a exige e quem é responsável pela decisão. Evite presumir quer que a exceção continua a ser necessária, quer que pode ser removida sem testes.

A cadeia de ataque: o que muda sem isolamento

Sem o isolamento do Credential Guard, um comprometimento local com privilégios suficientes pode tornar os segredos de domínio presentes no host mais acessíveis ao roubo a partir do LSASS. Quando o Credential Guard está em execução, os segredos protegidos são tratados através de um componente LSA isolado. O roubo e a reutilização continuam a depender dos segredos presentes, dos privilégios do atacante e de um caminho de autenticação disponível; um controlo desativado não significa automaticamente o comprometimento do domínio. Como funciona o Credential Guard

O nosso artigo sobre Pass-the-Hash no Active Directory explica como material NTLM roubado pode permitir movimento lateral quando o destino aceita NTLM e a conta possui direitos úteis. Já aborda o Credential Guard como medida de mitigação. Este guia acrescenta a investigação da desativação herdada e a verificação em tempo de execução necessárias para determinar se essa mitigação está efetivamente implementada.

O Credential Guard tem limitações mesmo quando está ativo: contas locais/Microsoft, tickets de serviço Kerberos, credenciais NTLM fornecidas manualmente, keyloggers e abuso dos privilégios de uma sessão existente continuam a ser riscos relevantes. Os verificadores em cache de início de sessão de domínio também não são hashes NTLM que possam simplesmente ser apresentados a outra máquina. Limites de proteção da Microsoft

Deteção: medir o serviço em execução

No dispositivo Windows de destino, utilize uma sessão PowerShell com privilégios elevados e o comando exato fornecido pela Microsoft em Verificar se o Credential Guard está ativado:

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

Interprete o resultado como um conjunto de identificadores de serviços. A presença de 1 significa que o Credential Guard está em execução; 2 significa integridade da memória. Um resultado que contenha 1 e 2 inclui o Credential Guard. SecurityServicesConfigured descreve a configuração, enquanto SecurityServicesRunning descreve a execução; VirtualizationBasedSecurityStatus descreve a VBS. São observações distintas. Referência das propriedades Win32_DeviceGuard da Microsoft

Em alternativa, abra msinfo32.exe, selecione Resumo do Sistema e procure o Credential Guard em Serviços de Segurança Baseada em Virtualização em Execução. A Microsoft desaconselha utilizar a presença de LsaIso.exe no Gestor de Tarefas como método de verificação. Orientação de verificação da Microsoft

Quando a configuração e o estado em execução diferirem, inspecione Registos do Windows → Sistema, origem WinInit. A Microsoft documenta estes sinais de arranque na mesma página de configuração:

Estes eventos descrevem o estado da proteção, não provam que as credenciais tenham sido roubadas. Uma recolha falhada significa desconhecido, não desativado. Registe o host, o momento da recolha e o contexto do reinício para que um evento antigo ou um endpoint inacessível não seja confundido com cobertura atual.

Correção (Remediation): substituir a exceção e verificar após reiniciar

1. Criar um inventário de exceções

Para cada candidato, registe a versão, a edição/licenciamento, a elegibilidade da plataforma, o papel no domínio/DC, as definições explícitas locais e geridas e o resultado em execução. Separe os dispositivos onde foi confirmado que o serviço não está em execução dos hosts que não puderam ser medidos. Priorize a investigação onde são utilizadas credenciais de domínio, mantendo as exclusões documentadas acima.

2. Testar a dependência que justificou a desativação

Utilize dispositivos representativos e os fluxos de autenticação reais. A Microsoft recomenda autenticação Wi-Fi/VPN baseada em certificados em vez de MS-CHAPv2, e Kerberos Constrained Delegation ou Resource-Based Kerberos Constrained Delegation para os fluxos de migração Hyper-V afetados. Estas alterações resolvem a dependência em vez de perpetuar a desativação. Registe um responsável e uma data de revisão para as exceções que tenham de permanecer. Orientação de compatibilidade da Microsoft

3. Definir uma configuração explícita suportada

Para dispositivos geridos pelo domínio, siga o procedimento GPO da Microsoft: ative Ativar Segurança Baseada em Virtualização em Configuração do Computador → Modelos Administrativos → Sistema → Device Guard e escolha Ativado com bloqueio UEFI ou Ativado sem bloqueio em Configuração do Credential Guard. Delimite e teste a implementação antes de a alargar. Reinicie após a aplicação da política. O Intune também disponibiliza estas opções do Credential Guard. Instruções de implementação da Microsoft

A alternativa documentada através do registo utiliza EnableVirtualizationBasedSecurity=1 em HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard, com LsaCfgFlags=1 ou 2 em HKLM\SYSTEM\CurrentControlSet\Control\Lsa. RequirePlatformSecurityFeatures no caminho DeviceGuard seleciona Secure Boot (1) ou Secure Boot com proteção DMA (3). Siga o procedimento documentado completo e resolva configurações geridas em conflito. Definições do registo da Microsoft

Escolha o bloqueio deliberadamente. A ativação por predefinição não utiliza bloqueio UEFI; remover uma configuração bloqueada por UEFI exige o procedimento de firmware da Microsoft e confirmação física. Uma alteração do registo, por si só, não remove esse estado do firmware. Documente a capacidade de recuperação antes de escolher o bloqueio. Procedimento de bloqueio UEFI da Microsoft

4. Verificar e conservar as provas

Após o reinício, repita o comando CIM documentado ou a verificação com msinfo32.exe e analise os erros WinInit. Encerre a correção quando o serviço pretendido estiver em execução e os fluxos de trabalho necessários passarem nos testes, não apenas quando existir uma GPO. Mantenha os dispositivos por resolver no inventário com as suas provas reais e a ação seguinte.

Esta verificação em tempo de execução não determina se as credenciais foram expostas antes de a proteção iniciar. A Microsoft recomenda ativar o Credential Guard antes da associação ao domínio ou do primeiro início de sessão de um utilizador de domínio, porque os segredos utilizados anteriormente podem já ter sido comprometidos. Orientação de implementação da Microsoft

Analise também as exposições de credenciais adjacentes. O nosso artigo sobre WDigest ativado explica como UseLogonCredential e exceções obsoletas podem aumentar o material de credenciais exposto no LSASS. É uma análise complementar do armazenamento de credenciais, não um substituto para a medição do isolamento do Credential Guard.

Como a EtcSec deteta este problema

O etc-collector da EtcSec inclui CREDENTIAL_GUARD_DISABLED, uma verificação de configuração GPO de gravidade Média. O seu método Detect() lê as políticas GPO recolhidas e procura um valor VBS de 1 e um valor Credential Guard LsaCfgFlags de 1 ou 2. Se faltar uma das condições, regista uma constatação de configuração.

A pesquisa utiliza a primeira definição encontrada em Default DC Policy, Default Domain Policy e depois noutras GPOs; os dois valores podem provir de políticas diferentes. Não calcula a política resultante de cada endpoint, não consulta o estado CIM de cada host nem identifica a ativação automática em cada máquina. A configuração GPO não é o estado efetivo em execução. A ausência de um valor GPO pode coexistir com um serviço em execução ativado por predefinição; uma definição presente não prova a execução em todo o parque.

Utilize a constatação para abrir a investigação de configuração e anexe depois medições ao nível do host ao registo de correção. A cadeia de provas útil é a elegibilidade, as definições explícitas, a configuração aplicada, o reinício e a verificação em tempo de execução. Mantenha visíveis os resultados desconhecidos para que a cobertura de configuração não seja apresentada como proteção medida.