Desactivar protocolos heredados (NTLMv1, LLMNR): qué falla y cómo reemplazarlos

Qué estás realmente corrigiendo (modelo de amenaza, no sensaciones)

Desactivar NTLMv1 y LLMNR es menos sobre ser “moderno” y más sobre cortar dos clases de fallos: (1) autenticación débil o susceptible de retransmisión, y (2) comportamiento de resolución de nombres que permite a atacantes insertarse en tu tráfico.

NTLMv1: desafío/respuesta débil, valores por defecto heredados y una larga cola de “todavía funciona”

NTLM es una familia de protocolos de autenticación de Windows. NTLMv1 es la forma más antigua y débil que aún ves en empresas reales. El problema no es solo la fuerza criptográfica; es lo fácil que es forzar, retransmitir o degradar tráfico NTLM cuando tienes clientes mixtos y políticas permisivas.

Cuando NTLMv1 está permitido, has creado una plataforma de aterrizaje blanda para clientes antiguos y aplicaciones mal configuradas. Algunas de esas “aplicaciones” son en realidad tareas programadas, impresoras, dispositivos NAS y servicios misteriosos instalados en 2014 y nunca tocados porque “simplemente funcionan”.

LLMNR: útil en redes pequeñas, peligroso en redes reales

LLMNR (Link-Local Multicast Name Resolution) es lo que hacen las máquinas cuando DNS falla o no está configurado correctamente y aun así quieren resolver fileserver o printer-7. Usa multicast en el segmento local. Es conveniente. También es un regalo para cualquiera que ejecute herramientas tipo responder en la misma red.

Si desactivas LLMNR pero mantienes DNS desordenado, los usuarios se quejarán de que “la red está rota”. La red no estaba rota. Estaba improvisando.

Una regla de confiabilidad aplica con fuerza aquí: haz la resolución de nombres determinista y la autenticación estricta. Todo lo demás es espectáculo.

Una cita, idea parafraseada: La idea de Gene Kranz (parafraseada): “Sé duro y competente” — a los sistemas no les importan las excusas, solo los resultados.

Broma #1: Desactivar NTLMv1 es como limpiar el ático: encontrarás muchas cosas antiguas y al menos algo que sisea.

Hechos históricos e información útil para reuniones

• NTLM es anterior a tu estrategia en la nube. NTLM se remonta a diseños de la era Windows NT; Kerberos llegó con Active Directory para reemplazarlo en la autenticación de dominio.
• NTLMv1 usa construcciones basadas en DES antiguas. Es una de las razones por las que se considera sustancialmente más débil que NTLMv2, especialmente en escenarios de captura y crackeo.
• NTLM persiste porque es “solo autenticación SMB”. Mucha gente asume que NTLM solo trata de recursos compartidos. Aparece en HTTP, bindings LDAP, RPC y rincones raros.
• LLMNR fue diseñado para reducir la dependencia de DNS en redes pequeñas. Es esencialmente un comportamiento “tipo DNS” sin la sobrecarga administrativa, que es precisamente por lo que se vuelve una muleta.
• LLMNR con frecuencia se combina con NBT-NS. En redes Windows, desactivar uno pero dejar el otro puede todavía permitir envenenamiento de nombres e intentos de captura de credenciales.
• Los ataques de coerción de credenciales adoran el multicast. Cuando un endpoint pregunta “¿quién es FILESERVER?”, un atacante puede responder más rápido que el servidor real y provocar autenticación.
• Kerberos puede fallar por razones aburridas. Desincronización de tiempo, errores de SPN y errores de DNS pueden empujar a los clientes hacia retrocesos NTLM a menos que cierres la puerta.
• El endurecimiento rompió cosas mucho antes de que se acuñara “Zero Trust”. La mayoría de las interrupciones por desactivar autenticación heredada provienen de dependencias no descubiertas, no del cambio del protocolo en sí.

Qué falla cuando desactivas NTLMv1 y LLMNR

Cuando desactivas NTLMv1: qué falla realmente

