Cerramos el Módulo 4 con la vía de acceso más transversal de todas. En 04-02 explotamos la web, en 04-03 la red y en 04-04 los sistemas; pero muchos de los footholds más fiables no vienen de un exploit sofisticado, sino de algo mucho más humano: una contraseña débil, por defecto o reutilizada. El Módulo 3 ya nos dejó pistas —credenciales y servicios débiles, un SSH que permite enumerar usuarios, un panel de administración de la tienda—. En esta lección evaluamos la autenticación de TechNova: cómo de fuertes son sus contraseñas, cómo se almacenan, y cómo un atacante intentaría romperlas.

El encuadre, una vez más y con motivo: los ataques a contraseñas pueden bloquear cuentas reales (los intentos online disparan políticas de bloqueo) y afectar a personas concretas. Por eso todo ocurre en el laboratorio autorizado de TechNova, dentro del alcance y la ventana pactada, con listas de usuarios ficticios, control del impacto (no provocar bloqueos masivos no acordados) y documentación de cada intento. Y como siempre: cada técnica ofensiva va con su contrapartida defensiva —hashing fuerte, MFA, bloqueo, monitorización—, porque el objetivo es que TechNova refuerce su autenticación, no vulnerarla por deporte.

1. Por qué la autenticación es el eslabón crítico
2. Hashing de contraseñas: por qué importa
3. Ataques offline vs. online
4. Diccionario, fuerza bruta y spraying
5. Herramientas: Hydra, John y Hashcat
6. Credenciales por defecto y reutilizadas
7. Tokens, sesiones y MFA: cómo se evalúan
8. Contrapartida defensiva
9. Errores comunes y consejos
10. Ejercicios
11. Conclusión

La autenticación es la frontera entre "cualquiera" y "usuario legítimo". Si se rompe, se accede con credenciales válidas, lo que además hace el ataque difícil de distinguir de un uso normal: no hay exploit ni payload sospechoso, solo un login correcto. Por eso las credenciales débiles son a la vez una de las vías más fáciles y más peligrosas.

Una aplicación nunca debe guardar contraseñas en claro. Debe almacenar un hash: una huella irreversible de la que no se puede recuperar la contraseña original. Pero no todos los hashes valen igual.

Código vulnerable (hashing débil):

Problemas: MD5/SHA1 son rapidísimos (una GPU prueba miles de millones por segundo) y sin sal (salt), hashes iguales para contraseñas iguales, lo que permite rainbow tables (tablas precalculadas). Si TechNova almacenara así y se filtrara la tabla users, se romperían en minutos.

Código seguro (hashing fuerte):

password_hash genera sal única automática y usa algoritmos lentos y con coste ajustable (argon2id añade además coste de memoria), lo que hace el crackeo masivo inviable. Esta es la contrapartida central de toda la lección: un hashing fuerte convierte una filtración en un problema manejable en lugar de una catástrofe.

La distinción más importante de la lección, porque cambia por completo la técnica y el impacto:

La consecuencia práctica: un ataque online es limitado y peligroso (bloquea cuentas reales), así que se hace con muchísimo cuidado y pocos intentos; un ataque offline solo es posible si ya has obtenido los hashes (por ejemplo vía la SQLi de 04-02), y ahí la única defensa real es que el hashing sea fuerte.

Tres estrategias, con impactos muy distintos:

• Diccionario: probar una lista de contraseñas probables (rockyou.txt, contraseñas filtradas). Eficaz porque la gente reutiliza contraseñas comunes.
• Fuerza bruta: probar todas las combinaciones. Inviable contra contraseñas largas; solo práctico offline y contra claves cortas.
• Password spraying: probar una contraseña común (Primavera2026!) contra muchos usuarios. Es la técnica online más sensata porque evita el bloqueo por cuenta (un intento por usuario), aunque sigue siendo detectable de forma agregada.

En el laboratorio de TechNova, un ataque online se limita a spraying muy contenido con una lista de usuarios ficticios y una o dos contraseñas, para no bloquear cuentas; el grueso del trabajo de crackeo se hace offline sobre hashes ya obtenidos legítimamente.

Cada estrategia tiene su herramienta (todas ampliadas en el Módulo 7):

Hydra — ataques online contra servicios. Uso controlado (spraying contenido):

-L toma la lista de usuarios y -p una contraseña (spraying), -t 1 limita a una conexión concurrente y -W 5 espera entre intentos: así se demuestra la debilidad sin bombardear el servicio. Un hydra a máxima velocidad contra un login real es exactamente lo que no se hace.

John the Ripper / Hashcat — crackeo offline de hashes ya obtenidos:

