Guia para eliminar completamente o NTLM do seu ambiente

Sumário executivo

Eliminar o NTLM de um ambiente empresarial é uma desafio significativo. Está profundamente enraizado em muitas infraestruturas e, em alguns casos, aplicações legadas críticas ainda dependem dele. Substituir essas aplicações pode parecer irrealista, e por anos esse tem sido o motivo. NTLM permaneceu em uso. Mas a realidade é diferente: a maioria das organizações não precisa realmente do NTLM, e o maior obstáculo é que a atividade do NTLM é difícil de detectar dentro Active Directory. Essa dificuldade só aumenta à medida que o ambiente se expande. 

Considerando o Fim da vida útil do Windows 10, juntamente com o anúncio da Microsoft sobre a descontinuação do NTLM, esse problema ressurgiu. As organizações precisam começar a se perguntar: como iremos operar sem o NTLM? autenticação, e que medidas devemos tomar agora para nos preparar? 

O NTLM não precisa ser um fato da vida — ele pode ser alterado. Este guia explica como o NTLM funciona em Active Directory, por que pode ser difícil eliminá-lo gradualmente e fornece um plano prático que você pode seguir para detectar e eliminar o uso do NTLM na sua organização.

Parte 1: Como o NTLM funciona?

NTLM (NT LAN Manager) é um dos protocolos de autenticação mais antigos da Microsoft, originalmente criado para as primeiras redes Windows. Ele foi projetado para permitir que os usuários comprovem sua identidade sem enviar uma senha em texto simples, confiando, em vez disso, em uma mecanismo de desafio-respostaEmbora isso tenha sido eficaz na década de 1990, hoje é considerado ultrapassado e inseguro pelos padrões atuais.  

O processo de autenticação NTLM segue uma troca de três mensagens entre o cliente, o servidor e o controlador de domínio: 

1. Negociação NTLM 
   O cliente inicia a autenticação enviando uma mensagem "Negociar" ao servidor. Essa mensagem inclui detalhes sobre os recursos do cliente, como as versões NTLM suportadas. 

2. Desafio NTLM 
   O servidor responde com uma mensagem de "Desafio" contendo um nonce de 16 bytes gerado aleatoriamente (o desafio). Isso garante que as tentativas de autenticação não possam ser simplesmente repetidas. 

3. Autenticar NTLM 
   O cliente agora prova sua identidade gerando uma resposta usando o hash de senha armazenado. 

• O passo crítico: da o cliente calcula a resposta do desafio NTLM de acordo com os critérios do servidor (por exemplo, NTLMv1 ou NTLMv2). 

• Com o NTLMv1, o cliente criptografa o desafio usando DES, que é fraco e facilmente atacado por força bruta. 

• Com o NTLMv2, o cliente inclui dados adicionais, como um carimbo de data/hora e um nonce do cliente, produzindo uma resposta mais forte, mas ainda imperfeita. O cliente envia essa resposta de volta ao servidor em uma mensagem de "Autenticação". 

4. Aceitar ou rejeitar 
   In Active Directory, o servidor encaminha o desafio e a resposta ao Controlador de Domínio. O DC procura o hash da senha armazenada pelo usuário em Active Directory, realiza o mesmo cálculo e compara os resultados. Se forem iguais, a autenticação é aceita; caso contrário, é rejeitada. 

Apesar Kerberos tem sido há muito tempo o método de autenticação preferido em Active DirectoryO NTLM ainda é amplamente utilizado. Frequentemente, os aplicativos recorrem ao NTLM quando o Kerberos falha. Esse comportamento de fallback é um dos principais motivos pelos quais a eliminação do NTLM é difícil: os administradores podem nem saber que o NTLM ainda está ativo em seus ambientes. 

Parte 2: Eliminando o NTLM na sua organização

A remoção do NTLM não é uma mudança única de configuração — é um processo que requer visibilidade, planejamento e execução cuidadosa. O segredo é começar entendendo onde o NTLM ainda está sendo usado, reduzir gradualmente a dependência dele e, por fim, eliminá-lo completamente. 

Etapa 1: determinar quais aplicativos usam NTLM

