Deshabilitar LLMNR, NBT-NS, mDNS y WPAD en AD

Cuando DNS no puede resolver un nombre, Windows pregunta a la red local: mediante LLMNR (UDP 5355), NetBIOS Name Service (UDP 137) y, en las versiones actuales, DNS multicast (UDP 5353). Nada autentica la respuesta. Cualquiera en el segmento que ejecute un envenenador como Responder o Inveigh puede contestar «soy yo», y la víctima se conecta entonces y envía una autenticación NTLM, que se captura para descifrarla o se reenvía en vivo. WPAD lo empeora: los navegadores y WinHTTP buscan wpad automáticamente, así que la víctima ni siquiera tiene que escribir mal nada.

Esto es el envenenamiento LLMNR, y aparece en casi todas las pruebas de penetración internas. El pilar de NTLM y protocolos heredados muestra la directiva de LLMNR y un script de NetBIOS por adaptador. Esta guía cubre los cuatro protocolos, las opciones que sobreviven a nuevos adaptadores de red y a dispositivos fuera del dominio, y cómo demostrar el resultado desde la red en lugar de desde una clave del registro.

Medir: qué responde hoy

Antes de cambiar nada, obtenga una referencia de cuánto tráfico de resolución alternativa tiene. Una captura de paquetes en algunas VLAN de usuarios (filtrando por UDP 5355, 137 y 5353) muestra qué equipos envían consultas y para qué nombres. Los nombres son la parte útil: revelan erratas en unidades asignadas, destinos de accesos directos obsoletos y scripts que apuntan a servidores retirados. Corríjalos en DNS o en la configuración que los referencia, porque cada uno es una oportunidad de envenenamiento garantizada.

Compruebe qué equipos ya tienen los protocolos deshabilitados:

