WDigest habilitado: por que credenciais em texto claro voltam a aparecer no LSASS

What Is WDigest habilitado?

WDigest habilitado significa que um sistema volta a armazenar material de autenticação reutilizável ligado ao WDigest dentro do LSASS, quando o objetivo defensivo deveria ser reduzir a quantidade de segredos exploráveis em memória. A orientação da Microsoft em torno do Security Advisory 2871997 buscava justamente dificultar o roubo de credenciais em sistemas Windows ingressados no domínio. Um dos pontos de hardening mais práticos dessa orientação é garantir que UseLogonCredential não reative o armazenamento de segredos WDigest em memória.

O risco importa porque WDigest não é apenas uma nota de rodapé de um protocolo antigo. A documentação da Microsoft explica que supplementalCredentials pode conter Primary:WDigest, descrito como hashes criptográficos da senha em texto claro para o protocolo Digest. Se uma equipe reativa o armazenamento WDigest em um host, aumenta a chance de um comprometimento local expor segredos reutilizáveis que não deveriam estar disponíveis no LSASS.

Por isso, WDigest habilitado deve ser analisado junto com Segurança de senhas no Active Directory: erros de configuração que importam, Senhas em campos de descrição do AD: detecção e limpeza e Contas obsoletas e superprivilegiadas no AD. Em todos esses casos, o problema não é apenas uma configuração fraca, mas o fato de material de autenticação reutilizável ficar mais fácil de roubar e reaproveitar do que a organização imagina.

How WDigest habilitado Works

A Microsoft documenta UseLogonCredential sob o caminho WDigest como o controle usado para impedir que o WDigest armazene credenciais em memória. Quando a configuração é reativada, material de autenticação volta a ficar disponível para código capaz de alcançar o LSASS com privilégios suficientes.

A lógica de hardening é simples:

• se o armazenamento WDigest estiver desativado, um atacante com comprometimento local precisará encontrar outros segredos reutilizáveis
• se o armazenamento WDigest estiver habilitado, o host oferece uma superfície de roubo de credenciais mais rica do que o necessário

O Advisory 2871997 da Microsoft também destaca o grupo Protected Users. Seus membros não podem se autenticar com NTLM, Digest Authentication ou CredSSP, e suas senhas não são tratadas da mesma forma em sistemas compatíveis. Isso não substitui desativar o WDigest, mas busca o mesmo objetivo: reduzir a quantidade de material reutilizável disponível depois de um comprometimento local.

The Attack Chain

Etapa 1 - Obter admin local ou SYSTEM em um host Windows

WDigest habilitado raramente é o vetor inicial. O risco aparece quando o atacante já conquistou admin local, SYSTEM ou execução equivalente em uma máquina. A partir daí, a diferença entre um host endurecido e um host fraco é a quantidade de material reutilizável ainda presente no LSASS.

Etapa 2 - Ler o LSASS e recuperar credenciais úteis

Com a configuração habilitada, o atacante não precisa de um ambiente totalmente quebrado. Basta um único host em que o comprometimento local possa ser convertido em acesso a credenciais.

# Verificação defensiva da configuração WDigest
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential

Para o time azul, o ponto importante não é a ferramenta de dump, mas o fato de o host manter mais material reutilizável na memória do que deveria.

Etapa 3 - Reutilizar o segredo em sistemas vizinhos

Se a credencial roubada pertence a um admin privilegiado, a um operador de helpdesk ou a uma conta de serviço com amplo alcance, o atacante pode se mover rapidamente para outros sistemas ou caminhos de privilégio. É por isso que WDigest habilitado raramente é um achado isolado: ele amplia o impacto de outros erros de acesso.

A mesma lógica aparece em Caminhos de ataque no Active Directory até Domain Admin: qualquer configuração que transforme um host comprometido em fonte de credenciais reutilizáveis encurta o caminho até algo mais crítico.

Detection

Você não precisa de suposição para detectar essa exposição. A Microsoft já fornece o ponto central de controle: o valor de registro UseLogonCredential. Uma revisão séria também deve verificar se admins mais sensíveis continuam fora de Protected Users e se sua telemetria detectaria rapidamente alterações no registro ou acessos suspeitos ao LSASS.

# Checagem rápida de WDigest em um host
reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential

# Verificar contas privilegiadas no grupo Protected Users
Get-ADGroupMember 'Protected Users'

A verificação de registro é a forma mais rápida de validação, mas não deve ser a única. Durante uma revisão de incidente, confirme se a configuração aparece em estações administrativas, jump hosts ou servidores onde identidades de alto valor fazem logon interativo.

Por que esse ajuste volta para o ambiente

WDigest raramente retorna porque uma equipe quer conscientemente menos proteção. Na maioria das vezes ele reaparece por hábitos antigos de troubleshooting: um engenheiro reutiliza um workaround antigo, uma gold image preserva o valor, ou um script de suporte volta a rodar sem que a dependência original da aplicação seja reavaliada. Esse padrão importa porque muda o tipo de revisão necessária. A pergunta não é apenas “a chave está definida?”, mas “qual baseline, qual script ou qual owner continua trazendo isso de volta?”.

