Guía para eliminar NTLM por completo de su entorno

Resumen ejecutivo

Eliminar NTLM de un entorno empresarial es una desafío significativoEstá profundamente arraigado en muchas infraestructuras y, en algunos casos, aplicaciones heredadas críticas aún dependen de él. Reemplazar esas aplicaciones puede parecer poco realista, y durante años esta ha sido la razón. NTLM permaneció en uso. Pero la realidad es otra: La mayoría de las organizaciones en realidad no necesitan NTLM, y el mayor obstáculo es que la actividad NTLM es difícil de detectar internamente. Active DirectoryEsta dificultad solo aumenta a medida que el entorno se escala. 

Considerando el Windows 10 Fin de VidaJunto con el anuncio de Microsoft sobre la descontinuación de NTLM, este problema ha resurgido. Las organizaciones deben empezar a preguntarse: ¿cómo operaremos sin NTLM? autenticación¿Y qué medidas debemos tomar ahora para prepararnos? 

El NTLM no tiene por qué ser una realidad; se puede cambiar. Esta guía explica cómo funciona el NTLM en Active Directory, por qué puede ser difícil eliminarlo gradualmente y proporciona un plan práctico que puede seguir para detectar y eliminar el uso de NTLM en su organización.

Parte 1: ¿Cómo funciona NTLM?

NTLM (NT LAN Manager) es uno de los protocolos de autenticación más antiguos de Microsoft, creado originalmente para las primeras redes de Windows. Fue diseñado para permitir a los usuarios comprobar su identidad sin enviar una contraseña en texto plano, basándose en una mecanismo de desafío-respuestaSi bien esto fue efectivo en la década de 1990, hoy se considera obsoleto e inseguro según los estándares actuales.  

El proceso de autenticación NTLM sigue un intercambio de tres mensajes entre el cliente, el servidor y el controlador de dominio: 

1. Negociación NTLM 
   El cliente inicia la autenticación enviando un mensaje de "Negociar" al servidor. Este mensaje incluye detalles sobre las capacidades del cliente, como las versiones de NTLM compatibles. 

2. Desafío NTLM 
   El servidor responde con un mensaje de "Desafío" que contiene un nonce de 16 bytes generado aleatoriamente (el desafío). Esto garantiza que los intentos de autenticación no se puedan repetir. 

3. Autenticación NTLM 
   El cliente ahora demuestra su identidad generando una respuesta utilizando el hash de contraseña almacenado. 

• El paso crítico: <font dir="auto" style="vertical-align: inherit;">las </font> El cliente calcula la respuesta al desafío NTLM según los criterios del servidor (por ejemplo, NTLMv1 o NTLMv2). 

• Con NTLMv1, el cliente cifra el desafío usando DES, que es débil y se puede atacar con fuerza bruta con facilidad. 

• Con NTLMv2, el cliente incluye datos adicionales, como una marca de tiempo y un nonce de cliente, lo que genera una respuesta más sólida, aunque aún imperfecta. El cliente envía esta respuesta al servidor en un mensaje de "Autenticar". 

4. Aceptar o rechazar 
   In Active DirectoryEl servidor reenvía el desafío y la respuesta al controlador de dominio. El controlador de dominio busca el hash de la contraseña almacenada del usuario en Active DirectoryRealiza el mismo cálculo y compara los resultados. Si coinciden, se acepta la autenticación; si no, se rechaza. 

Aunque Kerberos ha sido durante mucho tiempo el método de autenticación preferido en Active DirectoryNTLM sigue siendo ampliamente utilizado. A menudo, las aplicaciones recurren a NTLM cuando Kerberos falla. Este comportamiento de respaldo es una de las principales razones por las que la eliminación de NTLM es difícil: los administradores pueden incluso desconocer que NTLM sigue activo en sus entornos. 

Parte 2: Eliminación de NTLM en su organización

Eliminar NTLM no es un cambio de configuración único; es un proceso que requiere visibilidad, planificación y una ejecución meticulosa. La clave está en empezar por comprender dónde se sigue utilizando NTLM, reducir gradualmente su dependencia y, finalmente, eliminarlo por completo. 

Paso 1: Determinar qué aplicaciones utilizan NTLM

