After this lesson, you will be able to: Distinguish brute force from dictionary attacks, use wordlists effectively, run Hydra against common protocols, understand online vs offline attacks and hash cracking with hashcat/John, and explain credential stuffing; demonstrate and then mitigate an attack in a lab.
This lesson covers brute force vs dictionary attacks, wordlists (rockyou.txt, SecLists, CeWL), Hydra against HTTP forms and SSH/FTP, the critical online-vs-offline distinction, hash cracking with hashcat and John the Ripper, credential stuffing, and a DVWA lab that runs Hydra then defeats it with rate limiting and lockout.
A pure brute force tries every possible combination; it is guaranteed eventually but astronomically slow against long passwords. A dictionary attack tries likely passwords from a wordlist, which is far faster because humans pick predictable passwords. The difference matters for time estimates: brute forcing an 8-character random password is infeasible, but a dictionary catches 'Summer2024!' instantly because it is in every list.
rockyou.txt is the famous list of ~14 million real passwords leaked in the 2009 RockYou breach, and it cracks a depressing fraction of weak passwords. SecLists is a curated collection of wordlists for passwords, usernames, directories, and more. CeWL spiders a target website to generate a custom wordlist from its own content, which catches company-specific and themed passwords a generic list misses. Choosing the right list is half the battle.
Hydra is the standard network login brute forcer. The HTTP form syntax needs the failure string so Hydra knows a wrong guess.
# SSHhydra -l admin -P rockyou.txt ssh://<target_ip># FTPhydra -L users.txt -P rockyou.txt ftp://<target_ip># HTTP POST form (DVWA-style): specify path, body, and the failure markerhydra -l admin -P rockyou.txt <target_ip> http-post-form \"/login.php:username=^USER^&password=^PASS^:Login failed"
Online attacks hit a live service: slow (network latency), detectable (logs, alerts), and stoppable (rate limiting, lockout). Offline attacks crack a stolen hash file on the attacker's own hardware: fast (no network, GPU-accelerated), undetectable (you are not touching the target), and only possible after a breach exposed the hashes. hashcat (GPU) and John the Ripper crack offline; a modern GPU tries billions of fast-hash guesses per second, which is why password hashes must be slow (bcrypt/Argon2) and salted. Salts defeat precomputed rainbow tables by making every hash unique.
Credential stuffing replays username/password pairs leaked from one breach against many other services, betting on password reuse. It is not guessing; it is using known-valid credentials elsewhere. Because so many people reuse passwords, a single leak compromises accounts across the web. The root cause is reuse, and the defenses are unique passwords (a manager), MFA, and breach monitoring (the Have I Been Pwned API).
Run the attack, then implement the mitigation and watch it fail.
1. Run DVWA in Docker and set a weak, common password on the login.
2. From Kali, run Hydra against the login form with rockyou.txt and watch it find the password quickly.
3. Now add rate limiting and account lockout (DVWA's higher security level, or a small proxy) in front of the login.
4. Re-run Hydra and observe it stall: requests get throttled and the account locks.
5. Conclude with the defense stack: slow salted hashing, rate limiting, lockout, MFA, and breach monitoring.
Pick the best reason.
Omitting the failure string in Hydra's http-post-form, so every attempt looks successful. Running online attacks so aggressively they lock the very account you want. Using a fast hash (SHA-256/MD5) for password storage, which makes offline cracking trivial. Forgetting salts, leaving rainbow tables viable. Conflating credential stuffing (known-valid pairs) with brute force (guessing). Testing on systems you do not own.
Sign in and purchase access to unlock this lesson.