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

O que significa 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.

Como funciona

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.

A cadeia de ataque

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.

Por isso esse problema costuma aparecer junto com Kerberoasting: como atacantes quebram senhas de contas de serviço e AS-REP Roasting: coletando hashes sem credenciais. Atacantes encadeiam oportunidades de credenciais. Se um host entrega segredos reutilizáveis, o restante do ataque fica mais barato.

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 a credencial roubada 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.

Detecção

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. Uma única exceção no host errado pode anular boa parte de um trabalho de hardening de credenciais que, fora isso, seria sólido.

Remediation

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

Se o seu ambiente ainda tem scripts de baseline antigos ou templates de hardening pós-build, revise-os com cuidado. Às vezes o WDigest volta não por decisão consciente, mas por causa de um script esquecido que alguém copiou anos atrás para "corrigir" um problema de aplicação. Por isso o estado do registro, a baseline de build e a dependência real de produção precisam ser verificados juntos.

Valide a mudança antes de encerrar o achado

A sequência de validação mais segura é simples: confirme o estado do registro em sistemas representativos, confirme que o caminho de aplicação de risco continua funcionando caso exista uma dependência de negócio real, e confirme que sua stack de detecção dispararia um sinal se alguém reativasse UseLogonCredential depois. Esse é exatamente o tipo de controle que parece trivial até um incidente provar que ele havia sido desfeito silenciosamente meses antes.

Também vale revisar o lado de identidade. Se seus admins privilegiados continuam fazendo logon em superfícies amplas demais e sem proteções mais fortes, uma única exceção WDigest pode pesar muito mais do que parece. Por isso esse achado pertence a uma revisão de acesso privilegiado mais ampla, não apenas a uma checklist de hardening de estações de trabalho.

Por que as exceções de WDigest voltam ao 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 automação 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. Por isso também são úteis como leitura complementar 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: eles ajudam a ligar uma fraqueza de registro local à pergunta mais ampla sobre onde as credenciais privilegiadas realmente vivem.

Como o EtcSec detecta isso

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.

Referências oficiais

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

Leituras relacionadas

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.