“Desactivar NTLMv1” suena simple hasta que te das cuenta de que la mayoría de los entornos no tienen “clientes solo NTLMv1”. Tienen un puñado de dispositivos y servicios que aún negocian a la baja, a menudo en silencio. Modos comunes de fallo:

• NAS y appliances antiguos unidos a AD: Algunas pilas SMB embebidas aún intentan NTLMv1 o hacen firmas/encapsulados NTLM de forma extraña.
  Síntoma: los accesos a recursos compartidos repiten solicitudes o “The specified network password is not correct.”
• Escáneres/impresoras antiguas que usan “scan to folder”: A menudo almacenan credenciales e intentan autenticación SMB con dialectos antiguos.
  Síntoma: las exploraciones dejan de llegar; la interfaz del dispositivo muestra “login failed.”
• Aplicaciones personalizadas que usan librerías antiguas: Especialmente cualquier cosa que haga autenticación integrada sobre HTTP a IIS o proxies inversos.
  Síntoma: bucles 401, retrocesos de autenticación o la app cambia silenciosamente a “cuentas locales.”
• Versiones antiguas de Windows o políticas de seguridad mal configuradas: Algunos endpoints negociarán mal si las políticas son inconsistentes.
  Síntoma: picos repentinos en llamadas al soporte tras un cambio de GPO, afectando a un subconjunto de máquinas.
• Cuentas de servicio con SPN faltantes: Si Kerberos no puede usarse, los clientes pueden intentar NTLM; si bloqueas la familia NTLM demasiado agresivamente, el servicio parece caído.
  Síntoma: “server not available”, pero solo para usuarios de dominio.

Cuando desactivas LLMNR: qué falla realmente

LLMNR tiene menos que ver con “falla de autenticación” y más con “la gente deja de encontrar cosas por intuición”.
Específicamente, cualquier cosa que dependa de nombres cortos, nombres de un solo segmento o DNS obsoleto sufrirá.

• Usuarios que mapean unidades por nombres cortos: \\fileserver\share funciona hasta que DNS está mal y LLMNR solía rescatarlo.
• RDP a nombres cortos: La gente escribe rdp fileserver y “funcionaba” gracias al multicast o cachés.
• Scripts que usan nombres no calificados: Automatizaciones que asumen resolución por difusión local ahora fallarán rápidamente.
• Entornos multi-subred: LLMNR no cruza routers como DNS. Si ayudaba allí, ya tenías un problema mayor de diseño DNS.

Desactivar LLMNR no crea la falla subyacente. La hace visible. Ese es el tipo de fallo que quieres en producción: una suposición rota, no un protocolo roto.

Qué usar en su lugar (reemplazos que funcionan)

Reemplazar NTLMv1 con: Kerberos primero, NTLMv2 solo como retroceso controlado

El objetivo práctico no es “nada de NTLM nunca” en el día uno. Es:

1. Eliminar NTLMv1 en todas partes donde puedas.
2. Exigir NTLMv2 donde NTLM aún exista.
3. Impulsar la adopción de Kerberos corrigiendo DNS, SPN y sincronización horaria.
4. Restringir y monitorizar NTLM con auditoría, listas de permitidos y, finalmente, bloqueo.

Si tu entorno está respaldado por AD y no puedes hacer Kerberos fiable, no tienes un problema de “protocolo de autenticación”.
Tienes un problema de fundamentos: corrección de DNS, corrección de tiempo, higiene de identidades.

Reemplazar LLMNR con: buen DNS y buen comportamiento de cliente

LLMNR existe porque DNS a menudo no es lo suficientemente confiable para los endpoints. Así que el reemplazo es aburrido:

• Registros DNS A/AAAA precisos para servidores y appliances.
• Sufijos de búsqueda consistentes vía opciones DHCP o GPO para que los nombres de un solo segmento se resuelvan de forma predecible (o no se resuelvan).
• Dejar de usar nombres de un solo segmento en scripts y runbooks; usar FQDNs.
• Desactivar LLMNR y NBT-NS donde sea posible, juntos, y medir las consecuencias.

