Test WordPress Logins With Hydra on Kali Linux

wordpress login test penetration test


There are web forms all over the Internet. Even sites that don’t usually allow regular users to log in probably have an admin area. It’s important when running and deploying a site to make sure that the passwords gating access to sensitive controls and admin panels are as secure as possible.

There are different ways to attack a web application, but this guide is going to cover using Hydra to perform a brute force attack on a log in form. The target platform of choice is WordPress. It is easily the most popular CMS platform in the world, and it is also notorious for being managed poorly.

Remember, this guide is intended to help you protect your WordPress or other website. Use on a site that you don’t own or have written permission to test is illegal.

Getting Set Up

Before you do anything, you’re going to need a WordPress website to target. This guide also assumes that you are hosting the WordPress site on your own machine. If you need some help setting up LAMP on your machine check out our Debian LAMP and Ubuntu LAMP guides.

You could do this either on a regular Linux install or on a Kali Linux install. If you’re using Kali, follow the Debian LAMP from source guide. Just make sure that you have Hydra and cURL installed on whichever system you choose. They are available in most repositories.

If you really don’t want to use your regular install, you can definitely use another machine, just sub in the target’s IP for localhost, and make sure the target machine is accessible from the attacking one.

Gathering Information

Once you have WordPress up and running, it’s time to find as much information as you can about the installation that you will be targeting. This means finding out how the login form is built, what happens when you submit it, and possibly where it goes if the login is successful.

HTML Source

Start off by navigating to the login page. You can find it at localhost/wp-login.php. Use your browser’s ability to inspect the source code. You can just right click somewhere on the page and select “View Source” or “Inspect Element.” Either way you can view the source, it will just be displayed in different ways.

Search around toward the middle of the code. You are looking for the tags. That is the actual login form. Inside that form are a couple of pieces of information that you need.

Before collecting the information, check if the form sends a GET or POST request. In the first line of the form, there should be a method option that looks like this: method="post". In the case of WordPress, it is a POST.

First, find the user name input. It should look like the line below.

<input type="text" name="log" id="user_login" class="input" value="" size="20" />

The part that you need is the name. In this case, it’s log.

Next, find the password input. It should look similar.

<input type="password" name="pwd" id="user_pass" class="input" value="" size="20" />

Again, find the name which is pwd.

You also need to identify the submit button so Hydra can submit the form.

<input type="submit" name="wp-submit" id="wp-submit" class="button button-primary button-large" value="Log In" />

It’s important to log both the name and the value.

There is one last piece. If you haven’t notice, there are two hidden fields at the bottom of the form. One tells WordPress to redirect when the form is submitted and the other is a cookie that WordPress will look for when the form is submitted. You need the cookie.

<input type="hidden" name="testcookie" value="1" />

Again, make note of the name and value.


Even though there was a lot of information to be gained by looking at the HTML source, there are some more things that you need to know before unleashing Hydra. In most cases, though, you might be able to execute the test with just the information that you gathered. You would simply attempt to log in with incorrect credentials, record the error message, and use that message as a failing test condition in Hydra.

However, WordPress is designed differently, and there isn’t really a good way to test with failed attempts to log in. Because of this, you need to test for a successful log in. Because you can maintain your own WordPress install and log into it, this wouldn’t make a difference if you were testing out a system for a client. The condition that you find locally should be universal to WordPress.

There is another wrinkle here too. Do you remember the hidden redirect field in the form? Well, that redirect prevents you from using a condition like the presence of the word, “Dashboard,” to test success too. You’re going to have to take a look at the request itself, and for that, there’s cURL.

In order to compare, you need to first see the original login page with cURL.

$ curl -v http://localhost/wp-login.php

The majority of the information is the same as the source code that you looked at in the browser. At the top, though, is information about the HTTP request. Take note of this information. You’re going to need to compare it to a successful login.

The next thing you need to do is successfully log in with cURL. In order to do that, you’re going to need that cookie from the previous request. Take a look at the HTTP data and locate a line that looks like the one below.

< Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/

You’re going to need the wordpress_test_cookie=WP+Cookie+check part.

Alright, now you’re going to need the information that you gathered from the HTML along with that cookie to make the request. This is what it should look like.

curl -v --data 'log=username&pwd=realpassword&wp-submit=Log+In&testcookie=1' --cookie 'wordpress_test_cookie=WP+Cookie+check' http://localhost/wp-login.php

So, you have the same basic request as before, but this time, you are using the --data flag and the --cookie flag to pass cURL which form data you want to interact with and that cookie, so the form will actually submit.

That data string, log=username&pwd=realpassword&wp-submit=Log+In&testcookie=1 corresponds directly to the information that you gathered in from the HTML. It is saying to plug the value “username” into the input called log and the value “realpassword” into the input called pwd. Make sure to use the actual username and password to log in. Then, use the submit with the name wp-submit and a value of Log In to submit the data. At the end is testcookie with a value of 1. That’s just telling cURL to submit that along with the rest of the form data.

When cURL completes the request, you really won’t see any HTML, just a lot of request information. Remember that redirect that made testing with “Dashboard” not work as a test condition? Well, now the redirect itself will be the test condition. Take a look at the line below.

< Location: http://localhost/wp-admin/

That line wasn’t in the previous request. It also doesn’t contain any specific information related to that user or login. That means that it will always be present during a successful WordPress login, making it the perfect success condition to test with.

Testing With Hydra

Finally, you have everything that you need to test your passwords with Hydra. The point of this guide isn’t so much to cover Hydra syntax, but it will break down the command used. If you want to learn more about Hydra, check out the SSH guide that goes into much more detail.

There is really only one command that you need for Hydra to run through possible usernames and passwords to test the security of your WordPress site. The easiest thing to do is take a look at the command and break it down.

$ hydra -L lists/usrname.txt -P lists/pass.txt localhost -V http-form-post '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log In&testcookie=1:S=Location'

Okay, so this is obviously a lot to take in at once. The -L flag tells Hydra to use a wordlist of usernames at lists/usrname.txt. Similarly, the -P flag tells Hydra to use a wordlist of passwords at lists/pass.txt. localhost tells Hydra to target localhost, and -V tells it to log every test in the console output.

The rest of the command deals with the HTTP request itself. http-form-post activates the Hydra module for handling HTTP forms with a POST method. Remember from before that the WordPress login form is in face a POST from. The string that follows contains all of the parameters that Hydra will use. You should notice that it is very similar to the one used to log in through cURL.

The string consists of different sections separated by :. The first part is the exact address that is being tested, /wp-login.php. The next part is almost exactly like the one used by cURL. It passes values into the form and submits it, including the cookie. Instead of passing literal values, Hydra is actually using variables. Notice in log=^USER^ and pwd=^PASS^. Those are variables separated out with the carrot character that take the values from the wordlists and pass them along in the request for each test that Hydra runs.

The very last piece of the string is the test condition. S signifies that it is testing for success. If you wanted to test for failure, you’d use F. You set that equal to the word or phrase that it is testing for. Think if it almost like grep.

When you run this, you should get a positive result, provided the correct username and password are in the wordlists that you provided Hydra.

Closing Thoughts

First off, congratulations on making it through all of that. If you’ve made it through, you now have a solid method for testing the password strength of your WordPress user accounts.

This guide was tailored towards WordPress, but you can easily follow the same steps to test out other web forms. If you run a web application with multiple users, it is definitely a good idea to make
sure that they are using strong passwords. This can help inform your password policy. Again, make sure that you are always only testing with permission.