Ataques NTLM Relay: Deteccao e Prevencao

Ataques NTLM Relay continuam relevantes porque muitos ambientes do Active Directory ainda permitem pelo menos um caminho passível de relay: SMB não assinado, tratamento fraco de LDAP, exposição do registro web do AD CS, caminhos de coerção ou comportamento legado de resolução de nomes que faz com que máquinas se autentiquem onde não deveriam.

O Que É NTLM Relay?

Ataques NTLM Relay são técnicas de ataque de rede em que um invasor captura uma troca de autenticação NTLM de um sistema e a encaminha para outro serviço em tempo real. O invasor não precisa quebrar o hash da senha para isso. O serviço-alvo aceita a autenticação repassada porque a troca de desafio-resposta NTLM ainda é válida para aquela sessão.

Na prática, o NTLM relay importa quando três condições se alinham:

uma vítima pode ser coagida ou enganada a se autenticar via NTLM
o invasor consegue alcançar a vítima e o serviço-alvo na rede
o serviço-alvo ainda aceita NTLM de uma forma que não exige a proteção que bloquearia o caminho de relay

É por isso que o relay não é uma única falha isolada. É a combinação do uso de NTLM, resolução de nomes fraca ou caminhos de coerção, e configurações permissivas de serviço, como SMB não assinado ou tratamento fraco de LDAP.

Como Funciona

O NTLM é um protocolo de desafio-resposta:

o cliente envia uma mensagem de negociação (negotiate)
o servidor envia um desafio (challenge)
o cliente retorna uma mensagem de autenticação (authenticate) derivada desse desafio

Em um ataque de relay, o invasor encaminha essas mensagens entre a vítima e o serviço-alvo. O invasor não está quebrando o protocolo criptograficamente. O invasor está abusando do fato de que o serviço-alvo está disposto a aceitar o contexto de autenticação repassado.

As vítimas costumam ser coagidas a se autenticar por meio de caminhos fracos de resolução de nomes, como LLMNR ou NBT-NS, ou por meio de caminhos de coerção de aplicativos e serviços que disparam autenticação de saída.

A documentação de hardening de SMB da Microsoft afirma que a assinatura SMB ajuda a prevenir ataques de relay e que exigir a assinatura faz com que clientes e servidores rejeitem pacotes não assinados. É por isso que a assinatura SMB é um controle contra os resultados de relay SMB, e não uma configuração cosmética.

Ataques NTLM Relay: Caminhos de Relay Comuns e O Que os Bloqueia

Caminho de relay	O que o invasor deseja	Principal bloqueio
SMB relay	Administrador local ou execução de código em um servidor membro	Assinatura SMB obrigatória no alvo
LDAP relay	Alterações no diretório quando a identidade repassada tem direitos suficientes e o caminho-alvo permite	Assinatura LDAP e hardening do caminho de diretório
AD CS web enrollment relay	Emissão de certificado utilizável para abuso de autenticação posterior	Remoção ou hardening do caminho de registro vulnerável

Uma análise útil deve, portanto, separar o transporte do relay do resultado obtido. Bloquear o SMB relay não elimina automaticamente as oportunidades de relay LDAP ou AD CS.

Também vale a pena separar a exposição de estações de trabalho da exposição de servidores. Um caminho de relay que atinge apenas hosts membros de baixo valor ainda é um problema, mas a prioridade de resposta muda imediatamente quando o mesmo caminho pode alcançar controladores de domínio, servidores de gerenciamento, serviços de certificado ou contas de serviço fortemente delegadas.

Por que reduzir o NTLM não é o mesmo que um único valor de registro

Restrições de NTLM, assinatura SMB, assinatura LDAP, EPA/channel binding, hardening da resolução de nomes e hardening dos serviços de certificado tratam de partes diferentes do ataque. Um tenant pode configurar uma política relacionada a NTLM e ainda assim expor relay se um serviço-alvo aceitar a troca repassada.

Trate o conjunto de controles como algo em camadas:

