We close Module 4 with the most cross-cutting access path of them all. In 04-02 we exploited the web, in 04-03 the network, and in 04-04 the systems; but many of the most reliable footholds don't come from a sophisticated exploit, but from something far more human: a weak, default, or reused password. Module 3 already gave us leads, weak credentials and services, an SSH that allows user enumeration, an admin panel on the store. In this lesson we evaluate TechNova's authentication: how strong its passwords are, how they're stored, and how an attacker would try to break them.

The framing, once again and for good reason: password attacks can lock out real accounts (online attempts trip lockout policies) and affect specific people. That's why everything happens in TechNova's authorized lab, within scope and the agreed window, with lists of fictitious users, impact control (no unagreed mass lockouts), and every attempt documented. And as always: each offensive technique comes with its defensive counterpart, strong hashing, MFA, lockout, monitoring, because the goal is for TechNova to strengthen its authentication, not to breach it for sport.

1. Why authentication is the critical link
2. Password hashing: why it matters
3. Offline vs. online attacks
4. Dictionary, brute force, and spraying
5. Tools: Hydra, John, and Hashcat
6. Default and reused credentials
7. Tokens, sessions, and MFA: how they're evaluated
8. Defensive counterpart
9. Common mistakes and tips
10. Exercises
11. Conclusion

Authentication is the boundary between "anyone" and "legitimate user." If it's broken, access happens with valid credentials, which also makes the attack hard to distinguish from normal use: there's no exploit or suspicious payload, just a correct login. That's why weak credentials are at once one of the easiest and most dangerous paths.

An application must never store passwords in cleartext. It must store a hash: an irreversible fingerprint from which the original password can't be recovered. But not all hashes are equal.

Vulnerable code (weak hashing):

Problems: MD5/SHA1 are blazing fast (a GPU tries billions per second) and unsalted, identical hashes for identical passwords, which enables rainbow tables (precomputed tables). If TechNova stored passwords this way and the users table leaked, they'd be cracked in minutes.

Secure code (strong hashing):

password_hash generates a unique automatic salt and uses slow, cost-adjustable algorithms (argon2id also adds a memory cost), which makes mass cracking infeasible. This is the central counterpart of the whole lesson: strong hashing turns a leak into a manageable problem instead of a catastrophe.

The most important distinction of the lesson, because it completely changes the technique and the impact:

The practical consequence: an online attack is limited and dangerous (it locks out real accounts), so it's done with great care and few attempts; an offline attack is only possible if you've already obtained the hashes (for example via the SQLi from 04-02), and there the only real defense is that the hashing is strong.

Three strategies, with very different impacts:

• Dictionary: try a list of likely passwords (rockyou.txt, leaked passwords). Effective because people reuse common passwords.
• Brute force: try every combination. Infeasible against long passwords; only practical offline and against short keys.
• Password spraying: try one common password (Primavera2026!) against many users. It's the most sensible online technique because it avoids per-account lockout (one attempt per user), though it's still detectable in aggregate.

In TechNova's lab, an online attack is limited to very contained spraying with a list of fictitious users and one or two passwords, so as not to lock out accounts; the bulk of the cracking work is done offline against hashes already obtained legitimately.

Each strategy has its tool (all expanded in Module 7):

Hydra — online attacks against services. Controlled use (contained spraying):

-L takes the user list and -p one password (spraying), -t 1 limits it to one concurrent connection, and -W 5 waits between attempts: this demonstrates the weakness without bombarding the service. A hydra at full speed against a real login is exactly what you don't do.

John the Ripper / Hashcat — offline cracking of already-obtained hashes:

Here you see the value of strong hashing: against MD5 (-m 0) Hashcat tries billions per second and cracks almost everything; against bcrypt (-m 3200) barely a few thousand per second, and decent passwords don't fall. The algorithm's slowness is, literally, the defense.

Often there's nothing to "break": the credential is already known.

• Default: admin/admin, root/toor, factory accounts on devices and panels. Module 3 detected weak services; trying vendor-documented default credentials is a low-impact check.
• Reused: a password obtained on one site (or leaked in a public breach, Module 2 OSINT) tried against another TechNova service. Reuse is endemic.

Low-impact PoC: try one known default credential on the store's admin panel; if it works, capture the evidence (a screenshot of the session) and log out immediately, without operating inside. Demonstrating access is enough.

Counterpart: enforce changing default credentials at deployment, check passwords against known-leak lists (have-i-been-pwned), and deploy MFA so that a password alone isn't enough.

Authentication doesn't end at the password; the pentester evaluates the whole chain:

