Olá amigos, sejam muito bem vindos.
Antes de entrarmos de cabeça no assunto, vale a pena discutir por que é importante investir na segurança do Active Directory (AD), considerando que a Microsoft já o classifica como uma tecnologia legada (porém essencial). Afinal, pode parecer mais lógico priorizar a migração para os recursos mais modernos oferecidos pelo Entra ID, em vez de dedicar tempo ao Active Directory. Bom, não é assim que as coisas funcionam.
O Active Directory (AD) é amplamente utilizado por empresas em todo o mundo para gerenciar identidades e controlar o acesso a recursos de rede. Estima-se que aproximadamente 90% das empresas da lista Global Fortune 1000 utilizem o AD como método principal para autenticação e autorização (frost.com).
Além disso, o AD é considerado a principal infraestrutura de identidade local em muitas organizações, com cerca de 90% das maiores empresas globais (Global Fortune 1000) ainda dependendo do AD para suas necessidades de gerenciamento de identidade (auxility.be)
Essas estatísticas indicam que o Active Directory continua sendo uma solução predominante para gerenciamento de identidades em empresas de grande porte em todo o mundo.
Não se esqueça que o Active Directory ainda é uma ferramenta essencial para autenticação local (onpremisse) em diversas empresas e modelos de negócio incluindo os pequenos (Small Business). Existem inúmeras versões de Windows Server e estruturas de Active Directory funcionando mundo a fora.
Isso significa que os criminosos cibernéticos continuam obtendo sucesso ao acessar credenciais privilegiadas por meio do AD. Como resultado, conseguem controle sobre dados e sistemas críticos e, a partir daí, muitas vezes se expandem para recursos em nuvem como um alvo secundário.
A pergunta que deve ser levantada é, por que isso acontece? Bem, posso dizer que grande parte dessa culpa esta na forma com que nós, seres humanos, utilizamos os meios tecnológicos, principalmente os mais importantes como os responsáveis pela autenticação dos equipamentos, usuários e dispositivos. Já sabemos a tempos que o NTLM possui vulnerabilidades criticas e deve ser retirado de uso.
Quando falamos de protocolos vulneráveis é comum surgir a pergunta: "Por que a Microsoft não pode simplesmente reforçar a segurança do Active Directory com uma atualização de segurança?". Embora fosse ótimo ter um "botão fácil" para isso, a realidade é que a maioria dos clientes Microsoft carrega uma quantidade significativa de "dívida técnica", com dependências complexas no AD. A Microsoft faz melhorias na segurança do AD sempre que possível, mas, na maioria dos casos, esse trabalho precisa ser conjunto para evitar impactos negativos nos ambientes de produção.
Endurecer a segurança do AD (o famoso hardening) pode ser um processo que consome tempo e recursos, mas vale lembrar que a lista de verificação para proteger proativamente seu Active Directory é muito semelhante à necessária para uma recuperação pós-comprometimento. Tendo visto isso ser feito de ambas as formas, posso garantir que é muito melhor agir de forma preventiva do que em meio a uma crise.
O que é NTLM?
O NTLM (NT LAN Manager) é um protocolo de autenticação desenvolvido pela Microsoft para autenticar usuários em redes do Windows. Ele foi originalmente introduzido nas versões iniciais do Windows NT e servia como um mecanismo de autenticação para conexões seguras dentro de redes locais.
Para que serve o NTLM?
O NTLM é um protocolo utilizado para autenticar usuários em ambientes Windows, permitindo que eles acessem recursos como compartilhamentos de arquivos, servidores e aplicações dentro de um domínio ou de uma rede local. Este protocolo é um dos favoritos de quem utiliza equipamentos Firewall, proxy ou outras aplicações dentro do universo Open Source (já viu o problema que temos em mão certo).
Ele funciona em três etapas principais:
Desafio e resposta: O servidor envia um desafio criptográfico ao cliente.
Geração de resposta: O cliente responde com um hash baseado em sua senha e no desafio recebido.
Verificação: O servidor compara o hash enviado pelo cliente com o valor esperado, permitindo ou negando a autenticação.
Histórico e evolução
O NTLM foi introduzido com o Windows NT 3.1, em 1993. Com o tempo, ele foi substituído pelo Kerberos como protocolo padrão de autenticação no Windows 2000 e versões posteriores, devido às limitações de segurança do NTLM, como vulnerabilidades a ataques de replay e pass-the-hash.
Mesmo com essas limitações, o NTLM ainda é suportado em sistemas Windows modernos para compatibilidade legada, especialmente em ambientes onde o Kerberos não pode ser utilizado, como em conexões sem Active Directory ou em relações de confiança entre domínios diferentes.
Documentação oficial
A Microsoft disponibiliza documentação detalhada sobre o NTLM, incluindo especificações técnicas e diretrizes de segurança. As principais referências incluem:
O NTLM foi um protocolo essencial para autenticação no Windows, mas, devido a suas vulnerabilidades críticas, é altamente recomendado que organizações adotem o Kerberos sempre que possível. O entendimento do NTLM ainda é importante para administradores de redes e segurança, especialmente em ambientes que necessitam compatibilidade com sistemas legados.
Enforcing NTLMv2 (Forçando o uso do NTLMv2)
Se você não puder eliminar o NTLM de sua rede, pelo menos deve-se o uso do NTLMv2 - particularmente eu sempre recomendo fortemente a remoção, porém entendo que a empresa pode possuir aplicações legadas que precisam existir e não estão prontas para abandonar o uso de protocolos antigos.
Sempre que encontro um cenário destes, começo a olhar para o perímetro da vulnerabilidade. Já que não posso remover uma vulnerabilidade, posso reforçar a área exploratória em volta dela, mas bem, este é um assunto para outro momento. Vamos voltar ao NTLM por enquanto.
Lembre-se, ele existe desde o Windows NT 4.0 SP4 e há mais de 10 anos falamos sobre sua implementação obrigatória. Muito já foi escrito sobre o funcionamento do NTLM e os motivos pelos quais o NTLMv1 não é mais seguro, então aqui estão os principais pontos:
O NTLM não transmite a senha do usuário nem seu hash diretamente na rede. Ele utiliza um protocolo de desafio/resposta no qual o servidor envia um número aleatório (nonce) ao cliente, que o criptografa usando o hash da senha e o devolve ao servidor para verificação.
No NTLMv1, a criptografia utilizada é baseada no DES (extremamente fraco). Já o NTLMv2 utiliza HMAC-MD5, que, embora não seja ideal pelos padrões atuais, é significativamente mais seguro que o DES.
O NTLMv1 é altamente vulnerável a ataques Man-in-the-Middle e Relay, permitindo que invasores capturem e forcem a descoberta de hashes para acessar recursos sem a senha real.
A versão do NTLM usada é negociada entre o cliente e o servidor. O Windows sempre utilizará a versão mais segura compatível com ambos.
Desde o Windows Server 2008 R2, é possível desativar o NTLM (exceto para contas locais). No entanto, eliminar o NTLM por completo é difícil. Se você ainda não reforçou o uso do NTLMv2, priorize isso antes de tentar desativar o protocolo.
Muitas vezes, o NTLM é utilizado devido à falta de registros SPN, SPNs duplicados ou acesso a recursos usando endereços IP em vez de FQDNs. Para identificar esses problemas, analise os eventos de falha 4769.
Caso queira desativar o NTLM, o ideal é fazer isso gradualmente em servidores individuais, em vez de aplicar essa configuração em todo o domínio de uma só vez.
Configuração do NTLMv2
O nível de compatibilidade do NTLM é gerenciado pela configuração LmCompatibilityLevel, armazenada na chave do Registro:
HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel
A tabela abaixo detalha os diferentes níveis de configuração (0 a 5):
Importante: Se a chave de Registro LmCompatibilityLevel não existir, o comportamento padrão será determinado pelo sistema operacional.
Windows XP / Server 2000 → Nível 1 (NTLMv1)
Windows Server 2003 → Nível 2 (NTLMv1 com segurança de sessão NTLMv2)
Windows Vista / Server 2008 e superior → Nível 3 (NTLMv2)
Atenção: Essa chave de registro não faz parte das políticas de grupo padrão (GPOs). Isso significa que, se você definir um valor e depois removê-lo, o registro permanecerá "tattooed" nos dispositivos. Para removê-lo, será necessário limpar manualmente essa configuração em cada máquina afetada.
Como auditar o uso do NTLMv1
Antes de forçar o nível 5, é essencial verificar se há dependências inesperadas do NTLMv1. Para isso, monitore os eventos de autenticação 4624 no log de segurança do Windows.
Atenção: Se a autenticação ocorre em um servidor membro, o evento 4624 será registrado nos logs de segurança desse servidor. Já o controlador de domínio registrará o evento 4776, mas esse evento não indica qual versão do NTLM foi usada. Portanto, é necessário coletar eventos de todos os servidores para um diagnóstico completo.
Se sua organização usa um SIEM para centralizar logs de segurança, aproveite-o para filtrar e visualizar os eventos 4624. Caso contrário, você pode usar o Windows Event Forwarding para consolidar esses logs e, em seguida, rodar um script PowerShell como este para identificar autenticações NTLMv1:
Get-WinEvent -FilterXml @"
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624)]]
[EventData[Data[@Name='LmPackageName'] and (Data='NTLM V1')]]
</Select>
</Query>
</QueryList>
"@ | Where-Object {$_.Properties[5].Value -ne "ANONYMOUS LOGON"} | Select-Object TimeCreated, @{Name='Account Name';Expression={$_.Properties[5].Value}}, @{Name='Account Domain';Expression={$_.Properties[6].Value}}, @{Name='Logon Type';Expression={$_.Properties[8].Value}}, @{Name='Workstation Name';Expression={$_.Properties[11].Value}}, @{Name='Source Network Address';Expression={$_.Properties[18].Value}} | Export-Csv -Path C:\NTLMv1Events.csv -NoTypeInformationBoas práticas para desativar o NTLMv1
Priorize elevar todos os dispositivos ao nível 3 antes de configurar o nível 5 nos controladores de domínio.
Audite e mitigue qualquer uso de NTLMv1 antes de desativá-lo.
Considere gerenciar essa configuração via GPO ou Intune para evitar configurações inconsistentes.
Verifique se dispositivos antigos não possuem valores "tattooed" na chave LmCompatibilityLevel.
Siga as recomendações da CIS e Microsoft para configurar todos os dispositivos Windows no nível 5.
Ao seguir essas diretrizes, você estará bem encaminhado para eliminar o NTLMv1 da sua organização e aumentar a segurança do Active Directory.
Conclusão
O Windows Hardening começa com alinhamento de bom senso com boas práticas. Ficar atento a utilização de protocolos mais seguros, observar e conhecer aplicações legadas e suas características, buscar ferozmente por "Shadow IT" (aplicações não documentadas) que possam utilizar recursos duvidosos ou não seguros e principalmente, conscientizar seus usuários.
Acredito fortemente que a segurança cibernética se faz através de 04 pilares fundamentais onde o mais importante são as pessoas, depois os processos, depois as políticas e por fim, as tecnologias.
Referencial técnico adicional:
[MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol | Microsoft Learn
Security Watch: The Most Misunderstood Windows Security Setting of All Time | Microsoft Learn
Security guidance for NTLMv1 and LM network authentication - Microsoft Support