Aquí se ve el valor del hashing fuerte: contra MD5 (-m 0) Hashcat prueba miles de millones por segundo y rompe casi todo; contra bcrypt (-m 3200) apenas unos miles por segundo, y las contraseñas decentes no caen. La lentitud del algoritmo es, literalmente, la defensa.

A menudo no hay que "romper" nada: la credencial ya se conoce.

• Por defecto: admin/admin, root/toor, cuentas de fábrica de dispositivos y paneles. El Módulo 3 detectó servicios débiles; probar credenciales por defecto documentadas del fabricante es una comprobación de bajo impacto.
• Reutilizadas: una contraseña obtenida en un sitio (o filtrada en una brecha pública, OSINT del Módulo 2) probada en otro servicio de TechNova. La reutilización es endémica.

PoC de bajo impacto: probar una credencial por defecto conocida en el panel de administración de la tienda; si entra, se captura la evidencia (captura de la sesión) y se cierra sesión de inmediato, sin operar dentro. Demostrar el acceso basta.

Contrapartida: forzar cambio de credenciales por defecto en el despliegue, comprobar contraseñas contra listas de filtradas conocidas (have-i-been-pwned), y desplegar MFA para que una contraseña sola no baste.

La autenticación no acaba en la contraseña; el pentester evalúa toda la cadena:

• Tokens de sesión: ¿son largos y aleatorios, o predecibles? Un identificador de sesión secuencial o poco entrópico permite adivinar o secuestrar sesiones. Se evalúa capturando varios y midiendo su aleatoriedad.
• Gestión de sesión: ¿la sesión caduca?, ¿se invalida al cerrar sesión?, ¿la cookie es Secure + HttpOnly + SameSite? (enlaza con el XSS/CSRF de 04-02).
• MFA (autenticación multifactor): ¿está activo en cuentas sensibles?, ¿se puede saltar (endpoints que no lo exigen, recuperación de cuenta débil)? El MFA bien implementado es la defensa que más reduce el valor de una contraseña robada.

PoC de bajo impacto para tokens: registrar varias sesiones de un usuario de prueba y comprobar si los identificadores son predecibles; se demuestra el patrón sin secuestrar sesiones reales.

Contrapartida: identificadores de sesión largos y criptográficamente aleatorios, caducidad e invalidación correctas, cookies con todos los flags de seguridad, y MFA en cuentas privilegiadas con un flujo de recuperación robusto.

Consolidando las defensas de toda la lección —el mensaje que llevará el informe a TechNova:

• Hashing fuerte: bcrypt o argon2id con sal, nunca MD5/SHA1. Convierte una filtración de hashes en un problema acotado.
• Políticas de contraseña sensatas: priorizar longitud (frases de paso) y comprobar contra listas de filtradas, en vez de reglas de complejidad que la gente elude.
• MFA: el control con mejor retorno; neutraliza la mayoría de ataques de credenciales.
• Bloqueo y rate-limiting: frenan los ataques online (fuerza bruta y spraying). Con umbrales que no faciliten a su vez una denegación de servicio.
• Credenciales por defecto: eliminarlas en el despliegue; inventario de cuentas de servicio.
• Monitorización: alertar ante picos de logins fallidos, spraying (muchos usuarios, misma clave) y accesos desde ubicaciones anómalas.

• Lanzar fuerza bruta online a máxima velocidad. Bloquea cuentas reales (denegación de servicio no acordada) y llena los logs. Online: spraying contenido y pocos intentos; el volumen va offline.
• Crackear hashes que no obtuviste de forma autorizada. Los hashes deben venir de un acceso dentro del alcance. Trabajar sobre datos ajenos es ilegal.
• Operar dentro de una cuenta tras entrar con una credencial por defecto. Basta demostrar el acceso y salir; hurgar en la cuenta excede la PoC.
• Reportar el ataque sin la contrapartida. Cada hallazgo de credenciales debe ir con hashing fuerte, MFA y bloqueo. El valor está en el arreglo.
• Confundir "contraseña fuerte" con "sistema seguro". Si el hashing es MD5 o no hay MFA, una buena contraseña no salva la filtración. Evalúa la cadena entera.
• Bloquear a empleados reales durante el spraying. Usa listas de usuarios acordadas, un intento por cuenta y avisa al contacto técnico.
• Consejo: antes de romper nada, prueba lo obvio —credenciales por defecto y reutilizadas—. Suele ser la vía más rápida, fiable y de menor impacto.

Ejercicio 1. TechNova almacena las contraseñas de la tienda con md5($password) sin sal. Explica los dos problemas que esto supone frente a un atacante que haya obtenido la tabla users, y reescribe el almacenamiento de forma segura. ¿Por qué bcrypt/argon2 frena el ataque offline?

