NTLM
siglaSignifica: NT LAN Manager
Um protocolo legado de autenticação desafio-resposta da Microsoft.
O Gerenciador de LAN NT (do inglês NT LAN Manager) autentica um usuário via uma troca de desafio-resposta sem enviar a senha. Ainda visto em ambientes Windows, é mais fraco que o Kerberos e um alvo frequente de ataques de retransmissão. A especificação aberta da Microsoft, a MS-NLMP, na versão 37.0 de 30 de março de 2026 no dia em que foi lida, o descreve como um protocolo de autenticação do estilo desafio-resposta em que o servidor envia um desafio ao cliente e o cliente devolve uma resposta que é função do desafio, da senha do usuário e possivelmente de outras informações. Há variantes orientadas a conexão e sem conexão, e cada uma tem três versões, LM, NTLMv1 e NTLMv2, com o mesmo fluxo de mensagens e funções de resposta diferentes. As três mensagens são NEGOTIATE, CHALLENGE e AUTHENTICATE, cada uma começando com a assinatura de oito bytes NTLMSSP seguida de um nulo, um MessageType (0x00000001 para NEGOTIATE), os NegotiateFlags e campos de deslocamento e comprimento que apontam para uma carga com o domínio, a estação de trabalho e, na última mensagem, as respostas. Protocolos de aplicação embutem essas mensagens, e é por isso que o NTLM aparece dentro de HTTP, SMB e LDAP igualmente, e por isso desligá-lo é um problema de inventário antes de ser um de configuração.
O NTLM é o protocolo de autenticação que o Windows usava antes do Kerberos, e sobrevive porque compatibilidade dura mais que intenção de projeto. É um esquema de desafio e resposta: o servidor envia um desafio, o cliente prova conhecer o hash da senha sem enviá-lo, e nenhum terceiro é consultado. A especificação aberta da própria Microsoft, a MS-NLMP, que no dia da leitura estava na versão 37.0 de 30 de março de 2026, põe o escopo numa frase: ela especifica o protocolo de autenticação NT LAN Manager (NTLM), usado no Windows para autenticação entre clientes e servidores, e acrescenta que o NTLM é usado por protocolos de aplicação para autenticar usuários remotos e, opcionalmente, prover segurança de sessão quando a aplicação pede. Essa última cláusula é a razão de o NTLM ser encontrado dentro de tantos outros protocolos: ele não é um protocolo a que se conecta, e sim uma sequência de mensagens que HTTP, SMB, LDAP e outros carregam em seus próprios headers de autenticação.
A visão geral da especificação descreve a forma que toda versão compartilha. O NTLM é um protocolo de autenticação do estilo desafio-resposta: o servidor envia um desafio ao cliente, e o cliente devolve uma resposta que é função do desafio, da senha do usuário e possivelmente de outras informações. Há duas variantes, a orientada a conexão, em que uma mensagem NEGOTIATE do cliente precede o CHALLENGE do servidor e o AUTHENTICATE do cliente, e a sem conexão, que não consegue enviar NEGOTIATE_MESSAGE; e o documento diz que cada uma dessas variantes tem três versões, LM, NTLMv1 e NTLMv2, com o mesmo fluxo de mensagens, diferindo apenas na função usada para calcular os campos de resposta a partir do desafio e em quais campos de resposta são preenchidos. LM é a resposta do LAN Manager, NTLMv1 a primeira resposta NT e NTLMv2 a ainda em uso, e as duas primeiras são as que um domínio endurecido recusa.
As mensagens em si são estruturas simples, e é isso que torna o NTLM fácil de decodificar numa captura. A NEGOTIATE_MESSAGE da seção 2.2.1.1 começa com uma Signature, um vetor de 8 bytes que deve conter a string ASCII N, T, L, M, S, S, P seguida de um nulo, seguida de um MessageType de 0x00000001, dos NegotiateFlags que anunciam o que o cliente suporta, de DomainNameFields e WorkstationFields, cada um um comprimento, um comprimento máximo e um deslocamento dentro da carga, de uma estrutura Version opcional presente só quando a flag NTLMSSP_NEGOTIATE_VERSION está acesa, e do Payload para o qual os deslocamentos apontam. As mensagens CHALLENGE e AUTHENTICATE seguem o mesmo padrão com o desafio do servidor e as respostas do cliente no lugar dos nomes. Quem já viu a string TlRMTVNTUAAB no início de um header HTTP Authorization viu uma mensagem NEGOTIATE: é o Base64 dessa assinatura e desse tipo de mensagem.
Essa última propriedade, nenhum terceiro consultado, é a razão de ele persistir. O Kerberos precisa de um controlador de domínio alcançável no momento da autenticação; o NTLM não, então ele permanece como recurso de contingência quando uma máquina se conecta por endereço IP em vez de por nome, quando o nome principal de serviço está ausente ou errado, ou quando qualquer coisa no caminho do Kerberos falha. A maior parte do tráfego NTLM que sobrevive num domínio moderno é uma falha de Kerberos que ninguém diagnosticou. Suas fraquezas são estruturais, não incidentais. O hash da senha funciona como a credencial, então roubá-lo equivale a conhecer a senha, que é o pass-the-hash. Ataques de retransmissão encaminham uma tentativa de autenticação a um serviço diferente, e o protocolo não oferece por padrão amarração de canal para impedi-los. A direção é desligá-lo por completo, e o obstáculo prático é sempre um problema de inventário: descobrir o que ainda depende dele antes de desligá-lo, o que significa auditar os eventos de autenticação nos controladores de domínio e nos servidores de aplicação que ainda aceitam o header NTLMSSP. O artigo sobre o NTLM percorre as três mensagens e as versões, e os verbetes Active Directory e Kerberos descrevem o protocolo que o substituiu.
Também conhecido como: ntlm, ntlmssp, ntlmv1, ntlmv2, lan manager authentication, ms-nlmp
Fontes
- Microsoft NTLM documentation
- Microsoft Open Specifications, MS-NLMP, NT LAN Manager (NTLM) Authentication Protocol, version 37.0 of 30 March 2026 on the day read: the scope, the challenge-response overview, the connection-oriented and connectionless variants and the LM, NTLMv1 and NTLMv2 versions (read 2026-10-06)
- MS-NLMP section 2.2.1.1, NEGOTIATE_MESSAGE: the NTLMSSP signature, MessageType 0x00000001, NegotiateFlags, the domain and workstation fields, the optional Version and the Payload (read 2026-10-06)