Armazenamento de hashes LM desativado no Active Directory

Verificar o armazenamento de hashes LM desativado no Active Directory suscita duas perguntas distintas: o Windows está configurado para deixar de criar hashes LM das palavras-passe, e as palavras-passe relevantes foram alteradas desde que essa configuração entrou em vigor? Uma política de palavras-passe mais forte ou uma definição de rede NTLMv2, por si só, não responde a ambas.

Este guia explica o controlo de armazenamento da Microsoft, três verificações de configuração documentadas e um plano de remediação por etapas. Também explicita uma limitação do produto: a verificação EtcSec denominada ANSSI_R23_LM_HASH_NOT_DISABLED avalia LmCompatibilityLevel, não NoLMHash. O seu resultado não é um inventário de segredos LM armazenados.

Armazenamento de hashes LM desativado: significado no Active Directory

A Microsoft distingue duas representações da palavra-passe: o hash LM, mais antigo, e o hash NT. Podem residir na base de dados local Security Accounts Manager (SAM) ou no Active Directory. A representação LM é mais fraca e mais vulnerável à recuperação de palavras-passe offline. O KB 299656 da Microsoft sobre a prevenção do armazenamento de hashes LM descreve a geração histórica de material LM para palavras-passe com menos de 15 caracteres.

Essa descrição histórica não demonstra que todas as instalações atuais do Windows criam hashes LM para palavras-passe curtas. A referência da Microsoft sobre a política de armazenamento apresenta valores predefinidos efetivos ativados para as funções de sistema na sua tabela, enquanto as entradas das GPO predefinidas do domínio e dos controladores de domínio não estão definidas. São valores predefinidos documentados, não observações do seu domínio.

A política de armazenamento atua quando uma palavra-passe é alterada. Por isso, uma conta cuja palavra-passe é anterior à implementação efetiva deve constar de uma lista de revisão. Trata-se de uma inferência condicional a partir do momento em que a política atua: a palavra-passe antiga pode já não ter originado material LM utilizável devido ao comprimento, à configuração anterior ou ao comportamento do sistema operativo. A idade da palavra-passe, por si só, não prova a presença nem a ausência desse material.

Este artigo centra-se no armazenamento LM e na renovação. Os atributos de palavras-passe mais gerais e as dependências dos serviços são abordados em segurança de palavras-passe no Active Directory e gestão de contas de serviço. Utilize esse guia para a revisão mais ampla das contas; mantenha uma decisão de encerramento separada para a questão do armazenamento aqui tratada.

Como funciona: hashes armazenados e respostas de rede são controlos distintos

O procedimento de armazenamento da Microsoft documenta NoLMHash como um DWORD definido como 1 em HKLM\SYSTEM\CurrentControlSet\Control\Lsa para Windows XP e Windows Server 2003. O procedimento para Windows 2000 SP2 e posteriores utiliza uma chave em vez disso. Estes procedimentos históricos de registo exigem um reinício e diferem no tratamento do histórico de palavras-passe; não generalize os detalhes de eliminação entre versões. O KB 299656 também descreve que palavras-passe com pelo menos 15 caracteres produzem um valor LM inutilizável para autenticação. Aumentar a política de comprimento mínimo não demonstra que uma palavra-passe antiga foi renovada. Consulte os métodos da Microsoft específicos de cada versão.

O valor independente LmCompatibilityLevel controla o comportamento da autenticação de rede. A tabela seguinte parafraseia a referência da Microsoft sobre o nível de autenticação LAN Manager. Aqui, NTLMv1 designa a variante NTLM antiga da tabela da Microsoft.

O nível 3 altera as respostas do cliente sem impor a rejeição do nível 5 no servidor. O nível 5 continua a permitir NTLMv2 e não apaga segredos das bases de dados. Trate o reforço da segurança de rede e a supressão do armazenamento como tarefas distintas.

Orientações ANSSI relacionadas: Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory. O controlo de armazenamento LM aqui descrito é documentado pela Microsoft.

Deteção: recolher provas da configuração e da renovação

Os comandos seguintes são exemplos adaptados da documentação da Microsoft. Não foram executados num ambiente Active Directory de um cliente. Execute cada medição separadamente no sistema Windows relevante e conserve a sua identificação, a data e hora, a saída e quaisquer erros.

1. Inspecionar o valor do controlo de armazenamento

Isto combina a sintaxe reg query da Microsoft com o caminho e o valor do KB 299656:

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v NoLMHash

