Ataques NTLM Relay: Deteccion y Prevencion

Los ataques de retransmisión NTLM (NTLM Relay Attacks) siguen siendo relevantes porque muchos entornos de Active Directory todavía permiten al menos una ruta retransmisible: SMB sin firmar, manejo débil de LDAP, exposición de la inscripción web de AD CS, rutas de coerción o comportamiento heredado de resolución de nombres que provoca que las máquinas se autentiquen donde no deberían.

¿Qué es el NTLM Relay?

Los ataques de retransmisión NTLM (NTLM Relay Attacks) son técnicas de ataque de red en las que un atacante captura un intercambio de autenticación NTLM de un sistema y lo reenvía a otro servicio en tiempo real. El atacante no necesita descifrar el hash de la contraseña para hacerlo. El servicio objetivo acepta la autenticación retransmitida porque el intercambio de desafío-respuesta (challenge-response) de NTLM sigue siendo válido para esa sesión.

En la práctica, la retransmisión NTLM importa cuando se alinean tres condiciones:

se puede coaccionar o engañar a una víctima para que se autentique mediante NTLM
el atacante puede alcanzar en la red tanto a la víctima como al servicio objetivo
el servicio objetivo todavía acepta NTLM de una forma que no exige la protección que bloquearía la ruta de retransmisión

Por eso la retransmisión no es un único fallo. Es la combinación del uso de NTLM, rutas débiles de resolución de nombres o de coerción, y configuraciones de servicio permisivas como SMB sin firmar o manejo débil de LDAP.

Cómo funciona

NTLM es un protocolo de desafío-respuesta:

el cliente envía un mensaje de negociación (negotiate)
el servidor envía un desafío (challenge)
el cliente devuelve un mensaje de autenticación (authenticate) derivado de ese desafío

En un ataque de retransmisión, el atacante reenvía esos mensajes entre la víctima y el servicio objetivo. El atacante no está rompiendo el protocolo criptográficamente. El atacante está abusando del hecho de que el servicio objetivo está dispuesto a aceptar el contexto de autenticación retransmitido.

Las víctimas suelen ser coaccionadas para autenticarse a través de rutas débiles de resolución de nombres como LLMNR o NBT-NS, o mediante rutas de coerción de aplicaciones y servicios que desencadenan autenticación saliente.

La documentación de Microsoft sobre el endurecimiento de SMB indica que la firma SMB ayuda a prevenir los ataques de retransmisión y que exigir la firma hace que los clientes y servidores rechacen los paquetes sin firmar. Por eso la firma SMB es un control contra los resultados de retransmisión SMB, no una configuración cosmética.

Ataques de retransmisión NTLM: rutas de retransmisión comunes y qué las bloquea

Ruta de retransmisión	Qué busca el atacante	Bloqueador principal
Retransmisión SMB	Administrador local o ejecución de código en un servidor miembro	Firma SMB obligatoria en el objetivo
Retransmisión LDAP	Cambios en el directorio cuando la identidad retransmitida tiene suficientes permisos y la ruta objetivo lo permite	Firma LDAP y endurecimiento de la ruta del directorio
Retransmisión de inscripción web de AD CS	Emisión de certificados utilizable para un abuso de autenticación posterior	Eliminación o endurecimiento de la ruta de inscripción vulnerable

Por lo tanto, una revisión útil debe separar el transporte de retransmisión del resultado. Bloquear la retransmisión SMB no elimina automáticamente las oportunidades de retransmisión LDAP o AD CS.

También conviene separar la exposición de las estaciones de trabajo de la exposición de los servidores. Una ruta de retransmisión que solo afecta a hosts miembro de bajo valor sigue siendo un problema, pero la prioridad de respuesta cambia de inmediato cuando la misma ruta puede alcanzar controladores de dominio, servidores de gestión, servicios de certificados o cuentas de servicio con delegación intensiva.

Por qué reducir NTLM no es lo mismo que un único valor de registro

Las restricciones de NTLM, la firma SMB, la firma LDAP, EPA/channel binding, el endurecimiento de la resolución de nombres y el endurecimiento del servicio de certificados abordan partes diferentes del ataque. Un tenant puede configurar una política relacionada con NTLM y aun así seguir expuesto a la retransmisión si un servicio objetivo acepta el intercambio retransmitido.

