THC-Hydra (or simply Hydra) is a network logon cracker, that is, an online cracker, which means that it can be used to find login passwords by brute-forcing network services. A brute force attack is the one that tries to guess the correct password by attempting all the possible combinations of characters; these type of attacks are guaranteed to find an answer, even if they take ten million years to do it.
Although it is not feasible for a penetration tester to wait for more than a few days or maybe hours to get the login password for a website, sometimes testing a few username/password combinations in a large number of servers might be very productive.
In this recipe, we will use Hydra to break into a login page using a brute force attack over some known users.
We will need to have a user name list, as we browsed through our vulnerable_vm we saw some names of valid users in many applications; let's create a text file (ours will be users.txt) with them:
admin test user user1 john
- Our first step will be to analyze how the login request is sent and how the server responds to it. We use Burp Suite to capture a login request at DVWA:
We can see that the request is on
/dvwa/login.phpand it has three variables: username, password, and login. - If we stop capturing requests and check the result in the browser, we can see that the response is a redirect to the login page:
A valid username/password combination should not redirect to the same login but to some other page, such as
index.php. So we assume that a valid login will redirect to the other page and we will take"login.php"as our string to distinguish when an attempt is unsuccessful. Hydra will use this string to tell when a username/password combination is rejected and when it is not. - Now, we are ready to attack. Introduce the following command in a terminal:
hydra 192.168.56.102 http-form-post "/dvwa/login.php:username=^USER^&password=^PASS^&Login=Login:login.php" -L users.txt -e ns -u -t 2 -w 30 -o hydra-result.txt
We have tried only two combinations per user with this command: password = username and empty passwords. And we got two valid passwords from this attack, marked in green by Hydra.
The first part of the recipe, the capturing and analyzing of the request, is used to know how the request works; if we just consider the output of the login page, we will see the message "Login failed" and may be tempted to use that message as an input for Hydra to use as a failure string. However, by checking the proxy's history, we can see that it appears after the redirect is followed; Hydra only reads the first response, so that is not useful and that's why we used "login.php" as a failure string.
We used many parameters when calling Hydra:
- First, the IP address of the server.
http-form-post: This indicates that Hydra will be executed against an HTTP form using POST requests. Next to it are, separated by colons, the URL of the login page, the parameters of the request separated by ampersands (&)—^USER^ and ^PASS^ are used to indicate where the username and password should be placed in the requests—and the failure string.-L users.txt: This tells Hydra to take the user names from theusers.txtfile.-e ns: Hydra will try an empty password (n) and the username as password (s).-u: Hydra will iterate usernames first, instead of passwords. This means that Hydra will try all usernames with a single password first and then move to the next password. This is sometimes useful to prevent account blocking.-t 2: We don't want to flood our server with login requests, so we will use only two threads; this means only two requests at a time.-w 30: This sets the time out or the time to wait for a response from the server.-o hydra-result.txt: This saves the output to a text file. It is useful when we have hundreds of possible valid passwords.
Notice that we didn't used the -P option to use a password list or -x to automatically generate a password. We did so because brute-forcing web forms produces high levels of network traffic, and a DoS condition can be caused if the server has no protection against it.
It is not recommendable to perform brute force attacks or dictionary attacks with a large number of passwords on production servers because we risk interrupting the service, block valid users, or be blocked by our client's protection mechanisms.
It is recommended, as a penetration tester, to perform this kind of attack using a maximum of four login attempts per user to avoid blockage. For example, we could try -e ns, as we did here, and add -p 123456 to cover three possibilities: no password, password is the same as username, and password is 123456, which is one of the most common passwords in the world.