Controles de seguridad que alivian la transición

• SMB signing donde sea factible, especialmente para recursos administrativos y accesos servidor a servidor.
• LDAP signing/channel binding para cortar rutas de degradación y relés que suelen acompañar el abuso NTLM.
• Segmentación de firewall para que endpoints aleatorios no puedan comunicarse con endpoints aleatorios en SMB/HTTP/RPC y “ayudar” autenticándose.
• Credential Guard / protecciones LSA en endpoints para reducir la exposición de material de credenciales.

Broma #2: LLMNR es como preguntar en una sala llena quién es tu amigo, y luego entregarle la billetera a la primera persona que responde.

Playbook de diagnóstico rápido (primeras/segundas/terceras comprobaciones)

Desactivaste NTLMv1 o LLMNR y ahora algo está roto. No empieces por revertir la política “solo para que el lunes funcione”.
Empieza por probar qué falló y dónde vive la dependencia. Aquí está la ruta más rápida.

Primero: identifica si es resolución de nombres o autenticación

• ¿Puede el cliente resolver el servidor vía DNS? Si no, LLMNR/NBT-NS solía parchear el agujero.
• ¿Puede el cliente alcanzar el servidor en el puerto esperado? Si no, es enrutamiento/firewall, no autenticación.
• ¿El fallo es “access denied” o “host not found”? Eso divide el problema claramente.

Segundo: determina qué protocolo de autenticación se intentó

• ¿Kerberos vs NTLM? Revisa eventos de seguridad Windows, logs del servidor o captura de paquetes en una máquina de prueba.
• ¿NTLMv1 vs NTLMv2? Si aún permites NTLMv2, la única ruptura debería ser clientes verdaderamente antiguos o una negociación incorrecta.

Tercero: localiza la dependencia y elige un reemplazo

• Si es un appliance, revisa firmware/configuración SMB y si soporta NTLMv2 o Kerberos.
• Si es una app, verifica si puede usar Kerberos/Negotiate, librerías modernas o SPNs de cuenta de servicio.
• Si es un hábito de usuario, arregla los runbooks y scripts y aplica el uso de FQDN.

El “cuello de botella” en estos incidentes rara vez es CPU o red. Es la ambigüedad: resolución de nombres incierta y retroceso silencioso de autenticación.
Tu trabajo es eliminar la ambigüedad.

Tareas prácticas: comandos, salidas y decisiones

Abajo hay tareas prácticas que puedes ejecutar desde un host administrador Linux (o VM de troubleshooting) que esté en la misma red y pueda alcanzar servicios AD.
Algunas tareas también interrogan comportamiento Windows vía herramientas Samba. Para comandos nativos Windows normalmente usarías PowerShell;
aquí nos centramos en comandos que realmente puedes ejecutar desde un shell en modo incidente.

Tarea 1 — Detectar LLMNR en la red (¿los clientes siguen clamando?)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 5355 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:31:02.114890 IP 10.20.1.45.56724 > 224.0.0.252.5355: UDP, length 62
12:31:02.114932 IP 10.20.1.71.57811 > 224.0.0.252.5355: UDP, length 62
5 packets captured

Qué significa: Estás viendo multicast LLMNR (224.0.0.252:5355). Los clientes todavía lo están intentando.

Decisión: Si pretendías que LLMNR estuviera deshabilitado, verifica el alcance del GPO/MDM; también valida DNS para que los clientes dejen de necesitarlo.

Tarea 2 — Detectar NBT-NS (el otro vector legado de envenenamiento)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 137 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:32:19.901220 IP 10.20.1.45.137 > 10.20.1.255.137: NBT UDP PACKET(137): QUERY; REQUEST; name="FILESERVER<00>"
5 packets captured

Qué significa: Las difusiones del NetBIOS Name Service siguen en juego.

Decisión: Planea desactivar NetBIOS sobre TCP/IP donde sea posible, o contenerlo mediante segmentación. Desactivar solo LLMNR no es toda la historia.