Em ambientes maduros, essa verificação deve incluir estações administrativas, jump hosts e qualquer tier de servidor em que identidades privilegiadas trabalhem interativamente. Se a configuração estiver limpa em workstations comuns, mas continuar fraca nos hosts onde vivem as credenciais mais valiosas, o risco residual ainda é alto.

Remediation

💡 Quick Win: se um host não tem dependência justificada de armazenamento WDigest, desative o ajuste e confirme que ele não reaparece por baseline antiga, imagem base ou script de suporte.

Um caminho de remediação limpo costuma ser curto:

1. Inventariar onde UseLogonCredential está habilitado. Comece por estações administrativas, jump hosts e servidores sensíveis.
2. Desativar a configuração. Em sistemas suportados, defina UseLogonCredential como 0 ou retorne ao padrão moderno da baseline.
3. Revisar dependências legadas. Se uma equipe afirmar que precisa de WDigest, exija um fluxo de aplicação concreto e um plano para encerrar a exceção.
4. Proteger identidades de alto valor. Use Protected Users quando isso for operacionalmente viável para contas privilegiadas.
5. Monitorar deriva. Gere alertas para mudanças no caminho de registro WDigest e para acessos suspeitos ao LSASS.

# Exemplo de remediação local em um host Windows
New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential -Type DWord -Value 0

Validate Before You Close the Finding

A mudança não deve ser considerada concluída apenas porque o valor foi definido como 0 uma vez. Valide o estado do registro em sistemas representativos, confirme que um fluxo supostamente crítico continua funcionando se houver dependência legítima e garanta que sua pilha de detecção alertaria caso UseLogonCredential fosse reativado no futuro. Esse é exatamente o tipo de controle que parece simples até um incidente provar que ele voltou silenciosamente meses atrás.

Também vale revisar o lado de identidade. Se admins privilegiados continuam fazendo logon em superfícies amplas demais e sem proteções mais fortes, uma única exceção WDigest pode ser muito mais grave do que parece.

Onde revisar primeiro a deriva de WDigest

A revisão de WDigest deve começar pelos sistemas em que identidades de maior valor realmente fazem logon. A documentação de suporte da Microsoft sobre endurecimento de credenciais deixa claro que o comportamento padrão muda conforme a geração do Windows. No Windows 7, Windows Server 2008 R2, Windows 8 e Windows Server 2012, UseLogonCredential continua em 1 por padrão depois da atualização se a organização não o força para 0. Já no Windows 8.1, Windows Server 2012 R2 e versões posteriores, o cache WDigest fica desativado por padrão quando a entrada de registro não existe. Essa diferença ajuda a explicar por que imagens antigas, scripts legados ou baselines de suporte continuam reintroduzindo o risco.

Na prática, vale revisar separadamente estações administrativas, jump hosts e servidores onde acontecem logons privilegiados. Se o build moderno está limpo, mas uma imagem legacy usada para administração volta a escrever UseLogonCredential=1, o risco real permanece concentrado justamente nos hosts com as credenciais mais valiosas.

Outro controle útil é comparar a baseline documentada, a pipeline de imagem e o estado local real dos sistemas em produção. Quando essas três fontes não descrevem o mesmo valor, o problema costuma ser organizacional, e não técnico. Descobrir qual script, qual exceção ou qual artefato de build está reintroduzindo a chave costuma ser a parte mais importante da remediação.

A revisão também precisa se alinhar à orientação da Microsoft sobre Protected Users. Esse grupo não corrige WDigest sozinho, mas a Microsoft especifica que seus membros não podem se autenticar com NTLM, Digest Authentication nem CredSSP. Revisar WDigest sem observar onde contas privilegiadas se conectam e se já contam com essa proteção costuma deixar de fora a parte mais relevante do risco.

How EtcSec Detects This

EtcSec associa esse tema diretamente a WDIGEST_ENABLED. A pergunta útil não é só se a chave existe em algum ponto, mas se os hosts que mais importam ainda mantêm material reutilizável no LSASS e se a exceção tem um owner claro.

ℹ️ Note: EtcSec detecta automaticamente armazenamento de credenciais WDigest durante revisões de Active Directory para ajudar a priorizar os sistemas em que um comprometimento local exporia identidades de maior valor.

Official References

• Microsoft Security Advisory 2871997: Update to Improve Credentials Protection and Management
• Microsoft Support article for UseLogonCredential and WDigest credential storage behavior
• Microsoft protocol documentation for supplementalCredentials and Primary:WDigest

Related Reading

Revise esse tema junto com Segurança de senhas no Active Directory: erros de configuração que importam, Senhas em campos de descrição do AD: detecção e limpeza, Contas obsoletas e superprivilegiadas no AD, Como auditar a segurança do Active Directory: checklist prática para equipes internas e Monitoramento de segurança do Active Directory: eventos que realmente importam. Esses temas ajudam a ligar uma configuração local de registro à questão maior de quais credenciais reutilizáveis ainda existem no ambiente.