Trate el conjunto de controles como algo por capas:

reduzca el uso innecesario de NTLM donde la ruta de la aplicación admita Kerberos u otra autenticación más sólida
exija firma o una protección equivalente en los servicios que todavía aceptan NTLM
elimine los comportamientos de resolución de nombres que crean oportunidades fáciles de captura de autenticación
endurezca las rutas de AD CS y LDAP que convierten una retransmisión en una escalada de dominio
supervise el uso de NTLM para que las excepciones sigan siendo visibles

La cadena de ataque

Paso 1: levantar la infraestructura de retransmisión

responder -I eth0 -rdw --no-HTTP-Server --no-SMB-Server
ntlmrelayx.py -tf targets.txt -smb2support -socks

Paso 2: capturar y reenviar la autenticación

Cuando un sistema víctima intenta autenticarse ante un listener controlado por el atacante, este reenvía ese intercambio NTLM al objetivo elegido.

# Ejemplo de salida exitosa
# [*] Authenticating against smb://10.10.0.50 as CORP/jsmith SUCCEED

Paso 3: usar la identidad retransmitida donde importa

# Objetivo LDAP de ejemplo
ntlmrelayx.py -t ldap://dc01.corp.local --escalate-user attacker

# Objetivo SMB de ejemplo
ntlmrelayx.py -tf targets.txt -smb2support -c 'whoami'

# Ruta de AD CS de ejemplo
ntlmrelayx.py -t http://ca.corp.local/certsrv/certfnsh.asp --adcs --template Machine

La sesión retransmitida solo tiene el poder que permitan el objetivo y la identidad retransmitida. La pregunta importante en una revisión no es si una herramienta puede emitir la solicitud, sino si el entorno todavía expone un objetivo en el que esa solicitud resulte en un privilegio significativo.

Detección

IDs de evento de Windows

ID de evento	Origen	Qué buscar
4624	Sistema objetivo	Inicios de sesión de red de tipo 3 desde un host de origen inusual
4776	DC	Actividad de validación NTLM que no encaja con la ruta normal de la cuenta
4625	Sistema objetivo	Inicios de sesión de red fallidos y repetidos en torno a pruebas de retransmisión o reenvío fallido

Microsoft documenta el evento 4776 como validación de credenciales NTLM. En el caso de las cuentas de dominio, el controlador de dominio es la autoridad y puede mostrar los intentos de validación NTLM de esas cuentas. Esto es útil, pero no muestra todos los detalles del servicio de destino, por lo que debe correlacionarse con los registros de inicio de sesión y de servicio del lado del objetivo.

Indicios prácticos de detección

la misma cuenta se autentica en varios hosts en una ventana de tiempo corta desde un mismo origen
aparece actividad NTLM del lado del servidor procedente de estaciones de trabajo que normalmente no inician ese tráfico
la autenticación retransmitida va seguida inmediatamente de una modificación del directorio, actividad de administrador local o comportamiento de inscripción de certificados
una cuenta de equipo se autentica en un servicio inusual tras un desencadenante similar a la coerción
aparece validación NTLM en lugares donde normalmente debería usarse Kerberos

Consulta de detección para SIEM (Elastic KQL)

event.code: '4624' AND
winlog.event_data.LogonType: '3' AND
winlog.event_data.AuthenticationPackageName: 'NTLM'

Esa consulta por sí sola no es específica de la retransmisión. Se vuelve útil cuando se enriquece con el rol del host, las rutas de autenticación esperadas y la agrupación temporal (time clustering).

Mejor detección mediante correlación

Una detección sólida de retransmisión normalmente necesita al menos dos de estas señales:

validación NTLM desde una estación de trabajo o servidor inesperado
inicio de sesión de tipo 3 con NTLM en el lado del objetivo
acceso a servicios o named pipes relevantes para la coerción
acción inmediata sobre el directorio, de administrador local o de inscripción de certificados tras la autenticación
host de origen del que no se espera que inicie autenticación hacia el objetivo

