# NTLM explicado: três mensagens, três versões e por que ele ainda está na sua rede

> O que o NT LAN Manager de fato é, a partir da especificação da própria Microsoft: um desafio-resposta carregado dentro de outros protocolos, em mensagens NEGOTIATE, CHALLENGE e AUTHENTICATE que começam com a assinatura NTLMSSP; as variantes orientada a conexão e sem conexão; as versões LM, NTLMv1 e NTLMv2 que compartilham um fluxo e diferem na função de resposta; como reconhecê-lo num cabeçalho HTTP; por que sobrevive onde o Kerberos não alcança; o que pass-the-hash e retransmissão significam para ele; e como descobrir o que ainda depende dele antes de desligá-lo.

Source: https://ronutz.com/pt-BR/learn/ntlm-explained  
Updated: 2026-10-06

---

## Um protocolo a que ninguém se conecta

O NTLM não é algo a que um cliente abre uma conexão. É uma sequência de mensagens que outros protocolos carregam em seus próprios espaços de autenticação: um cabeçalho HTTP Authorization, um estabelecimento de sessão SMB, um bind LDAP (Lightweight Directory Access Protocol). A especificação aberta da Microsoft, a MS-NLMP, que no dia da leitura estava na versão 37.0 de 30 de março de 2026, define seu 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. A visão geral do Windows Server da Microsoft o situa no sistema operacional: a autenticação NTLM é uma família de protocolos de autenticação englobados na Msv1_0.dll do Windows, e os protocolos de autenticação NTLM incluem o LAN Manager versões 1 e 2 e o NTLM versões 1 e 2.

## A forma que toda versão compartilha

A seção de visão geral da MS-NLMP descreve o mecanismo: o NTLM é 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. Nada que contenha a senha cruza o fio; o que cruza é um valor que só quem tem a senha, ou o hash derivado dela, poderia ter calculado, e o servidor, ou o controlador de domínio que ele consulta, calcula o mesmo valor e compara. Nenhum tíquete é emitido e nenhum terceiro precisa estar alcançável no momento da autenticação, o que é ao mesmo tempo a fraqueza do NTLM e a razão de ele ainda estar aqui.

A especificação define duas variantes. A orientada a conexão tem três mensagens: o cliente envia uma NEGOTIATE_MESSAGE anunciando o que suporta, o servidor responde com uma CHALLENGE_MESSAGE carregando o desafio, e o cliente envia uma AUTHENTICATE_MESSAGE carregando as respostas. A variante sem conexão, usada onde não há troca prévia para carregar a primeira mensagem, não consegue enviar uma NEGOTIATE_MESSAGE e começa no desafio. E, nas duas, diz a MS-NLMP, cada uma dessas variantes tem três versões: LM, NTLMv1 e NTLMv2; o fluxo de mensagens das três é o mesmo, e as únicas diferenças são a função usada para calcular os campos de resposta a partir do desafio e quais campos de resposta são preenchidos. LM é a resposta do LAN Manager, NTLMv1 a primeira resposta NT e NTLMv2 a ainda em uso; as duas primeiras são o que um domínio endurecido é configurado para recusar.

## As mensagens, byte a byte

As mensagens são estruturas simples, e é por isso que o NTLM é fácil de reconhecer numa captura e por isso um decodificador para ele é um programa pequeno. A seção 2.2.1.1 da MS-NLMP define a NEGOTIATE_MESSAGE como: uma Signature, um vetor de 8 bytes que deve conter a string ASCII N, T, L, M, S, S, P seguida de um nulo; um MessageType de 0x00000001; os NegotiateFlags, um campo de 32 bits em que o cliente anuncia os recursos que suporta; DomainNameFields e WorkstationFields, cada um um comprimento, um comprimento máximo e um deslocamento dentro da carga da mensagem; uma estrutura Version, presente só quando a flag NTLMSSP_NEGOTIATE_VERSION está acesa; e o Payload, a área de comprimento variável para a qual os deslocamentos apontam. A CHALLENGE_MESSAGE e a AUTHENTICATE_MESSAGE seguem o mesmo padrão, com o desafio do servidor e as respostas LM e NT do cliente no lugar dos nomes, e a AUTHENTICATE_MESSAGE é onde a versão aparece, já que são os campos de resposta que diferem.

A consequência prática é uma assinatura que qualquer um aprende a reconhecer. Um cliente HTTP autenticando com NTLM envia um cabeçalho Authorization cujo valor começa com o Base64 dos primeiros bytes de uma NEGOTIATE_MESSAGE, e o Base64 da assinatura NTLMSSP, do seu nulo final e do tipo de mensagem 1 é TlRMTVNTUAAB. Um cabeçalho que começa com esses doze caracteres é uma negociação NTLM; um que começa com TlRMTVNTUAAC é o desafio do servidor e TlRMTVNTUAAD a autenticação do cliente, pela mesma aritmética sobre os tipos de mensagem 2 e 3. SMB e LDAP carregam as mesmas estruturas em suas próprias molduras.

## Por que ele ainda está na rede

