NTLM y Kerberos explicados con diagramas — por qué la autenticación «cae» a NTLM

Incluso en redes corporativas de las que se dice «aquí todo es Kerberos», si se revisan los registros de auditoría siempre aparece NTLM. Y lo que aparece suele ser, precisamente, la aplicación que se supone compatible con Kerberos.

La razón se entiende de un vistazo si se ponen una junto a la otra las dos preguntas que cada protocolo intenta responder: «¿qué se está demostrando?». Este artículo repasa con diagramas el funcionamiento de NTLM y Kerberos, y ordena, con el respaldo de la documentación oficial, en qué condiciones la autenticación cae a NTLM y por qué Microsoft está retirando NTLM.

El procedimiento para hacer el inventario del propio entorno (configuración de la directiva de auditoría, cómo seguir los eventos, en qué orden corregirlos) está recogido en el artículo complementario «¿Se detienen las aplicaciones de negocio al retirar NTLM?».

1. Empecemos por la conclusión

• NTLM demuestra únicamente que se posee el hash de la contraseña. Las credenciales son un hash unidireccional del nombre de dominio, el nombre de usuario y la contraseña, ¹ y en el NTLMv2 que usan las versiones actuales de Windows se calcula, con una clave derivada de ese hash, un HMAC sobre «el desafío del servidor + la hora + el desafío del lado del cliente + la información de destino», que es lo que se devuelve (apartado 2.2). ²
• Kerberos demuestra «quién» se autentica «ante qué servicio». Emite el ticket usando como clave el nombre del servicio de destino (SPN), de modo que un ticket con un destino distinto no sirve. ³
• Hay tres diferencias decisivas: si existe autenticación mutua, si el servidor necesita consultar al controlador de dominio (en la autenticación con cuentas de dominio) y si es posible la delegación. Microsoft deja las tres por escrito (capítulo 5). ⁴
• La razón más frecuente por la que la autenticación cae a NTLM es «el nombre». Kerberos no puede empezar si no logra obtener el SPN a partir del nombre del destino. Los cuatro factores principales son: usar directamente una dirección IP, un SPN no registrado, un grupo de trabajo y una ruta que no llega al controlador de dominio (capítulo 6). ⁵⁶
• «Kerberos falla» y «la autenticación cae a NTLM» son fenómenos distintos. El primero es un estado en el que se elige Kerberos y este termina en error (por ejemplo, un desfase horario), y la autenticación se detiene por completo. El segundo es un estado en el que Kerberos ni siquiera llega a iniciarse y el sistema pasa silenciosamente a NTLM, de modo que el trabajo sigue funcionando. La clasificación de un incidente debe empezar por esta disyuntiva (apartado 6.5). ⁷
• El ataque de retransmisión funciona porque NTLM no tiene ningún mecanismo que vincule «ante quién se está autenticando». Pass-the-Hash funciona porque lo único que hace falta para autenticarse es el propio hash (capítulo 7). ⁸¹
• NTLMv1 ya está eliminado. Afecta a Windows 11 versión 24H2 y Windows Server 2025. NTLMv2 está en desuso, pero todavía funciona (capítulo 8). ⁹
• Lo que debe usar una aplicación es Negotiate. Negotiate elige entre Kerberos y NTLM, y opta por Kerberos salvo que alguno de los sistemas implicados en la autenticación no pueda usarlo. ¹

2. Qué hace NTLM

NTLM (Windows Challenge/Response) es, tal como indica su nombre, un protocolo de autenticación basado en desafío/respuesta. Resumiendo la explicación de Microsoft: las credenciales se componen de un hash unidireccional del nombre de dominio, el nombre de usuario y la contraseña obtenidos durante el inicio de sesión interactivo, y, para autenticar sin enviar la contraseña por la red, la parte que solicita la autenticación realiza un cálculo que demuestra que «tiene acceso a las credenciales NTLM almacenadas de forma segura». ¹

Lo importante aquí es que el material de la autenticación no es la contraseña en sí, sino el hash de la contraseña. Este único punto es, como se verá más adelante, la condición que hace posible Pass-the-Hash.

2.1. Con una cuenta de dominio intervienen tres partes

Cuando un usuario que ya inició sesión accede a un recurso de un servidor usando una cuenta de dominio (autenticación no interactiva), intervienen tres partes: el cliente, el servidor y el controlador de dominio. Lo característico aquí es que el propio servidor no realiza el cálculo de autenticación, sino que pide al controlador de dominio que lo haga por él. ¹

sequenceDiagram
    autonumber
    participant C as Cliente
    participant S as Servidor
    participant DC as Controlador de dominio

    Note over C: Al iniciar sesión calcula el hash<br/>de la contraseña y descarta la contraseña
    C->>S: Nombre de usuario (texto claro)
    S->>C: Número aleatorio de 8 bytes (desafío)
    Note over C: Cifra el desafío<br/>con el hash de la contraseña
    C->>S: Respuesta
    S->>DC: Nombre de usuario / desafío / respuesta
    Note over DC: Extrae el hash de la SAM<br/>y repite el mismo cálculo
    DC-->>S: Si coincide, autenticación correcta
    S-->>C: Concede el acceso

Figura 1: Autenticación no interactiva de NTLM (con cuenta de dominio)

El procedimiento que Microsoft describe a nivel conceptual es el siguiente (el cálculo real cambia con NTLMv2, como se ve más adelante, pero los actores y el reparto de funciones son los de este diagrama). ¹