Você não pode eliminar o que não pode ver. O primeiro passo é detectar o uso de NTLM em seu ambiente. 

Mapear aplicativos NTLM manualmente não é uma tarefa fácil. É necessário analisar os Logs de Eventos do Windows — por exemplo, ID de Evento 4624 (logon bem-sucedido) e 4776 (autenticação NTLM) — e habilitar as políticas de auditoria NTLM por meio da Política de Grupo. Embora isso possa ser feito, é demorado e se torna ainda mais complexo em ambientes grandes. 

Em vez disso, moderno segurança de identidade Os recursos permitem que você compile todas as instâncias de uso do NTLM em seu ambiente em uma única exibição. 

De acordo com o relatório Silverfort plataforma, veja como você criaria um relatório abrangente de todos os aplicativos que usam NTLM em seu ambiente: 

1. Abra a aba Logs de Autenticação 

2. Crie um filtro de protocolo NTLM 

• Adicione quaisquer filtros adicionais conforme necessário (intervalo de tempo, usuários, dispositivos, etc.)
• O NTLMv1 pode ser filtrado diretamente aplicando o Indicador de Risco

3. Exportar o relatório

• Agrupe os dados por Destino para identificar quais aplicativos e servidores ainda usam NTLM

É importante lembrar que o cliente é responsável pela computação NTLM. Isso significa que os esforços de detecção não podem parar no nível do aplicativo — você também precisa identificar quais clientes retornam ao NTLM. Para eliminar completamente o NTLM, você deve monitorar continuamente os clientes e detectar os motivos do fallback. Em muitos casos, o fallback ocorre porque o Kerberos não pode ser estabelecido; por exemplo, devido a Nomes Principais de Serviço (SPNs) configurados incorretamente ou quando um cliente se conecta a um recurso usando um endereço IP em vez de um nome de host NetBIOS ou DNS, conforme exigido pelo Kerberos. Você deve abordar essas causas subjacentes para evitar que os clientes recorram ao NTLM por padrão. 

Ao investigar falhas de autenticação Kerberos, lembre-se de que, na maioria dos casos, uma tentativa malsucedida de autenticação Kerberos é imediatamente seguida por uma autenticação NTLM bem-sucedida. Esse comportamento facilita a persistência silenciosa do NTLM no ambiente. Portanto, cada falha do Kerberos deve ser analisada para entender a causa subjacente, seja devido a um Nome Principal de Serviço (SPN) ausente ou mal configurado, ao uso de endereços IP em vez de nomes de host ou a outros erros de implementação. Sem essa investigação, o fallback do NTLM continuará sem controle, prejudicando os esforços para eliminá-lo. 

Para investigar falhas do Kerberos usando Silverfort:

1. Abrir registros de autenticação

2. Aplicar filtros: Resultado do IdP: Negar, Protocolo: Kerberos

3. Analise os resultados

Etapa 2: Avalie o risco – NTLMv1 vs NTLMv2

Nem todo uso de NTLM apresenta o mesmo nível de risco. Uma parte essencial do seu plano de eliminação é diferenciar entre NTLMv1 e NTLMv2. 

NTLMv1

O NTLMv1 utiliza DES para seu cálculo de desafio-resposta, o que é muito fraco para os padrões modernos. Os invasores podem usar tabelas de arco-íris ou força bruta moderna baseada em GPU para quebrar as respostas do NTLMv1 em segundos. Por esse motivo, o NTLMv1 deve ser bloqueado imediatamente em todos os ambientes. Continuar permitindo isso coloca as credenciais do usuário em risco desnecessário. 

NTLMv2

O NTLMv2 aprimora a segurança introduzindo o HMAC-MD5 e incluindo informações extras na troca de autenticação. Uma melhoria fundamental é o uso de AV_PAIRS (pares atributo-valor), que podem transportar dados como o carimbo de data/hora do cliente, o nome do servidor de destino e as informações do alvo. Esses campos ajudam na defesa contra ataques simples de repetição e retransmissão, já que a resposta está vinculada a um servidor e contexto de sessão específicos. 