Procure o valor DWORD documentado 0x1 nos casos em que o procedimento DWORD se aplica. A consulta lê a configuração local, não o material de palavras-passe da SAM ou do AD. Um valor ausente ou uma consulta falhada exige interpretação à luz do sistema operativo e da política efetiva. Não prova que exista um hash LM. A Microsoft documenta o código de retorno 0 para uma consulta de registo bem-sucedida e 1 para uma falha.

2. Inspecionar separadamente o valor do controlo de rede

Isto utiliza a mesma sintaxe de consulta e a localização no registo da política de autenticação:

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LmCompatibilityLevel

Registe este valor num campo diferente de NoLMHash. Um valor de rede de 0x5 não é prova de supressão do armazenamento nem de renovação de palavras-passe. Manter as duas leituras separadas também facilita a investigação de um resultado inesperado do coletor.

3. Capturar o relatório de política do computador

A referência gpresult da Microsoft documenta o âmbito do computador e a saída HTML:

gpresult /scope computer /h lm-policy.html

Inspecione o relatório de política do computador gerado juntamente com as leituras do registo. A Microsoft documenta um requisito SysWow64 para relatórios HTML em ARM64 e requisitos de firewall para relatórios remotos. O exemplo local acima evita parâmetros para alvos remotos. Um relatório de política fornece contexto de configuração; não examina hashes armazenados.

Criar uma lista de candidatos sem exagerar o significado do sinal

Compare as datas de renovação das palavras-passe das contas com as datas verificadas de implementação da política de armazenamento. Se as datas de implementação efetiva diferirem, preserve essa incerteza em vez de atribuir uma única data conveniente a todo o domínio. Esta comparação é um método de revisão inferido do comportamento na próxima alteração, não um detetor LM direto nem uma constatação medida sobre o seu ambiente.

Remediação: ativar a supressão do armazenamento e renovar as palavras-passe relevantes (Remediation)

1. Identificar dependências e atribuir responsáveis

Antes de alterar qualquer coisa, crie uma lista delimitada dos DCs, das versões Windows aplicáveis e das contas que precisam de revisão. Acrescente os sistemas com contas locais relevantes se o armazenamento SAM local fizer parte da missão. Nomeie um responsável por cada alteração de conta de serviço e um responsável pela verificação da distribuição da política.

As referências da Microsoft sobre armazenamento e autenticação descrevem impactos de compatibilidade em clientes antigos e em algumas aplicações. Utilize esse alerta para planear testes das dependências reais do seu parque. Não é prova de que uma aplicação específica ainda necessite de LM. Registe uma dependência apenas depois de o responsável a ter identificado; evite transformar uma preocupação não testada numa exceção permanente.

2. Ativar a política de armazenamento da Microsoft

Nas opções de segurança do computador, ative “Network security: Do not store LAN Manager hash value on next password change”. A Microsoft situa-a em configuração do computador, definições do Windows, definições de segurança, políticas locais e opções de segurança. A página da política de armazenamento documenta que esta política não exige um reinício.

Se for necessário um procedimento de registo específico da versão, utilize as instruções aplicáveis do KB 299656, incluindo as orientações sobre cópias de segurança do registo. A sequência histórica para XP/Server 2003 inclui um reinício seguido de alteração da palavra-passe. Não confunda essa sequência com o comportamento de reinício descrito separadamente na página da política.

3. Confirmar a distribuição efetiva antes de agendar o encerramento

Repita as três medidas de deteção em cada DC relevante e em cada sistema aplicável com contas locais. Conserve o relatório e as leituras do registo em conjunto. Para cada sistema, registe uma data efetiva verificada ou assinale a data como não esclarecida.

Não utilize a existência de uma única GPO conforme como critério de aceitação da implementação. A implementação do coletor descrita abaixo pode aprovar a verificação quando qualquer GPO inventariada contém o nível de rede, sem provar a cobertura. O registo de remediação deve, portanto, identificar os sistemas diretamente verificados e os que continuam por verificar.

4. Organizar a renovação das palavras-passe com os responsáveis pelos serviços

As orientações da Microsoft para a política de armazenamento indicam que os utilizadores devem definir novas palavras-passe no próximo início de sessão no domínio. Planeie a renovação correspondente das contas depois de o controlo de armazenamento entrar em vigor.

Para contas que não iniciam sessão regularmente, atribua uma tarefa explícita de renovação em vez de aguardar um início de sessão habitual de utilizador. Nas contas de serviço, coordene os serviços dependentes, as tarefas agendadas e as aplicações através dos seus responsáveis. A sequência prática deve identificar a conta, preparar as atualizações das dependências, executar a alteração aprovada, testar o serviço e conservar o resultado. Trata-se de um plano operacional de implementação, não de uma afirmação de que foi efetuada uma rotação em massa.