1. (Solo en la autenticación interactiva) El usuario introduce el nombre de dominio, el nombre de usuario y la contraseña. El cliente calcula el hash criptográfico de la contraseña y descarta la contraseña real.
2. El cliente envía el nombre de usuario en texto claro al servidor.
3. El servidor genera un número aleatorio de 8 bytes (el desafío, o nonce) y lo envía al cliente.
4. El cliente cifra ese desafío con el hash de la contraseña del usuario y devuelve el resultado (la respuesta).
5. El servidor envía al controlador de dominio los tres datos: el nombre de usuario, el desafío enviado al cliente y la respuesta recibida.
6. El controlador de dominio extrae de la base de datos SAM el hash de la contraseña correspondiente al nombre de usuario y cifra con él el desafío.
7. Compara el resultado que acaba de calcular con la respuesta del cliente; si coinciden, la autenticación se considera correcta.

2.2. El cálculo real — NTLMv2 es un poco más complejo

Los siete pasos anteriores son el esquema básico que Microsoft explica en su página de introducción. El NTLMv2 que usan realmente las versiones actuales de Windows va un paso más allá de «cifrar el desafío con el hash de la contraseña». La especificación ([MS-NLMP]) lo define así: ²

• La clave de respuesta es NTOWFv2 = HMAC_MD5( MD4(UNICODE(contraseña)), nombre de usuario en mayúsculas + nombre de dominio )
• El cliente construye temp, la concatenación de la versión de la respuesta, la hora, un desafío de 8 bytes generado por el propio cliente y la información de destino (pares AV)
• El núcleo de la respuesta, NTProofStr, se calcula como NTProofStr = HMAC_MD5( clave de respuesta, desafío del servidor + temp )

Si se aísla solo el flujo de materiales y procesamiento, queda en una sola imagen.

flowchart TD
    PW["Contraseña"] --> MD4["MD4(UNICODE(contraseña))<br/>= hash NT"]
    UD["Nombre de usuario en mayúsculas<br/>+ nombre de dominio"] --> H1["HMAC_MD5"]
    MD4 -->|"se usa como clave"| H1
    H1 --> KEY["Clave de respuesta NTOWFv2"]

    MAT["Versión de la respuesta / hora /<br/>desafío de 8 bytes del cliente /<br/>información de destino (pares AV)"] --> TEMP["temp"]

    SC["Desafío del servidor"] --> H2["HMAC_MD5"]
    TEMP --> H2
    KEY -->|"se usa como clave"| H2
    H2 --> PROOF["NTProofStr"]
    PROOF --> RESP["NtChallengeResponse<br/>= NTProofStr + temp"]
    TEMP --> RESP

Figura 2: Cómo se construye la respuesta de NTLMv2 (contraseña → hash NT → clave de respuesta → HMAC)

Es decir, en la práctica se calcula un HMAC que mezcla no solo el desafío del servidor, sino también el número aleatorio del cliente, la hora y la información de destino. La parte que verifica reproduce el mismo cálculo: si la cuenta está en Active Directory, envía el par desafío/respuesta al controlador de dominio para su verificación; si la cuenta es local al servidor, el propio servidor calcula el valor esperado usando el OWF que tiene almacenado. ²

Para el argumento de este artículo, lo importante es que, aunque el cálculo se haya complicado, estos dos puntos no cambian:

1. El material de la clave sigue siendo el hash de la contraseña. El punto de partida de NTOWFv2 es MD4(UNICODE(contraseña)), es decir, el propio hash NT. ² Por eso Pass-the-Hash sigue funcionando (apartado 7.2).
2. El cliente no verifica si el servidor es auténtico. La explicación de Microsoft de que NTLM carece de autenticación mutua sigue siendo cierta en NTLMv2. ⁴

El resto del artículo se apoya en estos dos puntos.

2.3. Con una cuenta local todo se resuelve entre dos partes

Si la cuenta es local, el lado derecho de este diagrama desaparece. El servidor de recursos consulta al servicio de autenticación del controlador de dominio de esa cuenta cuando la cuenta es de dominio, pero consulta su base de datos de cuentas local cuando la cuenta es local. ¹⁰ Es decir, en un equipo de grupo de trabajo o al conectarse a un recurso compartido con una cuenta local de un servidor de archivos, el controlador de dominio no interviene en absoluto: se trata de un intercambio entre dos partes en el que el servidor consulta su propia SAM y decide por sí mismo.

Esta diferencia está directamente relacionada con el inventario de dependencias que se trata en el apartado 6.3: «no se puede usar Kerberos porque es una cuenta local». Esta ruta de NTLM no aparece aunque se revisen los registros de auditoría del controlador de dominio.

2.4. Tres consecuencias de este diseño

Si se observa la figura 1, se pueden leer directamente las propiedades que más adelante causarán problemas.

• El servidor no demuestra nada al cliente. El intercambio es en un solo sentido y no hay en ningún momento un paso en el que el servidor demuestre «que es auténtico».
• El servidor solo puede decidir cuando dispone él mismo del hash. El servidor de recursos necesita, cada vez que requiere un nuevo token de acceso, consultar al servicio de autenticación del controlador de dominio si la cuenta es de dominio, o consultar su base de datos de cuentas local si la cuenta es local. ¹⁰ Por eso la autenticación con cuentas de dominio depende del controlador de dominio.
• La respuesta solo vale «para ese desafío», pero no vincula el destino. Como el desafío cambia cada vez, no se puede reutilizar la misma respuesta. Pero, como no existe ningún elemento que demuestre «para qué servidor es esta respuesta», si se desvía hacia otro servidor no hay forma de darse cuenta.

