How to Use Hydra: Online Password Attacks (2026 Guide)

What Is Hydra?

Hydra is an open source login cracker that attacks network services by submitting username and password guesses to them in parallel. It was written by van Hauser of THC, is licensed under AGPLv3, and supports more than fifty protocols including SSH, FTP, SMB, RDP, MySQL, PostgreSQL, LDAP, SMTP, POP3, IMAP, VNC, SNMP and HTTP forms.

You will see it called THC Hydra, hydra, or occasionally xhydra when someone means the GTK front end. They are all the same project, hosted at vanhauser-thc/thc-hydra on GitHub.

Here is the split that trips up almost everyone starting out.

Online attacks talk to a live service. Hydra opens a connection, sends a guess, waits for the server to say yes or no, and tries again. Speed is capped by the network and by whatever the server allows. You are limited to hundreds or a few thousand guesses per minute, and the target's logs fill up with every one of them.

Offline attacks work on a hash you already recovered. No network, no rate limit, no logs. A single consumer GPU chews through billions of NTLM guesses per second. This is what hashcat and John the Ripper are for.

So the rule is simple: if you have a hash, you do not want Hydra. Hydra is for the moment before that, when all you have is a port, a service banner and a hunch about the username.

Installing Hydra and Seeing What It Can Attack

On Kali Linux it is already there. If it is not, or you are on Debian or Ubuntu:

sudo apt update
sudo apt install hydra

Kali currently packages version 9.7, which added GTK3 support for the graphical front end and a MongoDB v2 module. The GUI lives in a separate package, hydra-gtk, and you can safely ignore it. Nobody who uses Hydra regularly uses xhydra.

If you would rather not install anything, upstream publishes a container:

docker pull vanhauser/hydra

Three companion binaries come along with the package and two of them are genuinely useful:

• pw-inspector filters a wordlist down to passwords that match a target's policy. If the app demands 8 characters with a digit, there is no point sending it "cat".
• dpl4hydra builds a default password list for a given vendor, pulled from a bundled database of shipped credentials. Run dpl4hydra cisco and you get a login:pass file ready for -C.
• hydra-wizard walks you through building a command interactively. Fine for your first hour, a crutch after that.

Before your first real command, check what modules your build actually has. Compiled-in support varies by distribution:

hydra -h

The bottom of the help output lists every supported service. If rdp or ssh is missing, your package was built without the relevant library and no amount of correct syntax will help.

The Hydra Syntax You Actually Need

Hydra has around thirty command line options and you will reach for a handful of them. Every command follows one shape:

hydra [login options] [password options] [tuning] TARGET SERVICE

Target and service always come last, in that order. Get that wrong and Hydra will tell you it does not know a service called 192.0.2.10.

The options that matter:

• -l USER a single username. -L users.txt a file of them.
• -p PASS a single password. -P passwords.txt a file of them.
• -C creds.txt a file of login:pass pairs, tried as pairs rather than as a full cross product. This is what you use with credentials from a breach dump or from dpl4hydra.
• -t N parallel connections. Default is 16.
• -f stop as soon as one valid pair is found. Almost always what you want.
• -V print every attempt. Use it once to confirm the attack is shaped correctly, then turn it off.
• -s PORT when the service is not on its default port.
• -o results.txt write hits to a file, with -b json if something downstream needs to parse them.

There are two equivalent ways to name the target, and mixing them up is the most common beginner error:

hydra -l dana -P rockyou.txt 192.0.2.10 ssh
hydra -l dana -P rockyou.txt ssh://192.0.2.10

Both run the same attack. The URL form is tidier when you start adding module options, because everything stays in one string.

One flag punches above its weight: -e nsr. It adds three extra guesses per username, on top of your wordlist. n tries an empty password, s tries the username as the password, and r tries the username reversed. On internal networks the "s" check alone finds service accounts more often than any wordlist does.

How to Use Hydra Against SSH: Your First Attack

SSH is the classic starting point because the feedback is unambiguous. The service either authenticates you or it does not, with no redirects or error pages to interpret.

hydra -l dana -P /usr/share/wordlists/rockyou.txt 192.0.2.10 ssh -t 4 -f

Real output, trimmed to the lines that matter:

Hydra v9.7 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in
military or secret service organizations, or for illegal purposes [...]

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2026-09-05 11:04:31
[DATA] max 4 tasks per 1 server, overall 4 tasks, 14344392 login tries (l:1/p:14344392), ~3586098 tries per task
[DATA] attacking ssh://192.0.2.10:22/
[22][ssh] host: 192.0.2.10   login: dana   password: sunshine1
1 of 1 target successfully completed, 1 valid password found

The line beginning [22][ssh] is the hit: port, service, host, username, password. Everything above it is bookkeeping.

Read the [DATA] line before you walk away, because it is telling you how long this will take. 14,344,392 password tries across 4 tasks is roughly 3.6 million attempts per task. At a realistic SSH rate of a few hundred guesses per minute, the full rockyou.txt wordlist would run for months. That number is not a reason to panic. It is a reason to understand that online brute force finds weak passwords near the top of a sorted list, or it finds nothing.

Why -t 4 and Not the Default 16

Drop the -t 4 and Hydra will scold you:

[WARNING] Many SSH configurations limit the number of parallel tasks, it is
recommended to reduce the tasks: use -t 4

That warning fires whenever -t is above 8 on an SSH target, and it is not superstition. OpenSSH ships with MaxStartups 10:30:100, which starts randomly dropping unauthenticated connections once ten are in flight and refuses all of them at a hundred. MaxAuthTries defaults to 6, so the server also closes the session after six failures. Hammer it with 16 tasks and a large share of your guesses are discarded before they are ever checked, which produces the worst possible result: a slow attack that reports no valid password even though one exists in your list.