reduza o uso desnecessário de NTLM onde o caminho da aplicação suportar Kerberos ou autenticação mais forte
exija assinatura ou proteção equivalente nos serviços que ainda aceitam NTLM
remova comportamentos de resolução de nomes que criam oportunidades fáceis de captura de autenticação
reforce os caminhos de AD CS e LDAP que transformam um relay em escalonamento de domínio
monitore o uso de NTLM para que as exceções permaneçam visíveis

A Cadeia de Ataque

Passo 1 - Montar a Infraestrutura de Relay

responder -I eth0 -rdw --no-HTTP-Server --no-SMB-Server
ntlmrelayx.py -tf targets.txt -smb2support -socks

Passo 2 - Capturar e Encaminhar a Autenticação

Quando um sistema vítima tenta se autenticar em um listener controlado pelo invasor, o invasor encaminha essa troca NTLM para o alvo escolhido.

# Exemplo de saída de sucesso
# [*] Autenticando em smb://10.10.0.50 como CORP/jsmith SUCESSO

Passo 3 - Usar a Identidade Repassada Onde Importa

# Exemplo de alvo LDAP
ntlmrelayx.py -t ldap://dc01.corp.local --escalate-user attacker

# Exemplo de alvo SMB
ntlmrelayx.py -tf targets.txt -smb2support -c 'whoami'

# Exemplo de caminho AD CS
ntlmrelayx.py -t http://ca.corp.local/certsrv/certfnsh.asp --adcs --template Machine

A sessão repassada só é tão poderosa quanto o alvo e a identidade repassada permitirem. A pergunta importante da análise não é se uma ferramenta consegue emitir a requisição. É se o ambiente ainda expõe um alvo onde a requisição resulta em privilégio significativo.

Detecção

IDs de Evento do Windows

ID de Evento	Origem	O Que Procurar
4624	Sistema-alvo	Logons de rede do Tipo 3 vindos de um host de origem incomum
4776	DC	Atividade de validação NTLM que não se encaixa no caminho normal da conta
4625	Sistema-alvo	Logons de rede falhados repetidos em torno de testes de relay ou encaminhamento malsucedido

A Microsoft documenta o evento 4776 como validação de credenciais NTLM. Para contas de domínio, o controlador de domínio é a fonte autoritativa e pode mostrar tentativas de validação NTLM para contas de domínio. Isso é útil, mas não mostra todos os detalhes do serviço de destino, portanto deve ser correlacionado com os logs de logon e de serviço do lado do alvo.

Indícios Práticos de Detecção

a mesma conta se autentica em vários hosts em uma janela curta de tempo, a partir de uma única origem
atividade NTLM do lado do servidor aparece vinda de estações de trabalho que normalmente não iniciam esse tráfego
a autenticação repassada é seguida imediatamente por modificação de diretório, atividade de administrador local ou comportamento de registro de certificado
uma conta de máquina se autentica em um serviço incomum após um gatilho semelhante a coerção
validação NTLM aparece onde normalmente o Kerberos deveria ser usado

Consulta de Detecção SIEM (Elastic KQL)

event.code: '4624' AND
winlog.event_data.LogonType: '3' AND
winlog.event_data.AuthenticationPackageName: 'NTLM'

Essa consulta, por si só, não é específica para relay. Ela se torna útil quando você a enriquece com a função do host, os caminhos de autenticação esperados e o agrupamento por tempo.

Melhor detecção por meio de correlação

Uma detecção de relay robusta geralmente precisa de pelo menos dois destes sinais:

validação NTLM vinda de uma estação de trabalho ou servidor inesperado
logon do Tipo 3 do lado do alvo usando NTLM
acesso a serviços relevantes para coerção ou a named pipes
ação imediata de diretório, administrador local ou registro de certificado após a autenticação
host de origem do qual não se espera que inicie autenticação em direção ao alvo

Essa correlação é mais defensável do que alertar sobre todo o tráfego NTLM. Muitos ambientes ainda têm dependências legítimas de NTLM, portanto alertas amplos de NTLM geram ruído, a menos que a equipe já tenha reduzido o uso.

Remediação