3. Por qué el servidor consulta al controlador de dominio

En la autenticación con cuentas de dominio, el único lugar donde se guarda el hash de la contraseña es la base de datos de cuentas del controlador de dominio. El servidor de recursos no conoce el hash de ese usuario, así que no puede verificarlo por sí mismo. Por eso necesita consultar al controlador de dominio en cada autenticación (autenticación de paso, pass-through). ¹⁰¹ (Si la cuenta es local, el servidor consulta su propia SAM y decide por sí mismo; lo que sigue sobre la dependencia del controlador de dominio se refiere al caso de las cuentas de dominio.)

Esto tiene un coste, tanto en seguridad como en operación. Microsoft explica que, antes de Kerberos, en la autenticación NTLM el servidor de aplicaciones necesitaba conectarse al controlador de dominio cada vez que autenticaba a un cliente o a un servicio, mientras que en Kerberos los tickets de sesión renovables sustituyen esa autenticación de paso, y el servidor no necesita ir al controlador de dominio salvo que deba validar el PAC (certificado de atributos de privilegio). ⁴

Es decir, la migración a Kerberos no es solo una cuestión de seguridad: también es una forma de reducir la dependencia del controlador de dominio.

4. Qué hace Kerberos

El planteamiento de Kerberos es claramente distinto del de NTLM. En lugar de repetir la verificación de identidad en cada autenticación, se verifica la identidad una sola vez al principio, se recibe un «ticket», y a partir de ahí basta con presentar ese ticket.

El KDC (centro de distribución de claves) se ejecuta en el controlador de dominio y usa la base de datos de Active Directory Domain Services como base de datos de cuentas de seguridad. ⁴

sequenceDiagram
    autonumber
    participant C as Cliente
    participant KDC as KDC (controlador de dominio)
    participant S as Servicio (identificado por SPN)

    Note over C,KDC: Intercambio AS — verificación de identidad y obtención del TGT
    C->>KDC: KRB_AS_REQ<br/>(nombre de usuario + hora cifrada con la clave a largo plazo)
    Note over KDC: Si se puede descifrar con la clave a largo plazo, es la persona
    KDC-->>C: KRB_AS_REP<br/>TGT (cifrado con la clave de krbtgt) + clave de sesión

    Note over C,KDC: Intercambio TGS — obtención del ticket de servicio
    C->>KDC: KRB_TGS_REQ<br/>(TGT + SPN del destino + autenticador)
    Note over KDC: Obtiene la cuenta de servicio a partir del SPN<br/>y cifra el ticket con su clave a largo plazo
    KDC-->>C: KRB_TGS_REP<br/>ticket de servicio + clave de sesión

    Note over C,S: Intercambio AP — presentación al servicio
    C->>S: KRB_AP_REQ<br/>(ticket de servicio + autenticador)
    Note over S: Si puede descifrarlo con su propia clave a largo plazo,<br/>el ticket es para él
    S-->>C: KRB_AP_REP (si se solicitó autenticación mutua)

Figura 3: Los tres intercambios de Kerberos (AS / TGS / AP)

Leyenda — AS = Authentication Service (servicio de autenticación), TGS = Ticket Granting Service (servicio de concesión de tickets), AP = Application (aplicación). En los nombres de mensaje, _REQ es una solicitud y _REP es una respuesta. Por ejemplo, KRB_TGS_REQ significa «solicitud al servicio de concesión de tickets».

4.1. Intercambio AS — verificación de identidad, una sola vez

El cliente envía al KDC el nombre de usuario principal, el nombre de dominio de la cuenta y una marca de tiempo cifrada con su propia clave a largo plazo (la clave derivada de la contraseña). Esto es la autenticación previa (pre-authentication). Si el KDC puede descifrarlo con esa clave a largo plazo y, además, la marca de tiempo es válida, concluye que «es la persona». ³

El KDC devuelve el TGT (ticket de concesión de tickets). El TGT está cifrado con la propia clave a largo plazo del KDC (la clave de la cuenta krbtgt), así que el cliente no puede leer su contenido. Junto con él, se entrega la clave de sesión que se usará entre el cliente y el KDC, cifrada con la clave a largo plazo del cliente. ³

Conviene retener que la marca de tiempo forma parte de la autenticación. Por eso Kerberos es tan estricto con la sincronización horaria: el desfase permitido de forma predeterminada es de 5 minutos. ⁷ Si se sale de ese margen, la autenticación previa no se supera y la propia autenticación Kerberos falla con un error (la sincronización horaria de Windows se trata en la «Guía de sincronización horaria de Windows (w32time)»). Este «Kerberos falla» es algo distinto de «la autenticación cae a NTLM»; la distinción se trata en el apartado 6.5.

4.2. Intercambio TGS — declarar «a qué servicio me voy a conectar»

Aquí está el punto de divergencia decisivo respecto a NTLM. El cliente comunica al KDC el nombre del servicio al que quiere conectarse (el SPN) y solicita un ticket de servicio adjuntando el TGT y un autenticador. ³

El KDC busca la cuenta de servicio correspondiente a ese SPN y cifra el ticket de servicio con la clave a largo plazo de esa cuenta antes de devolverlo. ³ Por eso:

