Articulo de referencia

NTLM

En una red Windows , NT (New Technology) LAN Manager ( NTLM ) es un conjunto de protocolos de seguridad de Microsoft destinados a proporcionar autenticación, integridad y confid...

En una red Windows , NT (New Technology) LAN Manager ( NTLM ) es un conjunto de protocolos de seguridad de Microsoft destinados a proporcionar autenticación, integridad y confidencialidad a los usuarios. [ 1 ] [ 2 ] [ 3 ] NTLM es el sucesor del protocolo de autenticación en Microsoft LAN Manager (LANMAN), un producto anterior de Microsoft. El conjunto de protocolos NTLM se implementa en un Proveedor de soporte de seguridad , que combina el protocolo de autenticación de LAN Manager , NTLMv1, NTLMv2 y los protocolos de sesión NTLM2 en un solo paquete. El uso o la posibilidad de usar estos protocolos en un sistema está regido por la configuración de la Directiva de grupo , para la cual las diferentes versiones de Windows tienen configuraciones predeterminadas diferentes.

Las contraseñas NTLM se consideran débiles porque pueden ser descifradas mediante fuerza bruta con mucha facilidad utilizando hardware moderno. [ 4 ]

Protocolo

NTLM es un protocolo de autenticación de desafío-respuesta que utiliza tres mensajes para autenticar a un cliente en un entorno orientado a la conexión (el entorno sin conexión es similar), y un cuarto mensaje adicional si se desea integridad. [ 5 ] [ 6 ] [ 7 ] [ 8 ]

  1. Primero, el cliente establece una ruta de red hacia el servidor y envía un NEGOTIATE_MESSAGE anunciando sus capacidades. [ 9 ]
  2. A continuación, el servidor responde con CHALLENGE_MESSAGE, que se utiliza para establecer la identidad del cliente. [ 10 ]
  3. Finalmente, el cliente responde al desafío con un AUTHENTICATE_MESSAGE. [ 11 ]

El protocolo NTLM utiliza uno o ambos de dos valores de contraseña hash, los cuales también se almacenan en el servidor (o controlador de dominio) y que, al no utilizar sal, son equivalentes a la contraseña , lo que significa que si se obtiene el valor hash del servidor, se puede autenticar sin conocer la contraseña real. Los dos valores son el hash LM (una función basada en DES aplicada a los primeros 14 caracteres de la contraseña, convertidos al conjunto de caracteres PC tradicional de 8 bits para el idioma) y el hash NT ( MD4 de la contraseña Unicode UTF-16 little endian ). Ambos valores hash tienen 16 bytes (128 bits) cada uno. [ 12 ]

El protocolo NTLM también utiliza una de dos funciones unidireccionales , dependiendo de la versión de NTLM; NT LanMan y NTLM versión 1 utilizan la función unidireccional LanMan basada en DES (LMOWF), mientras que NTLMv2 utiliza la función unidireccional basada en NT MD4 (NTOWF). [ 12 ] [ 13 ]

NTLMv1

El servidor autentica al cliente enviándole un número aleatorio de 8 bytes, el desafío. El cliente realiza una operación que involucra el desafío y un secreto compartido entre el cliente y el servidor, específicamente uno de los dos hashes de contraseña descritos anteriormente. El cliente devuelve el resultado de 24 bytes del cálculo. De hecho, en NTLMv1, los cálculos generalmente se realizan utilizando ambos hashes y se envían ambos resultados de 24 bytes. El servidor verifica que el cliente haya calculado el resultado correcto y, a partir de esto, deduce que posee el secreto y, por lo tanto, la autenticidad del cliente.

Ambos hashes generan cantidades de 16 bytes. Se añaden cinco bytes de ceros para obtener 21 bytes. Estos 21 bytes se dividen en tres cantidades de 7 bytes (56 bits). Cada una de estas cantidades de 56 bits se utiliza como clave para cifrar el desafío de 64 bits mediante DES . Los tres cifrados del desafío se combinan para formar la respuesta de 24 bytes. Se devuelve tanto la respuesta que utiliza el hash LM como la que utiliza el hash NT, pero esto es configurable.

