Password Cracking with Hydra
Passwords are the oldest lock on the internet, and they are still the one most often left unlocked. Every login page is a door, and a surprising number of them are protected by nothing more than “password123” or a default that was never changed. Hydra is the tool that tests exactly that: it walks up to a login and patiently tries credentials until one works or it runs out of guesses.
In this entry of the series we cover how Hydra actually works, how to use it against the services you will most commonly meet, and, just as importantly, why understanding the attack makes you better at defending against it. The same knowledge that lets you test a client’s login for weak passwords is what lets you explain to them exactly how to make that test fail.
As always, the boundary is absolute. Everything here is for systems you own or are explicitly authorised to test. Pointing Hydra at a login you do not have permission for is not hacking, it is a crime. We will come back to that, because it matters.
Online versus offline: know which problem you have
Before touching Hydra, understand where it sits, because people confuse this constantly and it leads to using the wrong tool.
There are two worlds of password attacks. Offline cracking happens when you have already obtained password hashes (scrambled versions of passwords) and you test guesses against them on your own machine. Because there is no server involved, you can try billions of guesses per second with tools like Hashcat or John the Ripper. It is blisteringly fast, but it requires you to already have the hashes.
Online cracking is different, and it is Hydra’s world. Here you do not have any hashes. You have a live login page, and you test guesses by actually submitting them to the service, one request at a time, over the network. This is far slower, since every guess is a round trip the server has to process, and it is noisy, because the target sees every attempt. But it needs nothing except a reachable login.
Hydra is an online cracker. Keep that distinction clear: Hydra talks to a live service; Hashcat chews on hashes you already have. Reaching for the wrong one wastes a lot of time.
How Hydra thinks
Hydra’s job is simple to describe. You give it a target service, a list of usernames, and a list of passwords. It then tries combinations, sending each guess to the service and watching how the service responds, running many attempts in parallel to go as fast as the target allows. When a login succeeds, the service responds differently from a failure, and Hydra catches that difference and reports the winning credentials.
The two things that decide whether it works are entirely about the wordlists, not the tool:
- The username list. Often you already know or can enumerate usernames, from the service enumeration phase, from a company’s email format, or from common defaults like
admin. - The password list. This is everything: Hydra only tries what you give it, so the attack is only as good as the list. Nobody sensible tries every possible combination; instead you use lists of common and previously breached passwords, because those are what people actually use. The
rockyou.txtlist (millions of real passwords from an old breach, included with Kali) is the classic starting point, and SecLists collects far more targeted lists for specific technologies and default credentials.
Understand that and you understand why strong, unique passwords defeat this attack completely: if the password is not on the list, it is never tried.
Attacking SSH
SSH is the standard remote-login service on Linux systems and a common Hydra target on an authorised engagement. The syntax is straightforward once you have seen it:
hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://10.10.10.5Reading it: -l admin sets a single username to try (lowercase -l for one username; uppercase -L for a list of them). -P points at a password wordlist (uppercase for a file; lowercase -p for a single password). And ssh://10.10.10.5 tells Hydra the service and target.
Run it, and Hydra works through the list, reporting any combination that logs in successfully. If SSH allows password authentication and someone chose a weak password, this finds it. If the account uses a strong password or key-only authentication, it will grind through the whole list and find nothing, which is exactly what you want to see as a defender.
Attacking FTP
FTP works almost identically: only the service name changes.
hydra -L users.txt -P passwords.txt ftp://10.10.10.5Here -L users.txt tries every username in a file against every password. That is a much larger attack (every username times every password), so it takes longer and makes far more noise. FTP is worth testing because it still turns up on internal networks with weak or default credentials, often guarding files nobody remembered were there.
The pattern is now clear: Hydra’s structure stays the same across services, and you swap the protocol at the end. That consistency is a lot of why it is the go-to tool: learn it once, apply it everywhere.
Attacking web login forms (the tricky one)
Web forms are the most common target and the most fiddly to configure, because unlike SSH or FTP there is no standard protocol: every website’s login form is a little different. Hydra needs you to describe the form to it precisely.
You have to tell Hydra three things: the URL that receives the login, the exact format of the submitted data (with placeholders for where the username and password go), and, most important, how to tell a failed login apart from a successful one. That last part is the key. Hydra recognises failure by a string that appears on the page when login fails, such as “Invalid credentials” or “Login failed”. Anything without that string is treated as a success.
A typical command looks like this:
hydra -l admin -P rockyou.txt 10.10.10.5 \
http-post-form "/login:username=^USER^&password=^PASS^:Invalid credentials"Breaking down that last argument, which is where people get stuck:
/login: the path the form submits to.username=^USER^&password=^PASS^: the submitted data, where^USER^and^PASS^are Hydra’s placeholders for each guess.Invalid credentials: the failure string. When this text is absent from the response, Hydra concludes the login worked.
The way you find the exact path, field names, and failure string is by submitting a login yourself and watching the request in Burp Suite. Burp shows you precisely what the form sends and what the server returns on failure, and you copy those details straight into the Hydra command. The two tools work hand in hand here.
Get the failure string wrong and Hydra either reports every attempt as a success or misses the real one, so this is the part to double-check.
Reading the results, and the reality
When Hydra succeeds, it prints the working username and password plainly. That is the finding: proof that the login accepts weak credentials, which on a real engagement you document with the exact evidence.
But manage your expectations, because this is where enthusiasm meets reality. Against a well-defended target, Hydra often finds nothing, and that is not a failure of the tool: it is the defences working. Modern logins fight back:
- Rate limiting slows your guesses to a crawl.
- Account lockouts disable an account after a few wrong attempts, stopping the attack dead.
- CAPTCHAs block automated submissions entirely.
- Monitoring flags a burst of failed logins and alerts someone, possibly getting you noticed on an engagement.
So online password attacks are genuinely limited against anything competently configured. Hydra shines against weak, unprotected, or default-credentialled logins, and those still exist in abundance, especially on internal networks and forgotten services, which is exactly why it stays useful.
Tuning the attack (without breaking it)
Out of the box Hydra runs 16 parallel tasks, which is fine for a lab and often too aggressive for a real target. A few options let you match the tool to the situation.
-t sets the number of parallel tasks. Turn it down against a fragile or monitored service: a lower number is slower but gentler and far less likely to trip lockouts or alerts.
hydra -t 4 -l admin -P rockyou.txt ssh://10.10.10.5-f tells Hydra to stop the moment it finds a working login instead of grinding through the rest of the list, handy when you only need to prove that one weak credential exists. And -o results.txt writes findings to a file so you keep a clean record for your notes and your report.
Two mistakes waste the most time here. The first is using a giant wordlist against a slow online service: remember every guess is a network round trip, so a million-line list against a rate-limited login could run for days. Trim your list to the most likely passwords. The second is ignoring lockouts: fire too fast at a service that locks accounts after a few failures and you will lock out the very accounts you are testing, sometimes disrupting real users in the process. On a live engagement that is not just ineffective, it is the kind of thing that gets a test paused and a phone call started. Start slow, watch how the service reacts, and adjust from there.
Turn it around: this is a defence lesson
This next part matters more than any command: it’s the reason understanding attacks makes you a better defender. Every weakness Hydra exploits points straight at a fix.
If you run any kind of authentication, defending against exactly this attack comes down to a handful of layers, each of which breaks Hydra in a different way:
- Enforce strong, unique passwords. If the real password is not on any common or breached list, Hydra never guesses it. This is the foundation.
- Add rate limiting and lockouts. Throttle repeated attempts and lock accounts after a few failures, and online guessing becomes impractically slow.
- Require multi-factor authentication. Even a correct password is not enough on its own, since this defeats credential guessing even when a password is weak. It is the single highest-value control.
- Never leave default credentials. The
admin/adminlogin is the first thing every attacker tries. Change it, everywhere, always. - Monitor for failed-login bursts. If you can see the attack, you can respond to it.
No single one of these is a silver bullet, but stacked together they turn a login from an open door into a wall. Understanding Hydra is understanding precisely what you are defending against, which is the whole reason ethical hackers learn attacks in the first place.
The line you do not cross
I will say it once more plainly because it is the most important sentence in this guide. Only ever run Hydra against systems you own or have explicit written permission to test.
Guessing passwords against someone else’s login, whether a website, an email account, or anything else, is unauthorised access and a criminal offence in essentially every country, whether or not you succeed and whatever your intentions. There is no “just testing” defence.
The place to practise is a lab you control: your own vulnerable virtual machines, or authorised platforms like TryHackMe and Hack The Box that provide targets built for this. On a real engagement, stay strictly inside the agreed scope. The skill is valuable precisely because it is wielded responsibly.
Where it fits
Hydra sits in the exploitation stage, but it depends entirely on the phases before it. The usernames come from enumeration. The web-form details come from Burp Suite. The whole thing runs from the command line. It is one piece of a larger workflow, not a magic key.
For the offline half of the problem, Hashcat and John the Ripper are the standard tools, and on the defensive side the OWASP Password Storage Cheat Sheet sets out how credentials should be hashed in the first place. Checking your own accounts against Have I Been Pwned shows you concretely why breached-password lists work so well.
Learn it, understand what it teaches you about defence, and use it only where you are allowed. If you want to build these skills properly with hands-on labs and someone to guide you, that is exactly what our training is for. And if you are protecting your own systems and want them tested the right way, that is what our security assessments do.
