Mass WordPress Brute Force Attacks? – Myth or Reality

We are seeing in the media some noise about a large distributed brute force attacks against all hosts targeting WordPress sites. According to reports, they are seeing a large botnet with more than 90,000 servers attempting to log in by cycling different usernames and passwords against the WordPress access points: /wp-login.php and /wp-admin.

This got us thinking, well we block a lot of attacks why not look at the logs to see what they tell us. So we did.

The Data

Looking back, we can see in our historical database the following:

2012/Dec: 678,519 login attempts blocked

2013/Jan: 1,252,308 login attempts blocked (40k per day)

2013/Feb: 1,034,323 login attempts blocked (36k per day)

2013/Mar: 950,389 login attempts blocked (31k per day)

2013/Apr: 774,104 for the first 10 days – 77,410 per day

As you can see from our numbers, we were seeing 30 to 40 thousand attacks per day the last few months. In April 2013, it increased to 77,000 per day on average, reaching more than 100,000 attempts per day in the last few days.

That means that the number of brute force attempts more than tripled. This sharp increase would lead us to believe that there is some reality to these reports.

Diving deeper into our data we find a few interesting data points. For instance, we can see the top user names being attempted:

652,911 [log] => admin
10173 [log] => test
8992 [log] => administrator
8921 [log] => Admin
2495 [log] => root

In these cases, by the shear fact of having a non- admin / administrator / root usernames you are automatically out of the running. Which is kind of nice actually.

FYI, the number value next to the [log] is the number of scan completed. So the first line item, admin, was used against some 652,911 sites.

As far passwords, this is what we’re seeing:

16,798 [pwd] => admin
10,880 [pwd] => 123456
9,727 [pwd] => 666666
9,106 [pwd] => 111111
7,882 [pwd] => 12345678
7,717 [pwd] => qwerty
7,295 [pwd] => 1234567
6,160 [pwd] => #@F#GBH$R^JNEBSRVWRVW
5,640 [pwd] => password
5,446 [pwd] => 12345
5,392 [pwd] => $#GBERBSTGBR%GSERHBSR
5,058 [pwd] => %G#GBAEGBW%HBFGBFXGB
4,861 [pwd] => aethAEHBAEGBAEGEE%
4,317 [pwd] => 123
4,281 [pwd] => 123qwe
4,133 [pwd] => 123admin
4,092 [pwd] => 12345qwe
4,086 [pwd] => 12369874
3,880 [pwd] => 123123
3,831 [pwd] => 1234qwer
3,814 [pwd] => 1234abcd
3,787 [pwd] => 123654
3,751 [pwd] => 123qwe123qwe
3,744 [pwd] => 123abc
3,623 [pwd] => 123qweasd
3,606 [pwd] => 123abc123
3,422 [pwd] => 12345qwert

Most of these should be expected actually, it’s only what we’ve been reporting for a while.

What does stand out are these:

6160 [pwd] => #@F#GBH$R^JNEBSRVWRVW
5058 [pwd] => %G#GBAEGBW%HBFGBFXGB
4861 [pwd] => aethAEHBAEGBAEGEE%

Looking at some of our resources we have found these across a few wordlists which sounds very odd. The most obvious argument is, well crud, they are just randomly generated, right? But then you look at the number of sites it was tried against, that’s where it doesn’t make sense.

Almost feels like we’re missing something that they know.. hummmm.. then again it could be over thinking and we should just be glad they are blocked.

Top Scanner IP

Here is a bit more information for those managing their own servers and hosts. Here are the top 30 malicious IP addresses being used in the various attacks:

#number of attempts – IP Address

Should you be concerned?

Depends, what have you implemented to protect yourself against these attacks? The thing to understand about these attacks is that they play on the biggest WordPress vulnerability, you, the end-user. You have to be doing your part, specifically when leveraging good passwords.

If you aren’t, then yes, we’d say it’s worth being a bit concerned about. Especially if any of the data above looks familiar. Some things to consider looking at include solutions like a web application firewall (WAF) similar to our CloudProxy product or ModSecurity to block these attacks before they reach your site / server resources.

    1. There are several ways that you could stop these wordpress plugins. Firewalls or modsecurity as mentioned in the post, you can install wordpress plugins such as stealth login page, limit login attempts, wordfence. You could also use .htaccess to limit access to the wp-login and wp-admin pages to only ip addresses that need to be connecting to it.

      1. Limit Login Attempts will not work – they are using far too many IPs, usually one login per IP per account. Best way is to .htaccess block attempts to POST to wp-login.php without the HTTP_REFERER being your domain.

    2. moving the location of your login is the best option. use Better WP Security to make that easy.

        1. If you use Better WP Security you can make it . It uses mod_rewrite to mask the true location and denies direct access to the true wp-admin location.

  1. Really odd with the passwords that are clearly generated strings like ‘aethAEHBAEGBAEGEE%’..

    At first I suspected that these could be example passwords used in the WordPress Codex or posted publicly somewhere, but a Google search yields nothing except this post.

    Don’t you just hate that feeling.. that they may know something you don’t.

    1. Wild assed guess, these are hashes or strings used by things like ManageWP and InfiniteWP. I’ve never been exactly clear how those worked but they look vaguely close. Again, wild guess, not saying I know that’s what they are, but I might play around later today to see.

  2. My host just shut down access all together. I am now getting a 403 error when attempting to log in. Is that a common practice? Seems reasonable to me as long as it clears up soon. Thanks for the info!

      1. That would be the nuclear option, but it is a good tactic if they are having to choose between that or the server crashing. We had to use that on 1 to 2 of the servers being heavily attacked for a 6 hour period while we wrote and tested a series of new fixes / defenses as the attack evolved. It’s a good short term fix.

  3. Once your in their sights its more likely apache will fail than them brute forcing your login. Even if you shut down your login pages. Your IP will be passed across the botnet and you will be down till the attack is over.

  4. Please note they are now rotating the username including words without “admin” or anything similar in them.

    One of the best things to do is use .htaccess to make sure the HTTP_REFERER is actually your site before allowing access to wp-login.php.

    The worst part is that these attacks have been very successful, compromising at least 10% of the accounts they are hitting.

    If you have been attacked (in other words, if you have a WordPress site), follow this article to clean up and secure the site:

    1. You’ve spammed that link on every blog post discussing this, yet your link contains pretty much nothing of value asides from “change your password and if you don’t know how to review your code, call us!”.

    2. HTTP_REFERER can be faked actually. So you’ll have to add another layer of security probably

  5. Hi,

    You said using ModSecuity? is there any resource you can point to? I have Config Server Firewall that blocks IP’s that login to server related things like cPanel, FTP, etc. but not WordPress.

  6. I am also seeing these on my self-hosted WordPress site. Digest authentication in front of the WP login page + OSSEC = FAIL. 🙂

  7. I just tried to log into a site I manage and got this message: “WordPress administrator area access disabled temporarily due to widespread brute force attacks.” Anyone else getting this?

  8. Does anyone have any info on what a install after a successful login looks like? Are they installing plugins or modifying code? Can anyone share something to look for to identify compromised installs?

  9. All good and well, but the hosting companies do not seem to get it right either to counter this. My login gets disabled when subscriber activity is up who are logging in. When I do a a 302 redirect 15 minutes later I can login, so the bits are clicking on the homepage intead of using This shows that there is no bot activity, neither was an increased activity registered by google analytics.

  10. “chmod 0 wp-login.php wp-admin” does the trick for me until I catched up on the big picture.

  11. I am thinking the long strang password attempts are to access accounts that have previously been taken control of by this or another botnet.

  12. A very smart and powerful response is to set up Apache password for wp-login.php and wp-admin/ directory. Do this in the .htaccess file.

  13. NO Myth, I run limit login plugin and I was receiving emails all day about attempts. I installed an admin login page reroute and the emails stopped. Banned the ip’s and keep a close watch. SO far so good.

  14. My site has documented three attempts to break in and has locked out all three IP addresses. Should I be reporting these IPs somewhere?

    1. Create a new admin user (you will have to use different email address), log out of WordPress, log in as the new user, delete the old “admin” user, make the new user the author of all the old posts (WordPress will ask you to do this when you attempt to delete the old user), go into your settings and change your email address back to the old admin email addresses. Done.

      1. Actually there are plugins voor wordpress that you can install that will allow you to change the adminstrator password, without having to create a new one and deleting the old.

        Admin renamer extended is an example that I use, but there might be more.

        1. You can change administrator’s password without plugin too but the idea behind is to delete user with id=1.

      2. I also inlcluded a captcha plugin which ads an extra layer of security. Of course nothing is foolproof, but everything that makes it harder to crack your site helps, doesn’t it?

  15. solved with:
    iptables -I INPUT -m string –algo bm –string “wp-login” -j DROP


    2480 957K DROP all — any any anywhere anywhere STRING match “wp-login” ALGO name bm TO 65535

  16. Is there any way to
    limit attempts to login within “Sucuri Security” standard version or do I still
    have to use the plug-in “Limit Login Attempts” in addition?

Comments are closed.

You May Also Like