C = desafío del servidor de 8 bytes, aleatorio K1 | K2 | K3 = NTLM-Hash | 5 bytes-0 respuesta = DES(K1,C) | DES(K2,C) | DES(K3,C) 

NTLMv2

NTLMv2, introducido en Windows NT 4.0 SP4 [ 14 ] (y compatible de forma nativa en Windows 2000), es un protocolo de autenticación de desafío-respuesta. Su objetivo es reemplazar criptográficamente a NTLMv1, mejorando la seguridad de NTLM al fortalecer el protocolo contra numerosos ataques de suplantación de identidad y permitiendo que un servidor se autentique ante el cliente. [ 1 ] [ 15 ] [ 16 ]

NTLMv2 envía dos respuestas a un desafío de servidor de 8 bytes . Cada respuesta contiene un hash HMAC - MD5 de 16 bytes del desafío del servidor, un desafío del cliente generado total o parcialmente de forma aleatoria y un hash HMAC-MD5 de la contraseña del usuario y otra información de identificación. Las dos respuestas difieren en el formato del desafío del cliente. La respuesta más corta utiliza un valor aleatorio de 8 bytes para este desafío. Para verificar la respuesta, el servidor debe recibir el desafío del cliente como parte de la respuesta. Para esta respuesta más corta, el desafío del cliente de 8 bytes añadido a la respuesta de 16 bytes forma un paquete de 24 bytes que es consistente con el formato de respuesta de 24 bytes del protocolo NTLMv1 anterior. En cierta documentación no oficial (por ejemplo, DCE/RPC Over SMB, Leighton) esta respuesta se denomina LMv2.

La segunda respuesta enviada por NTLMv2 utiliza un desafío de cliente de longitud variable que incluye (1) la hora actual en formato NT Time , (2) un valor aleatorio de 8 bytes (CC2 en el recuadro inferior), (3) el nombre de dominio y (4) información de formato estándar. La respuesta debe incluir una copia de este desafío de cliente y, por lo tanto, es de longitud variable. En la documentación no oficial, esta respuesta se denomina NTv2.

Tanto LMv2 como NTv2 aplican una función hash al desafío del cliente y del servidor utilizando el hash NT de la contraseña del usuario y otra información de identificación. La fórmula exacta consiste en comenzar con el hash NT, que se almacena en SAM o AD, y continuar aplicando el hash MD5 al nombre de usuario y al nombre de dominio mediante HMAC . En el cuadro inferior, la X representa el contenido fijo de un campo de formato.

SC = desafío del servidor de 8 bytes, aleatorio CC = desafío de cliente de 8 bytes, aleatorio CC* = (X, tiempo, CC2, nombre de dominio) v2-Hash = HMAC-MD5(NT-Hash, nombre de usuario, nombre de dominio) LMv2 = HMAC-MD5(v2-Hash, SC, CC) NTv2 = HMAC-MD5(v2-Hash, SC, CC*) respuesta = LMv2 | CC | NTv2 | CC* 

Sesión NTLM2

El protocolo de sesión NTLM2 es similar a MS-CHAPv2. [ 17 ] Consiste en la autenticación de NTLMv1 combinada con la seguridad de sesión de NTLMv2.

En resumen, se aplica el algoritmo NTLMv1, con la salvedad de que se añade un desafío de cliente de 8 bytes al desafío de servidor de 8 bytes y se aplica la función hash MD5. La mitad de 8 bytes menos significativa del resultado del hash constituye el desafío utilizado en el protocolo NTLMv1. El desafío del cliente se devuelve en una ranura de 24 bytes del mensaje de respuesta, mientras que la respuesta calculada de 24 bytes se devuelve en la otra ranura.

Esta es una forma reforzada de NTLMv1 que mantiene la capacidad de usar la infraestructura de controlador de dominio existente, pero evita un ataque de diccionario por parte de un servidor malicioso. Para un X fijo , el servidor calcula una tabla donde la ubicación Y tiene el valor K tal que Y=DES_K(X) . Sin que el cliente participe en la elección del desafío, el servidor puede enviar X , buscar la respuesta Y en la tabla y obtener K. Este ataque puede hacerse práctico usando tablas arcoíris . [ 18 ]

