MD5, SHA1, SHA256 Hash Cracking: Complete Guide for Pentesters

El cracking de hashes es una capacidad importante en pruebas de penetración autorizadas. Ya sea que los hashes provengan de una base de datos comprometida durante el ejercicio, de credenciales capturadas en una evaluación interna o de archivos de configuración expuestos, saber evaluar su resistencia y recuperar contraseñas débiles puede ser clave para demostrar impacto real y continuar la validación del riesgo.

Pero crackear hashes no consiste simplemente en “lanzar una GPU” al problema. En entornos profesionales, el éxito depende de tres cosas: identificar correctamente el tipo de hash, elegir la estrategia adecuada y actuar dentro del alcance autorizado.

Esta guía explica cómo pensar el cracking de hashes de forma práctica: qué son los hashes, cómo reconocer formatos habituales, qué técnicas suelen funcionar mejor y cómo estructurar un workflow eficiente y defendible en un pentest.

Cuando un usuario crea una cuenta, la contraseña no debería almacenarse en texto plano. En su lugar, el sistema debería transformarla mediante una función hash criptográfica y guardar ese resultado.

Una función hash toma una entrada de longitud variable y produce una salida de longitud fija. En el caso del almacenamiento de contraseñas, la idea no es “cifrar” la contraseña para recuperarla después, sino guardar una representación verificable.

Cuando el usuario inicia sesión, el sistema aplica de nuevo el proceso sobre la contraseña introducida y compara el resultado con el hash almacenado. Si coinciden, la autenticación es válida. El sistema no necesita conocer ni almacenar la contraseña original.

Las funciones hash tienen varias propiedades que explican por qué se utilizan en autenticación.

La misma entrada siempre produce la misma salida.

Independientemente del tamaño de la entrada, el resultado tiene una longitud predecible.

Un pequeño cambio en la entrada produce una salida completamente diferente.

Dado un hash, debería ser computacionalmente inviable deducir la entrada original.

Debería ser extremadamente difícil encontrar dos entradas distintas que generen la misma salida.

En la práctica, cuando hablamos de “cracking”, normalmente no estamos revirtiendo matemáticamente el hash, sino probando candidatos hasta encontrar uno que produzca el mismo resultado.

Antes de intentar recuperar una contraseña, hay que identificar correctamente el formato. Este paso condiciona todo lo demás: la herramienta, el modo de ataque, el coste computacional y la probabilidad de éxito.

MD5

MD5 produce salidas de 128 bits, normalmente representadas como 32 caracteres hexadecimales.

Ejemplo:

5f4dcc3b5aa765d61d8327deb882cf99

Aunque está roto desde el punto de vista criptográfico y ya no debería utilizarse para proteger contraseñas, todavía aparece en sistemas legacy y bases de datos antiguas.

SHA-1

SHA-1 produce 160 bits, normalmente en 40 caracteres hexadecimales.

Ejemplo:

5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8

También se considera obsoleto para muchos usos de seguridad y sigue apareciendo en aplicaciones antiguas o migraciones incompletas.

SHA-256, SHA-384 y SHA-512

Pertenecen a la familia SHA-2. Son más robustos que MD5 o SHA-1 desde el punto de vista criptográfico general, pero eso no significa que sean ideales para almacenar contraseñas. Los hashes rápidos siguen siendo problemáticos para este caso de uso porque permiten probar muchos candidatos por segundo.

• SHA-256: 64 caracteres hexadecimales
• SHA-384: 96 caracteres hexadecimales
• SHA-512: 128 caracteres hexadecimales

NTLM

NTLM sigue siendo muy habitual en entornos Windows. Su cracking puede tener valor inmediato en evaluaciones internas porque puede facilitar movimiento lateral o validación de reutilización de credenciales, siempre dentro del alcance autorizado.

Hashes de MySQL

Algunos entornos legacy aún utilizan formatos históricos de MySQL.

• MySQL3: muy antiguo y débil
• MySQL5: suele representarse con 40 caracteres hexadecimales precedidos por *

bcrypt, scrypt y Argon2

Son algoritmos diseñados específicamente para almacenamiento de contraseñas.

No solo incorporan salt, sino que además son intencionalmente costosos de calcular. Ese coste es precisamente lo que dificulta ataques masivos.

• bcrypt suele aparecer con prefijos como $2a$, $2b$ o $2y$
• Argon2 suele empezar con $argon2
• scrypt también tiene formatos reconocibles según implementación

