4.3 · NTLM: captura, relay y coerción

Panorama#

NTLM (NT LAN Manager) es el protocolo de autenticación heredado que Active Directory arrastra desde antes de Kerberos y que, por compatibilidad, sigue activo en casi todos los dominios. Su debilidad no es un bug puntual sino un rasgo de diseño: es un protocolo de desafío/respuesta (challenge/response) donde el servidor envía un desafío aleatorio, el cliente lo cifra con un derivado del hash de su contraseña y devuelve esa respuesta. Esa respuesta —el Net-NTLM hash— tiene dos propiedades que la vuelven peligrosa. Primero, se puede capturar de la red y craquear offline para recuperar la contraseña. Segundo, y mucho más grave, se puede retransmitir (relay) a un tercer servicio sin conocer nunca la contraseña: como la respuesta prueba la identidad del cliente ante cualquier servidor que use el mismo desafío, un atacante en el medio la reenvía a un objetivo distinto y se autentica como la víctima sin haber craqueado nada.

Conviene separar dos hashes que suelen confundirse. El NT hash es el secreto almacenado, derivado de la contraseña, y sirve para Pass-the-Hash (ver 4.2 · Kerberos y 4.5 · Credential dumping). El Net-NTLM hash es la respuesta de red de una autenticación concreta: no sirve para Pass-the-Hash, pero sí para craqueo offline o para relay en vivo. Este capítulo cubre cómo se capturan los Net-NTLM de la red, cómo se retransmiten a servicios que no exigen signing, y cómo la coerción obliga a máquinas privilegiadas —incluido un controlador de dominio— a entregar su autenticación. El punto de partida es el mapa del dominio de 4.1 · Reconocimiento de AD; el punto de llegada, con frecuencia, es la creación de una cuenta de máquina con delegación (ver 4.6 · Delegación y trusts) o el DCSync de 4.5 · Credential dumping.

flowchart LR
  A["Sin credenciales"] --> B{"Obtener una\nautenticación NTLM"}
  B -->|"LLMNR/NBT-NS/mDNS\n(Responder)"| C["Net-NTLMv2 capturado"]
  B -->|"Coerción:\nPetitPotam / SpoolSample"| D["Auth de una cuenta\nde máquina (incl. DC)"]
  C --> E{"¿Craquear o\nrelayear?"}
  D --> F["Relay NTLM\n(ntlmrelayx)"]
  E -->|"contraseña débil"| G["Crack offline\nhashcat -m 5600"]
  E -->|"hash fuerte"| F
  F -->|"LDAP signing off"| H["Crear cuenta de máquina\n→ RBCD (ver 4.6)"]
  F -->|"SMB signing off"| I["Volcar SAM /\nproxy SOCKS"]
  F -->|"Drop the MIC\nSMB→LDAP"| J["DCSync (ver 4.5)"]

Capturar el Net-NTLM: v1 y v2#

La captura empieza por un envenenamiento de resolución de nombres. Cuando un equipo Windows no logra resolver un nombre por DNS, recurre a protocolos de fallback —LLMNR (Link-Local Multicast Name Resolution), mDNS y NBT-NS (NetBIOS Name Service)— que preguntan “¿quién es este nombre?” por multicast a toda la red local. Responder (o su equivalente en Windows, Inveigh) responde a esas preguntas fallidas afirmando ser el recurso buscado, con lo que la víctima intenta autenticarse contra el atacante y filtra su Net-NTLMv2 hash, craqueable offline.

La versión Net-NTLMv1 es un objetivo mucho más valioso cuando aparece, porque se deriva del NT hash con DES —criptografía débil— y, si se captura con un desafío fijo conocido, permite recuperar el NT hash directo (no la contraseña, sino el hash reutilizable para Pass-the-Hash). El truco es forzar a la víctima a usar v1 y configurar Responder con el desafío mágico 1122334455667788: contra ese valor constante existen tablas precomputadas (crack.sh) que devuelven el NT hash en minutos. La v1 solo está disponible si el nivel de compatibilidad LAN Manager de la víctima lo permite (LmCompatibilityLevel = 0x1), condición cada vez más rara en entornos modernos pero todavía presente en equipos y dispositivos heredados.

El relay: retransmitir en lugar de craquear#

Craquear un Net-NTLM depende de que la contraseña sea débil y puede tardar horas o no terminar nunca. El relay elimina esa dependencia: toma la autenticación capturada y la reenvía en vivo a otro servicio, sin craquear nada, con la única condición de que el servicio de destino no exija signing (la firma criptográfica que ata una sesión autenticada a su canal original y así impide la retransmisión). El problema es que ese signing viene desactivado o no requerido por defecto en las configuraciones que más importan, de modo que un atacante sin ninguna credencial puede inyectarse en el dominio aprovechando nada más que los valores de fábrica.

La herramienta central es ntlmrelayx (de Impacket), que recibe la autenticación de Responder —configurado para no responder él mismo a SMB/HTTP, sino cedérsela al relay— y la dirige a un objetivo. Los dos destinos canónicos son LDAP y SMB:

La creación de cuentas de máquina exige LDAP sobre TLS (LDAPS), de ahí el ldaps://. Una vez creada la cuenta controlada, se le puede configurar Resource-Based Constrained Delegation (RBCD) para impersonar a un administrador contra un objetivo — la cadena completa se desarrolla en 4.6 · Delegación y trusts. El relay a LDAP también es el vector de varios de los escenarios de AD CS de 4.4 · Active Directory Certificate Services, donde la autenticación relayeada se usa contra una autoridad certificadora vulnerable.

Coerción: fabricar la víctima#

El envenenamiento LLMNR captura autenticaciones oportunistas, pero las cuentas más valiosas —las de máquina de un DC— no suelen resolver nombres al azar. La coerción (coercion) resuelve eso: obliga a un host concreto a autenticarse contra el atacante bajo demanda, abusando de servicios RPC que aceptan una ruta UNC controlada. PetitPotam abusa de MS-EFSRPC (el servicio de cifrado de archivos), SpoolSample / printerbug abusa del Print Spooler, y el truco WebClient fuerza autenticación por HTTP en vez de SMB. Cualquiera de ellos convierte “no tengo nada” en “el DC se está autenticando contra mí ahora mismo”, y esa autenticación coaccionada es la que se relaya.

Sorteando las protecciones#

Cuando el signing está parcialmente configurado, existen variantes que abren el relay igualmente:

• Drop the MIC (CVE-2019-1040). El paquete NTLM incluye un MIC (Message Integrity Code) que debería impedir modificarlo. Esta vulnerabilidad permite alterar el paquete —removiendo los flags que bloquean el relay de SMB a LDAP— sin invalidar su integridad. Encadenado con la coerción del spooler y --escalate-user o --delegate-access, concede DCSync o RBCD directamente. Es el ejemplo de cómo una falla de integridad del propio protocolo abre el relay cross-protocolo.
• mitm6. Desde MS16-077 el archivo de autoconfiguración de proxy (WPAD) se pide por DNS, no por broadcast. mitm6 envenena la resolución DNS por IPv6 vía DHCPv6 —una pila que suele estar activa y sin vigilar— y sirve un WPAD malicioso; la víctima usa al atacante como proxy y su NTLM se relaya a LDAPS. Es especialmente efectivo porque IPv6 rara vez está monitoreado aun cuando no se usa deliberadamente.
• MS08-068 y las “papas”. MS08-068 fue la reflexión NTLM original (relayear una conexión SMB de vuelta a su propio origen). Sus sucesoras —Ghost Potato (CVE-2019-1384) y RemotePotato0— abusan de la activación DCOM para relayear en contextos donde hay un administrador logueado en otra sesión del mismo host.

Bajo el capó: SSPI, el MIC y por qué el relay es estructural#

Vale bajar una vez al nivel de la estructura, porque el relay no es un fallo puntual que un parche cierre: es una consecuencia directa de cómo Windows separó la autenticación del transporte, y entender esa separación es lo que explica por qué el MIC no alcanza, qué límite impone el double hop y por qué la protección definitiva viene desactivada de fábrica.

El intercambio de tres tokens y la SSPI. NTLM es un protocolo de tres mensajes binarios que las aplicaciones no manejan directamente sino a través de la SSPI (Security Support Provider Interface), la interfaz que aísla la lógica criptográfica del protocolo de red que la transporta. El cliente llama a InitializeSecurityContext y emite un NEGOTIATE con sus capacidades; el servidor llama a AcceptSecurityContext y responde con un CHALLENGE que lleva el desafío aleatorio de ocho bytes; el cliente cierra con un AUTHENTICATE que contiene la respuesta —el NTProofStr, un HMAC-MD5 calculado con el hash de la contraseña y, en NTLMv2, el desafío del propio cliente— probando que conoce el secreto sin transmitirlo.

La disociación es la causa raíz del relay. El punto crítico es que la SSPI produce tokens opacos y no sabe nada del canal que los lleva. Genera y valida el NEGOTIATE/CHALLENGE/AUTHENTICATE sin ninguna noción de qué conexión TCP, qué sesión SMB o qué handshake TLS los transporta; atar la autenticación a su canal es responsabilidad de la aplicación, y por defecto la aplicación no lo hace. De ahí que un AUTHENTICATE capturado en una conexión valide en otra: el relay no viola el protocolo, explota que la capa lógica y la capa de red nunca se presentaron. Es el mismo hueco visto en el panorama —la respuesta prueba la identidad ante cualquier servidor que use el mismo desafío—, ahora nombrado en su origen.