Tarea 3 — Ver si DNS puede resolver el host que los usuarios siguen tecleando

cr0x@server:~$ getent hosts fileserver

Qué significa: No mostrar salida suele significar que no es resolvible vía resolvers/sufijos de búsqueda configurados.

Decisión: Arregla registros DNS y/o la configuración de sufijos de búsqueda. Si quieres prohibir nombres de un solo segmento, haz que los scripts usen FQDNs y hazlo cumplir culturalmente.

Tarea 4 — Validar DNS desde un resolvedor específico (deja de adivinar)

cr0x@server:~$ dig @10.20.0.10 fileserver.corp.example A +noall +answer
fileserver.corp.example. 300 IN A 10.20.5.20

Qué significa: DNS conoce la respuesta y el TTL es razonable.

Decisión: Si DNS es correcto pero los clientes aún usan LLMNR, revisa la lista de sufijos DNS del cliente y si están consultando los servidores DNS correctos.

Tarea 5 — Verificar DNS inverso (beneficia Kerberos y diagnóstico)

cr0x@server:~$ dig @10.20.0.10 -x 10.20.5.20 +noall +answer
20.5.20.10.in-addr.arpa. 300 IN PTR fileserver.corp.example.

Qué significa: Existe PTR. Eso ayuda en auditorías, algunas herramientas y reduce el dolor operativo de “IP misteriosa”.

Decisión: La DNS inversa faltante no siempre rompe Kerberos, pero dificultará el diagnóstico rápido. Arréglalo de todos modos.

Tarea 6 — Comprobar sincronización horaria en Linux (porque Kerberos es alérgico a los viajes en el tiempo)

cr0x@server:~$ timedatectl status
               Local time: Tue 2026-02-05 12:35:10 UTC
           Universal time: Tue 2026-02-05 12:35:10 UTC
                 RTC time: Tue 2026-02-05 12:35:11
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Qué significa: El tiempo está sincronizado. Bien.

Decisión: Si la autenticación falla misteriosamente, verifica el tiempo en clientes, servidores y controladores de dominio. Arregla la deriva antes de culpar a Kerberos.

Tarea 7 — Obtener un ticket Kerberos para un usuario de dominio (prueba que la ruta Kerberos funciona)

cr0x@server:~$ kinit user1@CORP.EXAMPLE
Password for user1@CORP.EXAMPLE:

Qué significa: Si vuelve al prompt sin error, obtuviste un TGT.

Decisión: Si falla, revisa DNS hacia KDCs, deriva de tiempo, configuración de realm y bloqueo por firewall a DCs antes de tocar políticas NTLM.

Tarea 8 — Inspeccionar la caché de tickets (confirma detalles de realm/KDC)

cr0x@server:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: user1@CORP.EXAMPLE

Valid starting     Expires            Service principal
02/05/26 12:36:20  02/05/26 22:36:20  krbtgt/CORP.EXAMPLE@CORP.EXAMPLE

Qué significa: Tienes un TGT; los fundamentos de Kerberos funcionan.

Decisión: Si los clientes aún usan NTLM, el problema probablemente sea configuración de SPN/servicio, no “Kerberos está caído.”

Tarea 9 — Verificar acceso SPN a un servicio CIFS usando Kerberos (SMB con Kerberos)

cr0x@server:~$ smbclient -k -L //fileserver.corp.example -m SMB3
Anonymous login successful

	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       Remote IPC
	share           Disk      Team share
SMB1 disabled -- no workgroup available

Qué significa: -k usa Kerberos. Ver recursos compartidos significa que la autenticación Kerberos tuvo éxito (a pesar de la línea confusa “Anonymous login successful” que smbclient a veces muestra).

Decisión: Si Kerberos funciona desde un host de prueba pero los clientes Windows retroceden a NTLM, inspecciona SPNs y cómo los clientes resuelven el nombre del servidor.

Tarea 10 — Forzar NTLMSSP en smbclient (para demostrar que NTLM aún se usa en algún lado)