• Si no se puede obtener el SPN, no se emite el ticket. Si la cuenta de servicio no tiene el SPN registrado, el KDC no puede identificar a la otra parte. Tampoco se intenta Kerberos, de forma predeterminada, cuando el destino se especifica mediante una dirección IP (apartado 6.1).
• El ticket es «exclusivo de ese destino». Como no se puede descifrar con la clave a largo plazo de otro servicio, no se puede reutilizar cambiando el destino.

4.3. Intercambio AP — presentación al servicio y autenticación mutua

El cliente presenta al servicio el ticket de servicio y un autenticador. El servicio descifra el ticket con su propia clave a largo plazo y extrae de él la clave de sesión y la información de autorización. El propio hecho de poder descifrarlo ya demuestra que «este ticket es para mí». ³

Si el cliente había solicitado autenticación mutua, el servicio cifra con la clave de sesión la marca de tiempo recibida y la devuelve. Al verificarla, el cliente puede confirmar que la otra parte es el servicio auténtico. ³ Es un paso que no existe en NTLM.

5. Las diferencias decisivas

La fila «Delegación» se ramifica todavía más en la práctica. Existen varios tipos de delegación —delegación sin restricciones, delegación restringida (constrained delegation) y delegación restringida basada en recursos (RBCD, resource-based constrained delegation)—, y en configuraciones como una aplicación web de frontend que se conecta a un SQL Server de backend con las credenciales del usuario, elegir entre ellas es una decisión de diseño. Este artículo no entra en ese detalle, pero conviene recordarlo como el siguiente término de búsqueda al investigar la delegación de Kerberos.

Las dos últimas filas de esta tabla son, directamente, «la razón por la que la autenticación cae a NTLM»: la fortaleza de Kerberos (vincular el destino, verificar a la otra parte) se sostiene sobre la base de que el nombre se pueda resolver correctamente.

6. Por qué la autenticación «cae» a NTLM

Aunque la aplicación no especifique NTLM directamente, NTLM se acaba usando. Esto ocurre porque así se comporta Negotiate. Según explica Microsoft, Negotiate elige entre Kerberos y NTLM, y opta por Kerberos salvo que alguno de los sistemas implicados en la autenticación no pueda usarlo. ¹

Es decir, «se usó NTLM» es, en la gran mayoría de los casos, otra forma de decir «Kerberos no se pudo usar».

flowchart TD
    START["Se inicia la autenticación con Negotiate"]
    Q1{"¿Es una cuenta<br/>de dominio?"}
    Q2{"¿Se puede construir un SPN<br/>a partir del nombre de destino?"}
    Q3{"¿Ese SPN<br/>está registrado?"}
    Q4{"¿Se llega<br/>al KDC?"}
    KRB["Autenticación con Kerberos"]
    NTLM["Se recurre a NTLM"]

    START --> Q1
    Q1 -->|"No<br/>(grupo de trabajo / cuenta local)"| NTLM
    Q1 -->|Sí| Q2
    Q2 -->|"No<br/>(se usa la dirección IP directamente)"| NTLM
    Q2 -->|Sí| Q3
    Q3 -->|"No<br/>(SPN no registrado / acceso con otro nombre)"| NTLM
    Q3 -->|Sí| Q4
    Q4 -->|"No<br/>(sede / VPN / firewall)"| NTLM
    Q4 -->|Sí| KRB

Figura 4: Las bifurcaciones por las que Negotiate cae a NTLM

A continuación se listan de antemano, en una tabla de tres columnas, los cuatro factores principales, con su condición, la razón y la forma de corregirlo. Los detalles se tratan a partir del apartado 6.1.

6.1. Se conecta mediante una dirección IP

Es la causa más frecuente. Microsoft indica explícitamente que de forma predeterminada, cuando el nombre de host es una dirección IP, Windows no intenta la autenticación Kerberos contra ese host y recurre a otro protocolo de autenticación válido, como NTLM. ¹¹ La guía de auditoría también señala que, si el «servidor de destino» del evento 8001 no aparece ni en formato NetBIOS ni en formato FQDN, no se usa Kerberos. ⁵

Y también se indica el motivo por el que esto ocurre: aplicaciones que usan una dirección IP en lugar de un nombre DNS debido a errores de configuración o a la documentación del proveedor. ⁵ En la práctica es muy habitual encontrar configuraciones que en su día se cambiaron a IP porque «la resolución de nombres era inestable» y que se quedaron así.

Sin embargo, esto es un comportamiento predeterminado, no una limitación absoluta. A partir de Windows 10 versión 1507 y Windows Server 2016 existe un mecanismo que permite usar una dirección IP como nombre de host en el SPN. Si se pone a 1 el valor de registro TryIPSPN en el cliente y, además, se registra manualmente el SPN de la dirección IP con Setspn -s <clase de servicio>/<dirección IP> <cuenta>, Kerberos puede llegar a funcionar incluso contra un destino especificado por IP. La clase de servicio que hay que registrar es la que el cliente solicita realmente: para algo como una carpeta compartida, que se asigna a HOST, basta con host/192.168.1.1, pero para la Web hace falta HTTP/192.168.1.1, y para SQL Server, MSSQLSvc/192.168.1.1:1433, incluyendo el puerto, como un SPN distinto. Registrar solo host/ no sirve si no coincide con el SPN que se solicita; en ese caso Kerberos no se completa. Microsoft sitúa esta función precisamente como una forma de reducir el impacto de deshabilitar NTLM. ¹¹