Estos algoritmos modernos no son “incrackeables”, pero están diseñados para elevar mucho el coste del ataque y reducir la ventaja del hardware rápido.

La identificación suele apoyarse en tres señales: longitud, formato y contexto.

A veces la longitud permite reducir opciones rápidamente:

• 32 caracteres hexadecimales: MD5, NTLM, MD4
• 40 caracteres hexadecimales: SHA-1, algunos formatos legacy de MySQL
• 64 caracteres hexadecimales: SHA-256
• 96 caracteres hexadecimales: SHA-384
• 128 caracteres hexadecimales: SHA-512

La longitud, por sí sola, no basta. Hay formatos distintos que comparten tamaño.

Muchos hashes modernos incluyen marcadores muy útiles:

• $1$ suele asociarse a MD5 crypt
• $2a$, $2b$, $2y$ suelen indicar bcrypt
• $5$ suele indicar SHA-256 crypt
• $6$ suele indicar SHA-512 crypt
• * puede indicar ciertos formatos antiguos de MySQL
• $argon2 apunta a Argon2

El sistema del que proviene el hash suele ser una pista decisiva. Un hash extraído de un entorno Windows no se interpreta igual que uno encontrado en una tabla de usuarios de una aplicación web o en un fichero de configuración de un servicio Linux.

Cuando el formato no está claro, conviene apoyarse en herramientas de identificación que sugieren candidatos posibles. Son útiles como punto de partida, pero no sustituyen la validación manual, especialmente cuando varios algoritmos comparten características similares.

En la práctica, crackear un hash suele significar probar contraseñas candidatas y compararlas con el valor objetivo. No se trata de invertir mágicamente la función hash, sino de encontrar una entrada que produzca el mismo resultado.

Por eso el éxito depende menos de “romper la criptografía” y más de factores como:

• debilidad de la contraseña;
• reutilización de patrones previsibles;
• uso o no de salt;
• rapidez del algoritmo;
• y calidad de las listas o reglas utilizadas.

El ataque de diccionario consiste en probar palabras o contraseñas de una lista predefinida.

Sigue siendo una de las técnicas más efectivas porque muchas contraseñas reales no son aleatorias: derivan de palabras comunes, nombres, temporadas, años o combinaciones simples.

• Contraseñas débiles o reutilizadas
• Entornos corporativos con patrones previsibles
• Validaciones iniciales de bajo coste

• Solo funciona si la contraseña o una variante cercana está en la lista
• Su efectividad depende mucho de la calidad del corpus usado

En la práctica, suele ser el primer enfoque razonable porque ofrece una buena relación entre coste, velocidad y probabilidad de éxito.

Los ataques con reglas toman un diccionario base y aplican transformaciones comunes: añadir números, cambiar mayúsculas, sustituir letras por símbolos o agregar sufijos frecuentes.

Esto permite cubrir variaciones típicas sin pasar directamente a combinaciones exhaustivas.

• Políticas de contraseñas predecibles
• Organizaciones donde los usuarios añaden un año, un símbolo o un número final
• Casos donde el diccionario simple ya da algunas señales positivas

• Son más costosos que el diccionario puro
• Pueden crecer muy rápido si las reglas no se ajustan bien

En un entorno profesional, las reglas suelen ser mucho más rentables cuando se adaptan al contexto del cliente, en lugar de aplicarse de forma genérica.

La fuerza bruta prueba combinaciones de caracteres de forma sistemática.

Es el enfoque más completo en teoría, pero también el más costoso. Su viabilidad depende por completo de la longitud de la contraseña, del conjunto de caracteres y del algoritmo utilizado.

• Contraseñas muy cortas
• Conjunto de caracteres reducido o conocido
• Casos muy delimitados donde el coste es asumible

• Escala muy mal
• Se vuelve rápidamente inviable con contraseñas largas o algoritmos modernos

Por eso, en pentesting, la fuerza bruta rara vez debería ser la primera opción. Es una técnica de cierre, no de arranque.

Las rainbow tables son tablas precomputadas que relacionan contraseñas con hashes.

Fueron más relevantes en sistemas antiguos o sin salt, pero su utilidad práctica cae drásticamente cuando el almacenamiento moderno incorpora salt único por contraseña.

• Sistemas muy antiguos
• Hashes rápidos sin salt
• Entornos legacy mal diseñados