cr0x@server:~$ smbclient -U 'CORP\user1' -L //fileserver.corp.example -m SMB3 --option='client use spnego=no'
Password for [CORP\user1]:

	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       Remote IPC
	share           Disk      Team share

Qué significa: Acabas de autenticar usando NTLMSSP (familia NTLM). Si negoció v1 o v2 depende de la política cliente/servidor.

Decisión: Si desactivar NTLMv1 rompe esto, tienes un problema de negociación heredada—a menudo un appliance antiguo o una configuración servidor antigua.

Tarea 11 — Enumerar soporte de dialectos SMB (encontrar minas SMB1)

cr0x@server:~$ smbclient -L //fileserver.corp.example -m SMB1
protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE

Qué significa: SMB1 no es soportado/deshabilitado en el servidor (bien). Muchos dispositivos que mantienen NTLMv1 se correlacionan con la era SMB1.

Decisión: Si tu appliance solo soporta SMB1, no “crees una excepción”. Reemplázalo o aíslalo. Las excepciones se vuelven permanentes.

Tarea 12 — Escanear responders LLMNR (quieres cero)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 5355 -vv -c 10
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:40:11.004321 IP 10.20.1.45.5355 > 224.0.0.252.5355: 1234+ A? wpad. (34)
12:40:11.006002 IP 10.20.1.200.5355 > 10.20.1.45.5355: 1234* 1/0/0 A 10.20.1.200 (50)

Qué significa: Un host (10.20.1.200) respondió a una consulta LLMNR por wpad. Eso es o bien una mala configuración o un riesgo activo de envenenamiento.

Decisión: Identifica ese host inmediatamente. Si no es un resolvedor sancionado, cuaréntalo e investiga. Además: arregla DNS para que los clientes no estén preguntando por WPAD en multicast.

Tarea 13 — Comprobar si WPAD es resolvible vía DNS (evita drama de proxy auto-detect)

cr0x@server:~$ dig @10.20.0.10 wpad.corp.example A +noall +answer

Qué significa: Sin registro DNS. Si los clientes tienen proxy auto-detect habilitado, pueden intentar LLMNR/NBT-NS por WPAD.

Decisión: Implementa WPAD correctamente con controles estrictos, o desactiva el proxy auto-detect. No lo dejes en un estado a medias.

Tarea 14 — Prueba rápida de alcance de puerto a un controlador de dominio (fallos de auth que son en realidad firewalls)

cr0x@server:~$ nc -vz dc1.corp.example 88
Connection to dc1.corp.example 88 port [tcp/kerberos] succeeded!

Qué significa: TCP/88 de Kerberos es alcanzable. (UDP también importa, pero esto es una señal rápida.)

Decisión: Si esto falla desde ciertas subredes, tienes problemas de segmentación. Arregla enrutamiento/firewalls antes de culpar a los cambios NTLM.

Tres microhistorias corporativas del campo

Microhistoria 1: El incidente causado por una suposición errónea

Una empresa mediana decidió “simplemente desactivar NTLMv1” porque un escáner de seguridad lo señaló. El equipo IAM aplicó una GPO dirigida a “Todas las estaciones de trabajo” y luego envió un mensaje de celebración por el avance.

El lunes por la mañana, operaciones no pudo acceder a un conjunto de recursos compartidos usados por una línea de fabricación. No fue todo—solo los kioscos en el taller.
El helpdesk lo trató como una caída y comenzó a reiniciar todo lo que tenía botón de encendido. Eso no es solucionar; es ritual.

La suposición errónea: “Esos kioscos son Windows 10, así que deben usar NTLMv2 o Kerberos.” Eran Windows 10,
pero la dependencia real era un NAS con una década de antigüedad, unido al dominio hace mucho. Soportaba NTLM, pero su pila SMB negociaba a la baja de formas que el equipo nunca probó. Los kioscos no eran el problema. El servidor era.

Una vez identificado el NAS, la resolución fue brutalmente simple: mover las comparticiones a un servidor soportado y luego aislar el NAS para acceso solo de archivo. La lección real no fue “no desactiven NTLMv1”. Fue “no dejen que producción dependa de dispositivos que no pueden parchear ni observar”.

