LLMNR poisoning: cómo Windows entrega hashes de contraseña en la red

Alguien en la red escribe \\FILESRV en el Explorador de Windows — un carácter equivocado, el servidor con ese nombre no existe en el DNS. En vez de devolver un error y quedar ahí, Windows levanta la mano y le pregunta a gritos a todos en la red local: "¿alguien aquí se llama FILESRV?" El atacante, que está escuchando con el Responder corriendo en su laptop, responde de inmediato: "Soy yo." Windows lo acepta, intenta autenticarse — y le entrega el hash NTLMv2 del usuario conectado en bandeja de plata.

Esto es el LLMNR poisoning. Uno de los ataques más efectivos en redes internas Windows y, por lejos, uno de los más descuidados en el hardening de entornos corporativos.

Qué es LLMNR y por qué existe

LLMNR (Link-Local Multicast Name Resolution) es un protocolo de Microsoft definido en la RFC 4795, introducido en Windows Vista como respaldo de resolución de nombres. El flujo de resolución de Windows funciona así: primero intenta la caché local, después consulta el DNS configurado. Si el DNS falla o no responde, Windows recurre a LLMNR — que envía un paquete multicast UDP a todos los dispositivos de la subred preguntando quién tiene ese nombre. Cualquier máquina puede responder.

El protocolo fue creado para redes pequeñas sin servidor DNS, donde la conveniencia importa más que la seguridad. En redes corporativas con Active Directory y DNS funcionando no sería necesario — pero sigue activo por defecto en Windows hasta hoy.

Cómo funciona el ataque en la práctica

El montaje es simple: un atacante con acceso a la red local ejecuta el Responder (herramienta open-source de Laurent Gaffie, ampliamente usada en pruebas de penetración). El Responder se queda escuchando broadcasts LLMNR y NBT-NS en la red. Cuando una máquina pregunta por un nombre inexistente en el DNS, el Responder responde fingiendo ser ese servidor.

1. La víctima intenta acceder a un recurso compartido con un nombre incorrecto — error de tipeo, script mal configurado, acceso directo roto, cualquier cosa que termine en una consulta LLMNR.
2. El Responder responde al broadcast diciendo que es ese servidor.
3. El Windows de la víctima intenta autenticarse vía NTLM con el servidor falso, enviando el hash NTLMv2 del usuario conectado.
4. El hash queda capturado y puede crackearse offline con Hashcat o John the Ripper, o retransmitirse de inmediato hacia otro sistema vía ntlmrelayx (parte del proyecto Impacket).

¿Qué datos puede capturar el atacante?

El hash NTLMv2 del usuario autenticado en la máquina en el momento del ataque. El atacante no ve la contraseña en texto claro — pero el hash NTLMv2 puede crackearse offline contra wordlists o por fuerza bruta. Si la contraseña es débil o está en listas conocidas como rockyou.txt, cae en minutos. Si es una contraseña de dominio reutilizada en otros sistemas, el daño se multiplica.

NBT-NS: el hermano mayor con el mismo problema

NBT-NS (NetBIOS Name Service) es un protocolo todavía más antiguo que hace básicamente lo mismo: resolución de nombres por broadcast UDP en la red local. También activado por defecto en Windows, también abierto al mismo tipo de envenenamiento. El Responder ataca a ambos en paralelo.

La presencia de NBT-NS es especialmente común en redes con infraestructura heredada — servidores Windows Server 2008/2012 todavía activos, impresoras de red antiguas, aplicaciones que dependen de NetBIOS. Deshabilitar LLMNR sin abordar NBT-NS deja la mitad del vector abierto.

Qué se puede hacer con un hash NTLMv2 capturado

Dos opciones principales:

• Crack offline: el hash se guarda y se ataca con GPU y wordlist. Contraseñas de hasta 8 caracteres con complejidad moderada caen en horas con hardware accesible.
• NTLM relay: en lugar de crackear, el atacante usa el hash en tiempo real para autenticarse en otro sistema de la red — sin necesitar jamás la contraseña. Si el usuario capturado tiene privilegio de administrador local en otra máquina y esa máquina no exige firma SMB, el atacante obtiene acceso inmediato.

¿Se puede usar el hash sin descubrir la contraseña?

Sí — eso es el relay attack. El hash NTLMv2 capturado se retransmite a otro host antes de que expire. La herramienta ntlmrelayx lo ejecuta automáticamente y está documentada en MITRE ATT&CK T1557.001. La defensa específica contra el relay es habilitar la firma SMB obligatoria en todos los hosts del entorno.

Cómo deshabilitar LLMNR y NBT-NS

Ambas medidas son simples y no generan impacto en redes con DNS configurado correctamente.

Deshabilitar LLMNR vía Group Policy

Configuración del equipo
  → Plantillas administrativas
    → Red
      → Cliente DNS
        → Desactivar la resolución de nombres multicast
          → Habilitada

En máquinas independientes sin dominio, la misma configuración puede hacerse vía gpedit.msc o directamente en el registro: HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient, valor EnableMulticast de tipo DWORD igual a 0.

Deshabilitar NBT-NS vía PowerShell

$adaptadores = Get-WmiObject Win32_NetworkAdapterConfiguration -Filter "IPEnabled = True"
foreach ($a in $adaptadores) {
    $a.SetTcpipNetbios(2)  # 0=lo define el DHCP, 1=activo, 2=desactivado
}

El método SetTcpipNetbios(2) desactiva NetBIOS sobre TCP/IP en cada adaptador de red activo. El cambio es inmediato — no requiere reinicio.

Hardening complementario

Deshabilitar los protocolos elimina el vector de envenenamiento, pero el entorno queda más robusto con medidas adicionales:

• Habilitar la firma SMB obligatoria: bloquea el relay attack incluso si algún broadcast LLMNR se escapa. Vía GPO: Microsoft Network Server: Digitally sign communications (always).
• Monitorear autenticaciones NTLM anómalas: el post sobre auditoría de logs con PowerShell en Windows cubre cómo configurar y consultar eventos de seguridad para detectar autenticaciones sospechosas.
• Migrar a autenticación moderna: las cuentas que usan passkeys o FIDO2 no tienen hash NTLMv2 para capturar — el ataque entero se queda sin objetivo.
• Contraseñas largas y únicas: los hashes de contraseñas con 16+ caracteres aleatorios resisten el crack offline por un tiempo inviable en la práctica.

Para una lista más amplia de configuraciones defensivas en Windows, el post sobre las 10 configuraciones de seguridad de Windows 11 cubre otras medidas que complementan la desactivación de LLMNR.

Por qué esto todavía aparece en auditorías en 2026

LLMNR existe desde 2007. El ataque de envenenamiento es público y está documentado desde al menos 2013. La corrección toma menos de cinco minutos vía GPO. Y aun así se encuentra rutinariamente activo en auditorías de redes corporativas.

El motivo es que el ataque no aparece en los escaneos de vulnerabilidades convencionales — no es un CVE, no es un parche faltante, no es una versión desactualizada. Es un protocolo funcionando exactamente como fue diseñado, en un diseño que nunca consideró entornos adversarios. Deshabilitar LLMNR y NBT-NS es el tipo de medida que necesita que alguien sepa que el vector existe.

Ahora ya lo sabes. Dos minutos en gpedit.msc cierran este vector en tu entorno.