Hydra can be used to attack many different services including IMAP, SMB, HTTP, VNC, MS-SQL MySQL, SMTP, SSH, and many more.
(Hydra is to online-cracking of passwords, what John The Ripper is to offline-cracking of password hashes)
Often, web-based login forms authenticate using the HTTP POST method, but judging from several blogs I have read on this subject, it sounds like some people have great difficulty in getting Hydra to work effectively in this situation.
I have had a great deal of success with hydra, so here I describe how to get Hydra working with web-based form logins.
This attack is not limited to websites, and I would argue that it is more suited for gaining login access to software products that have a web UI, for example in penetration tests.
This tool should not be used to attack websites or services where you do not have permission to do so. Use this for legitimate testing purposes only.
Some differences between online and off-line password cracking
There are significant differences between online and off-line password cracking.
With off-line cracking, you have the hashes on your system, they are static, and you can try dictionary, hybrid, and brute force attacks to you hearts content. You have as long as you want, and you can try many billions of attempts in a short space of time.
The attack success is purely dependent on password strength, verses processor-power and time (and few user-chosen passwords will be strong enough to last).
With online password attacks there are more issues to consider, such as; network bandwidth, account lockouts, tar-pitting, changing passwords, detection in logs and IDS.
Online attacks are more suited to relatively small and focused dictionary attacks rather than exhaustive brute-force.
A simple Hydra SSH example
Here is a simple example of running a Hydra attack against an SSH server.
hydra 192.168.1.26 ssh2 -s 22 -P pass.txt -L users.txt -e ns -t 10
This will attack the system 188.8.131.52.26, on port 22 with the SSH protocol, 10 threads at a time, and try all the combinations of usernames and passwords supplied in the files user.txt and pass.txt (+ empty passwords and passwords the same as the username)
This can take a while, so it is best to only use usernames you know exist, and a relatively small list of passwords (many thousands rather than many millions). This attack generally works very well for simple dictionary passwords.
Web-based login forms prerequisites
For web-based forms, you have to know much more information about the form you are attacking before you start the attack. Every web-based form is slightly different, different URLs and parameters, and different responses for success or failure.
You need to know:
- The hostname/IP and URL
- Whether it is a HTTPS or HTTP service
- Whether the form supports GET or POST (or both)
- The parameters of the request
- The difference in response between success and failure
- Whether any session cookies are required to be set or maintained
- What lockout features and thresholds are enabled (if any)
For the parameters of the request, you can intercept and examine a normal login attempt with a web proxy (such as owasp-zap, webscarab or burpsuite) or use a browser plugin (such as tamperdata) or just look at the HTML form.
An example attack
The Web Security Dojo VM has various vulnerable applications that you can use to test these techniques. So looking at an example the w3af testing framework has a test login at the following location
The important parts of the HTML form are:
<form name="input" action="dataReceptor.php" method="post">
<input type="text" name="user">
<input type="password" name="pass">
If we put in one wrong username and password combination we get: