Online Password Attacks

The Soft Target

Biometrics, hardware keys, certificates: authentication has gotten fancier. And yet, passwords still run the world. Almost every system, somewhere underneath, still accepts a secret string a human chose.

Humans choose badly.

• They pick short, memorable words
• They reuse the same one across systems
• They follow predictable patterns when forced to add complexity (Password becomes Password1!)

A password is the one part of the security stack you can’t patch. That’s exactly why it’s so often the way in.

Two Arenas

Every password attack happens in one of two places. The difference is what you’re attacking: a live service, or a stolen hash.

Online

You attack the running login directly: SSH, RDP, a web form. You throw guesses at it and watch for one that works.

• Limited speed (the service answers at its own pace)
• Noisy (every attempt is a log entry)
• Dangerous (lockout policies can lock real users out)

Offline

You’ve already got the hash. Now you attack it on your own hardware, with no one watching: massive speed, silent, no lockouts.

Offline is almost always preferable. If you can get the hash, get the hash. Online attacks are a fallback for when you can’t.

This note covers the online arena. Cracking the stolen hash is the next note.

Brute Force vs Dictionary

When you must attack a live service, the workhorse is Hydra. Two flavors of guessing:

• Brute force tries every combination of characters. Thorough, but slow enough to be impractical for anything but short passwords.
• Dictionary attack tries words from a wordlist (like the famous rockyou.txt, ~14 million leaked passwords). Far faster, and it works because real passwords are rarely random.

SSH and RDP

Point Hydra at the service with a username, a wordlist, and a target:

hydra -l jdoe -P rockyou.txt -s 2222 ssh://10.10.10.10

• -l a single username (-L for a username list)
• -P the password wordlist
• -s the port
• the protocol prefix (ssh://, rdp://) sets the attack type

Password Spraying

Flip the usual approach around. Instead of many passwords against one user, try one password against many users:

hydra -L users.txt -p 'Spring2024!' rdp://10.10.10.10

Why this works so well: if you’ve recovered even one password (from a breach dump, an earlier crack, a config file), people reuse passwords constantly. One known password often unlocks several accounts.

It’s also quieter per account: one attempt each stays under most lockout thresholds.

HTTP Login Forms

Web forms take more setup than SSH, because Hydra needs to know two things:

1. The request body (the exact POST data the form submits), captured with a proxy like Burp
2. A failure string (text that appears only on a failed login), so Hydra can tell success from failure

hydra -l admin -P rockyou.txt 10.10.10.10 
  http-post-form "/login.php:user=^USER^&pass=^PASS^:Invalid login"

The three colon-separated fields are: the form’s path, the body (with ^USER^ and ^PASS^ as injection points), and the failure string.

Keep the failure string short and specific. Avoid words like password or username that might appear elsewhere in the response and cause false positives.

The Risk: Lockouts

Online attacks are loud and dangerous. Defenses you’ll run into:

Enumerate before you spray. Locking the finance team out of production during an engagement is a great way to fail the engagement. Know the lockout policy first.

Online attacks are the loud fallback. When you can get your hands on a hash instead, you move to the quiet, unlimited arena: offline cracking, the next note.

Practice Boxes

• Hydra - Brute-force web and service logins with Hydra.
• Network Services and Network Services 2 - Enumerate and brute-force SMB, Telnet, FTP, SSH, and more.