Silverfort descobre um Active Directory A Política de Grupo projetada para desabilitar o NTLMv1 é facilmente ignorada devido a uma simples configuração incorreta, permitindo que as autenticações NTLMv1 persistam.
TL, DR
- news: SilverfortA equipe de pesquisa da descobriu uma nova maneira para os invasores usar NTLMv1 em ataques, apesar dos esforços para desativá-lo. Usando uma configuração incorreta em aplicativos locais, os invasores podem ignorar o Política de grupo projetada para interromper NTLMv1 autenticações.
- Por que é importante: 64% de Active Directory contas de usuário regularmente autenticar com NTLM, apesar de suas fraquezas conhecidas e de ser obsoleto pela Microsoft. Muitas organizações tentaram resolver o problema NTLMv1 com um Active Directory Política de Grupo. No entanto, descobrimos que essa política é falha e permite que as autenticações NLTMv1 persistam, criando uma falsa sensação de segurança e deixando as organizações vulneráveis. Os invasores sabem que o NTLMv1 é um ponto fraco autenticação protocolo e buscá-lo ativamente como um método para mover-se lateralmente ou escalar privilégios.
- Quem é afetado: Qualquer organização que use aplicativos locais de terceiros ou desenvolvidos internamente e aqueles que não usam estritamente máquinas Windows. Por exemplo, se um computador Mac se conectar a um aplicativo bancário, eles podem ser comprometidos.
- Impacto para as organizações: Um invasor em uma rede pode ver o tráfego NTLMv1 e quebrar as credenciais dos usuários offline, levando a movimentos laterais e escalação de privilégios. Nosso POC emula um aplicativo ignorando a cerca, validando que essa configuração incorreta funciona em benefício do invasor.
- Resultado da divulgação: Embora o Microsoft Security Response Center (MSRC) tenha indicado o NTLMv1 bypass não é uma vulnerabilidade, eles tomaram medidas proativas para aumentar a segurança anunciando a remoção completa do NTLMv1 dentro de dois meses após nossa divulgação, começando com o Windows 11 versão 24H2 e o Windows Server 2025.
Recentemente, realizamos um webinar em que expliquei a pesquisa com mais detalhes, mostrando como mitigar autenticações NTLMv1 na ausência de um patch. Você pode assistir a este webinar sob demanda aqui.
Resumo e mitigações
Apesar de sua importância histórica, o NTLM representa uma responsabilidade de segurança considerável. Seus métodos criptográficos desatualizados, fraquezas bem documentadas e falta de recursos de segurança modernos (como MFA e validação de identidade do servidor) o tornam um alvo atraente para invasores. Os hashes NTLMv1 podem ser interceptados e usados para autenticação ataques de retransmissão ou mesmo ataques de dicionário, concedendo aos invasores acesso não autorizado a sistemas sensíveis. Novas vulnerabilidades NTLM foram divulgadas nos últimos meses, incluindo um dia zero. Mais recentemente, CyberSky descoberto uma vulnerabilidade NTLM explorada por agentes de ameaças russos como parte de uma cadeia de ataque que fornece o código aberto RATO FAÍSCA malware.
Muitas organizações usam proativamente o mecanismo de Política de Grupo da Microsoft para pare NTLMv1, acreditando que isso os protegerá de autenticações NTLMv1 inseguras. No entanto, nossa pesquisa mostra que aplicativos locais podem ser configurados para habilitar NTLMv1, negando o nível de autenticação mais alto do Group Policy LAN Manager definido em Active Directory. As organizações acham que estão fazendo a coisa certa ao definir essa política de grupo, mas ela ainda está sendo ignorada pelo aplicativo mal configurado. Até que os aplicativos não possam ser configurados para autenticar com NTLMv1, o problema persistirá.
At Silverfort, vimos muitas tentativas de autenticação via NTLMv1 em nossa base de clientes. Trabalhamos em estreita colaboração com nossos clientes para mapear e detectar o uso de NTLMv1 e aplicar cercas baseadas em risco para reduzir o risco de comprometimento. Sem um patch para NLTMv1, as empresas que usaram NTLMv1 no passado devem considerar o seguinte:
- Habilite logs de auditoria para todas as autenticações NTLM no domínio.
- Mapeie todos os aplicativos que usam autenticações NTLM na primeira instância ou como fallback.
- Detecte aplicativos vulneráveis que solicitam que os clientes usem mensagens NTLMv1.
- Proteja todos os NTLM com um método de autenticação moderno.
Mergulho técnico profundo: bypass NTLMv1 em Active Directory
NTLM (NT LAN Manager) é um mecanismo de autenticação antigo, mas amplamente usado, comumente visto em ambientes baseados em Windows. Desenvolvido pela Microsoft no início dos anos 1990, já foi o padrão para autenticação de usuários em uma rede, especialmente da Microsoft Active Directory. No entanto, apesar de ter sido amplamente substituído por protocolos mais seguros como Kerberos, o NTLM continua a permanecer em sistemas legados devido a requisitos de compatibilidade com versões anteriores. Medidas foram tomadas ao longo dos anos para incentivar o uso de formas de autenticação mais novas e seguras, como bloquear o NTLMv1 legado em todo o domínio. Em dezembro de 2024, a Microsoft anunciou o depreciação do desenvolvimento ativo NTLM. Mesmo com essas mudanças, ainda restam perguntas. Essas ações criam um ambiente mais seguro? Estamos realmente chegando perto de uma remoção completa do NTLMv1? Vamos mergulhar nos detalhes técnicos.
NTLM 101
NTLM é um mecanismo de autenticação usado para verificar a identidade de um usuário em sistemas baseados em Windows. NTLM consiste em três mensagens: Negotiate, Challenge e Authenticate. O processo começa com o cliente enviando uma mensagem Negotiate para o servidor, indicando sua intenção de usar NTLM para autenticação e fornecendo informações sobre opções de autenticação suportadas. O servidor então responde com uma mensagem Challenge, que inclui um número aleatório (o desafio) para o cliente fazer hash usando suas credenciais. O cliente então envia a resposta com hash de volta para o servidor na mensagem Authenticate, que também inclui o nome de usuário, domínio e informações de sessão do cliente. O servidor valida a resposta e, se bem-sucedida, concede acesso ao recurso solicitado.
O NTLM é frequentemente usado como o mecanismo de autenticação subjacente em protocolos de nível superior como SMB (Server Message Block) ou HTTP. Embora o NTLM seja um protocolo de autenticação independente, ele é frequentemente chamado de "mecanismo" porque é frequentemente implementado como parte de outros protocolos ou sistemas para fornecer autenticação.
Figura 1: Autenticação NTLM simples
NTLMv1 vs NTLMv2
O NTLMv1 foi introduzido pela primeira vez em 1993. A conscientização sobre segurança naquela época era baixa e o NTLM foi projetado de acordo. A criptografia, o primeiro mecanismo de segurança, estava em sua infância e apenas DES era suportado. O segundo mecanismo, o desafio, consistia apenas em um desafio de servidor de 8 bytes. Esse número de bytes aleatórios era mais fácil de adivinhar em termos de quebrar a cifra e descobrir as credenciais do usuário. O último mecanismo ausente na primeira versão do NTLM era especificar a origem e o destino da autenticação NTLM. Isso levou muito rapidamente ao infame método de ataque NTLM Relay, que posicionava o adversário entre o cliente e o servidor. Se uma mensagem NTLMv1 fosse capturada, ela poderia ser usada para reautenticar o adversário no aplicativo e até mesmo reutilizá-la com um protocolo diferente. Por exemplo, ao fazer a transição da autenticação NTLM sobre SMB para NTLM sobre LDAP.
A segunda versão do NTLM – NTLMv2 – introduziu mitigações para muitas das fraquezas de segurança detalhadas acima. A primeira foi a atualização do método de criptografia com o uso do RC4, que fortaleceu a cifra e tornou mais difícil a força bruta. A segunda foi a adição do Client Challenge, que adicionou outra fonte de entropia à computação da cifra. A última e maior modificação do NTLM foi o AV_PAIRS. Isso adicionou campos extras à mensagem NTLM Authenticate, como cliente de origem, servidor de destino, domínio e até mesmo SPN, que são alguns dos campos que criam uma chave de sessão exclusiva para cada autenticação. Essa proteção dificultou a execução de ataques de retransmissão.
Netlogon para avaliar NTLM
A última peça do quebra-cabeça é que o servidor de aplicativos em Active Directory não pode avaliar a mensagem NTLM por si só, simplesmente porque não tem as credenciais do usuário armazenadas. Em vez disso, a Microsoft usa a interface RPC Netlogon para avaliar a mensagem NTLM remotamente. O servidor deve anexar a mensagem NTLM à função NetrLogonSamLogonEx juntamente com os desafios NTLM. Se o Controlador de Domínio recriar com sucesso a mensagem usando as credenciais armazenadas do usuário, ele retornará sucesso e seguirá o Certificado de Acesso Privilegiado (PAC) do usuário para executar a autorização e uma chave de sessão correspondente. Se a avaliação falhar, ele responderá com o erro correspondente.
Figura 2: Autenticação NTLM em Active Directory
Divulgação NTLMv1
O mecanismo de Política de Grupo é a solução da Microsoft para desabilitar o NTLMv1 na rede. A chave de registro LMCompatibilityLevel impede que os Controladores de Domínio avaliem mensagens NTLMv1 e retorna um erro de senha incorreta (0xC000006A) ao autenticar com NTLMv1. Isso deve eliminar o NTLMv1 completamente e exigir que todos os servidores de aplicativos forneçam NTLMv2. Isso elimina o NTLMv1? Vamos dar uma olhada.
Figura 3: Rejeitar NTLMv1 com GP habilitado
Desvio NTLMv1
MS-NRPC é a especificação da interface remota Netlogon que descreve todas as suas estruturas e funções. O NetrLogonSamLogon e suas variantes (NetrLogonSamLogonEx e NetrLogonSamLogonWithFlags) supervisionam a passagem da mensagem NTLM do servidor para o Controlador de Domínio com segurança para avaliação. A estrutura da função requer que as informações de identidade sejam passadas junto com a mensagem NTLM. Conforme definido na seção 2.2.1.4.15, o NETLOGON_LOGON_IDENTITY_INFO contém muitos campos, como nome de domínio, nome de usuário, estação de trabalho e outros. Um campo interessante é o ParameterControl. Se olharmos para seus sinalizadores, podemos ver que no valor O, ele declara, "Permitir autenticação NTLMv1 (MS-NLMP) quando apenas NTLMv2 (NTLM) for permitido."
Figura 4: Uma captura de tela da documentação do MS-NRPC, página 65 do sinalizador ParameterControl.
Fiquei pensando se a Microsoft realmente permite que aplicativos usem NTLMv1 quando ele está desabilitado. Depois de construir a estrutura de dados e simular um aplicativo malicioso, descobri que esse sinalizador ignora a Política de Grupo que impede o uso da autenticação NTLMv1 na rede.
Figura 5: Ignorar a política de grupo NTLMv1.
Então, como isso afeta a eliminação do NTLMv1?
Os aplicativos que solicitam que os clientes gerem NTLMv1 ainda poderão fazê-lo, mesmo se a Política de Grupo estiver ativada. É importante observar que os clientes Windows com LMCompatibilityLevel 3 e acima não gerarão NTLMv1 se solicitado. No entanto, os clientes que não são Windows não são protegidos. Se um aplicativo solicitar uma mensagem NTLMv1 de um cliente que não é Windows, o Controlador de Domínio pode aprovar a autenticação e gerar uma chave de sessão. Usamos aplicativos em nossas redes de clientes que tentam usar NTLMv1 mesmo se a Política de Grupo relevante estiver ativada. Por causa desse bypass, você não pode dizer se um aplicativo vulnerável está totalmente mitigado. Embora muitas organizações tentem descobrir todo o uso de NTLMv1, elas podem nem estar cientes de que alguns aplicativos ainda estão usando NTLMv1.
O que devo fazer para mitigar completamente?
- Habilite logs de auditoria para todas as autenticações NTLM no domínio.
- Mapeie todos os aplicativos que usam autenticações NTLM na primeira instância ou como fallback.
- Detecte aplicativos vulneráveis que solicitam que os clientes usem mensagens NTLMv1.
- Proteja todos os NTLM com um método de autenticação moderno.
Silverforté unificado Segurança de Identidade A plataforma detecta e protege todas as autenticações NTLM. Nossa ITDR O módulo pode detectar aplicativos NTLMv1 e executar cercas modernas baseadas em risco para todos os aplicativos vulneráveis.
Processo de Divulgação
Embora o MSRC tenha indicado que o bypass NTLMv1 não foi classificado como uma vulnerabilidade, eles tomaram medidas proativas ao anunciar a remoção completa do NTLMv1 começando com o Windows 11 versão 24H2 e o Windows Server 2025. O problema foi relatado em 30 de setembro de 2024, e sua resposta foi alinhada com o anúncio oficial de remoção em novembro de 2024. Ao abordar riscos legados e eliminar protocolos desatualizados, a Microsoft demonstra um forte compromisso em aprimorar a segurança com uma abordagem com visão de futuro. Esta etapa ressalta a importância de proteger os sistemas com alternativas modernas e seguras, como SSO ou Kerberos e mostra como relatórios responsáveis podem contribuir para melhorias significativas.
Quer saber mais? Assista ao nosso webinar on-demand
Se você quiser se aprofundar nos detalhes dessa pesquisa, confira este webinar sob demanda, onde expliquei como mitigar autenticações NTLMv1 na ausência de um patch.