hashcat, hydra, and the art of credential attacks

brute force, hash cracking, and the login storms your SOC can’t ignore

Up to this point, we’ve been knocking on doors. Recon told us which doors exist. Scanning told us what’s behind them. Now we actually try the handle. Sometimes it’s locked. Sometimes someone left it open with a sticky note that says “password123.”

Credential attacks are where the exam—and real attacks—get loud. For a SOC analyst, this is often the first unambiguous “this is not normal” moment. For the attacker, it’s where you stop being a ghost.

From the attacker terminal

#

Two paths here, and CEH Practical covers both: online brute-forcing and offline hash cracking.

Online attacks mean you’re hammering a live service with login attempts. Hydra is the exam staple.

Against SSH: hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://<target>

Against FTP: hydra -l anonymous -P rockyou.txt ftp://<target>

Against a web login form (when you’ve captured the POST parameters with Burp): hydra -l admin -P rockyou.txt <target> http-post-form "/login.php:user=^USER^&pass=^PASS^:Invalid credentials"

The trick with Hydra isn’t the command; it’s knowing when to use it. Against a service with no lockout policy, a dictionary attack with rockyou.txt might take minutes and gift you a shell. Against a service that locks accounts after 5 attempts, you’ve just locked every user and failed the task. I’ve seen people (myself included) get overeager and lock themselves out. Not in the exam, thankfully, but in labs.

Offline attacks are the quieter sibling. You already have the hash—maybe from a dumped SAM file, a /etc/shadow, or a .sql backup you found during recon (remember the /backup/ directory from Post 2?). Now you crack it locally.

Hashcat on a GPU rig: hashcat -m 0 -a 0 hash.txt /usr/share/wordlists/rockyou.txt (-m 0 is MD5, common in CTF-style hashes. Adjust for SHA1, NTLM, etc.)

John the Ripper is also fair game: john --wordlist=rockyou.txt hash.txt

Offline cracking has a beautiful advantage: zero network noise. The target never sees it. If you can exfiltrate a hash quietly, you can crack it on your own machine with no alerts fired. The exam won’t make you exfiltrate—you’re already inside the lab environment—but the principle holds.

From the SOC side

#

Now, the defender’s view. Online brute-forcing is a beacon.

On Windows, every failed login generates Event ID 4625. A Hydra blast against SSH on a Linux box fills /var/log/auth.log with:

Failed password for admin from 192.168.1.100 port 22 ssh2

Multiply that by 14 million (the size of rockyou.txt) and you get a log flood.

A decent SIEM rule is:

• More than X failed logins from a single source IP in Y minutes → alert.
• Account lockout (Event ID 4740 on Windows) is even louder.
• Password spraying (one password against many users) is stealthier but still detectable with the right correlation—multiple 4625 events across different accounts from the same IP.

If the SOC has a well-tuned UEBA layer, they’ll also catch anomalies: “admin” logging in from a workstation that has never used SSH before.

Offline cracking? Silent. The SOC will never know unless they catch the hash exfiltration itself. That’s why defenders obsess over protecting credential stores: restrict access to SAM, /etc/shadow, database dumps, and backup files. Because once a hash walks out the door, the cracking is invisible. It’s just your GPU and a wordlist.

As a SOC analyst, I’ve triaged hundreds of brute-force alerts. Most are automated bots spraying default creds against internet-facing RDP. But the moment I see a burst of failures against a specific service with a targeted username like “admin” or “root”, my heartbeat picks up. That’s no bot. That’s a human with a purpose.

How this played out in the exam

#

Remember the .sql file from Post 2? Inside it were hashed passwords. I extracted the hash—looked like MD5—and fed it to hashcat with rockyou.txt. Ten seconds later: iloveyou123. I stared at it. Really? Yes, really.

I took that password and tested it against an SSH service on another target. It worked. One flag. No Hydra needed. That’s the dream scenario: offline cracking + credential reuse.

In another lab, I did run Hydra against an FTP server with a custom wordlist of 10 common passwords (in the exam, sometimes the flag is hidden behind a service that’s deliberately weak). It succeeded on the 7th attempt. Fast. No lockout.

The lesson I carried away: don’t default to full rockyou.txt brute-force unless you’re sure there’s no lockout or time isn’t a factor. Start small. Use the context you’ve gathered from recon. That .sql file was the real MVP.

The two-sides takeaway

#

Credential attacks are the loudest thing you’ll do before actual exploitation. As an attacker, you balance speed against stealth. As a defender, you pray your SIEM is tuned to catch those 4625 floods—and that your users aren’t reusing passwords that some hash dump just exposed.

If your SOC isn’t generating alerts for brute-force spikes, fix that. If you’re not rotating passwords after a database breach, fix that too. The attacker’s easiest win is a valid credential.

Next post: what exploitation actually looks like. Metasploit, shells, and the EDR alerts that follow.

Tools used

• hydra → online brute-force (generates massive login failure logs; Event ID 4625 on Windows, /var/log/auth.log on Linux)
• hashcat → GPU-accelerated hash cracking (offline, no network noise; requires hash exfiltration)
• john → alternative CPU-based cracker (same offline profile)
• rockyou.txt → common password wordlist (14 million entries; use with caution online)
• medusa → alternative to hydra (similar log footprint)
• Windows Event IDs → 4625 (failed login), 4740 (account lockout)
• Linux logs → /var/log/auth.log (SSH failures), /var/log/secure