Um problema relacionado com o ciclo de vida é explicado em fallback Kerberos RC4 e geração de chaves AES dependente da palavra-passe. A lição comum para o planeamento é incluir a renovação das contas nos projetos de configuração. A geração de chaves AES e a supressão LM continuam a ser mecanismos distintos com requisitos de validação diferentes.

5. Tratar o reforço da segurança de rede como uma alteração independente

Selecione e teste separadamente o nível de rede LAN Manager pretendido, utilizando as orientações de compatibilidade da Microsoft. Não considere uma implementação bem-sucedida do nível 5 como encerramento da limpeza do armazenamento LM.

Mantenha a negociação NTLMv1, as proteções contra relay, a exposição de WDigest na memória e as restrições de NTLM de saída no Tier 0 nos respetivos trabalhos em curso. Repetir esses projetos aqui ocultaria o resultado em falta: uma implementação documentada da política de armazenamento seguida da renovação das contas incluídas no âmbito.

Validação: encerrar a revisão com um registo de provas delimitado

Utilize um registo de encerramento que um segundo administrador consiga compreender sem reconstruir o projeto a partir de conversas ou capturas de ecrã. O formato seguinte é uma proposta para as provas, não um esquema de saída do Windows nem uma declaração de que os segredos foram inspecionados.

Descreva a conclusão ao nível que as provas suportam. Por exemplo, um registo pode demonstrar que a definição de armazenamento pretendida foi verificada nos DCs listados e que as contas listadas foram renovadas posteriormente. Não deve alargar essa afirmação a contas não revistas, ao histórico de palavras-passe em todas as versões Windows ou a um inventário de todos os segredos armazenados.

Repita as verificações de configuração após a alteração e esclareça os sistemas ou contas pendentes. Mantenha visíveis as provas incompletas: um DC inacessível, um serviço não testado ou uma data de renovação desconhecida devem ter um responsável e uma próxima ação.

Como a EtcSec deteta esta configuração

O código-fonte atual do etc-collector disponibiliza duas verificações relacionadas da política de rede. Nenhuma lê NoLMHash nem inventaria segredos LM na SAM ou no AD. A análise seguinte é uma revisão estática do código-fonte no commit do coletor b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c; não é o resultado de um scan de cliente.

ANSSI_R23_LM_HASH_NOT_DISABLED

Apesar do seu identificador histórico e do rótulo do catálogo orientado para armazenamento, este detetor avalia LmCompatibilityLevel. Em internal/audit/detectors/ad/compliance/anssi/anssi-r23-lm-hash-not-disabled.go:17, o ciclo nas linhas 30–43 ignora políticas ou definições nil e marca a condição como satisfeita assim que qualquer GPO inventariada tem um valor definido superior ou igual a 5.

Devolve Count = 0 quando essa condição é satisfeita e Count = 1 caso contrário, incluindo um conjunto vazio de políticas ou valores ausentes. A implementação não calcula a precedência efetiva das GPO nem prova a cobertura de todos os DCs ou OUs. Utiliza também um limiar numérico em vez de validar o intervalo 0–5 documentado pela Microsoft: um valor recolhido de 6 satisfaria a comparação, sem se tornar um nível Windows documentado.

A condição decisiva no código-fonte é:

if p.RegistrySettings.LmCompatibilityLevel != nil &&
    *p.RegistrySettings.LmCompatibilityLevel >= 5 {
    compliant = true
    break
}

Este é um excerto formatado das linhas 35–38, não um programa autónomo. Uma contagem zero significa que esta condição de política de rede foi encontrada nos dados fornecidos. Não confirma a supressão do armazenamento, a renovação das contas ou o reforço completo da segurança de rede; o detetor não verifica as definições mínimas de segurança de sessão NTLM.

NTLMV1_ALLOWED

O detetor vizinho em internal/audit/detectors/ad/gpo/ntlmv1-allowed.go:22 lê o mesmo campo nas linhas 32–34. As linhas 37–38 definem Count = 1 quando o valor selecionado está ausente ou é inferior a 5; caso contrário, a contagem permanece zero.

A seleção é diferente. A função auxiliar internal/audit/helpers/gpo_policy.go:130 procura primeiro um valor definido na política predefinida dos DCs, depois na política predefinida do domínio e, por fim, noutra política. Esta é a regra de seleção da função auxiliar, não um cálculo completo da política resultante do Windows.

Consequentemente, estas verificações podem divergir. Numa entrada hipotética com uma política predefinida dos DCs a 3 e outra GPO a 5, a verificação com o nome ANSSI devolve zero, enquanto NTLMV1_ALLOWED devolve um. Esse exemplo segue a lógica do código-fonte; não foi observada uma configuração de cliente desse tipo.