hydra
Brute-forces network logins: SSH, FTP, RDP, databases, and web forms. The standard way to prove weak or default credentials, with permission.
Authorized use only. Run these only on systems you own or have explicit written permission to test. Full notice at the foot of the page.
01Online versus offline cracking
There are two kinds of password attack, and hydra is one of them. Offline cracking (john, hashcat) works on captured hashes, as fast as your hardware allows. Online cracking, which is hydra, tries passwords against a live service, one login attempt at a time, over the network. It is far slower and far noisier, because every guess is a real connection the server sees and logs. You use hydra to prove that a reachable service accepts a weak or default credential, which is a different and very common finding.
02Install
$ sudo emerge net-analyzer/hydra # Gentoo
$ sudo apt install hydra # Debian / Ubuntu / Kali
$ sudo dnf install hydra # Fedora / RHEL
03A single service
The shape is always the same: a username source, a password source, and a target service. -l is one username, -L a file of them; -p is one password, -P a file. The service and host come last. SSH is the classic example.
$ hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://10.0.0.1
04Users and passwords together
Point -L and -P at files to try many usernames against many passwords. Watch the arithmetic: a thousand users by a million passwords is a billion attempts, which online is effectively forever and will hammer the service. Keep lists small and targeted; online attacks reward a short list of likely credentials, not a giant one.
$ hydra -L users.txt -P passwords.txt ssh://10.0.0.1 -t 4
$ hydra -C combined.txt ssh://10.0.0.1
» -C takes a file of user:password pairs, for trying known default-credential combos. -t sets parallel tasks; lower it on fragile services.
05The many protocols
hydra speaks dozens of protocols; the service name in the target is how you pick. The approach is identical across them, only the module changes.
$ hydra -l admin -P pw.txt ftp://10.0.0.1
$ hydra -l admin -P pw.txt rdp://10.0.0.1
$ hydra -L users.txt -P pw.txt 10.0.0.1 mysql
$ hydra -l admin -P pw.txt 10.0.0.1 smb
06Web login forms
Web forms are the fiddliest target because hydra has to know the form's fields and how the app signals failure. You give it the path, the POST body with ^USER^ and ^PASS^ markers, and a string that appears on a failed login. Capture the real request in a proxy first to get the fields exactly right.
$ hydra -l admin -P rockyou.txt 10.0.0.12 http-post-form \ '/login:username=^USER^&password=^PASS^:Invalid credentials'
07Making online attacks work at all
» Small, smart lists beat big ones online; try default and common passwords and known-breached ones first.
» -t controls parallelism; too high trips lockouts and rate limits, too low is slow. 4 to 16 is typical.
» -f stops at the first valid pair, which is usually what you want.
» Account lockout policies will stop you cold, and that is the service defending itself correctly.
08Making online attacks fail
Everything that makes hydra slow is a defence you can strengthen. Online brute force is one of the most defendable attacks, because the server controls the terms of every attempt.
» Account lockout or exponential backoff after a few failures turns a million-guess attack into a non-starter.
» Rate-limit authentication at the service or a reverse proxy; fail2ban banning an IP after N failures is a classic, effective control.
» Multi-factor authentication defeats password guessing entirely; a correct password alone is not enough.
» Do not expose SSH, RDP, and databases to the whole internet; put them behind a VPN so hydra cannot reach them.
» Kill default credentials; most successful online attacks are just an unchanged admin/admin.
» Run hydra against your own service with a small list and watch your logs and lockout behaviour. If it gets more than a handful of tries before being stopped, your rate-limiting needs work.
Authorized use only
The tools and techniques in these guides are for defending, testing, and understanding systems you own or have explicit written permission to assess. Unauthorized access to computers, networks, accounts, or data is a criminal offense in nearly every jurisdiction, and the penalties are real.
A few of the laws that apply, by way of example:
- Philippines: Cybercrime Prevention Act of 2012 (Republic Act No. 10175)
- United States: Computer Fraud and Abuse Act (18 U.S.C. § 1030)
- United Kingdom: Computer Misuse Act 1990
- European Union: Directive 2013/40/EU on attacks against information systems, as implemented by each member state
- Most other countries have equivalent computer-misuse laws
Wherever you are, the rule is the same: get authorization in writing, stay within the agreed scope, and never touch a system that is not yours to test. If you are unsure whether something is permitted, treat it as not permitted until you have clear authorization.
This is general information, not legal advice.