Esta correlación es más defendible que generar alertas por todo el tráfico NTLM. Muchos entornos todavía tienen dependencias legítimas de NTLM, por lo que las alertas amplias de NTLM generan ruido a menos que el equipo ya haya reducido su uso.

Remediación

Victoria rápida: exija la firma SMB en los sistemas que todavía aceptan SMB sin firmar. Esto elimina el resultado de retransmisión SMB más común, pero no sustituye el endurecimiento de las rutas de LDAP y de certificados.

1. Exigir la firma SMB

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature

Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbServerConfiguration -RequireSecuritySignature $true

Revise tanto los servidores como los clientes. Una implementación parcial deja rutas retransmisibles sin cubrir. Microsoft documenta que exigir la firma SMB hace que el cliente o el servidor rechacen los paquetes sin firmar, que es el comportamiento necesario para detener los resultados de retransmisión SMB.

2. Deshabilitar las rutas débiles de resolución de nombres

# Configuración de GPO
# Configuración del equipo > Plantillas administrativas > Red > Cliente DNS
# Desactivar la resolución de nombres de multidifusión = Habilitada

La documentación de políticas de Microsoft para el cliente DNS indica que habilitar esta política deshabilita LLMNR en todos los adaptadores de red disponibles. Revise también la resolución de nombres NetBIOS heredada donde todavía exista en el entorno.

3. Restringir NTLM donde la ruta de negocio lo permita

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 5

No implemente restricciones de NTLM a ciegas. Comience con el modo de auditoría y la detección de dependencias. Luego restrinja por servidor, cuenta y ruta de aplicación allí donde se comprenda la dependencia de negocio.

4. Endurecer los objetivos de directorio y de certificados

Si los controladores de dominio o los servicios de certificados todavía son alcanzables a través de rutas NTLM propicias para la retransmisión, la remediación no ha terminado. Revise:

los requisitos de firma LDAP en los controladores de dominio
el channel binding de LDAP y Extended Protection donde corresponda
la inscripción web de AD CS y la exposición de las plantillas de certificados
si los servidores de alto valor todavía aceptan NTLM en los casos en los que debería usarse Kerberos u otros controles más sólidos
si las rutas de inscripción de certificados pueden emitir certificados capaces de autenticación a identidades de equipo o de usuario retransmitidas

5. Validar servicio por servicio, no política por política

La pregunta sobre la retransmisión siempre es concreta: ¿se puede retransmitir esta autenticación capturada o coaccionada hacia este objetivo y producir este resultado? Valide de forma independiente las rutas de SMB, LDAP, AD CS y servidores de gestión. Un informe de GPO en verde no es suficiente si una OU de excepción, un dispositivo heredado o un endpoint de servicio de certificados siguen siendo retransmisibles.

Validar después del endurecimiento

La condición de éxito no es "la GPO existe". Es que el servicio objetivo ya no acepta la ruta retransmitida que importaba.

vuelva a probar objetivos SMB representativos y confirme que exigen la firma
verifique que la ruta de la víctima que antes generaba tráfico LLMNR, NBT-NS u otro tráfico NTLM saliente ya no produce el mismo resultado
confirme que los objetivos de directorio y de certificados más relevantes ya no son retransmisibles desde el mismo punto de apoyo (foothold)
revise la actividad reciente de los eventos 4624 y 4776 para asegurarse de que el entorno sigue funcionando para los usuarios legítimos mientras la ruta abusiva ha desaparecido
revise la configuración de firma de cliente y servidor SMB desde endpoints en cada OU principal o grupo de gestión de dispositivos
verifique que la inscripción web de AD CS y la exposición de las plantillas de certificados se hayan remediado si formaban parte de la cadena de retransmisión

Esa validación debe realizarse sobre sistemas relevantes para producción, no solo sobre una máquina de laboratorio que nunca formó parte del riesgo original.

Cómo lo detecta EtcSec

EtcSec correlaciona las condiciones que hacen viable la retransmisión: el uso de NTLM, los objetivos propicios para la retransmisión y las debilidades de configuración cercanas, como una exposición débil de SMB, LDAP o de inscripción de certificados. Esto resulta más útil que una única alerta aislada, porque la misma red puede contener tanto tráfico NTLM inofensivo como un pequeño número de rutas que realmente son explotables.