Ejercicio 2. Tienes que evaluar la fortaleza de las contraseñas de acceso SSH de un host de TechNova (10.10.10.15) sin bloquear cuentas de empleados. Diseña un enfoque de bajo impacto (¿online u offline?, ¿qué técnica?, ¿qué parámetros?) y justifícalo. Añade dos medidas de contrapartida.

Ejercicio 3. Entras en el panel de administración de la tienda probando una credencial por defecto del fabricante. Describe cómo lo demostrarías respetando el control de impacto, y explica por qué la MFA habría reducido el riesgo aunque la contraseña fuera débil.

Solución 1. Los dos problemas: (1) MD5 es rapidísimo, una GPU prueba miles de millones de candidatas por segundo, así que las contraseñas se crackean en masa casi al instante; (2) sin sal, contraseñas iguales producen hashes iguales, lo que permite usar rainbow tables precalculadas y romper muchas cuentas a la vez sin esfuerzo. Reescritura segura: $hash = password_hash($password, PASSWORD_ARGON2ID); y verificación con password_verify($password, $hash). bcrypt/argon2 frenan el ataque offline porque son algoritmos lentos y de coste ajustable (argon2 añade coste de memoria) con sal única por hash: reducen el ritmo de prueba de miles de millones por segundo a unos pocos miles, e impiden las rainbow tables, haciendo inviable el crackeo masivo de contraseñas decentes.

Solución 2. Enfoque: online contenido, porque no tenemos los hashes (no ha habido volcado), así que hay que probar contra el servicio SSH, pero con máximo cuidado para no bloquear cuentas. Técnica: password spraying —una contraseña común contra una lista de usuarios ficticios/acordados, un intento por cuenta— en vez de fuerza bruta por usuario (que bloquearía cuentas). Parámetros: hydra -L usuarios_lab.txt -p 'Primavera2026!' -t 1 -W 5 ssh://10.10.10.15, con una sola conexión concurrente, pausa entre intentos, dentro de la ventana pactada y avisando. Contrapartidas: (a) MFA en SSH (o claves en vez de contraseña), que anula el spraying; (b) bloqueo/rate-limiting y monitorización de logins fallidos para detectar el patrón "misma clave, muchos usuarios".

Solución 3. Demostración con control de impacto: probar una credencial por defecto documentada del fabricante; si se accede, capturar la evidencia (captura de la pantalla de administración autenticada, con la hora) y cerrar sesión de inmediato, sin crear, modificar ni borrar nada dentro del panel. La MFA habría reducido el riesgo porque, aunque la contraseña fuera débil o por defecto, el atacante necesitaría además el segundo factor (código temporal, llave) que no posee: la credencial sola no bastaría para entrar. Es el ejemplo perfecto de por qué el MFA es la contramedida con mejor retorno frente a ataques de contraseñas.

Hemos cerrado la vía de acceso más transversal: las credenciales. Sabemos ya por qué el hashing fuerte (bcrypt/argon2 frente a MD5) es la diferencia entre una filtración manejable y una catástrofe; distinguimos los ataques online (lentos, ruidosos, bloquean cuentas → spraying contenido) de los offline (rápidos, silenciosos, solo posibles con los hashes en la mano); manejamos Hydra, John y Hashcat con control de impacto; y evaluamos la cadena completa de autenticación —credenciales por defecto/reutilizadas, tokens, sesiones y MFA—, siempre con su contrapartida: hashing fuerte, MFA, bloqueo y monitorización.

Y con esto cerramos el Módulo 4. Hemos recorrido la explotación entera de forma autorizada y controlada: sentamos el marco (04-01), y luego convertimos las candidatas priorizadas del Módulo 3 en accesos reales a través de la web (04-02), la red (04-03), los sistemas (04-04) y ahora la autenticación (04-05). En cada frente aplicamos el mismo método —mecanismo, PoC de bajo impacto, remediación— y respetamos el mismo límite: la explotación termina cuando obtenemos el acceso o la ejecución. Ya tenemos uno o varios footholds en TechNova, con evidencia documentada de cada uno.

Ese es precisamente el punto de partida del Módulo 5: Post-Explotación. Ahora que tenemos el pie dentro —normalmente con privilegios limitados—, toca responder a la pregunta que de verdad mide el riesgo para TechNova: ¿hasta dónde llega realmente este compromiso? En 05-01 escalaremos privilegios desde el foothold, y después veremos cómo se mantiene el acceso, se pivota hacia otras subredes y se evalúa el alcance completo de la intrusión, siempre dentro del mismo marco ético y de control que ha guiado todo este módulo.