¿Qué es NTLM?
NTLM (NT LAN Manager) es un protocolo de autenticación de Windows que valida a los usuarios mediante autenticación de desafío-respuesta sin transmitir contraseñas a través de las redes. Según la documentación oficial de Microsoft, NTLM abarca múltiples versiones de protocolo, incluyendo el antiguo LAN Manager, NTLMv1 y el estándar actual NTLMv2. Aunque Kerberos reemplazó a NTLM como el método de autenticación preferido para entornos de Active Directory hace más de dos décadas, NTLM sigue activo en redes empresariales para autenticación en grupos de trabajo, inicios de sesión locales en controladores que no son de dominio y escenarios donde la negociación de Kerberos falla.
El proceso de desafío-respuesta funciona mediante un intercambio sencillo. Cuando te conectas a un recurso de red, el servidor envía a tu cliente un desafío de 16 bytes. Tu sistema cifra este desafío usando el hash de tu contraseña y envía la respuesta de vuelta al servidor, que valida estas credenciales contra la base de datos Security Accounts Manager o Active Directory. La autenticación se completa transmitiendo solo hashes cifrados, nunca tu contraseña real. Esta decisión de diseño, que trata los hashes como prueba de identidad, creó las vulnerabilidades de seguridad que los atacantes explotan hoy en día.
.jpg)
Por qué NTLM es un riesgo de seguridad
Las estadísticas de robo de credenciales muestran que el 31% de todas las brechas en la última década involucraron robo de credenciales, según el Verizon 2025 Data Breach Investigations Report. Los ataques a NTLM representan un componente significativo de este panorama de amenazas persistente porque el protocolo almacena hashes de contraseñas que los atacantes pueden robar y reutilizar sin descifrar la contraseña real.
Los atacantes extraen hashes NTLM de la memoria o del tráfico de red, luego se autentican en servidores de archivos y controladores de dominio pasando los hashes robados directamente a Windows. Tus controles de seguridad ven una autenticación NTLM legítima mientras el ataque se desarrolla de forma invisible.
CISA añadió CVE-2025-24054, una vulnerabilidad de divulgación de hash NTLM en Windows, a su catálogo de vulnerabilidades explotadas conocidas en marzo de 2025 tras confirmarse explotación activa. Aunque Microsoft corrigió la vulnerabilidad en marzo de 2025, la superficie de ataque persiste porque la desactivación de NTLM requiere una migración coordinada en toda la infraestructura de identidad, aplicaciones y servicios de red. Este cronograma es especialmente importante dado el plazo de Microsoft en octubre de 2026 para la aplicación automática de NTLMv1.
Cómo funciona la autenticación NTLM
La arquitectura de NTLM revela por qué los atacantes tienen éxito en tu entorno y por qué la migración presenta una complejidad significativa.
- Paquete de autenticación y almacenamiento de hashes: El paquete de autenticación MSV1_0 gestiona toda la autenticación NTLM a través del componente Msv1_0.dll. Si se compromete la memoria de LSASS, los atacantes extraen los hashes de contraseñas directamente. Tu entorno almacena dos tipos de hash: el hash LM utiliza cifrado DES roto sin distinción entre mayúsculas y minúsculas, lo que permite ataques triviales con tablas arcoíris, mientras que el hash NT utiliza MD4 con distinción de mayúsculas y minúsculas. Ambos residen en SAM o Active Directory y funcionan como credenciales de autenticación por sí mismos: no se requiere descifrado de contraseñas.
- Mecanismo de desafío-respuesta: El servidor genera un desafío aleatorio de 16 bytes, tu estación de trabajo lo cifra usando el hash de tu contraseña y el servidor valida la respuesta a través de la API LsaLogonUser. NTLMv2 utiliza un cálculo de respuesta basado en HMAC-MD5 con datos aleatorios adicionales, proporcionando una protección criptográfica más fuerte. Ambos protocolos comparten una vulnerabilidad fundamental: los hashes de contraseñas funcionan como credenciales de autenticación por sí mismos (MITRE ATT&CK T1550.002).
- Niveles de autenticación LAN Manager: La clave de registro HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel determina qué versiones de NTLM aceptan tus sistemas. La mayoría de las empresas ejecutan el Nivel 3 (Enviar solo respuesta NTLMv2) frente al Nivel 5 recomendado por NIST (rechazar LM y NTLM por completo), creando brechas explotables.
Estos componentes arquitectónicos, en particular el almacenamiento de hashes en la memoria de LSASS y el mecanismo de autenticación de paso, brindan a los atacantes múltiples oportunidades para interceptar o extraer credenciales.
Herramientas y técnicas de ataque NTLM
Los atacantes utilizan herramientas especializadas para explotar vulnerabilidades de NTLM con el fin de robar credenciales y movimiento lateral. Comprender estas herramientas ayuda a los defensores a reconocer patrones de ataque e implementar controles adecuados.
- Herramientas de extracción de credenciales apuntan a la memoria de LSASS donde Windows almacena los hashes de contraseñas durante sesiones activas. Mimikatz sigue siendo la herramienta más reconocida, utilizando técnicas como sekurlsa::logonpasswords para volcar credenciales desde la memoria. Los atacantes también emplean métodos nativos de Windows, incluidos comandos reg save para exportar los archivos de registro SAM y SYSTEM y extraer hashes fuera de línea. Herramientas de análisis de memoria como WCE (Windows Credentials Editor) ofrecen capacidades adicionales de extracción que evaden algunas soluciones de detección en endpoints.
- Frameworks de Pass-the-Hash permiten la autenticación usando hashes robados sin necesidad de descifrar contraseñas. El kit de herramientas basado en Python de Impacket incluye los módulos psexec.py y wmiexec.py que aceptan hashes NTLM directamente para ejecutar comandos remotos en sistemas Windows. CrackMapExec automatiza los ataques Pass-the-Hash en múltiples objetivos simultáneamente, permitiendo un rápido movimiento lateral en redes empresariales mientras registra autenticaciones exitosas para explotación posterior. Estos frameworks integran capacidades de hash spraying para identificar sistemas que aceptan credenciales comprometidas.
- Kits de herramientas de relay NTLM interceptan y reenvían solicitudes de autenticación a sistemas objetivo no autorizados. Responder captura autenticaciones NTLM envenenando respuestas de resolución de nombres LLMNR, NBT-NS y MDNS en segmentos de red local. Cuando los sistemas intentan resolver nombres de host, Responder responde con direcciones IP controladas por el atacante, capturando intentos de autenticación. El módulo ntlmrelayx de Impacket retransmite la autenticación capturada a servicios SMB, LDAP, HTTP y MSSQL, permitiendo la escalada de privilegios cuando Extended Protection for Authentication permanece deshabilitado en servicios críticos.
- Técnicas de coerción fuerzan a los sistemas objetivo a iniciar autenticaciones hacia servidores controlados por el atacante sin interacción del usuario. PetitPotam explota la interfaz MS-EFSRPC para forzar a los controladores de dominio a autenticarse en destinos arbitrarios, permitiendo la captura directa de credenciales o ataques de relay contra Active Directory Certificate Services. PrinterBug (también llamado SpoolSample) abusa de la interfaz remota del servicio Print Spooler para lograr autenticaciones forzadas similares. Estas técnicas evitan por completo los requisitos tradicionales de phishing, permitiendo el robo de credenciales de sistemas que nunca interactúan con contenido malicioso.
La detección defensiva se centra en monitorear firmas de herramientas en memoria, patrones anómalos de acceso a LSASS, flujos de autenticación inesperados y tráfico de red que indique intentos de relay. Sin embargo, la detección por sí sola no puede abordar las debilidades subyacentes del protocolo que hacen posibles estos ataques.
Vulnerabilidades de NTLM
Las debilidades arquitectónicas del protocolo crean brechas de seguridad persistentes que los controles del lado defensor no pueden abordar completamente sin protecciones complementarias a nivel de red y basadas en identidad.
- Ataques Pass-the-Hash (MITRE ATT&CK T1550.002) explotan la dependencia de NTLM en los hashes de contraseñas como credenciales de autenticación. Una vez que los atacantes extraen tu hash de la memoria de LSASS, la base de datos SAM o capturas de red, se autentican como tú sin conocer tu contraseña. Credential Guard proporciona protección parcial mediante seguridad basada en virtualización en sistemas Windows 10 Enterprise o Windows 11 con hardware TPM 2.0. Las protecciones a nivel de red como la firma SMB, la firma LDAP y Extended Protection for Authentication detienen los ataques de relay NTLM.
- Ataques de relay NTLM manipulan el mecanismo de desafío-respuesta interceptando la autenticación entre cliente y servidor. El atacante recibe tu intento de autenticación, lo retransmite a un sistema objetivo de su elección y obtiene acceso no autorizado usando tus credenciales en tiempo real. Extended Protection for Authentication detiene los ataques de relay mediante channel binding, pero requiere configuración explícita en Exchange Server, Active Directory Certificate Services y LDAP. La mayoría de las empresas ejecutan estos servicios críticos sin EPA habilitado porque Microsoft históricamente distribuyó productos con EPA deshabilitado por defecto.
- Debilidades criptográficas en versiones antiguas persisten en entornos de producción. Los hashes LM utilizan cifrado DES, un algoritmo criptográficamente roto, mientras convierten las contraseñas a mayúsculas y las dividen en fragmentos de 7 caracteres. NTLMv1 mejora la fortaleza criptográfica pero sigue siendo vulnerable a ataques de fuerza bruta fuera de línea. Solo NTLMv2 proporciona protecciones criptográficas modernas, pero muchas organizaciones operan entornos mixtos que aceptan NTLMv1 por compatibilidad con versiones anteriores.
El plazo de aplicación en octubre de 2026 crea un riesgo operativo para las organizaciones que retrasaron la migración. Microsoft estableció un cronograma de tres fases:
- Fase 1 (diciembre de 2024): Inicio de la desactivación
- Fase 2 (septiembre de 2025): Habilitación del modo de auditoría por defecto
- Fase 3 (octubre de 2026): Transición automática de la clave de registro BlockNtlmv1SSO a modo de aplicación sin intervención del administrador
Las organizaciones que no hayan iniciado la planificación de la migración enfrentan un riesgo significativo de interrupciones de autenticación cuando comience la aplicación.
Cómo migrar fuera de NTLM
La migración empresarial de NTLM requiere una ejecución estructurada por fases con patrocinio ejecutivo. La implementación completa suele abarcar de 18 a 22 meses dependiendo de la complejidad del entorno y las dependencias de aplicaciones heredadas.
Fase 1: Descubrimiento y auditoría (meses 1-3)
Habilita la auditoría completa de NTLM en todos los controladores de dominio y servidores miembros antes de intentar cualquier migración o políticas de bloqueo. Configura Network security: Restrict NTLM: Audit NTLM authentication in this domain en "Audit all" en lugar de bloquear. Windows 11 24H2 y Windows Server 2025 ofrecen eventos de auditoría mejorados que capturan nombres de procesos, códigos de motivo, información de usuario y dominio, y versión de NTLM. Recopila registros de auditoría durante un mínimo de 30 a 90 días para capturar servicios periódicos, tareas programadas y procesos mensuales. Analiza los registros para construir un inventario completo de dependencias categorizado por tipo de sistema, aplicación y complejidad de remediación.
Fase 2: Planificación de remediación (meses 4-6)
Clasifica las dependencias de NTLM por enfoque y complejidad de remediación. Los sistemas unidos a grupos de trabajo pueden requerir unión a dominio, registro en Azure AD o excepción continua con segmentación de red. Las aplicaciones heredadas necesitan contacto con el proveedor para cronogramas de soporte de Kerberos o planificación de reemplazo si el proveedor no puede ofrecer rutas de migración. Los dispositivos de red con limitaciones de firmware requieren programación de actualización, adquisición de reemplazo o estrategias de segmentación de red que aíslen el tráfico NTLM.
Fase 3: Implementaciones piloto de Kerberos (meses 7-9)
Selecciona unidades organizativas de bajo riesgo con mínimas dependencias heredadas para la aplicación inicial de solo Kerberos. Configura Network security: Restrict NTLM: NTLM authentication in this domain en "Deny all" solo en el alcance piloto. Monitorea de cerca los fallos de autenticación y problemas de aplicaciones, documentando todos los procedimientos de remediación para referencia en el despliegue en producción. Valida que los sistemas piloto mantengan plena funcionalidad sin autenticación NTLM.
Fase 4: Despliegue en producción (meses 10-18)
Amplía la aplicación de Kerberos de forma sistemática por unidad organizativa según los aprendizajes del piloto. Prioriza entornos de alta seguridad que contengan datos sensibles y sistemas de acceso privilegiado. Mantén listas documentadas de excepciones para dependencias heredadas con controles compensatorios como segmentación de red, monitoreo mejorado y alcance de acceso restringido. Implementa segmentación de red para sistemas que requieran acceso continuo a NTLM para limitar la exposición al movimiento lateral.
Fase 5: Aplicación (meses 19-22)
Habilita BlockNtlmv1SSO antes del plazo de aplicación automática de Microsoft en octubre de 2026. Valida la migración completa mediante una revisión exhaustiva de los registros de auditoría que confirme cero autenticaciones NTLM en el alcance de producción. Documenta las excepciones restantes con aceptación formal de riesgos y controles compensatorios para fines de cumplimiento y auditoría.
Mientras planifican la migración, las organizaciones también deben abordar brechas defensivas inmediatas. Muchos equipos de seguridad dejan inadvertidamente sus entornos expuestos por protecciones incompletas o mal configuradas.
Errores comunes en la defensa de NTLM
No implementar defensas en capas para NTLM crea brechas de seguridad explotables.
- Habilitar la firma SMB sin requerirla. Configuras la directiva de grupo para habilitar la opción "Microsoft network server: Digitally sign communications" en tus servidores de archivos, pero pasas por alto el requisito complementario del lado del cliente. La auditoría de configuración muestra cumplimiento en los servidores, pero tu pentester demuestra ataques de relay NTLM exitosos porque "habilitar" permite la degradación a conexiones no firmadas cuando los clientes no solicitan firma. Ambas configuraciones deben establecerse en "Enabled" simultáneamente: lado del servidor (Microsoft network server: Digitally sign communications (always)) Y lado del cliente (Microsoft network client: Digitally sign communications (always)). Según la guía de seguridad SMB de Microsoft, configurar solo los servidores crea una brecha explotable donde los atacantes hacen relay a través de clientes mal configurados.
- Asumir que Credential Guard detiene los ataques de relay NTLM. Despliegas Credential Guard en estaciones de trabajo administrativas de alto valor y controladores de dominio, luego presentas la cobertura de Credential Guard a la dirección ejecutiva como protección completa contra ataques NTLM. Un atacante compromete tu entorno mediante relay NTLM contra un servicio LDAP no protegido en un controlador de dominio. Credential Guard protege las credenciales en reposo en la memoria de LSASS usando seguridad basada en virtualización, evitando el robo de credenciales en sistemas comprometidos, pero no ofrece protección contra ataques de relay NTLM a nivel de red. Las organizaciones deben implementar simultáneamente protección de credenciales en endpoints y prevención de relay a nivel de red.
- Implementar EPA de forma inconsistente en servicios críticos. Tu equipo de seguridad habilitó Extended Protection for Authentication en Active Directory Certificate Services tras PetitPotam en 2021, pero los atacantes hacen relay de autenticación NTLM a tu servicio LDAP, que se ejecuta sin EPA habilitado. EPA debe configurarse en todos los servicios compatibles con NTLM, incluidos AD CS, LDAP, Exchange Server y cualquier aplicación personalizada que use Windows Integrated Authentication.
Evitar estos errores requiere un enfoque sistemático de defensa NTLM que aborde todos los vectores de ataque simultáneamente.
Mejores prácticas de defensa NTLM
Detén el movimiento lateral basado en credenciales mediante controles en capas que aborden las debilidades del protocolo en las capas de red, endpoint e identidad.
- Implementa inmediatamente el registro completo de auditoría NTLM. Habilita las políticas de auditoría NTLM en todos los controladores de dominio y servidores miembros antes de intentar cualquier migración o políticas de bloqueo. Configura Network security: Restrict NTLM: Audit NTLM authentication in this domain en "Audit all" en lugar de bloquear. Recopila registros de auditoría durante un mínimo de 30 a 90 días para capturar servicios periódicos y tareas programadas, luego analiza los registros para construir un inventario completo de dependencias.
- Aplica la firma SMB de forma universal en tu entorno. Configura requisitos duales de directiva de grupo en
Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. Establece tanto Microsoft network server: Digitally sign communications (always) como Microsoft network client: Digitally sign communications (always) en Enabled. La configuración dual detiene ataques de degradación donde clientes y servidores usan diferentes configuraciones de firma. - Configura Extended Protection for Authentication en todos los servicios críticos. EPA agrega channel binding a la autenticación NTLM, evitando el relay de credenciales al vincular la autenticación a la sesión TLS. La prioridad de implementación de EPA debe centrarse en Active Directory Certificate Services, LDAP en todos los controladores de dominio y Exchange Server. Windows Server 2025 habilita EPA por defecto para estos servicios.
- Despliega Credential Guard en sistemas de alto valor. Implementa Credential Guard en controladores de dominio, estaciones de trabajo administrativas y sistemas que procesan datos sensibles. Credential Guard requiere TPM 2.0, UEFI Secure Boot, extensiones de virtualización de procesador y soporte de Hyper-V.
- Requiere firma LDAP en todos los controladores de dominio. Configura
Domain controller: LDAP server signing requirementsen "Require signing" mediante directiva de grupo aplicada a la unidad organizativa de controladores de dominio. Windows Server 2025 agrega channel binding LDAP por defecto. - Implementa correlación de eventos para identificar Pass-the-Hash. Configura tu SIEM para correlacionar los ID de eventos de seguridad de Windows en múltiples controladores de dominio y servidores miembros. Genera alertas sobre el evento ID 4624 (inicio de sesión exitoso) con Logon Type 3 (inicio de sesión de red) y paquete de autenticación "NTLM" para cuentas privilegiadas SIN el evento ID 4624 Logon Type 2 (inicio de sesión interactivo) correspondiente en las 10 horas previas desde la misma IP de origen.
Estos controles manuales brindan protección esencial, pero los ataques basados en credenciales suelen moverse más rápido que los ciclos de investigación humana. La IA conductual puede identificar y detener la actividad Pass-the-Hash en tiempo real.
Detén ataques NTLM con SentinelOne
Tu latencia de respuesta determina si detienes el movimiento lateral o investigas las consecuencias de la brecha. SentinelOne detecta ataques basados en credenciales mediante IA conductual que reconoce técnicas Pass-the-Hash clasificadas como MITRE ATT&CK T1550.002.
Singularity™ Identity también proporciona visibilidad de extremo a extremo en entornos híbridos para detectar exposiciones y detener el abuso de credenciales. Reduce los riesgos de identidad y ofrece protección de identidad en tiempo real. Puedes correlacionar la actividad de endpoint e identidad para una detección basada en contexto y una triaje más rápida. También elimina puntos ciegos en entornos aislados y puede reforzar Active Directory y proveedores de identidad en la nube, incluidos Okta, Ping, SecureAuth, Duo y Entra ID. Puede recopilar información de intentos de ataque para detener compromisos repetidos y prevenir la escalada de privilegios.
SentinelOne es reconocido como Líder en el Cuadrante Mágico de Gartner para Plataformas de Protección de Endpoints durante cinco años consecutivos. En las evaluaciones MITRE ATT&CK, SentinelOne generó solo 12 alertas mientras que un competidor líder generó 178,000, lo que representa un 88% menos de alertas. Esta reducción de ruido consolida miles de eventos de seguridad en incidentes procesables únicos, transformando la investigación de abuso de credenciales de revisar miles de eventos de autenticación a analizar el contexto forense completo en segundos.
La Singularity Platform ofrece capacidades XDR unificadas a través de un solo agente y consola, consolidando la seguridad de endpoint, nube e identidad en un único data lake. La tecnología patentada Storyline monitorea, rastrea y contextualiza automáticamente los datos de eventos en todo tu entorno empresarial para reconstruir ataques en tiempo real.
Purple AI acelera las investigaciones de amenazas mediante consultas en lenguaje natural que correlacionan eventos de autenticación en todo tu entorno. Con hasta un 80% de mayor velocidad en la búsqueda de amenazas según los primeros usuarios, los analistas de seguridad pueden buscar en los registros sin conocer lenguajes de consulta y recibir el contexto completo del ataque con los siguientes pasos sugeridos.
Solicita una demostración para ver cómo la IA conductual de SentinelOne detiene los ataques basados en credenciales antes de la escalada de privilegios.
Singularidad™ Identidad
Detecte y responda a los ataques en tiempo real con soluciones integrales para Active Directory y Entra ID.
DemostraciónPuntos clave
Los ataques NTLM explotan el robo de credenciales para permitir el movimiento lateral antes de que la respuesta tradicional pueda detenerlos. El plazo de aplicación en octubre de 2026 requiere una planificación de migración inmediata: Microsoft aplicará automáticamente el bloqueo de NTLMv1 cambiando la clave de registro BlockNtlmv1SSO de modo de auditoría a modo de aplicación sin intervención del administrador.
La defensa efectiva exige controles en capas complementarios: firma SMB en servidores y clientes, Extended Protection for Authentication en servicios críticos incluidos AD CS, LDAP y Exchange Server, Credential Guard para la protección de credenciales en endpoints (teniendo en cuenta que protege credenciales en reposo pero NO detiene ataques de relay en red) y registro completo de auditoría para identificar dependencias antes de la aplicación.
La IA conductual que correlaciona patrones de autenticación en endpoints e infraestructura de identidad detecta el abuso de credenciales antes de que ocurra la escalada de privilegios.
Preguntas frecuentes
NTLM (NT LAN Manager) es un protocolo de autenticación de Windows que valida a los usuarios mediante un mecanismo de desafío-respuesta sin transmitir contraseñas a través de la red. El servidor envía un desafío aleatorio, el cliente lo cifra con el hash de la contraseña del usuario y el servidor valida la respuesta.
Aunque Kerberos reemplazó a NTLM como el método de autenticación preferido para Active Directory, NTLM sigue activo en entornos de grupo de trabajo, inicios de sesión locales y escenarios de aplicaciones heredadas.
NTLMv1 utiliza criptografía más débil que es vulnerable a ataques de fuerza bruta fuera de línea y ataques de texto plano conocido. NTLMv2 incorpora un cálculo de respuesta basado en HMAC-MD5 con datos aleatorios y capacidades de enlace de canal, proporcionando una protección criptográfica significativamente más fuerte.
Microsoft aplicará automáticamente el bloqueo de NTLMv1 en octubre de 2026, lo que requerirá que todos los sistemas utilicen como mínimo NTLMv2 o migren a Kerberos.
La eliminación completa de NTLM sigue siendo difícil debido a dependencias en sistemas unidos a grupos de trabajo, aplicaciones heredadas sin compatibilidad con Kerberos, dispositivos de red con limitaciones de firmware y escenarios de autenticación entre bosques.
Windows Server 2025 introduce la capacidad de deshabilitar completamente SMB NTLM para conexiones remotas salientes. La desaprobación total requiere remediación de aplicaciones, reemplazo de hardware y pruebas exhaustivas durante cronogramas de migración de 18 a 22 meses.
Los atacantes utilizan herramientas como Mimikatz para extraer hashes NTLM de la memoria de LSASS. El hash, una representación MD4 de 16 bytes de su contraseña, funciona como una credencial de autenticación en sí misma. Cuando Windows autentica usando NTLM, compara respuestas cifradas al desafío, no contraseñas.
Dado que el atacante posee el hash que genera respuestas válidas, Windows no puede distinguir entre una autenticación legítima y ataques Pass-the-Hash sin controles adicionales como Credential Guard o EPA.
La Protección Extendida para la Autenticación agrega el enlace de canal a la autenticación NTLM al vincular los tokens de autenticación a la sesión TLS entre el cliente y el servidor. Esta vinculación hace que las credenciales retransmitidas sean inutilizables incluso si se interceptan, porque los tokens de enlace de canal no coincidirán cuando el atacante intente retransmitirlos a diferentes servidores.
EPA detiene los ataques de retransmisión NTLM dirigidos a AD CS, LDAP, Exchange Server y otros servicios de autenticación integrados en Windows. Windows Server 2025 habilita EPA de forma predeterminada en los servicios críticos.