Microhistoria 2: La optimización que salió mal

Otra organización quiso reducir el volumen de logs y el “ruido” en su SIEM. Filtraron un conjunto de eventos de autenticación porque “es todo charla normal de Windows.” Esto ocurrió justo antes de un proyecto para desactivar LLMNR.

Tras desactivar LLMNR, un subconjunto de usuarios empezó a ver avisos intermitentes de login al acceder aplicaciones web internas.
El equipo sospechó de la nueva política, luego del balanceador de carga, luego del IdP. Pasaron dos días rebotando entre equipos,
porque los logs que habrían probado la degradación del protocolo de autenticación ahora estaban filtrados.

El problema: al optimizar la telemetría de autenticación “ruidosa”, hicieron el análisis de causa raíz más lento y político.
Finalmente una captura de paquetes mostró que los clientes no resolvían el nombre correcto del backend vía DNS, luego intentaban caminos de retroceso.
NTLM se estaba desencadenando vía un hostname heredado, y desactivar LLMNR simplemente removió los casos de éxito accidentales.

Las soluciones fueron aburridas: corregir registros DNS, imponer FQDNs en configuraciones de apps y reinstaurar eventos de seguridad—esta vez con parsing y alertas inteligentes en lugar de supresión burda. La enseñanza operativa: si vas a cambiar el comportamiento de autenticación, conserva los logs de autenticación.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una gran empresa hizo todo de la manera poco sexy. Antes de tocar GPOs, ejecutaron auditoría NTLM durante semanas y etiquetaron cada evento
con cliente origen, servidor destino y propietario de la aplicación. Crearon un flujo de trabajo simple: “Si posees el destino, posees la solución.”

También mantuvieron una OU de prueba que replicaba las políticas de producción. Cada cambio candidato—desactivar LLMNR, exigir NTLMv2,
restringir NTLM—se aplicaba allí primero. Fueron forzando apps clave a ejecutarse desde esa OU por un día cada una, con ventana de rollback.
No fue glamuroso. Fue efectivo.

Cuando finalmente deshabilitaron NTLMv1 de forma amplia, las únicas interrupciones fueron las preidentificadas: un par de escáneres, una app Java antigua
y un appliance de vendor. Tenían planes de remediación listos: actualizaciones de firmware, migración a SFTP y una escalación de vendor con fecha límite.

La práctica que los salvó: gestión de cambios estricta con instrumentación, no papeleo. No “esperaron” que nada dependiera de NTLMv1.
Recolectaron pruebas y luego hicieron el cambio. La fiabilidad a veces parece la persona que insiste en medir las cosas.

Errores comunes (síntomas → causa raíz → solución)

1) “Los usuarios no pueden acceder a comparticiones” después de desactivar NTLMv1

Síntomas: solicitudes repetidas de credenciales; “access denied”; algunos clientes funcionan, otros no.

Causa raíz: un appliance de almacenamiento o servidor antiguo negocia NTLMv1 o comportamientos de la era SMB1; Kerberos no se está usando por problemas de SPN/DNS.

Solución: confirma que Kerberos funciona hacia el nombre CIFS SPN; corrige DNS/uso de FQDN; actualiza/migra el appliance; exige NTLMv2 como paso intermedio.

2) “Desactivar LLMNR rompió todo” (no lo hizo; tu DNS lo hizo)

Síntomas: nombres cortos dejan de resolverse; mapeos de unidad fallan; scripts fallan en una subred.

Causa raíz: registros DNS faltantes, servidores DNS DHCP incorrectos, sufijos de búsqueda faltantes o dependencia de nombres de un solo segmento.

Solución: corrige registros A/PTR; asegura que DHCP empuje servidores DNS y sufijos correctos; actualiza scripts a FQDNs; elimina dependencia en resolución por difusión.

3) “Kerberos es inestable, así que necesitamos NTLM”

Síntomas: fallos de autenticación intermitentes; funciona después de reiniciar; funciona para algunos usuarios.