• Requieren mucho almacenamiento
• Pierden utilidad frente a hashes con salt
• Hoy tienen menos protagonismo que antes en muchos escenarios reales

Existen servicios que consultan grandes repositorios de hashes ya asociados a contraseñas conocidas o filtradas previamente.

Su valor está en la velocidad: permiten comprobar si un hash corresponde a una contraseña ya expuesta públicamente.

• Triage inicial
• Contraseñas comunes
• Validaciones rápidas de impacto

• Solo sirven si el hash ya ha sido resuelto anteriormente o deriva de datos conocidos
• No sustituyen el análisis local
• Deben usarse con criterio, respetando siempre políticas legales, contractuales y de confidencialidad

Es una de las herramientas más conocidas para recuperación de contraseñas y destaca por su rendimiento, especialmente cuando se apoya en GPU.

Su valor no está solo en la velocidad, sino también en la flexibilidad: permite trabajar con múltiples formatos, reglas, máscaras y estrategias adaptadas a cada caso.

Sigue siendo una referencia clásica. Es muy apreciado por su versatilidad, por el soporte de muchos formatos y por su utilidad en workflows mixtos de identificación, preparación y cracking.

Además de los crackers, las herramientas de identificación de formato y normalización de hashes son importantes para evitar errores tempranos.

Uno de los conceptos más importantes en almacenamiento de contraseñas es el salt.

Un salt es un valor adicional, normalmente aleatorio y único por contraseña, que se incorpora antes del proceso de hashing. Su objetivo es evitar que dos usuarios con la misma contraseña tengan el mismo hash y dificultar ataques masivos basados en tablas precomputadas o comparaciones directas.

Sin salt, dos contraseñas idénticas producen el mismo resultado. Con salt, ese patrón desaparece.

Esto complica enormemente ciertos enfoques y obliga a realizar cálculos específicos para cada hash objetivo.

Por eso, cuando una aplicación utiliza correctamente salt junto con algoritmos de hashing lentos y diseñados para contraseñas, el coste del cracking sube de forma muy significativa.

Los equipos más efectivos no empiezan por la técnica más agresiva, sino por la más rentable.

Antes de cualquier intento, clasifica correctamente el tipo de hash y separa los valores por algoritmo.

Comienza con enfoques de bajo coste y alta probabilidad, como listas comunes o validaciones sobre contraseñas ampliamente reutilizadas.

Ajusta transformaciones según idioma, política corporativa, estacionalidad, nombres de marca o patrones observados durante el ejercicio.

Pasa a métodos más costosos únicamente cuando exista una razón clara para hacerlo y cuando el valor esperado compense el esfuerzo.

No basta con decir que “se crackearon hashes”. Hay que explicar qué proporción fue recuperable, qué debilidad representa eso y cómo afecta al riesgo del cliente.

Desde el punto de vista del reporte, recuperar una contraseña no es el final del trabajo. Lo importante es qué demuestra.

Una buena evidencia conecta el resultado con preguntas como:

• ¿la contraseña era trivial o predecible?
• ¿hay reutilización entre cuentas o sistemas?
• ¿se incumple la política interna?
• ¿la protección del almacenamiento era inadecuada?
• ¿la recuperación permite demostrar un impacto adicional autorizado?

Ese contexto transforma una recuperación técnica en un hallazgo útil para el cliente.

El cracking de hashes solo debe realizarse en sistemas y datos incluidos explícitamente en el alcance del engagement.

También exige controles claros sobre:

• manejo de credenciales recuperadas;
• minimización de exposición innecesaria;
• protección de evidencia sensible;
• y documentación responsable de resultados.

La capacidad técnica no sustituye la autorización. En un pentest profesional, el objetivo es demostrar riesgo de forma controlada, no maximizar acceso sin necesidad.

El cracking de hashes no es simplemente una cuestión de potencia computacional. Es, sobre todo, una cuestión de priorización y criterio.

Los mejores resultados suelen venir de este enfoque:

• identificar bien el tipo de hash;
• empezar por métodos de bajo coste y alta probabilidad;
• adaptar reglas al contexto real del objetivo;
• y escalar solo cuando el valor de la evidencia lo justifique.

En un pentest bien ejecutado, el objetivo no es crackear por crackear, sino demostrar debilidades reales en el almacenamiento de credenciales y convertirlas en evidencia clara, responsable y accionable.