Aun así, no es la primera opción. La propia Microsoft indica que, como las direcciones IP son temporales y pueden provocar conflictos y fallos de autenticación al expirar y renovarse la concesión, normalmente no deben usarse en lugar de un nombre de host, y que el registro de SPN basado en IP es un trabajo manual que solo debe usarse cuando resulte imposible cambiar a un nombre de host basado en DNS. ¹¹ Si en una auditoría se detecta el uso directo de direcciones IP, lo primero que hay que plantearse es corregirlo a un FQDN. TryIPSPN es el último recurso para los destinos en los que eso, definitivamente, no se puede hacer.

6.2. El SPN no está registrado

Es la segunda causa más frecuente. Microsoft cita, como uno de los tipos de aplicación que, aun siendo compatibles con Kerberos, terminan usando NTLM, las aplicaciones cuyo SPN no está configurado correctamente. ⁵

Como se vio en el intercambio TGS de la figura 3, el KDC obtiene la cuenta de servicio a partir del SPN y con ella cifra el ticket. Si no hay SPN, el KDC no puede identificar «la clave de ese servicio». Lo mismo ocurre cuando se accede mediante un alias de DNS (CNAME) o un nombre de host propio: si el SPN de ese nombre no está registrado, sucede exactamente lo mismo. La aplicación funciona correctamente, pero el nombre concreto sencillamente no figura en el registro.

6.3. Está fuera de Active Directory desde el principio

Los equipos en configuración de grupo de trabajo y el acceso a recursos compartidos con cuentas locales no están dentro del terreno de Kerberos. Microsoft también establece que en la autenticación de Windows de los sistemas configurados como miembros de un grupo de trabajo, y en el inicio de sesión local fuera de un controlador de dominio, se usa y se debe usar NTLM. ¹⁰

Este es el motivo por el que no se puede «simplemente prohibir» NTLM. El KDC local previsto para la fase 2 es precisamente la función pensada para cubrir este hueco. ⁶ Sin embargo, hay que tener en cuenta que solo se cubre cuando ambos extremos son versiones de Windows compatibles. La autenticación con cuentas locales frente a un Windows antiguo o frente a equipos de otros fabricantes, como un NAS o una impresora multifunción, no se convierte automáticamente en Kerberos solo porque llegue el KDC local. Esta clasificación se trata en los capítulos 5 y 6 del artículo práctico.

6.4. No llega al KDC

También se produce el mismo tipo de degradación cuando hay un problema de ruta: no se puede llegar al controlador de dominio desde una sede o a través de una VPN, o el firewall bloquea los puertos que Kerberos necesita. ⁶ Si no se puede hablar con el KDC, no hay forma de obtener un ticket, así que Negotiate elige la única opción que le queda: NTLM.

6.5. No confunda «el fallo de Kerberos» con «la caída a NTLM»

Por último, conviene separar dos cosas que se confunden fácilmente pero que son distintas. Todo lo visto en los apartados 6.1 a 6.4 son casos en los que no se pudo ni siquiera iniciar Kerberos. Como no se puede iniciar, Negotiate elige NTLM.

En cambio, cuando se elige Kerberos y, aun así, falla, la situación es otra. El ejemplo típico es el desfase horario. Si se puede obtener el SPN y también se llega al KDC, Negotiate elegirá primero Kerberos. Si después la hora supera el margen permitido (5 minutos por defecto), la autenticación previa no se supera y el proceso falla como un error de Kerberos. ⁷ El hecho de que el protocolo elegido falle no significa que Negotiate cambie automáticamente a NTLM y reintente (salvo que la propia aplicación reintente explícitamente con otro método).

En la práctica, el significado es sencillo. Un incidente de desfase horario no se encuentra por mucho que se busque el evento 8001. Los síntomas también son distintos.

Separe primero si «la autenticación cayó a NTLM» o si «Kerberos está roto», y a partir de ahí investigue.

7. La diferencia vista desde los ataques — retransmisión y Pass-the-Hash

Microsoft indica explícitamente, en su documentación de configuración de políticas, que la autenticación NTLM y NTLMv2 es vulnerable a diversos ataques malintencionados, incluidos la retransmisión SMB, los ataques de intermediario y los ataques de fuerza bruta. ⁸ La razón se explica mirando la figura 1.

7.1. Ataques de retransmisión — la consecuencia de no vincular el destino

sequenceDiagram
    autonumber
    participant V as PC de la víctima
    participant A as Servidor del atacante
    participant T as Servidor auténtico

    Note over V,A: Se atrae a la víctima hacia el servidor del atacante
    V->>A: Inicia la autenticación (nombre de usuario)
    A->>T: Inicia la autenticación con el mismo usuario
    T-->>A: Desafío
    A-->>V: Reenvía ese mismo desafío tal cual
    Note over V: No puede distinguir si procede<br/>del servidor auténtico
    V->>A: Respuesta (calculada con la clave derivada del hash)
    A->>T: Reenvía esa misma respuesta tal cual
    Note over T: Si no se exige ni firma<br/>ni channel binding
    T-->>A: Autenticación correcta → conexión establecida como la víctima

Figura 5: Cómo se completa una retransmisión NTLM (contra un destino sin firma ni vinculación de canal)