No puedes eliminar lo que no puedes ver. El primer paso es... Detectar el uso de NTLM en todo su entorno. 

Asignar aplicaciones NTLM manualmente no es tarea fácil. Requiere revisar los registros de eventos de Windows (por ejemplo, el ID de evento 4624 (inicio de sesión correcto) y 4776 (autenticación NTLM) y habilitar las políticas de auditoría NTLM mediante la directiva de grupo. Si bien esto es posible, requiere mucho tiempo y se vuelve aún más complejo en entornos grandes. 

En cambio, lo moderno seguridad de identidad Las capacidades le permiten compilar todas las instancias de uso de NTLM en su entorno en una sola vista. 

En la sección Silverfort Plataforma, aquí le mostramos cómo crear un informe completo de todas las aplicaciones que utilizan NTLM en su entorno: 

1. Abra la pestaña Registros de autenticación 

2. Crear un filtro de protocolo NTLM 

• Agregue filtros adicionales según sea necesario (rango de tiempo, usuarios, dispositivos, etc.)
• NTLMv1 se puede filtrar directamente aplicando el Indicador de Riesgo

3. Exportar el informe

• Agrupe los datos por destino para identificar qué aplicaciones y servidores aún utilizan NTLM

Es importante recordar que el cliente es responsable del cálculo de NTLM. Esto significa que los esfuerzos de detección no se limitan a la aplicación; también es necesario identificar qué clientes recurren a NTLM. Para eliminar NTLM por completo, es necesario supervisar continuamente a los clientes y detectar las razones de la recurrencia. En muchos casos, la recurrencia se produce porque no se puede establecer Kerberos; por ejemplo, debido a una configuración incorrecta de los nombres principales de servicio (SPN) o cuando un cliente se conecta a un recurso utilizando una dirección IP en lugar de un nombre de host NetBIOS o DNS, como exige Kerberos. Es necesario abordar estas causas subyacentes para evitar que los clientes recurran a NTLM de forma predeterminada. 

Al investigar fallos de autenticación Kerberos, recuerde que, en la mayoría de los casos, un intento fallido de autenticación Kerberos se acompaña inmediatamente de una autenticación NTLM exitosa. Este comportamiento facilita la persistencia silenciosa de NTLM en el entorno. Por lo tanto, cada fallo de Kerberos debe revisarse para comprender la causa subyacente, ya sea por un Nombre Principal de Servicio (SPN) faltante o mal configurado, el uso de direcciones IP en lugar de nombres de host u otros errores de implementación. Sin esta investigación, la función de respaldo de NTLM continuará sin control, lo que dificultará los esfuerzos para eliminarla. 

Para investigar fallas de Kerberos utilizando Silverfort:

1. Abrir registros de autenticación

2. Aplicar filtros: Resultado de IdP: Denegar, Protocolo: Kerberos

3. Analiza los resultados

Paso 2: Evaluar el riesgo: NTLMv1 vs. NTLMv2

No todos los usos de NTLM conllevan el mismo nivel de riesgo. Una parte fundamental de su plan de eliminación es diferenciar entre NTLMv1 y NTLMv2. 

NTLMv1

NTLMv1 utiliza DES para su cálculo de desafío-respuesta, que es demasiado débil para los estándares modernos. Los atacantes pueden usar tablas arcoíris o ataques de fuerza bruta basados ​​en GPU para descifrar las respuestas de NTLMv1 en segundos. Por esta razón, NTLMv1 debería bloquearse inmediatamente en todos los entornos. Seguir permitiéndolo pone en riesgo innecesario las credenciales de los usuarios. 

NTLMv2

NTLMv2 mejora la seguridad al introducir HMAC-MD5 e incluir información adicional en el intercambio de autenticación. Una mejora clave es el uso de AV_PAIRS (pares atributo-valor), que pueden contener datos como la marca de tiempo del cliente, el nombre del servidor de destino y la información del destino. Estos campos ayudan a defenderse contra ataques simples de repetición y retransmisión, ya que la respuesta está vinculada a un servidor y contexto de sesión específicos. 

Sin embargo, la protección no es completa. Si los atacantes pueden manipular o eliminar los AV_PAIRS (por ejemplo, en configuraciones que no aplican la validación de destino), los ataques de retransmisión siguen siendo posibles. En la práctica, NTLMv2 sigue siendo vulnerable a la transferencia de hash y a la retransmisión NTLM en escenarios donde no se aplican la firma ni la vinculación de canales. 

Al desarrollar su plan de eliminación de NTLM, es importante priorizar por riesgo. NTLMv1 debe considerarse un riesgo inmediato y bloquearse sin demora, ya que su uso crea una vulnerabilidad directa y fácilmente explotable. superficie de ataqueNTLMv2, aunque más robusto, debe considerarse solo como una medida temporal. Ofrece mayor protección que NTLMv1, pero aún deja su entorno expuesto a ataques de retransmisión y basados ​​en hash. En la práctica, esto implica eliminar primero NTLMv1 y luego centrarse en la reducción sistemática y la eliminación gradual de NTLMv2 hasta su completa eliminación. 

Paso 3: Bloquear NTLMv1 con la política de grupo y conocer sus limitaciones

Bloquear NTLMv1 mediante la directiva de grupo es un paso esencial en cualquier plan de eliminación. La directiva LMCompatibilityLevel (o su equivalente en la directiva de grupo) permite configurar los controladores de dominio para que rechacen las autenticaciones NTLMv1 y solo acepten NTLMv2. Esta es la configuración base recomendada para cada... Active Directory ambiente. 

Cómo activar la directiva de grupo: 

1. Abra Consola de administración de políticas de grupo (GPMC). 

2. Vaya a: Configuración del equipo → Configuración de Windows → Configuración de seguridad → Políticas locales → Opciones de seguridad 

3. Localice la configuración: Seguridad de red: nivel de autenticación de LAN Manager 

4. Establezca el valor en: Enviar solo respuesta NTLMv2. Rechazar LM y NTLM. 

Esto garantiza que los sistemas Windows reciban instrucciones para generar únicamente respuestas NTLMv2 y que los controladores de dominio rechacen las autenticaciones NTLMv1. 

Sin embargo, es importante comprender que este control por sí solo podría no brindarle protección completa. En ciertos casos, las aplicaciones mal configuradas pueden forzar autenticaciones NTLMv1 a pesar de la configuración de la directiva de grupo. Esto crea un riesgo de falsa confianza, ya que los administradores creen que NTLMv1 está bloqueado, aunque en realidad permanece activo en el entorno. 

Para obtener una explicación técnica detallada de cómo funciona dicho bypass y por qué se produce, consulte la publicación de mi blog: Omisión de NTLMv1 en Active Directory – Análisis técnico profundo. 

Mi recomendación actual es monitorear y eliminar NTLMv1 y, si es posible, crear una política basada en riesgos para toda la autenticación NTLMv1 que utilice Silverfort. 

Paso 4: Verifique si las aplicaciones admiten otros métodos de autenticación

Una razón común por la que NTLM persiste en entornos es la suposición de que ciertas aplicaciones solo funcionan con NTLM. En muchos casos, esto no es cierto. Las aplicaciones pueden recurrir a NTLM debido a una configuración incorrecta, la falta de requisitos previos o simplemente porque los administradores no han habilitado protocolos más robustos. 

Antes de reemplazar o retirar una aplicación, verifique si ya admite un método de autenticación más seguro: 

• Kerberos La mayoría de las aplicaciones modernas de Windows son compatibles con la autenticación Kerberos cuando los nombres principales de servicio (SPN) están configurados correctamente. Muchas dependencias de NTLM pueden resolverse corrigiendo los SPN o garantizando que los clientes se conecten mediante nombres de host DNS en lugar de direcciones IP. 

• SAML, OpenID Connect (OIDC) u OAuth – Las aplicaciones web y los servicios en la nube suelen ser compatibles con estos estándares de autenticación modernos, ya sea de forma nativa o mediante la integración con proveedores de identidad (IdP). 

• Autenticación basada en certificados – Algunas aplicaciones empresariales permiten el inicio de sesión basado en tarjetas inteligentes o certificados, eliminando por completo la necesidad de NTLM. 

Al evaluar las solicitudes: 

• Comprobar versiones posteriores – Es posible que las versiones más nuevas hayan eliminado las dependencias de NTLM o agregado soporte para protocolos de identidad modernos. 

• Investigar la documentación – Muchos proveedores documentan la compatibilidad con Kerberos o identidad federada, pero a menudo no se utiliza. 

• Revisar las configuraciones de identidad – Asegúrese de que sus aplicaciones estén integradas con su proveedor de identidad central siempre que sea posible. 

Un buen ejemplo de esto es Microsoft SQL Server cuando se accede con el controlador oficial mssql-jdbc. A primera vista, muchas implementaciones parecen depender de la autenticación NTLM. Sin embargo, en realidad, el controlador es totalmente compatible. Autenticación Kerberos, siempre que los nombres principales de servicio (SPN) estén configurados correctamente y el cliente se conecte mediante un nombre de host DNS en lugar de una dirección IP. Además, la documentación de Microsoft describe cómo configurar explícitamente el controlador para Kerberos, evitando así el uso de NTLM. En este caso, NTLM parece inevitable, pero al revisar la documentación y ajustar la configuración de identidad, los administradores pueden migrar la aplicación a Kerberos y reducir el uso de NTLM. 

Además, Considere agregar autenticación multifactor (MFA) siempre que sea posible. Incluso si NTLM o Kerberos siguen en uso, la MFA reduce significativamente el riesgo de robo de credenciales y mal uso. Silverfort Amplía la protección MFA a protocolos de autenticación como NTLM y Kerberos, proporcionando una capa adicional de defensa tanto para sistemas tradicionales como modernos. 

Paso 5: Planifique el cierre de las aplicaciones basadas en NTLM

Una vez que haya identificado el uso de NTLM, bloqueado NTLMv1 y habilitado alternativas más fuertes cuando sea posible, el paso final es planificar el cierre total de las aplicaciones basadas en NTLMEsta es la única manera de eliminar por completo los riesgos que introduce NTLM. 

Este plan debe incluir: 

Actualizaciones – Migrar a versiones más recientes de aplicaciones compatibles con Kerberos o estándares de autenticación modernos. Muchos proveedores han eliminado las dependencias de NTLM en versiones recientes. 

Reemplazos – Cuando no sea posible realizar actualizaciones, evalúe opciones de reemplazo que se alineen con su estrategia de identidad. 

Desmantelamiento – Establecer un cronograma claro para retirar las aplicaciones que dependen únicamente de NTLM. 

Además, recuerda que Los clientes juegan un papel clave en la eliminación de NTLM. Debido a que el cliente es responsable del cálculo NTLM, es necesario realizarlo continuamente. Monitorear a los clientes que vuelven a NTLM e identificar las razones. Las causas comunes incluyen: 

Uso de IP en lugar de nombres de host – Cuando un cliente se conecta con una dirección IP en lugar de un nombre de host NetBIOS o DNS, no se puede utilizar Kerberos, lo que obliga a recurrir a NTLM. 

Uso inadecuado de Kerberos en aplicaciones Algunas aplicaciones no implementan Kerberos correctamente y, en su lugar, utilizan NTLM de forma predeterminada. Un buen ejemplo de uso indebido es... Vulnerabilidades de suplantación de identidad de KDC identificadas por Silverfort en múltiples productos como IBM QRadar (CVE-2019-4545),  Cisco ASA y Palo Alto Networks PAN-OS , donde el manejo incorrecto de Kerberos permitió a los atacantes eludir Kerberos y obtener acceso elevado (leer más aquí). 

Para obtener una hoja de trucos rápida de estos pasos que puede compartir con su equipo, visite aquí.

Detectar y abordar estos problemas es esencial para evitar que NTLM reaparezca silenciosamente después de creer que ha sido eliminado. 

La próxima Windows 10 Fin de Vida y Microsoft Anuncio de la descontinuación de NTLM Genere la oportunidad adecuada para alinear este plan de cierre con proyectos más amplios de modernización de TI. Considere la eliminación de NTLM como parte de la actualización de su infraestructura, de modo que, cuando Windows 10 se descontinúe, su entorno ya no dependa de NTLM.

Para preparar a tu equipo para estos cambios cruciales, ¡No te pierdas nuestro seminario web bajo demanda! donde explico cómo exponer la autenticación NTLM y crear políticas escalables para ayudarte a eliminarla.