CodeKitHub¿Qué es esta herramienta?
NTLM (NT LAN Manager) es el protocolo heredado de autenticación por desafío-respuesta de Microsoft, todavía usado hoy para inicios de sesión locales en Windows y como alternativa de respaldo en muchos entornos de Active Directory. Su verificador de contraseña —conocido habitualmente como «el hash NTLM»— se define en la propia especificación del protocolo MS-NLMP de Microsoft como `MD4(UTF-16-LE(password))`: la contraseña se codifica primero en UTF-16 little-endian (de modo que cada carácter ocupa 2 bytes, a diferencia de UTF-8), y esa secuencia de bytes se pasa una única vez por el algoritmo MD4 definido en el RFC 1320.
El paso de UTF-16LE es el detalle que más gente falla al reimplementar NTLM: calcular el hash de los bytes UTF-8 de una cadena en lugar de sus bytes UTF-16LE produce un resumen completamente distinto e incorrecto, aunque el texto visible sea idéntico. Esta herramienta codifica correctamente, así que su salida coincide con lo que el propio Windows almacena y con lo que esperan herramientas como hashcat (modo 1000) y Mimikatz.
Como NTLM es anterior al diseño moderno de hashing de contraseñas, carece de todas las protecciones que se incorporaron después específicamente para ralentizar el cracking: no hay sal por usuario, no hay factor de coste configurable y no hay iteración deliberada. Es una única pasada de MD4, lo que lo hace extremadamente rápido de calcular, una propiedad cómoda para la compatibilidad heredada pero desastrosa a la hora de resistir ataques de fuerza bruta y de diccionario.
¿Por qué utilizarlo?
- Estás en medio de un pentest autorizado, volcaste el NTDS.dit del controlador de dominio y necesitas confirmar rápidamente que un hash concreto corresponde a la contraseña que acabas de crackear con hashcat, sin subir nada a un servicio online.
- Escribiste tu propio script en Python para calcular hashes NTLM y el resultado no coincide con el de Mimikatz — necesitas una implementación de referencia fiable para aislar si el bug está en tu codificación UTF-16LE o en otra parte.
- Preparas un laboratorio de formación en seguridad para tu equipo y necesitas generar varios hashes NTLM de contraseñas de ejemplo para que practiquen con hashcat en modo 1000 sin exponer credenciales reales.
- Estás resolviendo un reto de CTF que exige generar el hash NTLM de una cadena específica antes de poder avanzar a la siguiente fase.
- Auditas la configuración heredada de un Active Directory y necesitas verificar manualmente si una cuenta de servicio antigua sigue usando una contraseña débil y conocida.
- 100 % local: tu entrada nunca sale del navegador, por lo que es seguro usarlo incluso con material de credenciales sensible en una evaluación autorizada.
Cómo utilizarlo
- Escribe la contraseña o cadena de texto que quieres hashear en el cuadro de entrada.
- Haz clic en «Generar hash NTLM».
- Lee el hash NTLM de 32 caracteres hexadecimales (la salida en mayúsculas está activada por defecto, tal como lo muestran Windows y la mayoría de herramientas de cracking; desmarca la casilla para minúsculas).
- Haz clic en «Copiar» para copiar el hash al portapapeles.
Ejemplo
Entrada
passwordResultado
8846F7EAEE8FB117AD06BDD830B7586CEste es un vector de prueba bien conocido y verificable de forma independiente: el hash NTLM de la cadena literal «password» es siempre 8846F7EAEE8FB117AD06BDD830B7586C. Puedes comprobar la salida de esta herramienta frente a cualquier otra implementación NTLM correcta.
NTLM frente al hashing moderno de contraseñas
La siguiente tabla muestra por qué NTLM se considera obsoleto para proteger sistemas nuevos, aunque siga presente en infraestructura heredada de Windows y Active Directory.
| Propiedad | NTLM | bcrypt / scrypt / Argon2 |
|---|---|---|
| Primitiva subyacente | Una única pasada de MD4 | Hash lento diseñado a propósito, con coste ajustable |
| Salado | Ninguno: contraseñas idénticas siempre generan el mismo hash | Sal aleatoria única por contraseña |
| Iteración / stretching | Ninguna | Factor de coste configurable, ampliable con el tiempo |
| Resistencia a fuerza bruta | Muy débil: miles de millones de intentos por segundo en GPU actuales | Deliberadamente costoso por cada intento |
| Dónde se sigue encontrando | Autenticación Windows heredada, respaldo de Active Directory | Aplicaciones nuevas, mejor práctica actual |
Herramientas relacionadas
Si necesitas un hash criptográfico de propósito general en lugar de la construcción MD4(UTF-16LE) específica de NTLM, estas herramientas pueden encajar mejor.
→ Generador de hash multialgoritmo · Generador de MD5 · Generador de contraseñas
Errores comunes al reimplementar NTLM desde cero
- Codificar en UTF-8 en vez de UTF-16LE antes del MD4 — el error más frecuente, y el que produce un hash con el aspecto correcto (32 caracteres hex) pero completamente equivocado.
- Olvidar que MD4 no es MD5: son algoritmos distintos con salidas distintas, aunque ambos produzcan un resumen de 128 bits — usar una librería MD5 por error es un fallo silencioso muy común.
- No verificar el orden de bytes little-endian dentro de cada par UTF-16 — algunos lenguajes por defecto usan big-endian y hay que forzar explícitamente little-endian.
- Confundir el hash NTLM base con el hash NTLMv2 de sesión — son cálculos distintos, y el segundo depende de un desafío del servidor que no puede reproducirse solo con la contraseña.
Preguntas frecuentes
¿Qué es exactamente un hash NTLM?
Es el verificador de contraseña que Windows calcula y almacena para la autenticación NT LAN Manager, definido en la especificación MS-NLMP de Microsoft como MD4(UTF-16LE(password)): una única pasada de MD4 sobre la codificación en bytes UTF-16 little-endian de la contraseña. Siempre tiene 128 bits, mostrados como 32 caracteres hexadecimales.
¿Por qué UTF-16LE en concreto, y no UTF-8 o ASCII?
Windows almacena internamente el texto en UTF-16LE desde que se diseñó NT, así que las contraseñas también se codifican de ese modo antes de hashearlas. Cada carácter ocupa 2 bytes (en orden little-endian), incluidos los caracteres ASCII normales como «a», que pasan a ser 0x61 0x00 en lugar de simplemente 0x61. Hashear los bytes UTF-8 de esa misma cadena produce un resultado totalmente distinto e incorrecto: es el error más habitual al implementar NTLM desde cero.
¿Es seguro usar NTLM hoy en día?
No, y el propio Microsoft recomienda abandonarlo en favor de Kerberos siempre que sea posible. NTLM no usa sal, así que contraseñas idénticas producen siempre hashes idénticos en cualquier usuario y sistema, lo que permite búsquedas con tablas rainbow precalculadas. Tampoco tiene iteración ni factor de coste —una única pasada de MD4 sin sal—, así que las GPU actuales pueden probar miles de millones de combinaciones por segundo contra un hash capturado. Sobrevive básicamente por compatibilidad con sistemas y aplicaciones Windows antiguos.
¿En qué se diferencia NTLM del hashing moderno de contraseñas, como bcrypt, scrypt o Argon2?
Los algoritmos modernos de hashing de contraseñas son deliberadamente lentos y usan sal: bcrypt, scrypt y Argon2 añaden cada uno una sal aleatoria única por contraseña y un factor de coste ajustable que se puede aumentar con el tiempo a medida que el hardware mejora, precisamente para que la fuerza bruta salga cara incluso a gran escala. NTLM no hace ninguna de las dos cosas: se diseñó en una época en la que la fuerza bruta offline no era un modelo de amenaza realista, y se nota. Por eso NTLM nunca debería usarse para proteger nada que se diseñe hoy; los casos de uso reales de esta herramienta son la compatibilidad con infraestructura Windows existente y las pruebas de seguridad autorizadas, no construir sistemas nuevos.
¿Cuáles son los usos legítimos de un generador de hash NTLM?
Verificar hashes extraídos de una base de datos SAM o de un NTDS.dit durante un test de penetración autorizado o una auditoría de credenciales; comprobar que tu propio código o scripts implementan MS-NLMP correctamente; generar hashes de prueba para hashcat (modo 1000) o comprobaciones de compatibilidad con el formato de Mimikatz en un laboratorio que controlas; y resolver ejercicios de CTF o formación que impliquen explícitamente NTLM. Usar esta herramienta para atacar cuentas o sistemas que no te pertenecen o para los que no tienes autorización por escrito no es un uso legítimo.
¿Se envía mi contraseña o entrada a un servidor?
No. El cálculo de MD4 se ejecuta íntegramente en JavaScript en tu navegador —no existe ninguna API nativa del navegador para MD4, así que está implementado directamente en el código cliente de esta página— y nada de lo que escribes se transmite a ningún sitio.
¿Por qué mi hash no coincide con el que obtengo con un pequeño script en Python?
La causa más común es codificar la cadena en UTF-8 en lugar de UTF-16LE antes de aplicar MD4 — revisa que tu script use `.encode('utf-16le')` en Python, no `.encode('utf-8')`, que es el valor por defecto en la mayoría de librerías y el error más frecuente al reimplementar NTLM desde cero.
¿El hash cambia si la contraseña contiene tildes o la eñe?
Sí, y de forma correcta: UTF-16LE codifica cada carácter Unicode fielmente, así que una contraseña como «contraseña123» produce bytes distintos —y por tanto un hash distinto— a una versión sin tilde ni eñe. Esto es exactamente lo que Windows hace internamente.
¿Puedo usar esta herramienta para calcular el hash NTLMv2, no solo el NTLM básico?
No — esta herramienta calcula únicamente el hash NTLM base (MD4 sobre UTF-16LE), que es el verificador de contraseña almacenado. NTLMv2 es un protocolo de desafío-respuesta que usa ese hash base como entrada de un cálculo HMAC-MD5 adicional junto con datos de sesión, y requiere parámetros que van más allá de una simple contraseña de entrada.