Sin embargo, la infraestructura NTLMv1 existente permite que el par desafío/respuesta no sea verificado por el servidor, sino que se envíe a un controlador de dominio para su verificación. Al usar NTLM2 Session, esta infraestructura sigue funcionando si el servidor sustituye el desafío por el hash de los desafíos del servidor y del cliente.

NTLMv1 Cliente<-Servidor: SC Cliente->Servidor: H(P,SC) Servidor->Control Doméstico: H(P,SC), SC Servidor<-DomCntl: sí o no Sesión NTLM2 Cliente<-Servidor: SC Cliente->Servidor: H(P,H'(SC,CC)), CC Servidor->Control Dom: H(P,H'(SC,CC)), H'(SC,CC) Servidor<-DomCntl: sí o no 

Disponibilidad y uso de NTLM

Desde 2010, Microsoft ya no recomienda NTLM en las aplicaciones: [ 19 ]

Los implementadores deben tener en cuenta que NTLM no admite ningún método criptográfico reciente, como AES o SHA-256. Utiliza comprobaciones de redundancia cíclica (CRC) o MD5 para la integridad y RC4 para el cifrado.

La obtención de una clave a partir de una contraseña se rige por las normas RFC1320 y FIPS46-2. Por lo tanto, se recomienda a las aplicaciones que no utilicen NTLM.

A pesar de estas recomendaciones, NTLM sigue estando ampliamente implementado en los sistemas. Una de las principales razones es mantener la compatibilidad con sistemas más antiguos. Sin embargo, en algunas circunstancias puede evitarse.

Microsoft ha añadido el hash NTLM a su implementación del protocolo Kerberos para mejorar la interoperabilidad (en particular, el tipo de cifrado RC4-HMAC). Según un investigador independiente, esta decisión de diseño permite engañar a los controladores de dominio para que emitan un ticket Kerberos a un atacante si se conoce el hash NTLM. [ 20 ] Microsoft adoptó Kerberos como protocolo de autenticación preferido para Windows 2000 y los dominios posteriores de Active Directory. [ 16 ] Kerberos se utiliza normalmente cuando un servidor pertenece a un dominio de Windows Server . Microsoft recomienda a los desarrolladores que no utilicen Kerberos ni el proveedor de soporte de seguridad (SSP) NTLM directamente. [ 21 ]

Su aplicación no debe acceder directamente al paquete de seguridad NTLM; en su lugar, debe usar el paquete de seguridad Negotiate. Negotiate permite que su aplicación aproveche protocolos de seguridad más avanzados si son compatibles con los sistemas involucrados en la autenticación. Actualmente, el paquete de seguridad Negotiate selecciona entre Kerberos y NTLM. Negotiate selecciona Kerberos a menos que alguno de los sistemas involucrados en la autenticación no pueda usarlo.

Uso del proveedor de soporte de seguridad NTLM

