NTLM relay

NTLM es el protocolo de desafío y respuesta anterior a Kerberos y sigue habilitado en casi todas partes. El servidor emite un desafío, el cliente devuelve una respuesta calculada a partir del hash de la contraseña, y el servidor la verifica con el controlador de dominio. No se recupera nada, así que esto no es pass-the-hash: el hash no llega a estar en manos del atacante en ningún momento. Nada en ese intercambio ata la respuesta al servidor que emitió el desafío, así que un atacante colocado entre los dos puede pasar el desafío desde otro destino y devolver la respuesta, y autenticarse contra ese destino haciéndose pasar por la víctima.

Conseguir que la víctima se autentique es la parte fácil. Los protocolos de resolución de nombres por difusión contestan por nombres que no existen, así que un atacante en el mismo segmento puede decir que él es cualquier recurso compartido mal escrito. A varias funciones de Windows se las puede inducir a que hagan que una máquina se autentique contra la dirección que elija el atacante. Hay herramientas públicas, principalmente Responder y las utilidades de relay de Impacket, que implementan todo esto.

Las contramedidas son configuración, están bien documentadas y faltan en casi todos los parques que probamos. La firma en el protocolo SMB impide el relay hacia servicios de ficheros y no se exige por defecto en todas partes. El channel binding y la protección extendida impiden el relay hacia servicios sobre TLS, como los servicios de directorio y los puntos web de emisión de certificados. Los dos son interruptores, y los dos rompen algo antiguo, y por eso siguen apagados.

El destino de más valor en un parque moderno es el servicio de certificados. Retransmitir la autenticación de una máquina o de un usuario hacia un punto web de emisión y obtener un certificado para esa identidad convierte una autenticación pasajera en una credencial duradera que sobrevive a un cambio de contraseña, y ahí es donde esto se encuentra con el abuso de los servicios de certificados. La corrección de verdad es desactivar del todo el protocolo heredado, y eso es un proyecto y no un ajuste, porque la parte difícil es inventariar qué sigue dependiendo de él.

Lo informamos como una cadena con el destino nombrado, porque retransmitir hacia un puesto de trabajo y retransmitir hacia un servicio de directorio son hallazgos distintos. La evidencia es la autenticación capturada, el destino alcanzado, la identidad con la que se nos aceptó y qué podía hacer esa identidad, junto con el estado de firma y de channel binding de los servicios afectados, porque esa es la tabla de configuración con la que va a trabajar el cliente. Es una de las rutas más fiables que van de un cable de red a un privilegio de dominio, y no necesita ningún parche pendiente, y por eso forma parte de cómo probamos la autenticación de red de Windows en un proyecto interno.