El atacante no necesita conocer ni la contraseña ni el hash. Se limita a hacer pasar el desafío y la respuesta de un lado a otro. Esto funciona porque el cliente no tiene forma de comprobar si esa respuesta llega realmente al destinatario que pretendía.

Sin embargo, la retransmisión no funciona contra cualquier destino. Que el intercambio retransmitido se convierta en una sesión utilizable depende de las defensas del destino.

• No funciona contra un destino que exige firma SMB. Microsoft indica explícitamente que la firma que se añade a todos los mensajes SMB incluye el hash del mensaje completo y, al confirmar la identidad del emisor y del receptor, evita los ataques de retransmisión. ¹² Cabe señalar que los controladores de dominio exigen firma SMB al origen de la conexión de forma predeterminada. ¹²
• Tampoco funciona contra servicios que imponen Extended Protection for Authentication (vinculación de canal, channel binding). Al vincular la autenticación al canal TLS subyacente, una autenticación retransmitida a otro canal deja de ser válida.

Es decir, lo que describe la figura 5 es la ruta que funciona en condiciones concretas: un destino que acepta NTLM y no exige ni firma ni channel binding. Y esto, visto al revés, significa que hay una medida que se puede aplicar ya mismo en la práctica: conviene comprobar el estado de la exigencia de firma SMB en paralelo al inventario de NTLM.

En Kerberos, de entrada, no es posible este mismo tipo de intermediación. Como el ticket de servicio está cifrado con la clave a largo plazo del servicio de destino, no se puede descifrar aunque se lleve a otro servicio. ³ Además, mediante la autenticación mutua, el cliente puede confirmar si la otra parte es auténtica. ⁴

El motivo por el que Microsoft creó el bloqueo de NTLM en el lado del cliente SMB es precisamente este. Se explica que su objetivo es evitar el truco de hacer que se envíen solicitudes NTLM a un servidor malintencionado. ¹³ Además, entre las recomendaciones de Microsoft relacionadas con la firma SMB figuran usar Kerberos en lugar de NTLMv2, para que la clave de sesión empiece siendo fuerte, y no conectarse a los recursos compartidos mediante direcciones IP ni registros CNAME (porque eso hace que se use NTLM en lugar de Kerberos). ¹² Es la misma cuestión que se vio en los apartados 6.1 y 6.2.

7.2. Pass-the-Hash — el hash equivale a la contraseña

flowchart LR
    P["Contraseña"] -->|"hash unidireccional"| H["Hash de la contraseña"]
    H -->|"deriva la clave de respuesta<br/>y calcula el HMAC"| R["Respuesta"]
    R --> AUTH["Autenticación correcta"]
    STEAL["Robo del hash<br/>desde el equipo"] --> H
    NOTE["No hace falta<br/>la contraseña en texto claro"] -.-> STEAL

Figura 6: Lo que se necesita para autenticarse es el hash, no la contraseña en texto claro

Las credenciales de NTLM son un hash unidireccional de la contraseña. ¹ En NTLMv2, ese MD4(UNICODE(contraseña)) se usa como clave para derivar la clave de respuesta, y con esa clave se calcula además un HMAC para construir la respuesta. ² Aunque cambie la forma del cálculo, el punto de partida sigue siendo el hash. Es decir, lo que se necesita para autenticarse es el hash, no la contraseña en texto claro.

Esta consecuencia tiene un peso operativo considerable. Alargar y complicar la contraseña no cierra la vía por la que se puede robar el hash. Microsoft también menciona Pass-the-Hash, junto con la fuerza bruta y el descifrado (cracking), entre los ataques a los que se enfrenta el bloqueo de NTLM en SMB. ¹³

En Kerberos también existen claves a largo plazo, pero lo que circula en el día a día de la autenticación son tickets con caducidad y claves de sesión. ³ El alcance de lo que se puede hacer con lo robado es distinto.

8. NTLMv1, NTLMv2 y la «eliminación»

NTLM no es un único protocolo, sino un conjunto de protocolos de autenticación que incluye LAN Manager versión 1 y 2, y NTLM versión 1 y 2. ¹⁰

En la actualidad, la situación se divide así:

Es decir, no vale «como es NTLMv2, se puede dejar así por ahora». Aun así, las prioridades están claras: los equipos o hosts que solo hablan NTLMv1 son la máxima prioridad. Si una auditoría registra NTLM V1 en un host, al actualizarlo directamente a una versión más reciente de Windows la autenticación dejará de funcionar. Cómo distinguir la versión (revisando el «Nombre de paquete (solo NTLM)» en el registro de seguridad) se trata en el apartado 4.4 del artículo práctico. ⁵

Cabe señalar que las políticas de auditoría y bloqueo que restringen NTLM tienen el mismo efecto sobre NTLMv1 y NTLMv2. ⁵ Al aplicar la restricción, el comportamiento no cambia según la versión.

9. Qué viene a partir de ahora

Microsoft indica tres direcciones.

La primera es que las aplicaciones usen Negotiate. El propio anuncio de la obsolescencia indica que las llamadas a NTLM deben sustituirse por llamadas a Negotiate. ⁹ También se especifica que las aplicaciones no deben acceder directamente al paquete de seguridad NTLM. ¹