El protocolo NTLM SSP se utiliza en las siguientes situaciones:

  • El cliente se está autenticando en un servidor que no pertenece a un dominio o en el que no existe ningún dominio de Active Directory (lo que comúnmente se conoce como "grupo de trabajo" o "peer-to-peer").
    • El servidor debe tener habilitada la función de "uso compartido protegido con contraseña", que no está habilitada de forma predeterminada y que es mutuamente excluyente con Grupo Hogar en algunas versiones de Windows.
    • Cuando tanto el servidor como el cliente pertenecen al mismo Grupo Hogar , se utilizará un protocolo similar a Kerberos, basado en la autenticación de usuario a usuario mediante criptografía de clave pública, en lugar de NTLM. [ 22 ] El Grupo Hogar es probablemente la forma más sencilla de compartir recursos en una red pequeña, ya que requiere una configuración mínima, incluso en comparación con la configuración de algunos usuarios adicionales para que puedan utilizar el uso compartido protegido con contraseña, lo que puede significar que se utiliza mucho más que el uso compartido protegido con contraseña en redes pequeñas y redes domésticas.
  • Si el servidor es un dispositivo compatible con SMB , como los dispositivos NAS y las impresoras de red, el protocolo NTLM SSP puede ser el único método de autenticación compatible. Algunas implementaciones de SMB o versiones antiguas de, por ejemplo, Samba, pueden provocar que Windows negocie NTLMv1 o incluso LM para la autenticación saliente con el servidor SMB, lo que permite que el dispositivo funcione aunque tenga instalado software obsoleto e inseguro, independientemente de si se trata de un dispositivo nuevo.
  • Si el servidor pertenece a un dominio pero no se puede utilizar Kerberos .
    • El cliente se autentica en un servidor mediante una dirección IP (y no hay resolución inversa de nombres disponible).
    • El cliente se está autenticando en un servidor que pertenece a un bosque de Active Directory diferente que tiene una relación de confianza NTLM heredada en lugar de una relación de confianza transitiva entre bosques.
    • Donde un cortafuegos restringiría de otro modo los puertos requeridos por Kerberos (normalmente TCP 88)

Uso de versiones del protocolo

Una vez que el desarrollador de la aplicación o el SSP de Negotiate hayan decidido utilizar el SSP NTLM para la autenticación, la Directiva de grupo determina la capacidad de usar cada uno de los protocolos que implementa el SSP NTLM. Existen cinco niveles de autenticación. [ 23 ]

  • Enviar respuestas LM y NTLM : Los clientes utilizan la autenticación LM y NTLM, y nunca utilizan la seguridad de sesión NTLMv2; los controladores de dominio aceptan la autenticación LM, NTLM y NTLMv2.
  • Enviar LM y NTLM: usar seguridad de sesión NTLMv2 si se negocia : Los clientes usan autenticación LM y NTLM, y usan seguridad de sesión NTLMv2 si el servidor lo admite; los controladores de dominio aceptan autenticación LM, NTLM y NTLMv2.
  • Enviar solo respuesta NTLM : Los clientes usan solo autenticación NTLM y seguridad de sesión NTLMv2 si el servidor lo admite; los controladores de dominio aceptan autenticación LM, NTLM y NTLMv2.
  • Enviar solo respuesta NTLMv2 : Los clientes usan solo autenticación NTLMv2 y seguridad de sesión NTLMv2 si el servidor lo admite; los controladores de dominio aceptan autenticación LM, NTLM y NTLMv2.
  • Enviar solo respuesta NTLMv2\rechazar LM : Los clientes usan solo autenticación NTLMv2 y seguridad de sesión NTLMv2 si el servidor lo admite; los controladores de dominio rechazan LM (solo aceptan autenticación NTLM y NTLMv2).
  • Enviar solo respuesta NTLMv2\rechazar LM y NTLM : Los clientes usan solo autenticación NTLMv2 y seguridad de sesión NTLMv2 si el servidor lo admite; los controladores de dominio rechazan LM y NTLM (solo aceptan autenticación NTLMv2).

DC significa Controlador de Dominio, pero el uso de ese término puede resultar confuso. Cualquier equipo que actúe como servidor y autentique a un usuario cumple la función de DC en este contexto; por ejemplo, un equipo Windows con una cuenta local como Administrador cuando se utiliza dicha cuenta durante un inicio de sesión en la red.

Antes del Service Pack 4 de Windows NT 4.0, el SSP negociaba NTLMv1 y recurría a LM si la otra máquina no lo admitía.

A partir de Windows NT 4.0 Service Pack 4, el SSP negociaría la sesión NTLMv2 siempre que tanto el cliente como el servidor la admitieran. [ 24 ] Hasta Windows XP inclusive, esto utilizaba cifrado de 40 o 56 bits en equipos fuera de EE. UU., ya que Estados Unidos tenía severas restricciones a la exportación de tecnología de cifrado en ese momento. A partir de Windows XP SP3, se podía agregar cifrado de 128 bits instalando una actualización y, en Windows 7, el cifrado de 128 bits sería el predeterminado.