El MIC protege la integridad, no la dirección. Para impedir que un atacante manipule la negociación, NTLM deriva una clave de sesión de la respuesta y calcula sobre los tres tokens un MIC (Message Integrity Code), un HMAC-MD5 que congela lo negociado: si alguien altera un token para pedir más permisos o remover los flags que bloquean el relay entre protocolos, la validación del MIC falla. Pero el MIC firma el contenido, no el trayecto: unos tokens retransmitidos sin modificar pasan la verificación intactos. Esa es exactamente la distinción que CVE-2019-1040 («Drop the MIC») convierte en ataque —degrada la negociación para prescindir del MIC y así poder alterar los tokens en el relay de SMB a LDAP—; con los internals a la vista, el bypass deja de ser un truco opaco y pasa a ser «desactivar la única firma que protegía la negociación».

El double hop: el límite que NTLM impone y que la delegación existe para levantar. Hay una propiedad estructural con lado defensivo: el servidor de destino nunca recibe la contraseña ni el NT hash del usuario, solo la clave de sesión de esa autenticación puntual. Por eso no puede reutilizar la credencial para autenticarse, en nombre del usuario, contra un tercer servidor: la credencial no encadena. Es el double hop problem —la razón por la que una sesión remota (WinRM, PowerShell Remoting) no alcanza un segundo salto sin más—, y también el motivo por el que existe la delegación de 4.6 · Delegación y trusts: conceder de forma controlada justo ese encadenamiento que NTLM niega por defecto. La no-delegabilidad de NTLM es, leída al derecho, una contención natural del movimiento en cascada.

La protección definitiva viene apagada. La forma correcta de volver a presentar la capa lógica con la de red es el Channel Binding (Extended Protection for Authentication, EPA): el cliente incrusta dentro del AUTHENTICATE cifrado un resumen del certificado TLS del canal externo, de modo que un token relayeado a otro canal ya no valida. Su pariente, el Target Name (el SPN del servidor pretendido incrustado en el token), ata la autenticación al destino esperado. El problema —y la razón por la que el relay sobrevive— es que ambos son de inclusión afirmativa (opt-in): por defecto el cliente no fija el target name y el servidor SMB no lo exige, así que en un entorno grande y heterogéneo la protección casi nunca está puesta a menos que alguien la imponga deliberadamente. Todo el intercambio se puede además diseccionar con NtObjectManager (New-LsaCredentialHandle -Package NTLM, y reproducir el NTProofStr y el MIC con HMACMD5 de .NET), que es lo que convierte esta explicación en algo que un analista puede abrir y verificar.

Defensa y detección#

La defensa contra el relay NTLM es, de todas las de Active Directory, una de las más efectivas por su relación costo/beneficio: casi todo el ataque nace de defaults que se pueden endurecer con política de grupo, y ese endurecimiento cierra la familia entera de raíz.

• Habilitar el signing obligatorio es la contramedida estructural: SMB signing “required” y LDAP signing más channel binding activados anulan el relay en su núcleo, porque la autenticación queda atada a su canal y ya no puede retransmitirse. Es la línea de defensa que más ataques cierra con un solo cambio.
• Deshabilitar LLMNR y NBT-NS por GPO elimina el envenenamiento de resolución de nombres que alimenta la captura, y deshabilitar IPv6 donde no se use deliberadamente mata a mitm6.
• MachineAccountQuota = 0 impide que una autenticación relayeada cree una cuenta de máquina, cortando el paso de RBCD que corona el ataque.
• Detección en telemetría. Autenticaciones NTLM donde el contexto haría esperar Kerberos son la señal central: Event ID 4624 (logon exitoso) y 4776 (validación de credencial NTLM) con paquete NTLM sobre hosts unidos a dominio. La creación de una cuenta de máquina (Event ID 4741) originada por relay, y las conexiones entrantes de EFSRPC o del spooler hacia hosts que no son controladores de dominio, delatan la coerción. Y en la capa de red, el desafío fijo 1122334455667788 en el tráfico es una firma directa e inequívoca de Responder.

Las cuentas privilegiadas deben marcarse además como “Account is Sensitive and Cannot Be Delegated” para que una impersonación por delegación no las alcance. El mapeo defensivo consolidado de toda la superficie de Active Directory, con las reglas SIEM y los playbooks de respuesta, se desarrolla en 4.9 · Defensa de AD.

Referencias#

• red-infra/ad-attacks/cap-06 — Captura de Net-NTLMv1/v2, relaying NTLM, coerción y las variantes de bypass del signing.
• red-infra/windows-security-internals/cap-13 — Forshaw, Network Authentication (NTLM): el intercambio de tres tokens vía SSPI (InitializeSecurityContext/AcceptSecurityContext), la disociación entre la capa lógica y el transporte como raíz del relay, el cálculo del NTProofStr y el MIC (HMAC-MD5), el double hop problem y las protecciones opt-in (channel binding/EPA, target name); disección con NtObjectManager.
• MITRE ATT&CK — T1557.001 LLMNR/NBT-NS Poisoning and SMB Relay y T1187 Forced Authentication.
• CVE-2019-1040 — Drop the MIC: manipulación de la integridad del paquete NTLM para relay cross-protocolo.
• Microsoft — guía de mitigación de relay NTLM (KB5005413) y Enforcing SMB/LDAP signing.