$targets = (Get-ADComputer -Filter 'OperatingSystem -like "*Windows*"' -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com').DNSHostName
Invoke-Command -ComputerName $targets -ErrorAction SilentlyContinue -ScriptBlock {
    $llmnr = (Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -ErrorAction SilentlyContinue).EnableMulticast
    $mdns  = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters' -ErrorAction SilentlyContinue).EnableMDNS
    $nbt   = Get-CimInstance Win32_NetworkAdapterConfiguration -Filter 'IPEnabled=True' |
             Select-Object -ExpandProperty TcpipNetbiosOptions
    [PSCustomObject]@{ Host = $env:COMPUTERNAME; LLMNR = $llmnr; mDNS = $mdns; NetBIOS = ($nbt -join ',') }
} | Export-Csv .\name-resolution-posture.csv -NoTypeInformation

Para TcpipNetbiosOptions, 0 significa «usar la configuración de DHCP», 1 habilitado y 2 deshabilitado. Un valor de LLMNR o mDNS vacío significa el valor predeterminado, que es habilitado.

Deshabilitar LLMNR

Directiva de grupo:

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

Esto escribe EnableMulticast = 0 en HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient. Aplíquelo a todas las OU que contengan equipos Windows, servidores incluidos. Los controladores de dominio y los servidores rara vez necesitan resolución de nombres alternativa.

Deshabilitar NetBIOS sobre TCP/IP

NetBIOS se configura por adaptador, y por eso los scripts que se ejecutan una sola vez pasan por alto las estaciones de acoplamiento, los adaptadores VPN y las nuevas tarjetas de red. Use controles en capas.

Opción DHCP para clientes dinámicos

En los servidores DHCP de Windows, configure la opción de proveedor de Microsoft en cada ámbito o a nivel de servidor:

# Clase de proveedor "Microsoft Windows 2000 Options", opción 001 "Microsoft Disable Netbios Option", valor 2
Set-DhcpServerv4OptionValue -ComputerName dhcp01.corp.example.com -ScopeId 10.20.0.0 `
    -VendorClass 'Microsoft Windows 2000 Options' -OptionId 1 -Value 2

Los clientes con TcpipNetbiosOptions = 0 (el valor predeterminado) deshabilitan entonces NetBIOS en ese adaptador en la siguiente renovación de la concesión. Los servidores DHCP de terceros pueden enviar la misma opción específica del proveedor; consulte la documentación de su proveedor para la sintaxis.

Registro y GPO para adaptadores estáticos y VPN

Para los adaptadores que no usan DHCP de Windows, establezca NetbiosOptions = 2 en todas las interfaces bajo HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID}. Un script de inicio o elementos de registro de Group Policy Preferences con una colección que cubra todas las claves de interfaz mantienen la configuración aplicada a los nuevos adaptadores:

Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces' |
    ForEach-Object { Set-ItemProperty -Path $_.PSPath -Name NetbiosOptions -Value 2 -Type DWord }

Los archivos ADMX más recientes de Windows 11 incluyen una directiva "Configure NetBIOS settings" bajo el nodo DNS Client. Si todo su parque la admite, es una opción más limpia que los scripts; compare el texto de «compatible con» de la directiva con las compilaciones de cliente más antiguas que tenga.

Como capa adicional, establecer NodeType = 2 (nodo P) en HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters detiene las consultas de nombres por difusión incluso donde NetBIOS sigue habilitado.

Deshabilitar mDNS

Configure directamente el parámetro del cliente DNS mediante Group Policy Preferences:

HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
  EnableMDNS (DWORD) = 0

Las plantillas ADMX recientes de Windows 11 también exponen una directiva de mDNS bajo el nodo DNS Client. Pruebe esta primero en un piloto: algunas impresoras, dispositivos de transmisión y funciones de descubrimiento entre pares dependen de mDNS.

Bloquear WPAD

Las búsquedas WPAD proceden de los navegadores configurados con «Detectar la configuración automáticamente» y del servicio de proxy automático de WinHTTP. Una respuesta maliciosa puede llegar por cuatro vías, y cada una necesita su propio control:

1. Resolución multicast alternativa (LLMNR, NetBIOS, mDNS): se trata en las secciones anteriores.
2. DNS: los usuarios autenticados pueden crear registros en zonas integradas en AD de forma predeterminada, incluido wpad. La lista global de bloqueo de consultas del servidor DNS impide que los servidores DNS de Microsoft respondan a wpad e isatap aunque exista un registro así. Está habilitada de forma predeterminada, pero a menudo se vacía para que funcione una implementación legítima de WPAD.
3. Opción DHCP 252: asegúrese de que ningún ámbito la publique salvo que use WPAD deliberadamente.
4. La propia detección automática del cliente: si no usa WPAD, desactive la detección automática del proxy en los navegadores mediante sus directivas y configure el proxy de forma explícita o con una URL PAC.

# En cada servidor DNS: confirmar que la lista de bloqueo está habilitada y contiene wpad
Get-DnsServerGlobalQueryBlockList -ComputerName dc01.corp.example.com

# Restaurarla si alguien la ha vaciado
Set-DnsServerGlobalQueryBlockList -ComputerName dc01.corp.example.com -Enable $true -List 'wpad','isatap'

# Buscar registros wpad creados en zonas integradas en AD
Get-DnsServerZone -ComputerName dc01.corp.example.com | Where-Object { $_.IsDsIntegrated -and -not $_.IsReverseLookupZone } |
    ForEach-Object { Get-DnsServerResourceRecord -ComputerName dc01.corp.example.com -ZoneName $_.ZoneName -Name 'wpad' -ErrorAction SilentlyContinue }

Si realmente depende de WPAD, publique un registro wpad legítimo que usted controle, quite solo wpad de la lista de bloqueo y mantenga isatap en ella. Quien pueda escribir ese registro controla el proxy de sus usuarios, así que restrinja su ACL. La parte DNS de los controladores de dominio encaja de forma natural con el resto de su hardening de controladores de dominio.

Dispositivos que no administra

La directiva de grupo solo llega a los equipos Windows unidos al dominio. Al envenenador le da igual quién pregunte, y la víctima que importa es quien envía credenciales en respuesta, así que los dispositivos no administrados merecen atención:

• Los equipos Windows fuera del dominio (portátiles de contratistas, equipos de laboratorio, quioscos) mantienen los tres protocolos habilitados. La opción DHCP de NetBIOS sigue llegándoles, pero LLMNR y mDNS no. El control de acceso a la red o una VLAN separada para dispositivos no administrados limitan a qué pueden llegar y qué puede recopilar un envenenador en su segmento.
• macOS y Linux dependen de mDNS (Bonjour, Avahi) por diseño, y algunas distribuciones de Linux incluyen un respondedor LLMNR en systemd-resolved. Envían NTLM con menos frecuencia que Windows, pero los equipos Linux integrados en el dominio y los Mac con montajes SMB pueden hacerlo. Configure LLMNR=no y MulticastDNS=no en systemd-resolved en los equipos que administre, y use su MDM para macOS.
• Los servidores de DMZ y de redes de administración suelen quedar fuera del ámbito principal de las GPO. Compruebe que la misma base de referencia está vinculada a sus OU, o aplicada localmente con LGPO si no están unidos al dominio.

La segmentación también importa por sí misma. La resolución de nombres multicast es de enlace local: un envenenador tiene que estar en el mismo dominio de difusión que la víctima. Las VLAN de usuario pequeñas, el aislamiento de clientes en Wi-Fi y las VLAN privadas para servidores reducen la audiencia de cualquier envenenador que consiga entrar en la red, lo que reduce el daño causado por los dispositivos que no puede configurar.

Verificar

Las comprobaciones del registro son necesarias, pero no suficientes. Verifique desde la red:

• Vuelva a ejecutar el script de postura: LLMNR y mDNS deben estar a 0, y NetBIOS a 2 en todos los adaptadores.
• Repita la captura de paquetes en las mismas VLAN. No debería ver consultas en UDP 5355 y 5353 desde equipos Windows administrados, ni consultas de nombres NetBIOS en UDP 137.
• Desde un cliente administrado, Resolve-DnsName -Name doesnotexist01 -LlmnrNetbiosOnly debe devolver un error en lugar de una respuesta.
• Resolve-DnsName wpad.corp.example.com debe fallar en todos los servidores DNS.
• Mantenga una detección para los equipos que no administra: un equipo canario que consulte periódicamente un nombre aleatorio e inexistente mediante LLMNR y NetBIOS solo recibirá respuesta si hay un envenenador en el segmento. Microsoft Defender for Identity y la mayoría de los productos NDR también alertan sobre estas respuestas. Combínelo con honeytokens para detectar el uso de credenciales capturadas.

Qué se rompe

• La resolución de nombres cortos para equipos sin registros DNS: servidores antiguos con IP estáticas que nunca se registraron, equipos de laboratorio y dispositivos en redes sin la lista de búsqueda de sufijos DNS correcta. Corrija la parte DNS, no la directiva.
• Las aplicaciones heredadas que usan nombres NetBIOS o el servicio de exploración (exploración del entorno de red, algunas aplicaciones de línea de negocio antiguas y servidores de licencias).
• El descubrimiento mDNS de impresoras, dispositivos de transmisión, algunos equipos de salas de reuniones y funciones entre pares, si se usan en redes corporativas.
• La configuración de proxy basada en WPAD: los clientes que dependen de la detección automática pierden su proxy si se aplica la entrada de la lista de bloqueo sin alternativa; configure antes una URL PAC o un proxy explícito.
• Las redes domésticas y de hotel en portátiles: los usuarios acceden ocasionalmente a dispositivos domésticos por nombre; esto es una nota para el servicio de asistencia, no un motivo para mantener los protocolos.

Lecturas relacionadas: el tema NTLM y protocolos heredados, exigir la firma SMB y firma LDAP y enlace de canal para que nada de lo que aún se capture pueda reenviarse, y la entrada del glosario NTLM relay para la cadena de ataque completa.