La segunda es reducir las situaciones en las que NTLM resulta necesario. A esto corresponden IAKerb y el KDC local previstos para la fase 2 (segunda mitad de 2026). ⁶ Es un intento de tapar, desde el propio protocolo, los dos huecos vistos en el apartado 6.3: «no se puede usar Kerberos porque es una cuenta local» y «no se puede usar Kerberos porque no se llega al controlador de dominio». Sin embargo, el alcance de lo que se cubre tiene límites. Lo que resuelve IAKerb es la accesibilidad al controlador de dominio, no la compatibilidad de la otra parte. El KDC local tampoco funciona salvo entre versiones de Windows compatibles entre sí. Si la otra parte es un NAS o una impresora multifunción de otro fabricante, esperar a la fase 2 no cambiará la situación, así que hay que elegir por cuenta propia entre renovar el equipo, unirlo al dominio, cambiar a otro protocolo o gestionarlo como excepción.

La tercera es cambiar el valor predeterminado. En la fase 3 está previsto que, en la próxima versión mayor, la autenticación NTLM de red quede deshabilitada de forma predeterminada. ⁶ Aunque también se indica la premisa de que se podrá volver a habilitar mediante una directiva.

Este orden tiene sentido: primero se elimina el motivo para usarlo, y después se cambia el valor predeterminado. Por eso conviene clasificar, entre las dependencias de NTLM que aún quedan en la propia organización, cuáles se pueden esperar que resuelva la fase 2 (la autenticación con cuentas locales entre versiones de Windows compatibles, y la accesibilidad al DC) y cuáles hay que corregir por cuenta propia (el uso directo de direcciones IP, los SPN sin registrar y, sobre todo, la autenticación con cuentas locales frente a un Windows antiguo o a equipos de otros fabricantes). Si se clasifica este último grupo como «a la espera de la fase 2», cuando llegue la deshabilitación por defecto aparecerá como un incidente. El procedimiento concreto para hacer esta clasificación está recogido en el artículo práctico.

10. Resumen

• NTLM es un protocolo que demuestra, mediante desafío/respuesta, «que se posee el hash de la contraseña». La decisión la delega en el controlador de dominio si la cuenta es de dominio, y la toma el propio servidor consultando su SAM si la cuenta es local. ¹¹⁰
• Kerberos demuestra «quién» se autentica «ante qué servicio». El ticket de servicio está cifrado con la clave a largo plazo del servicio de destino, así que no se puede reutilizar cambiando de destino. ³
• Las diferencias decisivas son la existencia de autenticación mutua, la consulta al DC en cada autenticación y la posibilidad de delegación. ⁴
• La autenticación cae a NTLM casi siempre cuando no se pudo ni siquiera iniciar Kerberos. Los cuatro factores principales son: usar directamente una dirección IP, un SPN no registrado, estar fuera de Active Directory y no llegar al KDC. ⁵⁶¹¹
• En cambio, un problema como el desfase horario, en el que Kerberos se elige y después falla, se manifiesta como un error de autenticación, no como una caída a NTLM. No se encuentra buscando el evento 8001. ⁷
• El ataque de retransmisión funciona porque la respuesta de NTLM no vincula el destino. Pass-the-Hash funciona porque lo único que se necesita para autenticarse es el propio hash. ⁸¹¹³
• NTLMv1 ya está eliminado (Windows 11 24H2 / Windows Server 2025), y todas las versiones, incluida NTLMv2, están en desuso. ⁹
• Lo que debe usar una aplicación es Negotiate. A partir de ahí, unificar los nombres de destino en FQDN y registrar los SPN es, en la práctica, lo que hace posible que Kerberos funcione. ¹⁵

Artículos relacionados

• ¿Se detienen las aplicaciones de negocio al retirar NTLM? — Cómo recopilar los registros de auditoría y en qué orden eliminar las dependencias
• Las trampas de las unidades de red y las rutas UNC — el manejo práctico de servidores de archivos (carpetas compartidas) en aplicaciones de negocio
• Guía de sincronización horaria de Windows (w32time)
• Investigar registros de eventos de forma práctica con Get-WinEvent — la velocidad del filtrado determina el tiempo de investigación
• Manejo seguro de credenciales en PowerShell — desterrando las contraseñas en texto claro de los scripts
• Qué es el TPM de Windows — la «caja fuerte que no deja salir la clave» y el arranque medido, explicados con diagramas
• Las 10 principales amenazas de seguridad de la información 2026 — cómo leer el ranking y qué deben afrontar realmente las pymes

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa de la modernización de aplicaciones de negocio de Windows con motivo de revisiones del método de autenticación, así como de la investigación de las causas de problemas de autenticación relacionados con Kerberos y NTLM.

• Desarrollo de aplicaciones para Windows
• Investigación de fallos y análisis de causas
• Aprovechamiento de activos existentes y soporte para la migración
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

En definitiva, ¿en qué se diferencian NTLM y Kerberos?

La diferencia más importante es si se puede verificar a la otra parte o no. Microsoft indica explícitamente que en NTLM el cliente no puede verificar la identidad del servidor, ni un servidor puede verificar la identidad de otro servidor. NTLM está diseñado para entornos donde se puede asumir que «el servidor es auténtico», mientras que Kerberos no parte de esa suposición. La segunda diferencia es si el servidor necesita consultar al controlador de dominio. En NTLM, cuando la autenticación se hace con una cuenta de dominio, el servidor de aplicaciones se conecta al controlador de dominio cada vez que autentica a un cliente (si la cuenta es local al servidor, el propio servidor consulta su base de datos de cuentas y decide por sí mismo, sin que intervenga el controlador de dominio). En Kerberos, los tickets de sesión renovables sustituyen esta autenticación de paso, de modo que el servidor no necesita ir al controlador de dominio salvo que deba validar el PAC. La tercera diferencia es que Kerberos admite la delegación por parte de un servicio (el mecanismo por el que un servicio se conecta a otros servicios en representación del cliente).

