Large Bruteforce Attack Against WordPress Sites Starting To Subside

Security company Wordfence is reporting that the large distributed brute force attack on WordPress sites is starting to subside. On the morning of February 10th, employees noticed a large increase in the volume of attacks. Their real-time activity map was showing so much activity, they had to throttle the amount of data displayed. I asked BruteProtect if they were seeing the same amount of attacks using their monitoring system:

Yes, we’ve been watching it going crazy. We’ve been seeing levels about 8 times higher than average. Interestingly, while this is definitely a large attack, it’s not the biggest we’ve seen. We were seeing nearly twice as much activity for a 4-day period in mid-January.

Wordfence released an update earlier today saying the attacks have subsided but there are still occasional surges. Think of it like aftershocks after a powerful earthquake.

How These Services Work To Protect WordPress Sites

BruteProtect and Wordfence use the power of many to protect users against distributed attacks. The idea is similar to how Akismet operates. Both companies track failed logins across a large number of WordPress sites, then analyze the data to find patterns and identify attack bots. The more people using their plugin, the more data they have to work with. This results in more protection for site owners and fewer false positives.

Brute Force Featured Image

Cost Of Protection

The service offered by BruteProtect is free with no limits attached. Wordfence is also free but they offer additional protection such as country blocking, scheduled scans, and remote scans for $39 per year. While the primary goal of BruteProtect is to protect the login page against distributed attacks, Wordfence is more like a full security suite similar to VaultPress.

Limit Login Attempts is a popular plugin used to limit the attempts an IP address can login. This is a great alternative but I like Wordfence and Bruteprotect for the simple fact that many sites grouped together through a service is a more effective strategy than battling brute force attacks alone.


Use A Strong Password

It’s hard to protect a website from a distributed attack but the easiest thing site owners can do to protect themselves is to use a strong password. WordPress 3.7 shipped with a password strength meter that does an excellent job with informing you whether your password is strong or not. Using a strong password will lower the chances of a distributed attack from succeeding to gain access.

The Problem Is Only Going To Get Worse

Unfortunately, these types of attacks are becoming more common. Early in 2013, a huge botnet was used to perform brute force attacks on WordPress websites to crack the administrative credentials of users.

Services like Wordfence and Bruteprotect are playing a pivotal role in helping users to combat this annoying type of attack. These plugins/services are going to be as common place on WordPress sites as Akismet. Are you using either of them on your site? If not, what precautions do you have in place to help protect against brute force attacks?