No entanto, a proteção não é completa. Se os invasores conseguirem manipular ou remover os AV_PAIRS (por exemplo, em configurações que não impõem a validação do alvo), ataques de retransmissão ainda serão possíveis. Na prática, o NTLMv2 permanece vulnerável a pass-the-hash e retransmissão NTLM em cenários onde a assinatura e a vinculação de canal não são impostas. 

Ao elaborar seu plano de eliminação de NTLM, é importante priorizar por risco. O NTLMv1 deve ser considerado um risco imediato e bloqueado sem demora, pois seu uso cria um ambiente direto e facilmente explorável. superfície de ataqueO NTLMv2, embora mais robusto, deve ser tratado apenas como uma medida temporária. Ele oferece melhor proteção que o NTLMv1, mas ainda deixa seu ambiente exposto a ataques de retransmissão e hash. Na prática, isso significa eliminar primeiro o NTLMv1 e, em seguida, focar na redução sistemática e na eliminação gradual do NTLMv2 até que o NTLM seja totalmente removido. 

Etapa 3: Bloqueie o NTLMv1 com a Política de Grupo e conheça suas limitações

Bloquear o NTLMv1 por meio da Política de Grupo é uma etapa essencial em qualquer plano de eliminação. A política LMCompatibilityLevel (ou seu equivalente na Política de Grupo) permite configurar os Controladores de Domínio para recusar autenticações NTLMv1 e aceitar apenas NTLMv2. Esta é a configuração básica recomendada para todos os Active Directory ambiente. 

Como ativar a Política de Grupo: 

1. Abra Console de Gerenciamento de Diretiva de Grupo (GPMC). 

2. Navegue até: Configuração do computador → Configurações do Windows → Configurações de segurança → Políticas locais → Opções de segurança 

3. Localize a configuração: Segurança de rede: nível de autenticação do LAN Manager 

4. Defina o valor como: Enviar apenas resposta NTLMv2. Recusar LM e NTLM 

Isso garante que os sistemas Windows sejam instruídos a gerar apenas respostas NTLMv2 e que os controladores de domínio rejeitem autenticações NTLMv1. 

No entanto, é importante entender que esse controle por si só pode não protegê-lo totalmente. Em certos casos, aplicativos mal configurados ainda podem forçar autenticações NTLMv1, independentemente da configuração da Política de Grupo. Isso cria um risco de falsa confiança, em que os administradores acreditam que o NTLMv1 está bloqueado, mas, na realidade, ele permanece ativo no ambiente. 

Para uma explicação técnica detalhada de como esse desvio funciona e por que ele ocorre, veja minha postagem no blog: Ignorar NTLMv1 em Active Directory – Mergulho técnico profundo. 

Minha recomendação atual é monitorar e eliminar o NTLMv1 e, se possível, criar uma política baseada em risco para toda autenticação NTLMv1 usando Silverfort. 

Etapa 4: verifique se os aplicativos oferecem suporte a outros métodos de autenticação

Um motivo comum para a persistência do NTLM em ambientes é a suposição de que determinados aplicativos funcionam apenas com ele. Em muitos casos, isso não é verdade. Os aplicativos podem recorrer ao NTLM devido a configurações incorretas, pré-requisitos ausentes ou simplesmente porque os administradores não habilitaram protocolos mais fortes. 

Antes de substituir ou descontinuar um aplicativo, verifique se ele já oferece suporte a um método de autenticação mais seguro: 

• Kerberos – A maioria dos aplicativos Windows modernos é capaz de autenticação Kerberos quando os Nomes Principais de Serviço (SPNs) estão configurados corretamente. Muitas "dependências" do NTLM podem ser resolvidas corrigindo SPNs ou garantindo que os clientes se conectem usando nomes de host DNS em vez de endereços IP. 

• SAML, OpenID Connect (OIDC) ou OAuth – Aplicativos da Web e serviços voltados para a nuvem geralmente oferecem suporte a esses padrões modernos de autenticação, nativamente ou por meio da integração com provedores de identidade (IdPs). 

• Autenticação baseada em certificado – Alguns aplicativos corporativos permitem login baseado em cartão inteligente ou certificado, eliminando completamente a necessidade de NTLM. 

Ao avaliar as candidaturas: 

• Verifique se há versões posteriores – Versões mais recentes podem ter eliminado dependências do NTLM ou adicionado suporte para protocolos de identidade modernos. 

