Bloquear el NTLM saliente en los controladores de dominio Tier 0: ataques de coerción y relay detenidos en la GPO

Qué significa «NTLM saliente» para un controlador de dominio

Esta guía explica cómo bloquear el NTLM saliente en los controladores de dominio Tier 0: las cadenas de coerción y relay como PetitPotam y las técnicas que vinieron después dependen por completo de que esa autenticación saliente exista en primer lugar — deniégala y no les queda nada que retransmitir. Los controladores de dominio autentican con Kerberos casi todo lo que hacen entre ellos y hacia los demás servicios integrados en Active Directory, pero NTLM sigue existiendo por debajo como mecanismo de reserva y, de forma predeterminada, cualquier sistema Windows se autentica de buen grado hacia fuera mediante NTLM ante cualquier servidor que se lo pida.

La ANSSI, la agencia nacional francesa de ciberseguridad, documenta este patrón directamente en su guía de administración de Active Directory. La autenticación NTLMv2 es un inicio de sesión de red — distinto de los inicios de sesión interactivos que dejan hashes reutilizables en memoria — y su respuesta al desafío puede interceptarse en vuelo y retransmitirse a un segundo objetivo sin que el atacante llegue nunca a conocer el secreto subyacente: toma prestados los derechos de acceso de la víctima en lugar de robarle la contraseña (ANSSI-PA-099, §4.15.2). Cuando el sistema coaccionado es un controlador de dominio, los derechos de acceso que se retransmiten son los del Tier 0.

Cómo los ataques de coerción y relay abusan del NTLM saliente

