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
5,024 [pwd] => RGA%BT%HBSERGAEEAHAEH
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
5392 [pwd] => $#GBERBSTGBR%GSERHBSR
5058 [pwd] => %G#GBAEGBW%HBFGBFXGB
5024 [pwd] => RGA%BT%HBSERGAEEAHAEH
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
41315 31.184.238.38
10004 178.151.216.53
9817 91.224.160.143
8773 195.128.126.6
6838 85.114.133.118
6624 177.125.184.8
5896 89.233.216.203
5534 89.233.216.209
5469 109.230.246.37
5364 188.175.122.21
5110 46.119.127.1
4485 176.57.216.198
4205 173.38.155.22
4114 67.229.59.202
3956 94.242.237.101
3460 209.73.151.64
3443 212.175.14.114
3294 78.154.105.23
3162 50.116.27.19
3054 195.128.126.114
2740 78.153.216.56
2732 31.202.217.135
2661 204.93.60.182
2520 173.38.155.8
2371 204.93.60.75
2303 50.117.59.3
2301 209.73.151.229
2287 216.172.147.251
2234 204.93.60.57
2227 94.199.51.7
2215 204.93.60.185

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.

Scan your website for free:
About Daniel Cid

Daniel is the Founder & CTO of Sucuri and also the founder of the open source project - OSSEC HIDS. His interests range from intrusion detection, log analysis (log-based intrusion detection), web-based malware research and secure development.

You can find more about Daniel at his site dcid.me or on Twitter: @danielcid

  • http://www.facebook.com/people/Marin-Todorov/1830042990 Marin Todorov

    So is there any solution how to stop the brute force attempts?

    • Randy

      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.

    • http://www.cynicologist.com/ Orun Bhuiyan

      Block them.
      Or limit maximum login attempts in a time period using a plugin.

      • http://twitter.com/absurd_human Absurd Human

        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.

        • http://www.cynicologist.com/ Orun Bhuiyan

          Makes sense, overlooked that.

    • Mike Ramirez

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

      • http://www.cynicologist.com/ Orun Bhuiyan

        I think you can just nest your wp-admin subdirectory an extra level deep, like yoursite.com/foo/wp-admin/.

        • Mike Ramirez

          If you use Better WP Security you can make it yoursite.com/admin-area-that-no-one-will-ever-guess . It uses mod_rewrite to mask the true location and denies direct access to the true wp-admin location.

  • http://www.cynicologist.com/ Orun Bhuiyan

    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.

    • Jon Brown

      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.

    • Kate

      Perhaps they are attempts at SQL injection?

  • Kitzmiller

    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!

    • http://twitter.com/alexjvasquez alex vasquez

      Change hosts!

      • http://twitter.com/BenOnBiz Ben Welch-bolen

        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.

  • Vrocks

    Even if you limit wp login, there is xmlrpc

    • http://twitter.com/perezbox Tony Perez

      You’re absolutely right, in our CloudProxy, we point out xmlrpc specifically in addition to wp-admin. :)

    • Mike Ramirez

      Better WP Security plugin has an option to turn off xmlrpc

  • Tofi

    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.

  • http://twitter.com/absurd_human Absurd Human

    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:

    http://calladeveloper.blogspot.com/2013/04/global-wordpress-brute-force-attacks.html

    • Shadow

      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!”.

    • Godwinh

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

  • harishchouhan

    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.

  • Michael starks

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

  • Mike Ramirez

    One of the servers I manage has been dealing with this problem, so I wrote up a checklist for securing WordPress …which includes installing the Securi plugin http://www.transcendevelopment.com/web-design-news/wordpress-can-make-such-a-word-mess-how-to-secure-it/ glad to say we’re doing much better now, with a large amount of gratitude to Securi’s fine work.

  • judysunshine

    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?

    • http://www.thechurchstateguy.com/ The Church State Guy

      GoDaddy did this (one of my clients sites), but they didn’t provide that notification. That’s nice!

  • http://www.facebook.com/adoo.zumeri Adoo Zumeri

    Facebook Hacked, Claims – No Evidence of User Data Compromised
    http://topworldwidestories.blogspot.com/2013/02/facebook-hacked-claims-no-evidence-of.html

  • Shadow

    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?

  • http://absolutivity.org/ Anton Lorenz Vrba

    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 xxx.com/wp-login.php This shows that there is no bot activity, neither was an increased activity registered by google analytics.

  • Johannes

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

    • Johannes

      0 being a zero

  • Charlie

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

  • Rick

    Dumped a list of offending ip addresses to Pastebin for anyone who is digging into this… http://pastebin.com/eCjGyyBR

  • EastGhostCom

    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.

  • http://twitter.com/coloradofree John Garza

    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.

  • Emily Scifres

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

    • http://codeangry.com/ Claude “CodeAngry” Adrian

      The FBI and CIA… The White House should be the last resort! (facepalm)

  • inscribd

    To really safeguard WordPress, it’s best to have lockout plugins, cloudflare-type CDN and very strong password
    for the admin role. I wrote an article about the method I use to create
    very strong passwords you’ll remember, read here
    http://www.inscribd.com/how-to-create-an-unhackable-password-youll-remember/

    Hope this helps

  • EsojSounds

    How can we change our usernames from ‘admin’ to something else?

    • Sherra Scott

      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.

      • Bas van Zuilen

        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.

        • aza

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

      • Bas van Zuilen

        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?

  • HighWay

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

    result:

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