En Windows Vista y versiones posteriores, LM se ha deshabilitado para la autenticación entrante. Los sistemas operativos basados ​​en Windows NT, hasta Windows Server 2003 inclusive, almacenan dos hashes de contraseña: el hash de LAN Manager (LM) y el hash de Windows NT. A partir de Windows Vista , existe la capacidad de almacenar ambos, pero uno está desactivado de forma predeterminada. Esto significa que la autenticación LM ya no funciona si el equipo que ejecuta Windows Vista actúa como servidor. Las versiones anteriores de Windows (hasta Windows NT 4.0 Service Pack 4) podían configurarse para comportarse de esta manera, pero no era la configuración predeterminada. [ 25 ]

Debilidades y vulnerabilidades

NTLM sigue siendo vulnerable al ataque de paso de hash , una variante del ataque de reflexión que se abordó con la actualización de seguridad MS08-068 de Microsoft. Por ejemplo, Metasploit puede utilizarse en muchos casos para obtener credenciales de una máquina y así tomar el control de otra. [ 3 ] [ 26 ] El kit de herramientas Squirtle puede utilizarse para aprovechar los ataques de secuencias de comandos entre sitios web y convertirlos en ataques a recursos cercanos a través de NTLM. [ 27 ]

En febrero de 2010, Amplia Security descubrió varias vulnerabilidades en la implementación de Windows del mecanismo de autenticación NTLM que comprometían la seguridad del protocolo, permitiendo a los atacantes obtener acceso de lectura/escritura a archivos y ejecutar código de forma remota. Uno de los ataques presentados incluía la capacidad de predecir números pseudoaleatorios y desafíos/respuestas generados por el protocolo. Estas vulnerabilidades habían estado presentes en todas las versiones de Windows durante 17 años. El aviso de seguridad que explicaba estos problemas incluía exploits de prueba de concepto completamente funcionales. Todas estas vulnerabilidades fueron corregidas por MS10-012. [ 28 ] [ 29 ]

En 2012, se demostró que cualquier permutación posible de hash de contraseña NTLM de 8 caracteres puede descifrarse en menos de 6 horas. [ 30 ]

En 2019, este tiempo se redujo a aproximadamente 2,5 horas gracias al uso de hardware más moderno. [ 4 ] [ 31 ] Además, existen tablas Rainbow disponibles para contraseñas NTLM de ocho y nueve caracteres. Las contraseñas más cortas pueden recuperarse mediante métodos de fuerza bruta. [ 32 ]

En 2019, EvilMog [ 33 ] [ 34 ] publicó una herramienta llamada ntlmv1-multitool [ 35 ] para formatear las respuestas de desafío NTLMv1 en un formato de descifrado compatible con hashcat. Con hashcat y suficiente potencia de GPU, el hash NTLM se puede derivar utilizando un ataque de texto plano conocido descifrando las claves DES con el modo 14000 de hashcat, como demostró atom [ 36 ] en los foros de hashcat.

Cabe destacar que los hashes equivalentes a contraseñas utilizados en ataques de robo de hash y descifrado de contraseñas deben ser previamente obtenidos (por ejemplo, comprometiendo un sistema con permisos suficientes para acceder a los hashes). Además, estos hashes no son iguales al hash NTLMSSP_AUTH transmitido por la red durante una autenticación NTLM convencional.

Compatibilidad con Linux

Las implementaciones de NTLM para Linux incluyen Cntlm [ 37 ] y winbind (parte de Samba ) [ 38 ] que permiten a las aplicaciones de Linux usar proxies NTLM.

FreeBSD también admite el almacenamiento de contraseñas a través de Crypt (C) en el formato inseguro NT-Hash. [ 39 ]

Véase también