A visão geral da Microsoft é explícita sobre a alternativa preferida e sobre os usos que restam. A autenticação Kerberos versão 5 é o método de autenticação preferido para ambientes Active Directory, mas uma aplicação da Microsoft ou de terceiros ainda pode usar NTLM. E: a autenticação NTLM continua suportada e precisa ser usada para autenticação Windows com sistemas configurados como membros de um grupo de trabalho, e também é usada para a autenticação de logon local em máquinas que não são controladores de domínio. O Kerberos precisa de um controlador de domínio alcançável no momento da autenticação e de um nome principal de serviço registrado para a coisa que está sendo alcançada; o NTLM não precisa de nenhum dos dois. Então o NTLM é o que acontece quando uma máquina se conecta a um servidor por endereço IP em vez de por nome, quando o nome principal de serviço está ausente ou duplicado, quando um cliente não está ingressado no domínio, quando uma aplicação foi escrita para pedi-lo ou quando qualquer coisa no caminho do Kerberos falha. A maior parte do tráfego NTLM de um domínio moderno é uma falha de Kerberos que ninguém diagnosticou, o que é uma boa notícia num sentido: consertar a falha remove o tráfego.

## Quais são as fraquezas

Dois problemas estruturais decorrem do projeto, e os dois são familiares a quem já leu um relatório de incidente. O hash da senha funciona como a credencial. A resposta é função do desafio e do hash, então quem tem o hash consegue calcular respostas sem jamais conhecer a senha; roubar o hash da memória de uma máquina ou de um cofre de credenciais equivale a roubar a senha, que é o pass-the-hash. E uma autenticação pode ser retransmitida. Como a resposta é calculada para um desafio e o desafio pode vir de qualquer um com quem o cliente aceite falar, um atacante posicionado entre um cliente e um servidor pode tomar a autenticação do cliente e apresentá-la a outro serviço, e o protocolo não oferece por padrão amarração de canal para impedir isso. Nenhuma das duas fraquezas é um defeito de implementação; as duas são propriedades de um desafio-resposta projetado antes de ataques de retransmissão fazerem parte do modelo de ameaças de alguém, e as duas são a razão de a direção de todo domínio ser restringir o NTLM e depois removê-lo.

## Encontrá-lo antes de desligá-lo

O obstáculo à remoção nunca é a chave; é saber o que vai quebrar. A visão geral da Microsoft aponta o ferramental: novas ferramentas e configurações foram acrescentadas para ajudar a descobrir como o NTLM é usado, de modo a restringir seletivamente o tráfego NTLM. O método é o que a visão geral sugere. Audite primeiro os eventos de autenticação NTLM nos controladores de domínio e nos servidores membros, por meses e não por dias, porque alguns dependentes se autenticam trimestralmente. Para cada origem, encontre a razão: uma string de conexão por endereço IP, um nome principal de serviço ausente, um dispositivo não ingressado, uma aplicação que fixa o método no código. Conserte as razões que são falhas de Kerberos, o que remove a maior parte do volume sem custo para ninguém. Depois restrinja o NTLM com exceções para os dependentes que restarem, e encolha a lista de exceções num calendário. O artigo companheiro sobre Kerberos e SPNEGO descreve o protocolo que deveria estar respondendo no lugar, e a lista curta de jeitos de ele quebrar é a mesma lista que gera os recursos ao NTLM.

## Onde o NTLM encontra o resto desta série

O desafio-resposta MS-CHAP-V2 que o PEAP carrega pelo Wi-Fi é parente do do NTLM, calculado a partir do mesmo hash NT da senha, e é por isso que um servidor RADIUS (Remote Authentication Dial-In User Service) consegue verificar logins PEAP-MSCHAPv2 contra um domínio e por isso o diretório precisa guardar esse hash; o artigo sobre 802.1X cobre o método e seu túnel. O Active Directory guarda os hashes, emite os tíquetes Kerberos que deveriam substituir o NTLM e responde às consultas LDAP que mapeiam um login a uma pessoa; seu verbete e o artigo de fundamentos de LDAP carregam esse lado.

## Fontes

- [Microsoft Open Specifications, MS-NLMP, NT LAN Manager (NTLM) Authentication Protocol, versão 37.0 de 30 de março de 2026: a declaração de escopo e a visão geral do desafio-resposta, as variantes orientada a conexão e sem conexão, as versões LM, NTLMv1 e NTLMv2 (lida em 06/10/2026)](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/b38c36ed-2804-4868-a9ff-8dd3182128e4)
- [MS-NLMP, seção 2.2.1.1 NEGOTIATE_MESSAGE: a Signature, o MessageType, os NegotiateFlags, os campos de domínio e estação de trabalho, a estrutura Version e o Payload (lida em 06/10/2026)](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/b34032e5-3aae-4bc6-84c3-c6d80eadf7f2)
- [Microsoft Learn, NTLM Overview (Windows Server): a família na Msv1_0.dll, os usos em grupo de trabalho e logon local, o Kerberos como método preferido, as ferramentas para descobrir e restringir o NTLM (lida em 06/10/2026)](https://learn.microsoft.com/en-us/windows-server/security/kerberos/ntlm-overview)
- [RFC 2759, Microsoft PPP CHAP Extensions, Version 2, Zorn, janeiro de 2000: a resposta MS-CHAP-V2 calculada a partir de um hash MD4 da senha, o parente que o PEAP carrega (lida em 06/10/2026)](https://www.rfc-editor.org/rfc/rfc2759)