Se supone que la aplicación admite Kerberos, entonces ¿por qué termina usando NTLM?

Kerberos emite tickets usando como clave el «nombre del destino», así que si ese nombre no se puede resolver, el mecanismo no funciona. El cliente presenta al KDC el SPN (nombre principal de servicio) del destino para solicitar un ticket de servicio, pero, de forma predeterminada, Windows no intenta la autenticación Kerberos cuando el nombre de host es una dirección IP, y el KDC no puede emitir un ticket si la cuenta de servicio no tiene el SPN registrado. La guía de auditoría de Microsoft también indica que, si el «servidor de destino» del evento 8001 no aparece ni en formato NetBIOS ni en formato FQDN, no se usa Kerberos (en el caso de las direcciones IP, se puede lograr que Kerberos funcione de forma excepcional configurando TryIPSPN en el cliente y registrando manualmente el SPN de la dirección IP, pero se considera el último recurso cuando no es posible cambiar a un nombre DNS). Además, la autenticación en equipos de grupo de trabajo o con cuentas locales (que de entrada está fuera de Active Directory), las sedes que no pueden llegar al controlador de dominio y la autenticación contra partes sin relación de confianza son también condiciones en las que Kerberos no puede completarse. Como Negotiate elige NTLM cuando no puede usar Kerberos, en estos casos la autenticación «cae» a NTLM.

¿Qué es un ataque de retransmisión (relay) de NTLM? ¿Por qué funciona?

Es un ataque en el que el atacante atrae a la víctima hacia su propio servidor y retransmite tal cual, hacia el servidor auténtico, el intercambio de autenticación NTLM que llega allí, para suplantar a la víctima. Funciona porque el desafío/respuesta de NTLM no tiene ningún mecanismo que vincule «ante quién se está autenticando». El cliente se limita a calcular una respuesta a partir del desafío que envió el servidor y a devolverla, y no dispone de ninguna forma de comprobar, desde su lado, si esa respuesta va destinada al servidor auténtico o si un atacante la está retransmitiendo. La propia Microsoft indica explícitamente, en su documentación de configuración de políticas, que la autenticación NTLM y NTLMv2 es vulnerable a diversos ataques malintencionados, incluidos la retransmisión SMB, los ataques de intermediario (man-in-the-middle) y los ataques de fuerza bruta. Sin embargo, la retransmisión no funciona contra cualquier destino. Si el destino exige la firma SMB, la retransmisión no se completa porque la firma verifica la identidad del emisor y del receptor, y ocurre lo mismo con los servicios que imponen Extended Protection for Authentication (vinculación de canal, channel binding). Dicho de otro modo, los objetivos son aquellos que aceptan NTLM sin exigir ni firma ni channel binding. En Kerberos, como el ticket de servicio está cifrado con la clave a largo plazo de ese servicio concreto, un ticket destinado a otro servicio no puede descifrarse aunque se presente en un servicio distinto.

¿Pass-the-Hash significa que se puede suplantar a alguien sin descifrar su contraseña?

Así es. Las credenciales de NTLM se componen de un hash unidireccional del nombre de dominio, el nombre de usuario y la contraseña. En el NTLMv2 que usan las versiones actuales de Windows, la clave de respuesta se deriva como un HMAC que usa como clave el hash MD4 de la contraseña (el hash NT), y con esa clave se calcula un HMAC sobre el conjunto formado por el desafío del servidor, la hora, el desafío generado por el cliente y la información de destino. No es un simple cifrado del desafío, pero el punto de partida sigue siendo el hash de la contraseña. Es decir, lo que se necesita para autenticarse es el hash, no la contraseña en texto claro. Por lo tanto, un atacante que logre extraer el hash, por ejemplo de la memoria de un equipo, puede autenticarse como ese usuario sin necesidad de descifrar la contraseña. Alargar y complicar la contraseña no cierra esta vía. Una de las razones por las que Microsoft creó la función de bloqueo de NTLM en el lado del cliente SMB es precisamente contrarrestar los ataques Pass-the-Hash.

¿Usar NTLMv2 no es seguro por ahora?

NTLMv2 es más robusto que NTLMv1, pero eso no lo excluye de la lista de funciones en desuso. El listado de funciones obsoletas de Microsoft indica que todas las versiones de NTLM, incluidas LANMAN, NTLMv1 y NTLMv2, quedan fuera del desarrollo activo de funciones y se consideran obsoletas (deprecated). El comportamiento de las políticas de restricción es el mismo: se explica que las políticas de auditoría y bloqueo tienen el mismo efecto sobre las dos versiones. NTLMv1, en cambio, recibe un trato distinto: no se ha quedado solo en obsoleto, sino que ha entrado en la fase de eliminación, y ya se ha eliminado a partir de Windows 11 versión 24H2 y Windows Server 2025. Por lo tanto, la conclusión no es «como es NTLMv2, se puede dejar así por ahora», sino más bien: «NTLMv1 tiene ya un plazo vencido; para NTLMv2 hay que avanzar en el inventario de cara a su deshabilitación por defecto».

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.