Referencias

  1. 1 2 "Introducción" , Especificación del protocolo de autenticación NT LAN Manager (NTLM) , Microsoft , consultado el 15 de agosto de 2010
  2. "Detalles de seguridad de sesión" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) , Microsoft , consultado el 15 de agosto de 2010.
  3. 1 2 Takahashi, T (17-12-2009), "Reflexiones sobre NTLM Reflection" , Blog FrequencyX , IBM Internet System Security (ISS), archivado del original el 31-12-2009 , recuperado el 14-08-2010
  4. 1 2 Claburn, Thomas (14 de febrero de 2019). "¿Usas una contraseña NTLM de Windows de 8 caracteres? No lo hagas. Todas se pueden descifrar en menos de 2,5 horas" . www.theregister.co.uk . Consultado el 26 de noviembre de 2020 .
  5. "Microsoft NTLM" , MSDN , Microsoft , consultado el 15 de agosto de 2010
  6. "Sintaxis de mensajes | sección 2.2" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) , Microsoft , consultado el 15 de agosto de 2010.
  7. "Orientado a la conexión" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) ( ed. 3.1.5.1 ), Microsoft , consultado el 15 de agosto de 2010. 
  8. "Sin conexión" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) ( ed. 3.1.5.2 ), Microsoft , consultado el 15 de agosto de 2010. 
  9. "NEGOTIATE_MESSAGE" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) ( ed. 2.2.1.1 ), Microsoft , consultado el 15 de agosto de 2010. 
  10. "CHALLENGE_MESSAGE" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) ( ed. 2.2.1.2 ), Microsoft , consultado el 15 de agosto de 2010. 
  11. "AUTHENTICATE_MESSAGE" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) ( ed. 2.2.1.3 ), Microsoft , consultado el 15 de agosto de 2010. 
  12. 1 2 "Autenticación NTLM v1" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) ( ed. 3.3.1), Microsoft , consultado el 15 de agosto de 2010. 
  13. "Autenticación NTLM v2" , Especificación del protocolo de autenticación NT LAN Manager (NTLM) ( ed. 3.3.1 ), Microsoft , consultado el 15 de agosto de 2010. 
  14. ¿Qué novedades incluye Windows NT 4.0 Service Pack 4?
  15. Cómo habilitar la autenticación NTLM 2 , Soporte, Microsoft, 25/01/2007 , consultado el 14/08/2010
  16. 1 2 "Configuración de seguridad" , Guía de endurecimiento de seguridad de Microsoft Windows 2000 , TechNet, Microsoft, 24 de marzo de 2009 , consultado el 14 de agosto de 2010.
  17. Glass, Eric, "NTLM" , Davenport , Source forge
  18. Varughese, Sam (febrero de 2006). "Rainbow Cracking and Password Security" . Palisade. Archivado del original el 1 de junio de 2010. Recuperado el 14 de agosto de 2010 .
  19. "Consideraciones de seguridad para implementadores" , Especificación del protocolo de autenticación NT LAN Manager (NTLM) , Microsoft , consultado el 16 de agosto de 2010.
  20. "Divulgación de vulnerabilidad de Active Directory: el cifrado débil permite al atacante cambiar la contraseña de una víctima sin iniciar sesión - Aorato" . Archivado del original el 6 de octubre de 2014. Consultado el 5 de octubre de 2014 .
  21. "Microsoft NTLM" . Biblioteca TechNet . Microsoft . Consultado el 2 de noviembre de 2015 .
  22. "Descripción general de la autenticación de usuario a usuario basada en criptografía de clave pública" . Biblioteca TechNet . Microsoft . Consultado el 2 de noviembre de 2015 .
  23. "Nivel de autenticación de LAN Manager" . Biblioteca MSDN . Microsoft . Consultado el 2 de noviembre de 2015 .
  24. "Autenticación de Windows" . Biblioteca TechNet . Microsoft. 29 de junio de 2011. Consultado el 2 de noviembre de 2015 .
  25. Jesper Johansson. "La configuración de seguridad de Windows más incomprendida de todos los tiempos" . Revista TechNet . Microsoft . Consultado el 2 de noviembre de 2015 .
  26. HD Moore. "MS08-068: Metasploit y retransmisión SMB" .
  27. Kurt Grutzmacher (8 de agosto de 2008). Clavar el ataúd, NTLM está muerto . Defcon 16.
  28. Hernan Ochoa y Agustin Azubel (28 de julio de 2010). Comprensión de la vulnerabilidad de nonce débil de NTLM SMB de Windows (PDF) . Blackhat USA 2010.
  29. Hernán Ochoa y Agustín Azubel. "Aviso de seguridad sobre la vulnerabilidad de nonce débil de Windows SMB NTLM" .
  30. Goodin, Dan (10 de diciembre de 2012). "Un clúster de 25 GPU descifra todas las contraseñas estándar de Windows en menos de 6 horas" . Ars Technica . Consultado el 23 de noviembre de 2020 .
  31. hashcat (13 de febrero de 2019). "Hashcat 6.0.0 beta optimizado manualmente y 2080Ti (frecuencias de reloj estándar) rompe la marca de velocidad de descifrado NTLM de 100 GH/s en un solo dispositivo de cómputo" . @hashcat . Consultado el 26 de febrero de 2019 .
  32. Argumentos a favor del uso de tablas arcoíris modernas
  33. "El hacker ético Dustin Heywood, alias EvilMog: 'Mi misión es hacer que las empresas sean más seguras'"" . The Globe and Mail . 09-12-2019 . Consultado el 12-10-2023 .
  34. "Dustin Heywood: El hacker "malvado" que usa su mente neurodivergente para el bien" . Sala de prensa de IBM . Consultado el 12 de octubre de 2023 .
  35. Heywood, Dustin (11 de octubre de 2023), Actualizaciones del 10 de noviembre de 2020 , consultado el 12 de octubre de 2023.
  36. "Cómo utilizar el modo DES KPA" . hashcat.net . Consultado el 12 de octubre de 2023 .
  37. "Cntlm: Proxy de autenticación NTLM rápido en C" .
  38. "Autenticación NTLM - MoodleDocs" .
  39. "NT MD4 password hash como nuevo método de cifrado de contraseñas para FreeBSD" . Mail-archive.com . Consultado el 2 de diciembre de 2018 .
  • Descifrado de hashes NTLM en línea mediante tablas Rainbow.
  • Especificación del protocolo de autenticación del administrador de LAN de NT (NTLM)
  • Cntlm – Proxy y acelerador de autenticación NTLM, NTLMSR, NTLMv2. Proxy HTTP(S) y SOCKS5 personal para aplicaciones que no admiten NTLM (Windows/Linux/UNIX).
  • El protocolo de autenticación NTLM y el proveedor de soporte de seguridad. Un análisis detallado del protocolo NTLM.
  • Artículo de MSDN que explica el protocolo y que ha sido renombrado.
  • Página de MSDN sobre autenticación NTLM
  • Libntlm : una implementación gratuita.
  • Software de servidor proxy de autorización NTLM que permite a los usuarios autenticarse a través de un servidor proxy de Microsoft.
  • Instalación de la autenticación NTLM : instrucciones de configuración de NTLM para Samba y Midgard en Linux
  • NTLM versión 2 (NTLMv2) y la configuración LMCompatibilityLevel que la rige.
  • Jespa – Integración Java Active Directory. Proveedor de servicios de seguridad NTLM completo con validación NETLOGON del lado del servidor (comercial, pero gratuito hasta 25 usuarios).
  • EasySSO: autenticador NTML para JIRA. Autenticador NTML que utiliza la biblioteca Jespa para proporcionar IWA para productos Atlassian .
  • ntlmv2-auth API NTLMv2 y filtro de servlet para Java
  • Una herramienta generadora de mensajes ntlm
  • WAFFLE – Marco de autenticación de Windows en Java/C# Archivado el 20/10/2010 en Wayback Machine
  • objectif-securite (Mesas arcoiris para ophcrack)
  • Px para Windows : un servidor proxy HTTP para autenticarse automáticamente a través de un proxy NTLM.
  • NTLMv1 Multi Tool : una herramienta para formatear las respuestas de desafío NTLMv1 en un formato que se puede descifrar con hashcat.