NTLM Relay

El protocolo de autenticación NTLM es un reto-respuesta: el cliente prueba que conoce el hash sin enviarlo. El problema es que esa prueba no está atada al servidor al que va dirigida. Si un atacante captura (o coacciona) un intento de autenticación NTLM de una víctima, puede reenviarlo en tiempo real a un tercer servicio y autenticarse como la víctima allí, sin conocer ni crackear su contraseña. Eso es NTLM relay: no robas la credencial, la rediriges.

flowchart LR
    V[Víctima] -->|"autentica NTLM"| A[Atacante / relay]
    A -->|"reenvía la auth"| T[Servidor objetivo]
    T -->|"acceso como la víctima"| A

Modelo de amenaza

NTLM carece de una vinculación fuerte entre la autenticación y el canal/servicio destino. La defensa que lo rompe es la firma (SMB signing, LDAP signing + channel binding): si el servicio exige firma, el relay falla porque el atacante no puede firmar con la clave de sesión. Donde la firma no se exige —y por defecto no siempre se exige— el relay funciona. El atacante encadena coerción → relay → ejecución/escalada.

Red Team

El flujo

1. víctima autentica contra el atacante (LLMNR/Responder, coerción, WPAD)
2. ntlmrelayx reenvía ese handshake a un servicio objetivo
3. el objetivo cree que es la víctima -> atacante actúa como ella

Importante: Responder y ntlmrelayx compiten por los puertos 445/80; en relay se desactiva SMB/HTTP de Responder (Responder.conf) y se deja que ntlmrelayx reciba.

Herramientas y objetivos de relay

# relay a SMB para ejecutar o volcar SAM donde la víctima sea admin local
ntlmrelayx.py -tf targets.txt -smb2support
# relay a LDAP/LDAPS en el DC -> RBCD o shadow credentials
ntlmrelayx.py -t ldaps://<DC> --delegate-access
# relay a AD CS Web Enrollment (ESC8) -> certificado -> TGT de la víctima
ntlmrelayx.py -t http://<CA>/certsrv/certfnsh.asp -smb2support --adcs --template User

Destinos de relay de alto impacto:

SMB → ejecutar comandos / volcar SAM en un host donde la cuenta relayed sea admin local.
LDAP(S) en el DC → escribir RBCD sobre un equipo (Delegación de Kerberos) o Shadow Credentials (Shadow Credentials) → luego impersonar.
AD CS HTTP (ESC8) → solicitar un certificado como la víctima → usarlo para obtener su TGT (AD CS (Active Directory Certificate Services)). Si la víctima coaccionada es un DC, esto es compromiso total del dominio.
MSSQL, HTTP internos.

Coerción (conseguir que la víctima autentique)

PetitPotam (EFSRPC), PrinterBug/SpoolSample (MS-RPRN), DFSCoerce, ShadowCoerce, Coercer → fuerzan a un servidor (incluido un DC) a autenticar contra el atacante.
mitm6 (DHCPv6/WPAD) → fuerza autenticación vía proxy.
UNC injection (\\attacker\x) en documentos, campos LDAP, etc.

La combinación PetitPotam (coerce DC) → relay a AD CS (ESC8) → certificado de DC → DCSync es una de las cadenas a Domain Admin más potentes.

Herramientas

impacket ntlmrelayx.py — el motor de relay (SMB/LDAP/HTTP/AD CS/MSSQL).
Responder / Inveigh — captura/coerción en la LAN.
PetitPotam / Coercer / SpoolSample / DFSCoerce — coerción forzada.
mitm6 — relay vía IPv6.

Impacto

Ejecución de comandos, volcado de credenciales, creación de rutas de delegación (RBCD) y, encadenado con coerción de un DC + AD CS, toma del dominio completo sin crackear una sola contraseña.

Blue Team

Detección

Autenticaciones NTLM donde el origen y el destino no cuadran con el flujo normal; una cuenta de máquina (DC$) autenticando contra hosts raros (señal de coerción+relay).
Llamadas MS-EFSRPC/MS-RPRN hacia máquinas no servidores (PetitPotam/PrinterBug).
Solicitudes de certificado anómalas en AD CS (ESC8); escrituras msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD) inesperadas.

Telemetría

Eventos 4624/4648 (logon NTLM), auditoría de AD CS (certificados emitidos), cambios en atributos de delegación en el DC, y detección de coerción (tráfico RPC a \pipe\efsrpc, \pipe\spoolss).

Hardening

Exige firma: SMB signing obligatorio en todos los hosts, LDAP signing + LDAP channel binding en los DCs (rompe el relay a LDAP).
EPA (Extended Protection for Authentication) en servicios web, especialmente AD CS Web Enrollment (mitiga ESC8); o deshabilita el enrollment HTTP.
Deshabilita NTLM donde sea posible (Kerberos only); Protected Users, Channel Binding.
Mitiga coerción: parches (PetitPotam), deshabilita el Spooler en DCs, filtra RPC.
Reduce/elimina LLMNR, NBT-NS, WPAD, IPv6 no usados (corta la captura inicial — ver LLMNR / NBT-NS / mDNS Poisoning).

Respuesta

Identifica la cadena (origen de coerción, servicio relayed), aísla, revierte RBCD/shadow creds/certificados maliciosos emitidos, rota credenciales (incluida la cuenta de máquina/krbtgt si tocó el DC) y aplica firma/EPA.

CVEs y casos reales

PetitPotam (CVE-2021-36942) + AD CS ESC8 → cadena pública de coerción de DC a Domain Admin; muy explotada.
PrinterBug (MS-RPRN) y DFSCoerce — coerción sin parche fiable durante años.
Drop the MIC (CVE-2019-1040) y CVE-2019-1166 — bypass de MIC que revivió relays que se creían mitigados.
MITRE T1557.001 (relay) + T1187 (forced authentication); presente en playbooks de ransomware y APT.

Checklist de prueba

¿SMB signing no obligatorio en hosts objetivo? (relay a SMB viable)
¿LDAP signing / channel binding no forzado en DCs? (relay a LDAP → RBCD/shadow)
¿AD CS Web Enrollment (HTTP) sin EPA? (ESC8)
¿Coerción posible (PetitPotam/PrinterBug/DFSCoerce) hacia un DC?
¿mitm6/IPv6 disponible para forzar auth?
Cadena completa coerce DC → relay AD CS → DCSync
Blue: ¿detección de MS-EFSRPC/MS-RPRN y firma aplicada?