Tanquem el Mòdul 4 amb la via d'accés més transversal de totes. A 04-02 vam explotar el web, a 04-03 la xarxa i a 04-04 els sistemes; però molts dels footholds més fiables no venen d'un exploit sofisticat, sinó d'una cosa molt més humana: una contrasenya feble, per defecte o reutilitzada. El Mòdul 3 ja ens va deixar pistes —credencials i serveis febles, un SSH que permet enumerar usuaris, un panell d'administració de la botiga—. En aquesta lliçó avaluem l'autenticació de TechNova: com de fortes són les seves contrasenyes, com s'emmagatzemen, i com un atacant intentaria trencar-les.

L'enquadrament, un cop més i amb motiu: els atacs a contrasenyes poden bloquejar comptes reals (els intents online disparen polítiques de bloqueig) i afectar persones concretes. Per això tot passa al laboratori autoritzat de TechNova, dins de l'abast i la finestra pactada, amb llistes d'usuaris ficticis, control de l'impacte (no provocar bloquejos massius no acordats) i documentació de cada intent. I com sempre: cada tècnica ofensiva va amb la seva contrapartida defensiva —hashing fort, MFA, bloqueig, monitoratge—, perquè l'objectiu és que TechNova reforci la seva autenticació, no vulnerar-la per esport.

1. Per què l'autenticació és el baula crítica
2. Hashing de contrasenyes: per què importa
3. Atacs offline vs. online
4. Diccionari, força bruta i spraying
5. Eines: Hydra, John i Hashcat
6. Credencials per defecte i reutilitzades
7. Tokens, sessions i MFA: com s'avaluen
8. Contrapartida defensiva
9. Errors comuns i consells
10. Exercicis
11. Conclusió

L'autenticació és la frontera entre "qualsevol" i "usuari legítim". Si es trenca, s'accedeix amb credencials vàlides, cosa que a més fa l'atac difícil de distingir d'un ús normal: no hi ha exploit ni payload sospitós, només un login correcte. Per això les credencials febles són alhora una de les vies més fàcils i més perilloses.

Una aplicació mai ha de desar contrasenyes en clar. Ha d'emmagatzemar un hash: una empremta irreversible de la qual no es pot recuperar la contrasenya original. Però no tots els hashes valen igual.

Codi vulnerable (hashing feble):

Problemes: MD5/SHA1 són rapidíssims (una GPU prova milers de milions per segon) i sense sal (salt), hashes iguals per a contrasenyes iguals, cosa que permet rainbow tables (taules precalculades). Si TechNova emmagatzemés així i es filtrés la taula users, es trencarien en minuts.

Codi segur (hashing fort):

password_hash genera sal única automàtica i fa servir algorismes lents i amb cost ajustable (argon2id afegeix a més cost de memòria), cosa que fa el cracking massiu inviable. Aquesta és la contrapartida central de tota la lliçó: un hashing fort converteix una filtració en un problema manejable en lloc d'una catàstrofe.

La distinció més important de la lliçó, perquè canvia per complet la tècnica i l'impacte:

La conseqüència pràctica: un atac online és limitat i perillós (bloqueja comptes reals), així que es fa amb moltíssima cura i pocs intents; un atac offline només és possible si ja has obtingut els hashes (per exemple via la SQLi de 04-02), i allà l'única defensa real és que el hashing sigui fort.

Tres estratègies, amb impactes molt diferents:

• Diccionari: provar una llista de contrasenyes probables (rockyou.txt, contrasenyes filtrades). Eficaç perquè la gent reutilitza contrasenyes comunes.
• Força bruta: provar totes les combinacions. Inviable contra contrasenyes llargues; només pràctic offline i contra claus curtes.
• Password spraying: provar una contrasenya comuna (Primavera2026!) contra molts usuaris. És la tècnica online més sensata perquè evita el bloqueig per compte (un intent per usuari), tot i que continua sent detectable de manera agregada.

Al laboratori de TechNova, un atac online es limita a spraying molt contingut amb una llista d'usuaris ficticis i una o dues contrasenyes, per no bloquejar comptes; el gruix de la feina de cracking es fa offline sobre hashes ja obtinguts legítimament.

Cada estratègia té la seva eina (totes ampliades al Mòdul 7):

Hydra — atacs online contra serveis. Ús controlat (spraying contingut):

-L pren la llista d'usuaris i -p una contrasenya (spraying), -t 1 limita a una connexió concurrent i -W 5 espera entre intents: així es demostra la debilitat sense bombardejar el servei. Un hydra a màxima velocitat contra un login real és exactament el que no es fa.

John the Ripper / Hashcat — cracking offline de hashes ja obtinguts:

Aquí es veu el valor del hashing fort: contra MD5 (-m 0) Hashcat prova milers de milions per segon i trenca gairebé tot; contra bcrypt (-m 3200) tot just uns quants milers per segon, i les contrasenyes decents no cauen. La lentitud de l'algorisme és, literalment, la defensa.

Sovint no cal "trencar" res: la credencial ja es coneix.

• Per defecte: admin/admin, root/toor, comptes de fàbrica de dispositius i panells. El Mòdul 3 va detectar serveis febles; provar credencials per defecte documentades del fabricant és una comprovació de baix impacte.
• Reutilitzades: una contrasenya obtinguda en un lloc (o filtrada en una bretxa pública, OSINT del Mòdul 2) provada en un altre servei de TechNova. La reutilització és endèmica.

PoC de baix impacte: provar una credencial per defecte coneguda al panell d'administració de la botiga; si entra, es captura l'evidència (captura de la sessió) i es tanca sessió immediatament, sense operar-hi dins. Demostrar l'accés n'hi ha prou.

Contrapartida: forçar canvi de credencials per defecte en el desplegament, comprovar contrasenyes contra llistes de filtrades conegudes (have-i-been-pwned), i desplegar MFA perquè una contrasenya sola no basti.

L'autenticació no s'acaba a la contrasenya; el pentester avalua tota la cadena:

• Tokens de sessió: són llargs i aleatoris, o predictibles? Un identificador de sessió seqüencial o poc entròpic permet endevinar o segrestar sessions. S'avalua capturant-ne diversos i mesurant-ne l'aleatorietat.
• Gestió de sessió: la sessió caduca?, s'invalida en tancar sessió?, la cookie és Secure + HttpOnly + SameSite? (enllaça amb el XSS/CSRF de 04-02).
• MFA (autenticació multifactor): està actiu en comptes sensibles?, es pot saltar (endpoints que no l'exigeixen, recuperació de compte feble)? El MFA ben implementat és la defensa que més redueix el valor d'una contrasenya robada.

PoC de baix impacte per a tokens: registrar diverses sessions d'un usuari de prova i comprovar si els identificadors són predictibles; es demostra el patró sense segrestar sessions reals.

Contrapartida: identificadors de sessió llargs i criptogràficament aleatoris, caducitat i invalidació correctes, cookies amb tots els flags de seguretat, i MFA en comptes privilegiats amb un flux de recuperació robust.

Consolidant les defenses de tota la lliçó —el missatge que portarà l'informe a TechNova:

• Hashing fort: bcrypt o argon2id amb sal, mai MD5/SHA1. Converteix una filtració de hashes en un problema acotat.
• Polítiques de contrasenya sensates: prioritzar longitud (frases de pas) i comprovar contra llistes de filtrades, en lloc de regles de complexitat que la gent eludeix.
• MFA: el control amb millor retorn; neutralitza la majoria d'atacs de credencials.
• Bloqueig i rate-limiting: frenen els atacs online (força bruta i spraying). Amb llindars que no facilitin al seu torn una denegació de servei.
• Credencials per defecte: eliminar-les en el desplegament; inventari de comptes de servei.
• Monitoratge: alertar davant pics de logins fallits, spraying (molts usuaris, mateixa clau) i accessos des d'ubicacions anòmales.

• Llançar força bruta online a màxima velocitat. Bloqueja comptes reals (denegació de servei no acordada) i omple els logs. Online: spraying contingut i pocs intents; el volum va offline.
• Crackejar hashes que no vas obtenir de manera autoritzada. Els hashes han de venir d'un accés dins de l'abast. Treballar sobre dades alienes és il·legal.
• Operar dins d'un compte després d'entrar amb una credencial per defecte. N'hi ha prou de demostrar l'accés i sortir; furgar al compte excedeix la PoC.
• Reportar l'atac sense la contrapartida. Cada troballa de credencials ha d'anar amb hashing fort, MFA i bloqueig. El valor està en l'arranjament.
• Confondre "contrasenya forta" amb "sistema segur". Si el hashing és MD5 o no hi ha MFA, una bona contrasenya no salva la filtració. Avalua la cadena sencera.
• Bloquejar empleats reals durant el spraying. Fes servir llistes d'usuaris acordades, un intent per compte i avisa el contacte tècnic.
• Consell: abans de trencar res, prova l'obvi —credencials per defecte i reutilitzades—. Sol ser la via més ràpida, fiable i de menor impacte.

Exercici 1. TechNova emmagatzema les contrasenyes de la botiga amb md5($password) sense sal. Explica els dos problemes que això suposa enfront d'un atacant que hagi obtingut la taula users, i reescriu l'emmagatzematge de manera segura. Per què bcrypt/argon2 frena l'atac offline?

Exercici 2. Has d'avaluar la fortalesa de les contrasenyes d'accés SSH d'un host de TechNova (10.10.10.15) sense bloquejar comptes d'empleats. Dissenya un enfocament de baix impacte (online o offline?, quina tècnica?, quins paràmetres?) i justifica'l. Afegeix dues mesures de contrapartida.

Exercici 3. Entres al panell d'administració de la botiga provant una credencial per defecte del fabricant. Descriu com ho demostraries respectant el control d'impacte, i explica per què la MFA hauria reduït el risc encara que la contrasenya fos feble.

Solució 1. Els dos problemes: (1) MD5 és rapidíssim, una GPU prova milers de milions de candidates per segon, així que les contrasenyes es crackegen en massa gairebé a l'instant; (2) sense sal, contrasenyes iguals produeixen hashes iguals, cosa que permet fer servir rainbow tables precalculades i trencar molts comptes alhora sense esforç. Reescriptura segura: $hash = password_hash($password, PASSWORD_ARGON2ID); i verificació amb password_verify($password, $hash). bcrypt/argon2 frenen l'atac offline perquè són algorismes lents i de cost ajustable (argon2 afegeix cost de memòria) amb sal única per hash: redueixen el ritme de prova de milers de milions per segon a uns pocs milers, i impedeixen les rainbow tables, fent inviable el cracking massiu de contrasenyes decents.

Solució 2. Enfocament: online contingut, perquè no tenim els hashes (no hi ha hagut bolcat), així que cal provar contra el servei SSH, però amb la màxima cura per no bloquejar comptes. Tècnica: password spraying —una contrasenya comuna contra una llista d'usuaris ficticis/acordats, un intent per compte— en lloc de força bruta per usuari (que bloquejaria comptes). Paràmetres: hydra -L usuarios_lab.txt -p 'Primavera2026!' -t 1 -W 5 ssh://10.10.10.15, amb una sola connexió concurrent, pausa entre intents, dins de la finestra pactada i avisant. Contrapartides: (a) MFA a SSH (o claus en lloc de contrasenya), que anul·la el spraying; (b) bloqueig/rate-limiting i monitoratge de logins fallits per detectar el patró "mateixa clau, molts usuaris".

Solució 3. Demostració amb control d'impacte: provar una credencial per defecte documentada del fabricant; si s'accedeix, capturar l'evidència (captura de la pantalla d'administració autenticada, amb l'hora) i tancar sessió immediatament, sense crear, modificar ni esborrar res dins del panell. La MFA hauria reduït el risc perquè, encara que la contrasenya fos feble o per defecte, l'atacant necessitaria a més el segon factor (codi temporal, clau) que no posseeix: la credencial sola no bastaria per entrar. És l'exemple perfecte de per què el MFA és la contramesura amb millor retorn enfront d'atacs de contrasenyes.

Hem tancat la via d'accés més transversal: les credencials. Ja sabem per què el hashing fort (bcrypt/argon2 enfront de MD5) és la diferència entre una filtració manejable i una catàstrofe; distingim els atacs online (lents, sorollosos, bloquegen comptes → spraying contingut) dels offline (ràpids, silenciosos, només possibles amb els hashes a la mà); manegem Hydra, John i Hashcat amb control d'impacte; i avaluem la cadena completa d'autenticació —credencials per defecte/reutilitzades, tokens, sessions i MFA—, sempre amb la seva contrapartida: hashing fort, MFA, bloqueig i monitoratge.

I amb això tanquem el Mòdul 4. Hem recorregut l'explotació sencera de manera autoritzada i controlada: vam assentar el marc (04-01), i després vam convertir les candidates prioritzades del Mòdul 3 en accessos reals a través del web (04-02), la xarxa (04-03), els sistemes (04-04) i ara l'autenticació (04-05). En cada front vam aplicar el mateix mètode —mecanisme, PoC de baix impacte, remediació— i vam respectar el mateix límit: l'explotació acaba quan obtenim l'accés o l'execució. Ja tenim un o diversos footholds a TechNova, amb evidència documentada de cadascun.

Aquest és precisament el punt de partida del Mòdul 5: Post-Explotació. Ara que tenim el peu dins —normalment amb privilegis limitats—, toca respondre la pregunta que de veritat mesura el risc per a TechNova: fins on arriba realment aquest compromís? A 05-01 escalarem privilegis des del foothold, i després veurem com es manté l'accés, es pivota cap a altres subxarxes i s'avalua l'abast complet de la intrusió, sempre dins del mateix marc ètic i de control que ha guiat tot aquest mòdul.