Causa raíz: deriva de tiempo; colisiones de SPN; clientes resolviendo nombres distintos a los que espera el SPN; configuraciones erróneas de delegación restringida.

Solución: imponer NTP; auditar SPNs; estandarizar hostnames y certificados; tratar DNS como crítico de producción, no “asunto del equipo de red.”

4) “Bloqueamos NTLM y ahora una app está caída”

Síntomas: app interna devuelve 401; bucles de autenticación; llamadas servicio a servicio fallan.

Causa raíz: identidad del app pool/SPN no configurado; la app usa NTLM explícitamente en lugar de Negotiate; proxy/load balancer rompe Kerberos.

Solución: configura SPNs para la cuenta de servicio; asegura que los clientes usen el FQDN correcto; revisa requisitos de delegación; si es necesario, mantén NTLMv2 temporalmente pero restringido.

5) “Deshabilitamos LLMNR pero Responder todavía captura cosas en una prueba”

Síntomas: tráfico multicast/broadcast de nombres aún presente; solicitudes de credenciales disparadas por nombres falsos.

Causa raíz: NBT-NS aún habilitado; WPAD/proxy auto-detect sigue activo; otros protocolos de descubrimiento están en juego.

Solución: desactiva NBT-NS donde sea posible; controla WPAD; segmenta redes; reduce la alcanzabilidad lateral (SMB/RPC) entre clientes.

Listas de verificación / plan paso a paso

Fase 0 — Hacerlo observable (no cambies lo que no puedes ver)

1. Habilitar y centralizar telemetría de autenticación (uso de NTLM, fallos, retrocesos).
2. Comenzar a capturar muestras de tráfico LLMNR/NBT-NS por VLAN para entender dónde se usa.
3. Construir un inventario: servidores de archivos, NAS, impresoras/escáneres, servidores de aplicaciones, balanceadores, controladores de dominio.
4. Identificar rutas de acceso “no humanas”: cuentas de servicio, tareas programadas, credenciales almacenadas en dispositivos.

Fase 1 — Arreglar DNS para que LLMNR sea irrelevante

1. Asegurar que cada servidor tenga registros A/AAAA y PTR correctos.
2. Estandarizar la distribución de sufijos de búsqueda (DHCP/GPO) y verificar que los clientes los reciban.
3. Actualizar mappings de unidades, scripts y runbooks para usar FQDNs.
4. Decidir política para nombres de un solo segmento: desalentar o bloquear en herramientas.

Fase 2 — Desactivar LLMNR (y preferiblemente NBT-NS) en alcance controlado

1. Aplicar GPO/MDM a una OU piloto primero (TI, usuarios avanzados, una unidad de negocio representativa).
2. Monitorizar incidentes de resolución de nombres; cuando ocurran, arregla DNS, no la política.
3. Expandir alcance VLAN por VLAN o sitio por sitio.

Fase 3 — Eliminar NTLMv1 y endurecer NTLMv2

1. Configurar clientes y servidores para rechazar NTLMv1; exigir NTLMv2 donde NTLM permanezca.
2. Arreglar bloqueadores de Kerberos: sincronización horaria, SPNs, higiene de cuentas de servicio, corrección DNS.
3. Actualizar o reemplazar appliances que no soporten NTLMv2 o Kerberos.
4. Mantener un registro de excepciones con fechas de expiración. Si no tiene expiración, no es una excepción; es política.

Fase 4 — Restringir o eliminar NTLM (opcional, pero objetivo final)

1. Bloquear NTLM a servidores de alto valor primero (controladores de dominio, endpoints administrativos, planos de gestión).
2. Usar listas de permitidos para dependencias heredadas inevitables, y luego reducirlas con el tiempo.
3. Validar que todas las nuevas apps y vendors soporten Kerberos o patrones de autenticación modernos.

Preguntas frecuentes

1) Si desactivamos NTLMv1, ¿obtenemos Kerberos automáticamente en todas partes?