• Session tokens: are they long and random, or predictable? A sequential or low-entropy session identifier allows guessing or hijacking sessions. It's evaluated by capturing several and measuring their randomness.
• Session management: does the session expire? Is it invalidated on logout? Is the cookie Secure + HttpOnly + SameSite? (this links to the XSS/CSRF from 04-02).
• MFA (multi-factor authentication): is it active on sensitive accounts? Can it be bypassed (endpoints that don't require it, weak account recovery)? Well-implemented MFA is the defense that most reduces the value of a stolen password.

Low-impact PoC for tokens: register several sessions of a test user and check whether the identifiers are predictable; the pattern is demonstrated without hijacking real sessions.

Counterpart: long, cryptographically random session identifiers, correct expiration and invalidation, cookies with all the security flags, and MFA on privileged accounts with a robust recovery flow.

Consolidating the defenses from the whole lesson, the message the report will carry to TechNova:

• Strong hashing: bcrypt or argon2id with salt, never MD5/SHA1. Turns a hash leak into a bounded problem.
• Sensible password policies: prioritize length (passphrases) and check against leak lists, instead of complexity rules that people work around.
• MFA: the highest-return control; it neutralizes most credential attacks.
• Lockout and rate-limiting: they brake online attacks (brute force and spraying). With thresholds that don't in turn enable a denial of service.
• Default credentials: eliminate them at deployment; inventory service accounts.
• Monitoring: alert on spikes of failed logins, spraying (many users, same key), and access from anomalous locations.

• Running online brute force at full speed. It locks out real accounts (an unagreed denial of service) and floods the logs. Online: contained spraying and few attempts; the volume goes offline.
• Cracking hashes you didn't obtain in an authorized way. The hashes must come from access within scope. Working on other people's data is illegal.
• Operating inside an account after entering with a default credential. Demonstrating access and leaving is enough; poking around the account exceeds the PoC.
• Reporting the attack without the counterpart. Every credential finding must come with strong hashing, MFA, and lockout. The value is in the fix.
• Confusing "strong password" with "secure system." If the hashing is MD5 or there's no MFA, a good password doesn't save the leak. Evaluate the whole chain.
• Locking out real employees during spraying. Use agreed user lists, one attempt per account, and warn the technical contact.
• Tip: before breaking anything, try the obvious, default and reused credentials. It's usually the fastest, most reliable, lowest-impact path.

Exercise 1. TechNova stores the store's passwords with md5($password), unsalted. Explain the two problems this poses against an attacker who has obtained the users table, and rewrite the storage securely. Why do bcrypt/argon2 brake the offline attack?

Exercise 2. You have to evaluate the strength of the SSH login passwords on a TechNova host (10.10.10.15) without locking out employee accounts. Design a low-impact approach (online or offline? which technique? which parameters?) and justify it. Add two counterpart measures.

Exercise 3. You get into the store's admin panel by trying a vendor default credential. Describe how you would demonstrate it while respecting impact control, and explain why MFA would have reduced the risk even if the password were weak.

Solution 1. The two problems: (1) MD5 is blazing fast, a GPU tries billions of candidates per second, so passwords are cracked en masse almost instantly; (2) unsalted, identical passwords produce identical hashes, which allows using precomputed rainbow tables and breaking many accounts at once effortlessly. Secure rewrite: $hash = password_hash($password, PASSWORD_ARGON2ID); and verification with password_verify($password, $hash). bcrypt/argon2 brake the offline attack because they're slow, cost-adjustable algorithms (argon2 also adds a memory cost) with a unique salt per hash: they cut the trial rate from billions per second to a few thousand, and prevent rainbow tables, making mass cracking of decent passwords infeasible.

Solution 2. Approach: contained online, because we don't have the hashes (there's been no dump), so we have to test against the SSH service, but with maximum care not to lock out accounts. Technique: password spraying, one common password against a list of fictitious/agreed users, one attempt per account, instead of per-user brute force (which would lock out accounts). Parameters: hydra -L usuarios_lab.txt -p 'Primavera2026!' -t 1 -W 5 ssh://10.10.10.15, with a single concurrent connection, a pause between attempts, within the agreed window and with notice given. Counterparts: (a) MFA on SSH (or keys instead of passwords), which nullifies spraying; (b) lockout/rate-limiting and monitoring of failed logins to detect the "same key, many users" pattern.

Solution 3. Demonstration with impact control: try one vendor-documented default credential; if access is gained, capture the evidence (a screenshot of the authenticated admin screen, with the timestamp) and log out immediately, without creating, modifying, or deleting anything in the panel. MFA would have reduced the risk because, even if the password were weak or default, the attacker would also need the second factor (a time-based code, a key) that they don't possess: the credential alone wouldn't be enough to get in. It's the perfect example of why MFA is the highest-return countermeasure against password attacks.

We've closed the most cross-cutting access path: credentials. We now know why strong hashing (bcrypt/argon2 vs. MD5) is the difference between a manageable leak and a catastrophe; we distinguish online attacks (slow, noisy, they lock out accounts → contained spraying) from offline ones (fast, silent, only possible with the hashes in hand); we handle Hydra, John, and Hashcat with impact control; and we evaluate the complete authentication chain, default/reused credentials, tokens, sessions, and MFA, always with its counterpart: strong hashing, MFA, lockout, and monitoring.

And with this we close Module 4. We've walked through the entire exploitation in an authorized, controlled way: we laid the framework (04-01), and then turned Module 3's prioritized candidates into real access through the web (04-02), the network (04-03), the systems (04-04), and now authentication (04-05). On every front we applied the same method, mechanism, low-impact PoC, remediation, and we respected the same limit: exploitation ends when we obtain access or execution. We now have one or several footholds in TechNova, with documented evidence of each.

That's precisely the starting point of Module 5: Post-Exploitation. Now that we have a foot inside, usually with limited privileges, it's time to answer the question that truly measures the risk to TechNova: how far does this compromise really reach? In 05-01 we'll escalate privileges from the foothold, and then we'll see how access is maintained, how you pivot toward other subnets, and how the full extent of the intrusion is assessed, always within the same ethical and control framework that has guided this entire module.