El miembro mejor documentado de esta familia es PetitPotam. El aviso del CERT/CC dedicado a la técnica explica que abusa del Protocolo remoto del sistema de cifrado de archivos (EFSRPC): una llamada a EfsRpcOpenFileRaw hace que el sistema objetivo «use NTLM para autenticarse con el host especificado dentro de la ruta», y un atacante puede apuntar esa ruta hacia infraestructura bajo su control — desencadenando un intento de autenticación NTLM desde la propia cuenta de equipo del controlador de dominio, sin necesidad de credenciales para iniciar la cadena (CERT/CC VU#405600).

Esa autenticación NTLM capturada solo es peligrosa porque en algún otro sitio se acepta. El CERT/CC expone en tres pasos la cadena completa contra los Servicios de certificados de Active Directory (AD CS):

Paso 1 — Coerción

El atacante llama a EfsRpcOpenFileRaw (o a un método RPC equivalente con el mismo comportamiento desencadenante de autenticación) contra el controlador de dominio, apuntándolo hacia infraestructura controlada por el atacante. La cuenta de equipo del DC abre una autenticación NTLM saliente — se trata de un inicio de sesión de red, señala la guía de la ANSSI, y no del tipo interactivo que deja hashes reutilizables en memoria.

Paso 2 — Relay

El atacante captura la respuesta al desafío NTLMv2 — el hash «Net-NTLMv2» — y la retransmite de inmediato, sin modificarla, al punto de conexión HTTP de inscripción web de AD CS antes de que caduque.

Paso 3 — Conversión

AD CS emite un certificado para la cuenta de equipo del controlador de dominio. El CERT/CC indica que ese certificado «puede usarse para obtener un Ticket Granting Ticket (TGT)», lo que basta para comprometer el dominio entero — sin que jamás hiciera falta descifrar una contraseña ni un hash.

Cada paso de esa cadena depende de que el paso 1 tenga éxito: el controlador de dominio tiene que estar dispuesto a enviar autenticación NTLM hacia fuera en primer lugar. Elimina eso y los pasos 2 y 3 se quedan sin materia prima.

La corrección de Microsoft, registrada como CVE-2021-36942 («Windows LSA Spoofing Vulnerability»), cerró únicamente la versión no autenticada de la llamada EfsRpcOpenFileRaw. No cerró el patrón subyacente — un sistema Tier 0 todavía puede ser empujado a una autenticación NTLM saliente a través de otras interfaces RPC que se comportan igual, razón por la cual las propias recomendaciones de mitigación de Microsoft para esta familia de ataques van más allá de un solo parche. El artículo KB5005413 recomienda habilitar la protección extendida para la autenticación en los puntos de conexión de AD CS y, como opción más contundente a nivel de protocolo, «deshabilitar la autenticación NTLM en el controlador de dominio de Windows» lisa y llanamente (Microsoft KB5005413). Esa segunda opción es precisamente lo que la recomendación R73 de la ANSSI concreta en un único parámetro de directiva de grupo.

Bloquear el NTLM saliente en los controladores de dominio Tier 0 (ANSSI R73)

La recomendación R73 de la ANSSI es directa: «las autenticaciones NTLM salientes de todos los sistemas del Tier 0 deben bloquearse», aplicada mediante un único parámetro de directiva de grupo. La ruta de la GPO, tomada de la guía, es:

Computer Configuration\Windows Settings\Security Settings\Local Policies\
Security Options\Network Security: Restrict NTLM: Outgoing NTLM traffic
to remote servers → Deny all

La documentación de referencia de Microsoft para este parámetro confirma los mismos tres estados — Allow all (sin restricción), Audit all (registra cada intento de NTLM saliente sin bloquearlo) y Deny all (el dispositivo «no puede autenticar ninguna identidad ante un servidor remoto mediante autenticación NTLM») — y señala que el parámetro está en Not Configured de forma predeterminada en todo controlador de dominio y todo servidor miembro (Microsoft Learn — Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers). Si se deja sin configurar, la familia de coerción y relay dispone exactamente de la vía saliente que necesita.

La ANSSI es explícita: Audit all no es suficiente para R73 — la recomendación prescribe el bloqueo, no el registro. El modo auditoría es el paso previo al despliegue: déjalo funcionando el tiempo suficiente para confirmar que no existe tráfico NTLM saliente legítimo desde el Tier 0 (normalmente no debería haberlo, ya que el tráfico de DC a DC y de DC a los servicios de AD admite Kerberos de forma nativa) y después cambia a Deny all. La guía añade una salvedad operativa que conviene tomarse en serio: bloquear el NTLM saliente presupone que los sistemas del Tier 0 alcanzan los demás servicios de AD por FQDN en lugar de por dirección IP en bruto, ya que Kerberos depende de la resolución de nombres para seleccionar el ticket de servicio correcto — una configuración incorrecta que la fase de auditoría sacará a la luz antes de que provoque una interrupción.

El control complementario: restringir lo que el Tier 0 envía hacia abajo (ANSSI R82/R83)

Bloquear el NTLM saliente cierra la vertiente de autenticación de red de la exposición del Tier 0. La posición de referencia de la ANSSI es que las estaciones de administración del Tier 0 no deberían tener ninguna conectividad descendente de partida — dedicadas físicamente, con tráfico saliente permitido únicamente hacia recursos del Tier 0 (R80). R82 y R83 se aplican específicamente cuando una organización adopta en su lugar la segunda arquitectura alternativa de la ANSSI: la mutualización del acceso remoto del Tier 0 hacia entornos de menor confianza, como repliegue transitorio a la espera de una segregación completa. Dentro de ese modelo, R82 restringe qué métodos de conexión remota se permiten desde el Tier 0 hacia zonas de menor confianza — RPC/MMC, PowerShell WinRM con su autenticación de red Kerberos-o-NTLM predeterminada, o RDP nativo ya sea en modo RestrictedAdmin o usando una cuenta acotada al tier de destino. R83 va más allá: la cuenta empleada para una sesión interactiva en ese destino de menor confianza debe pertenecer a la propia zona de confianza de ese destino, nunca a una credencial del Tier 0 o del Tier 1, de modo que un sistema de tier inferior comprometido nunca acabe reteniendo secretos reutilizables del Tier 0. Para el recorrido completo de las restricciones de inicio de sesión acotadas por tier, consulta Directivas de autenticación y silos de Active Directory para el Tier 0.

Detectar el NTLM saliente antes y después del bloqueo

Ambos Event ID están confirmados directamente en el ANSSI-PA-099 §4.15.2.1, y la documentación de referencia de Microsoft para este parámetro de directiva apunta a la misma ruta de registro operativo. Dos cosas que merece la pena vigilar una vez que el bloqueo esté activo:

• Cualquier ráfaga de Event ID 4001 tras el despliegue merece investigación — o bien se pasó por alto una dependencia legítima durante la fase de auditoría, o bien algo está intentando activamente provocar una autenticación saliente y está siendo detenido.
• Los Event ID 8001 durante la fase de auditoría son tu mapa de dependencias. Cada par origen/destino que aparezca es algo que resolver — corrígelo, exímelo o migra a Kerberos — antes de pasar a Deny all.

La cobertura de detección relacionada — las defensas contra el relay de LDAP y SMB, que importan con independencia de que el NTLM saliente esté bloqueado o no — se trata en El enlace de canal LDAP en los controladores de dominio y La firma SMB y el relay NTLM.

Remediation

1. Confirma primero el alcance del Tier 0. R73 solo funciona si tu UO de Tier 0 contiene realmente todos los controladores de dominio y todos los servidores sensibles del Tier 0 — contrástalo con tu modelo de administración por tiers antes de vincular ninguna GPO.
2. Despliega Audit all en una GPO vinculada a la UO del Tier 0. Déjala funcionando el tiempo suficiente para abarcar tu ciclo de parches, tus trabajos de copia de seguridad y cualquier tarea administrativa mensual o trimestral — las ventanas de auditoría cortas dejan fuera dependencias recurrentes.
3. Revisa las entradas de Event ID 8001 y resuelve cada una de las legítimas: apunta el origen a Kerberos (normalmente una corrección de DNS/SPN), añádelo a la lista de excepciones de servidores NTLM si realmente no puede abandonar NTLM, o retira la dependencia.
4. Cambia esa misma GPO a Deny all. Vigila el Event ID 4001 en los días siguientes — cualquier cosa inesperada es o una dependencia que se pasó por alto o un intento de coerción activo.
5. Extiende a R74+ una vez que el Tier 0 esté limpio: vincula una GPO equivalente en la raíz del dominio para el resto del entorno, con excepciones filtradas por WMI allí donde NTLM todavía no pueda eliminarse de verdad.
6. Añade R82/R83 para los administradores del Tier 0 que deban conectarse hacia abajo — restringe el método de conexión remota y exige una cuenta del tier de destino, conforme a la sección anterior, para que este control y el bloqueo a nivel de red cubran ambos sentidos del riesgo.
7. Combínalo con el endurecimiento del lado del relay. El bloqueo del NTLM saliente elimina la fuente de las autenticaciones retransmitidas desde el Tier 0, pero cualquier sistema del SI que siga aceptando objetivos de relay NTLM sin firmar o sin proteger (LDAP sin enlace de canal, SMB sin firma, inscripción web de AD CS sin protección extendida) sigue siendo explotable contra víctimas fuera del Tier 0. Trata esta GPO como una capa, no como toda la defensa.

Cómo lo detecta EtcSec

La auditoría de Active Directory de EtcSec busca exactamente esta carencia de configuración. ANSSI_R73_NTLM_OUTBOUND_TIER0 señala la ausencia de cualquier parámetro de GPO que ponga RestrictSendingNTLMTraffic en Deny all en el conjunto de los sistemas del Tier 0 — el modo de solo auditoría se considera correctamente como no satisfactorio para el control. ANSSI_R74_NTLM_OUTBOUND_DOMAIN hace un seguimiento aparte de si esa misma directiva de bloqueo se ha extendido a una GPO vinculada en la raíz del dominio. ANSSI_R82_R83_ADMIN_ARCHITECTURE señala los sistemas del Tier 0 que carecen de las salvaguardas de arquitectura de administración que exigen R82 y R83, y NTLM_RELAY_OPPORTUNITY señala la exposición al relay más amplia del entorno siempre que NTLM siga siendo alcanzable sin las protecciones compensatorias descritas arriba.