No. Obtendrás fallos donde Kerberos no pueda usarse (problemas de SPN/DNS/tiempo) y donde clientes/dispositivos solo conozcan NTLMv1.
La ganancia es forzar esos problemas a la luz para que puedas corregirlos.

2) ¿Es suficiente desactivar LLMNR, o también necesitamos desactivar NBT-NS?

Si quieres reducir el envenenamiento de nombres y ataques tipo responder, típicamente necesitas ambos. LLMNR y NBT-NS son primos.
Desactivar solo uno a menudo deja una ruta alternativa.

3) ¿Por qué antes “funcionaba” si DNS estaba mal?

Porque la resolución de nombres por multicast/difusión y las cachés crean éxitos accidentales. Es como un sistema que “funciona” porque los reintentos ocultan el error.
No tienes fiabilidad; tienes suerte.

4) ¿Cuál es el orden más seguro: desactivar LLMNR primero o NTLMv1 primero?

Normalmente arregla DNS → desactiva LLMNR/NBT-NS → luego elimina NTLMv1. Los cambios de LLMNR son mayormente resolución de nombres y hábitos de usuario.
Los cambios de NTLMv1 pueden romper dispositivos y flujos de autenticación más bruscamente.

5) Tenemos impresoras/escáneres que no pueden usar Kerberos. ¿Cuál es la opción menos mala?

Prefiere dispositivos que soporten SMB moderno y al menos NTLMv2, o cambia el flujo: scan to email, SFTP, carga HTTPS o un servicio intermediario. Si debes mantener SMB legado, aíslalo en una VLAN dedicada y restringe con qué servidores puede hablar.

6) ¿El SMB signing reemplaza la necesidad de desactivar NTLMv1?

No. SMB signing ayuda a prevenir ciertas manipulaciones y algunos escenarios de relé, pero no actualiza mágicamente una autenticación débil.
Aún quieres que NTLMv1 desaparezca, e idealmente Kerberos para acceso de dominio.

7) ¿Cómo evitamos una avalancha de tickets al helpdesk al desactivar LLMNR?

Arregla por adelantado DNS para servicios más usados (servidores de archivos, impresión, endpoints intranet), empuja sufijos de búsqueda consistentemente,
y actualiza mappings de unidad GPO/scripts a FQDNs. Además: comunica la nueva regla “usar FQDN” en documentación IT.

8) ¿Cuál es la señal clara de que Kerberos no se está usando?

Repetidas solicitudes de login, eventos de servidor relacionados con NTLM y autenticación que solo tiene éxito usando una dirección IP o un nombre corto.
Kerberos es sensible al nombre. Si accedes a un servicio con un nombre que no coincide con su SPN, Kerberos no ocurrirá.

9) ¿Podemos simplemente bloquear todo NTLM de inmediato?

Puedes, si disfrutas de tiempos de inactividad no planificados y excepciones “temporales” de emergencia. Un enfoque por etapas con auditoría y bloqueo focalizado
te lleva al mismo destino sin prender fuego a las operaciones.

Siguientes pasos que no arruinarán tu fin de semana

Si quieres un plan práctico y de bajo drama, haz esto en orden:

1. Medir el estado actual: captura tráfico LLMNR/NBT-NS; audita uso de NTLM; lista los principales emisores.
2. Arreglar DNS: registros A/PTR, sufijos y uso de FQDN en configuraciones y scripts.
3. Piloto: desactivar LLMNR (y idealmente NBT-NS): alcance pequeño, retroalimentación rápida, arregla causas raíz.
4. Desactivar NTLMv1: exigir NTLMv2; migrar o aislar dispositivos que no cumplan.
5. Hacer que las excepciones sean caras: cada excepción tiene un propietario, una razón y una fecha de expiración.
6. Conservar logs de autenticación: no “optimices” la telemetría que te dice si el entorno está mejorando.

El estado final es simple: los endpoints resuelven nombres vía DNS, se autentican vía Kerberos y retroceden a NTLMv2 solo donde lo permitas explícitamente.
Todo lo demás es inercia heredada. Arrásalo con cuidado.