Vitória rápida: exija a assinatura SMB nos sistemas que ainda aceitam SMB não assinado. Isso elimina o resultado mais comum de relay SMB, mas não substitui o hardening dos caminhos de LDAP e de certificados.

1. Exigir a Assinatura SMB

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature

Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbServerConfiguration -RequireSecuritySignature $true

Revise tanto os servidores quanto os clientes. Uma implantação parcial deixa caminhos passíveis de relay para trás. A Microsoft documenta que exigir a assinatura SMB faz com que o cliente ou o servidor rejeite pacotes não assinados, que é o comportamento necessário para impedir os resultados de relay SMB.

2. Desativar Caminhos Fracos de Resolução de Nomes

# Configuração de GPO
# Configuração do Computador > Modelos Administrativos > Rede > Cliente DNS
# Desativar a resolução de nome multicast = Habilitado

A documentação de política da Microsoft para o Cliente DNS afirma que habilitar essa política desativa o LLMNR em todos os adaptadores de rede disponíveis. Revise também a resolução de nomes NetBIOS legada onde ela ainda existir no ambiente.

3. Restringir o NTLM Onde o Caminho de Negócio Permitir

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 5

Não implante restrições de NTLM às cegas. Comece com o modo de auditoria e o levantamento de dependências. Em seguida, restrinja por servidor, conta e caminho de aplicação onde a dependência de negócio for compreendida.

4. Reforçar os Alvos de Diretório e Certificado

Se os controladores de domínio ou os serviços de certificado ainda estiverem acessíveis por meio de caminhos NTLM favoráveis a relay, a remediação não está concluída. Revise:

os requisitos de assinatura LDAP nos controladores de domínio
o channel binding do LDAP e o Extended Protection, onde aplicável
a exposição do registro web do AD CS e dos modelos de certificado
se servidores de alto valor ainda aceitam NTLM onde Kerberos ou controles mais fortes deveriam ser usados
se os caminhos de registro de certificado conseguem emitir certificados capazes de autenticação para identidades de máquina ou usuário repassadas

5. Validar serviço por serviço, não política por política

A pergunta sobre relay é sempre concreta: essa autenticação capturada ou coagida pode ser repassada para este alvo e produzir este resultado? Valide os caminhos de SMB, LDAP, AD CS e servidores de gerenciamento de forma independente. Um relatório de GPO "verde" não é suficiente se uma OU de exceção, um appliance legado ou um endpoint de serviço de certificado permanecerem passíveis de relay.

Validar Após o Hardening

A condição de sucesso não é "a GPO existe". É que o serviço-alvo não aceita mais o caminho repassado que importava.

reteste alvos SMB representativos e confirme que exigem assinatura
verifique se o caminho da vítima que antes gerava tráfego LLMNR, NBT-NS ou outro tráfego NTLM de saída não produz mais o mesmo resultado
confirme que os alvos de diretório e de certificado mais importantes deixaram de ser passíveis de relay a partir do mesmo ponto de apoio
revise a atividade recente de 4624 e 4776 para garantir que o ambiente ainda funciona para usuários legítimos enquanto o caminho abusivo foi eliminado
revise a configuração de assinatura SMB de clientes e servidores a partir de endpoints em cada OU principal ou grupo de gerenciamento de dispositivos
verifique se a exposição do registro web do AD CS e dos modelos de certificado foi corrigida, caso tenham feito parte da cadeia de relay

Essa validação deve ser realizada em sistemas relevantes para a produção, não apenas em uma máquina de laboratório que nunca fez parte do risco original.

Como a EtcSec Detecta Isso

A EtcSec correlaciona as condições que tornam o relay viável: uso de NTLM, alvos favoráveis a relay e fraquezas de configuração próximas, como SMB fraco, LDAP fraco ou exposição do registro de certificado. Isso é mais útil do que um único alerta isolado, porque a mesma rede pode conter tanto tráfego NTLM inofensivo quanto um pequeno número de caminhos que são, de fato, exploráveis.

Ataques NTLM Relay: Sequestrar Autenticacao Sem Crackear Senhas