• Investigar documentação – Muitos fornecedores documentam o suporte ao Kerberos ou à identidade federada, mas muitas vezes isso não é utilizado. 

• Revisar configurações de identidade – Garanta que seus aplicativos estejam integrados ao seu provedor de identidade central sempre que possível. 

Um bom exemplo disso é o Microsoft SQL Server quando acessado com o driver oficial mssql-jdbc. À primeira vista, muitas implantações parecem depender da autenticação NTLM. No entanto, na realidade, o driver oferece suporte total. Autenticação Kerberos, desde que os Nomes Principais de Serviço (SPNs) estejam configurados corretamente e o cliente se conecte usando um nome de host DNS em vez de um endereço IP. Além disso, a documentação da Microsoft descreve como configurar explicitamente o driver para Kerberos, evitando o fallback de NTLM. Este é um caso em que o NTLM parece inevitável, mas, ao revisar a documentação e ajustar as configurações de identidade, os administradores podem migrar o aplicativo para Kerberos e reduzir o uso de NTLM. 

Além disso, considere adicionar a autenticação multifator (MFA) sempre que possível. Mesmo que o NTLM ou o Kerberos continuem em uso, o MFA reduz significativamente o risco de roubo de credencial e uso indevido. Silverfort estende a proteção MFA aos protocolos de autenticação, como NTLM e Kerberos, fornecendo uma camada extra de defesa para sistemas legados e modernos. 

Etapa 5: Planeje o desligamento de aplicativos baseados em NTLM

Depois de identificar o uso do NTLM, bloquear o NTLMv1 e habilitar alternativas mais fortes sempre que possível, a etapa final é planejar o desligamento completo de aplicativos baseados em NTLM. Esta é a única maneira de eliminar completamente os riscos introduzidos pelo NTLM. 

Este plano deve incluir: 

Upgrades – Migrar para versões mais recentes de aplicativos que suportem Kerberos ou padrões de autenticação modernos. Muitos fornecedores eliminaram dependências NTLM em lançamentos recentes. 

Replacements – Quando não for possível fazer atualizações, avalie opções de substituição que estejam alinhadas com sua estratégia de identidade. 

Desativação – Crie um cronograma claro para descontinuar aplicativos que dependem exclusivamente do NTLM. 

Além disso, lembre-se que os clientes desempenham um papel fundamental na eliminação do NTLM. Como o cliente é responsável pela computação NTLM, você precisa continuamente monitorar clientes que retornam ao NTLM e identificar as razões. As causas comuns incluem: 

Uso de IP em vez de nomes de host – Quando um cliente se conecta com um endereço IP em vez de um nome de host NetBIOS ou DNS, o Kerberos não pode ser usado, forçando o fallback para NTLM. 

Uso impróprio do Kerberos em aplicativos – Alguns aplicativos não conseguem implementar o Kerberos corretamente e, em vez disso, adotam o NTLM como padrão. Um ótimo exemplo de uso indevido é o Vulnerabilidades de falsificação do KDC identificadas por Silverfort em vários produtos, como IBM QRadar (CVE-2019-4545),  Cisco ASA e Palo Alto Networks PAN-OS , onde o tratamento incorreto do Kerberos permitiu que invasores ignorassem o Kerberos e obtivessem acesso elevado (leia mais aqui). 

Para uma rápida folha de dicas dessas etapas que você pode compartilhar com sua equipe, visite aqui.

Detectar e resolver esses problemas é essencial para evitar que o NTLM reapareça silenciosamente depois que você acredita que ele foi eliminado. 

O próximo Fim da vida útil do Windows 10 e da Microsoft anúncio de descontinuação do NTLM Crie a oportunidade certa para alinhar este plano de desligamento com projetos mais amplos de modernização de TI. Trate a eliminação do NTLM como parte da atualização da sua infraestrutura, para que, quando o Windows 10 for descontinuado, seu ambiente não dependa mais do NTLM.

Para preparar sua equipe para essas mudanças críticas, Confira nosso webinar sob demanda. onde explico como expor a autenticação NTLM e criar políticas escaláveis ​​para ajudá-lo a eliminá-la.