In practice, four tasks against SSH and sixteen against a plain HTTP form is a sensible default pair. Turn -t down further, not up, when results look inconsistent between runs.

Attacking a Web Login Form with http-post-form

This is where most people give up on Hydra, and it is worth pushing through, because web forms are what you will actually meet in a CTF.

The problem is that HTTP has no concept of a failed login. The server answers 200 OK whether you guessed right or wrong. So you have to tell Hydra how to tell the difference, and that is what the third field of the module string is for.

The syntax has three colon-separated parts:

hydra -l admin -P passwords.txt 192.0.2.20 http-post-form \
  "/login.php:user=^USER^&pass=^PASS^:incorrect"

1. The path. /login.php, the page the form posts to. Not the page the form is displayed on, if they differ.
2. The POST body. Copy it verbatim from your browser's network tab or from Burp, then replace the username value with ^USER^ and the password value with ^PASS^. Keep every other field, including hidden ones. A CSRF token you dropped is the reason your attack returns nothing.
3. The failure string. Text that appears in the response when a login fails. Hydra treats "this string is present" as failure and its absence as success.

You can invert that last field. Prefix it with S= to match on success instead, which is more reliable when the app redirects on a good login:

hydra -l admin -P passwords.txt 192.0.2.20 http-post-form \
  "/login.php:user=^USER^&pass=^PASS^:S=302"

You get one or the other, never both. F= is the explicit form of the default failure check, and S= replaces it.

When an attack reports that every password in your list worked, the failure string is wrong. That is the single most common mistake with this module, and the module's own help says so in as many words. Run hydra -U http-post-form to read it, and add -d to dump the requests and responses Hydra is actually exchanging.

Three Details That Save an Hour

• Escape colons inside the string. Colons separate the fields, so a colon inside a header or a value has to be written \:. Custom headers look like H=Cookie\: sessid=aaaa.
• Base64 encoded fields exist. If the form encodes credentials, use ^USER64^ and ^PASS64^ and Hydra handles the encoding for you.
• Cookies are gathered automatically. The module fetches the login page first to pick up a session cookie, and follows up to five redirects. Use C=/some/page to gather the cookie somewhere else, or G= to skip that pre-request when the app does not need one.

For HTTPS, swap the module name to https-post-form. Everything else stays identical.

Wordlists, Speed, and Knowing When to Stop

Your wordlist decides the outcome far more than your flags do. Feeding a 14 million line list into an online attack is a beginner move that looks thorough and accomplishes nothing.

Two approaches beat it, and both come down to sending fewer, better guesses.

Trim the list to the target's password policy. If registration rejects anything under 8 characters, every shorter candidate is wasted traffic:

pw-inspector -i rockyou.txt -o filtered.txt -m 8 -n

That keeps only passwords of at least 8 characters containing a number. Run wc -l on both files afterwards to see how much traffic you just avoided sending.

Spray instead of brute forcing. By default Hydra tries every password against one username before moving on, which is exactly the pattern that trips account lockout. The -u flag loops the other way, trying one password against every username first:

hydra -L users.txt -p 'Autumn2026!' -u 192.0.2.10 smb -t 1 -W 30

One password per user per pass, one task, thirty seconds between attempts. Against an Active Directory domain with a five-attempt lockout, this is the difference between finding an account and locking out the entire company. -W sets that delay between connections and only makes sense at low task counts.

Two more things worth knowing before you run anything long. Hydra writes a hydra.restore file every five minutes, so a session killed by Ctrl-C can be resumed with hydra -R. That file cannot be moved between platforms. And -M targets.txt attacks a whole list of hosts in one run, with -F to stop the moment any host gives up a credential.

When Hydra Is the Wrong Tool

Honest assessment: Hydra fails against most internet-facing applications built in the last decade, and you should know that going in rather than discovering it after an afternoon of no results.

Rate limiting, account lockout, CAPTCHA, MFA and WAF rules all defeat it, and any of them can be in place without being visible from the outside. Verizon's 2026 Data Breach Investigations Report found that 31% of breaches now start with software vulnerabilities, which beat stolen passwords as the top way attackers get in. Guessing at the front door is no longer where the industry finds most of its access.

Reach for something else when:

• You already have hashes. Crack them offline. Orders of magnitude faster, and completely silent.
• The target is a public login page. Look for the credentials somewhere else first: an exposed .git directory, a config file in a public bucket, a developer's paste. Search almost always beats guessing.
• There is an SMB or LDAP service on an internal network. Tools built for those protocols validate credentials across a whole subnet in one command and handle lockout policy properly.
• You have not enumerated yet. A username list assembled from real reconnaissance beats a generic one by a wide margin. Find the services first with the techniques in our Nmap cheat sheet, then decide what deserves an attack.

Where Hydra still earns its place is legacy and internal infrastructure: the FTP server on a manufacturing VLAN, the printer web interface, the switch that never had its default credentials changed, the CTF box built to be brute forced. On those, it is fast, reliable, and often the shortest path to a foothold.

Legal and Ethical Considerations

Hydra is unusually easy to misuse, so a few practical boundaries:

• Test only systems named in a signed scope document, or lab environments you built yourself
• Account lockout is a real denial of service. Understand the target's policy before you send a single guess, and say so in writing if you are unsure
• Credentials you recover belong in the report, encrypted, and nowhere else. Never reuse them outside the engagement window
• Password spraying a production directory during business hours can lock out staff and stop a company working. Agree the timing with the client
• CTF platforms and deliberately vulnerable machines are unlimited practice. Use them

The Hydra banner itself asks you not to use it for illegal purposes and calls that request non-binding. Treat the law as the binding part.

Frequently Asked Questions