I am hosting some wordpress sites on an apache 2.4 webserver, and I have discovered thousands of entries in my server logs like this: - - [09/Mar/2015:03:29:25 +1300] "GET /example.com/wp-login.php HTTP/1.1" 200 6656 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" - - [09/Mar/2015:03:29:26 +1300] "POST /wp-login.php HTTP/1.1" 302 644 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"

and tens of thousands of entries like this: - - [13/Mar/2015:07:19:18 +1300] "POST /wp-login.php HTTP/1.0" 302 608 "-" "-"

In these cases the server is giving a 302 response, which looks to me like wordpress is redirecting them back to the login page, which indicates a failed login attempt.

then I saw entries like this - - [14/Mar/2015:06:42:31 +1300] "POST /wp-login.php HTTP/1.1" 200 1695 "http://example.com/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0"

where the HTTP response is a 200.

Did the brute force login attempts obtain passwords and are these actual successful logins?


1 Answer 1


First of all, here is how it's handled by default when you visit the login page and try to log in:

POST /wp-login.php
[invalid credentials]
-> 200

POST /wp-login.php
[valid credentials]
-> 302

So it's the other way around than what you assumed. 302 means valid credentials (redirect to admin area), while invalid credentials result in 200 (stay on login page).

There are however various ways you can achieve a 302 without passing valid credentials. For example, you could add a POST field containing action=postpass, which would result in a cookie being set, and wp_safe_redirect (which by default uses 302) being called with the referer that was passed.

There are a lot of other actions that would result in a 302, for example action=register.

So while I can't say for sure that there were no successful bruteforce attempts, it could very well be that those 302 attackers are just scanning your website to check if your registration is open (possibly to register and then try to escalate their privileges). It could also be that their bruteforce tool is misconfigured.

  • interesting, thanks. considering that you cant reliably detect logins from the apache logs, do you have any suggestions on where I might look to see if any logins were successful? Apr 30, 2015 at 14:00
  • @user4668401 Any logins - how would you distinguish the valid ones from the succesful hacks?
    – user13695
    Apr 30, 2015 at 14:18
  • @user4668401 you could add code to log successful logins. You could also look in your apache log for 200 repsonses to /wp-admin/, as only logged in users get those, others get a 302 (I didn't check if non-logged in users can somehow also generate 200, but it's not the default). But this assumes that the attacker actually followed the redirect from the login (which probably doesn't happen when they use a bruteforce tool, only when they use the bruteforced credentials).
    – tim
    Apr 30, 2015 at 14:18
  • and regarding @JanDoggen point, you will probably get a lot of hits for 200 /wp-admin/, so you would need to filter out your ip address (or possibly user agent, if it's unique enough) and maybe remove all duplicate entries with the same ip address for easier readability.
    – tim
    Apr 30, 2015 at 14:20
  • 2
    My testing found the same results as @tim. I found wordpress is a pretty "noisy" system (especially if you have extra caching rules in .htaccess) as it invokes lots of redirects either via 302's or via internal apache URL rewrites and because the php code makes alot of decisions about how to respond its hard to know what execution paths are firing. but one BIG give away on a successful login is that wordpress will send the HTML for the admin area to the browser, this will make dozens of subsequent HTTP requests e.g. for stylesheets, images etc to "build" the admin areas. May 5, 2015 at 1:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.