45 responses to “Large Bruteforce Attack Against WordPress Sites Starting To Subside”

  1. My standard installation has Wordfence + Better WP Security to harden my installation + Sucuri free to monitor the integrity of WordPress and the plugins + Login Security Solutions which in my opinion is more sophisticated than “limit login attempts”. Wordfence in fact comes already with a function to limit the number of login attempts but LSS offers more options.

    • +1 for Login Security Solution over Limit Login Attempts. In addition to being much more sophisticated, it’s also actively maintained. Limit Login Attempts hasn’t been updated since June 2012.

  2. I think WordPress should include a default minimum password strength. Over time, all users passwords would be upgraded and would eventually result in these attacks being ineffective and so they would stop automatically. They only reason these attacks work, is because people use stupid passwords. Remove the stupid password problem and the attacks should disappear automatically.

    • Creating stronger passwords alone will not stop the attacks. Even if you have a strong password and the attackers are not able to gain access they can still hit your login page ten of thousands of times in a short period of time, overloading the server and effectively denying service.

      • Yes it will. Once everyone’s passwords are strong enough, then bots will simply stop using this attack vector as it won’t work.

        Note the bold bit below:

        I think WordPress should include a default minimum password strength. Over time, all users passwords would be upgraded and would eventually result in these attacks being ineffective …

          • You haven’t read what I wrote.

            Having a strong password will not stop a DDOS attack. Having every password in every WordPress installation in the world be strong will stop this type of DDOS attack. If the attackers can’t brute force the passwords, then there is no point in trying.

            They’re specifically targeting WordPress due to weak passwords. If the passwords are strong, the problem goes away.

            The only catch to this, is that it will take a very long time for passwords to be upgraded (unless it was forced on the users).

    • Unfortunately, you can’t protect a user from themselves.

      WordPress 3.7 included a smarter password meter (called zxcvbn) which uses a much better method of realistically providing users information about whether or not a password is any good.

      But even if it “forced” users to select a strong password, that wouldn’t help them. They’d just write it down on a post-it note on their monitor.

      The truth is that passwords are terrible in the first place. Long term, we’d be well advised to making it easy for the code to support better ways in the future. Fortunately, it’s already mostly there. Now we just need those better ways. 2FA is great, but not the end of the line, I feel.

      • In this situation, it wouldn’t matter if they wrote their password on a post-it note and stuck it to their monitor since the bot wouldn’t have access to that.

        Unfortunately I don’t think there are any better solutions to passwords just now, so in the interim I think making people use good ones would be nice, if only to prevent these silly DOS attacks from occurring. Multi-factor authentication would work as well, but I think too many people would object if that were made compulsory.

      • Maybe teaching people to use password managers could be a good idea? Users usually don’t subscribe to only one service, if they have then accounts on ten services it would mean remembering ten strong random passwords. Is that even doable? Ok, write them on a post it, every time you login somewhere you must take your post it and copy a 12+ characters password made of mixed upper case, lower case, numbers and symbols. We simply cannot ask users to do that, they wouldn’t. A password manager as of now is the best possible solution until we’ll find some reliable biometric method.

        • I don’t think WordPress would have much lucking convincing everyone who uses it to install LastPass unfortunately. People always take the easiest route, such as their password of “password”.

  3. I was used similar plugins before and they working well. Except issue that they overloading server in case of bruteforce attack.

    That’s why i disable them at all and switch to http password on wp-login.php file and wp-admin folder as explained in Codex section “Password protect wp-login”. This simply action doing terrific job and once bots seen password protected file they attacking this site.

  4. I also use better WP security, but one thing I have found continually surprising is that the wp-config file, containing all of your database setup is there in the root directory.
    I’d also like to see the security of the admin/login page for WP improved. It’s long overdue and badly needed.

    • For some time now WP has supported moving the wp-config file up a directory level (aka, one level above your public_html root directory). No special changes, WP will look for it there automatically.

      • Yes I already have all of my config files one layer above (note: not all host servers allow this, but where they do, I do make use of it). I wonder how many other people know this though (think: non-web designers, simple bloggers).

        However it’s just my surprise that highly sensitive details are still placed by default, and left there in such an easy place to obtain.
        What i’m getting at really I suppose is that WP dev do not “appear” to have paid much attention to built-in front end security, considering the very subject of this thread and how long it has been a known issue.

        Frankly: out of the box, WP is very weak.

  5. What I never see every time another series of brute force attacks triggers another article like this is acknowledgment of what Hosting Companies are doing to protect users.

    NONE of these plugins work to protect you when a company like or ROUTINELY DISABLE WP LOGINS.

    More companies are doing this. They detect a brute force attack and shut down the administrative access of all client sites using WordPress for days sometimes. and do not notify their customers. Not a single peep.

    You can’t find information in the or Client logins; you check out the Facebook pages and no specific mention. Only in the Forums when some users begin to report that they have lost Administrative logins to ALL WordPress sites do you get confirmation about your own problems with WordPress Admin logins.

    I post a series of responses asking if another brute force attack is hitting their WordPress customer websites and nothing.

    I write Customer inquiries and nothing for several days. Finally, once the Admin logins are accessible again, someone will admit that it was another brute force attack on WordPress, particularly the wp-login.php file.

    But these plugins do no good when it is your Hosting Servers that are globally disabling your Admin logins for WordPress.

    I wish someone would force these Hosting Companies to have a transparent and consistent process for handling their client accounts.

    • Sounds like you need to say “bye-bye” to 1and1! I suffered a comment spam attack while on GoDaddy. That used so much CPU that they disabled my shared machine. Didn’t take me long to say bye-bye to GoDaddy!

  6. For protecting the login page there are couple of simple, but highly effective mechanisms you can use. The first is what Peter mentioned, require HTTP Basic Authentication at the web server level.

    The second is to use two factor authentication. If you already have the Google Authenticator app for iPhone/Android then you can easily use this plugin – – to apply two factor authentication to your login form.

    • If your password is so weak that it is at risk of an attack like this, then you should reassess your password system. Two factor authentication should be for blocking other attack vectors, not as a way to beef up your password.

      • Additional layers of security provide different benefits depending on the exact attack.

        Adding HTTP Basic Authentication is helpful assuming it has a separate password from your WordPress account. But between that and two factor authentication I actually prefer two factor authentication because is adds one more of the three standard authentication pillars.

        In general authentication can be categorized into something you know ( a password ), something you have ( a smart phone with two factor authentication ), something you are ( usually biometric, finger print, retina scan, etc. ). Each of these have various trade offs as well.

        Out of the box WordPress covers something you know by having a username and password. Adding two factor authentication combines that with something you have. You’ve now increased the minimum requirements someone needs to successfully login as you. Assuming that doesn’t increase the pain of logging in to an unbearable amount that is usually considered a good thing.

        I agree that the first step is to have a good password. Even if you have a super strong password I would still recommend using two factor authentication. Even if no one ever tries to brute for the password on your account I’d still recommend using two factor authentication.

        • I use multiple factor authentication on my own site. But I do that in case someone finds a way to access my password (or bypass it), not to protect against someone brute forcing my password.

  7. I think a lot of people here have passed over the first line of defence, and that is a user name that is as difficult to sort out as a password is. I use long usernames with caps and small letters and numbers – some systems don’t like other characters here, but you can get a good security level with a 20-character user name. I think I read that something like 80-85% of the WP users are still using admin as their user name! When you are making that change, delete the original user name and then user 1 will also disappear, and that’s not bad either.

    Then go to the next step – the password, and carry on from there.

    • In WordPress usernames are not considered private data. I’d suggest using something besides ‘admin’ as the username, but that shouldn’t be considered in the same category as having a strong password.

      A slightly smarter bot will simply scrape the username from the front of the site.

  8. I find that using Limit Login Attempts ( really helps with brute force attacks. I also use some of the other plugins that have already been mentioned. I’m pretty satisfied with the level of security it brings me. The only time I’ve had a security problem in the past year, or so, has been due to files being compromised via a theme, and I’m not sure if that was due to a security breach at my ISP or me downloading a bad update from a non-sanctioned repository. (But, I’m pretty sure it was a server-side issue at my ISP) And even then, that was detected by the AntiVirus plugin (, so I could clean up the problem.

    The real “problem” is that WordPress has a large installed base, so it’s a good target for automated attacks. It’s a standard attack pattern with a high potential yield for attackers. Security is not an absolute and there is no absolute solution. Security is a process that we must faithfully execute on a regular basis. And, that is true no matter what the system.

  9. Brute force attacks have two possible rewards for the attacker: gain access to the site back end by correctly guessing the password *or* take down the targeted site/server for a period of time by causing a Denial Of Service.

    Of these results, the most dangerous is gaining access to the site’s back end as from that point the attacker can do whatever they want to your WordPress installation. A Denial of Service just means your site is unreachable or offline for a period of time (although if a server is misconfigured, this too can become dangerous and allow attackers to access more than they should).

    So to address this you really need two solutions: 1) Use a unique and hard to guess password to reduce the likelihood of a successful guess by an attacker (two factor authentication helps a lot here) and 2) make it hard for attackers to even access the login functionality to try and attack it (HTTP Basic Authentication helps here).

  10. A plugin I have used and can heartily recommend is the WP All in One Security. It’s free. The problem with “locking down logins” is that you’re using a LOT of machine cycles to identify, log and turn away those attackers. The better solution is to not let the bots even get to your login page! This is something that the All In One Security does well. If you try to hit my WP login page without a particular keyword or cookie you’ll get bounced immediately via an .htaccess rule.

  11. I’ve noticed these attacks are looking at the author slug to guess usernames. I’ve been using a plugin to change the author slug, the Limit Login Attempts plugin, and Google Authenticator to beef up security. I’ve also been trying out Clef, a two-factor auth plugin that just added the ability to remove the user/pass fields from the login screen completely. No login fields shuts down a brute force attack pretty effectively.

  12. For the vast majority of sites, there’s a much faster and simpler approach compared to plugins: just restrict access to wp-login.php by IP address or CIDR range. If only a handful of people with a handful of IP addresses log in to a site, just allow those and deny everything else. Even an attacker with your credentials can’t gain access unless he can figure out one of the allowed IP’s.

    • In January my 1&1 web hosting closed the administration of all hosted WordPress sites due to force attack.
      I am using a strong password and an identifier different than “Admin”. I didn’t have any problem and I think this will prevent main problems on such attacks. Thanks to that they exceptionally reopen my administration access. I was probably one of the single user during those 4 force attack days.
      I haven’t hear anything in February. Will see….

  13. I use the ThreeWP Activity Monitor plugin to keep an eye on what’s being poked at, but in terms of increasing security, I use the Google Authenticator plugin and have enabled two-factor authentication on my account. That means that even if you should happen to have my password for some reason, you still can’t login without the two-factor number from Google Authenticator.

    Another aspect is to minimize the number of accounts, period.

  14. Our sites couldn’t survive without WordFence and the fantastic job they do! These recent attacks have been horrible, but Wordfence stopped everyone! I highly recommend it’s feature to block instantly anyone who tries to use an incorrect username.

  15. Interestingly three of my sites which I thought were hardened by Better WP Security, BulletProof Security and Limit Login Attempts have over the last 2 days had the primary admin account user names attempt to login – and they weren’t by me. An IP lookup informs me the attempts came from a server farm in South Korea.

    My user names have never been exposed before during this ongoing bruteforce attack with the usual “admin”, “administrator” and others being the only user names that have attempted to login in the past. Seeing my current user names in the email alert sent a cold shudder down my back. Somewhere, in all the precautions I thought I had taken, the user names are being leaked.

    I’ve rebuilt the security and .htaccess files, deleted those admin accounts and even turned off the database cache (W3 Total Cache) in case the leak was there. Any suggestions on further hardening is welcome because the only other possible scenarios are either; a form of malware/keylogger on my local system (which is unlikely as they would also have the passwords) or there is an interception somewhere along the line (also unlikely as again they would theoretically have the passwords also).

    I will look into “Google Authenticator for WordPress” as mentioned by Gordon above though.

    • Why do you care if everyone knows your username? I’ve seen bots repeatedly attempting to log into my account and never cared. They’re just going to keep hammering away at it until they give up. The only way they can get in is if you are using a silly password.

      • I just realised why you are probably trying to hide your username. I’m guessing you are trying to reduce the server load, by preventing WordPress needing to check your password each time? But I’d have thought the load caused by looking up a non-existent username would have been just as bad (that’s just a wild guess on my part though, I’m not really sure).

  16. I use wangGuard to stop spam posters and it works amazingly. I also use a strong password. I use a nickname on postings so they cannot see my admin username. In the past I used Blacklist IP which worked great as well, but since WangGuard came along I switched to that.

  17. I’ve installed Wordfence on several sites to “test drive” it and compare to better-WP-security and login-limits. Interesting that within an hour or so, I received an email telling me that the php file associated with the Hello Dolly plugin (that was inactivated but still present) had reported as a “critical” attack possibility. This raises the question about “false positives” – or are core inclusions a bigger issue than we’ve always thought they were?

  18. It looks like if you have a paid CloudFlare account it helps protect against these types of attacks using a web application firewall:

    I second a couple of comments recommending Clef. It allows you to login using your phone like a barcode scanner, syncing with a Clef “Wave.” I like that you can control your session length via phone.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: