Dissecting a WordPress Brute Force Attack

Update: Brute force protection now available: http://cloudproxy.sucuri.net/brute-force-protection

Over the past few months there has been a lot of discussion about WordPress Brute Force attacks. With that discussion has come a lot of speculation as well. What are they doing? Is it a giant WordPress botnet? Is it going to destroy the internet? Well, as you would expect of any good geeks we set out to find a way to find out.

This is not to be exhaustive case study or meant to be a representative sample of what all attacks look like, but it does have similar characteristics to the types of attacks and infections we deal with on a daily basis.

In this post, my goal is to highlight a hack that occurred this weekend, July 20th to be exact, against one of our several honeypots. In this specific instance, it was setup and configured approximately 2 months ago. It had been hacked about a month and a half ago and silly me I forgot to configure what I needed to do real forensics, oops. In any event, everything was cleared and pushed out again to see what happened, it was nothing more than a matter of sitting back and waiting.

Sure enough, about 30 days later and it was hacked, this time we were ready to see what happened..

The Baseline

The honeypot in this case is operating the current version of WordPress, 3.5.2, on a Linux distribution provided by a very popular shared-hosting platform.

It is operating current versions of the following plugins:


  • Google Plus
  • Sucuri Security

It is operating current versions of the following theme:


  • Twenty Twelve – ACTIVE

There are a number of other plugins and themes installed, currently inactive, that played no role in this attack, with exception to one inactive Theme – Duster.

In terms of security, there was only one thing done, that was to disable PHP execution in wp-content. We had our Premium plugin installed, predominantly to use the auditing and integrity checks. No other configuration changes were made and it was operating a basic WP installation.

What They Did – At a high Level

This attack resulted in a very simple defacement:

Hacked By Fayzou

This is what it actually looked like, I know, so boring, but effective:

Sucuri - Hacked by Fayzoun

That however was not the gem of the attack. If I were a betting man, the defacement was more in response to their annoyance in getting it to work. In the end, they did a number of things that help us better understand how they think and operate.

Below is what our server side scanner picked up:

File possibly compromised: ./wp-content/themes/twentytwelve/index.php. 
File possibly compromised: ./wp-content/themes/duster/footer.php. 
File possibly compromised: ./XfX.php. 

Each one of those are backdoors.

If you’re not familiar with the concept of backdoors we encourage you to read some of our previous posts where we talk about them in more depth. The idea is simple however, a backdoor as implied by the name, provides an attacker the mechanism required to regain access at a later time. This idea of sustaining access is critical in today’s attacks, we have learned over the years that gaining access to a site, and being able to effectively deface or use it to distribute malware, is but one phase of the attack. The real success comes in the attackers ability to continuously regain access.

These backdoors are the most prevalent attacks these days, they are designed such that they allow attackers to quickly bypass access control mechanisms and security protocols on most servers. They range in complexity, size and functionality, but the core principle is always the same – retain access.

important is because it provides them access that allows them to bypass all your existing access control mechanisms.

Who Were the Attackers

It appears the attacker is part or attempting to represent a Tunisian hactivist group. The IP used for the attack also originated out of the Africa region:

RegDate:        2004-05-17
Updated:        2010-06-28
Comment:        AfriNIC - http://www.afrinic.net
Comment:        The African & Indian Ocean Internet Registry
Ref:            http://whois.arin.net/rest/org/AFRINIC


IP Address:
Location: Tunisia, Africa 
ISP: Agence Tunisienne Internet - ATI

A little more digging leads us to the Fayzoun Hactivist group, and guess what, they have a Facebook page too:

Sucuri - Fayzoun.ao Hactivists

The Details of What and How they Did It

Here is an unbiased description of the events that took place June 20th, by the attacker:

Attack time took approximately 12 minutes:

  • Start Time: 20/Jul/2013:02:22:03
  • Stop Time: 20/Jul/2013:02:34:33

They gained access by brute forcing the WordPress administrator panel, wp-admin. Fortunately for them, my username and password were as weak as they come, gaining them access after a few successive attempts.

   1 [20/Jul/2013:02:22:03 "POST //wp-login.php
   1 [20/Jul/2013:02:22:05 "POST //wp-login.php
   1 [20/Jul/2013:02:22:06 "POST //wp-login.php
   1 [20/Jul/2013:02:22:07 "POST //wp-login.php

Once logged in they proceeded to navigate around the site for a bit. They then came across the theme editor and used that to make modifications to an existing theme file in the duster theme, note however that it was not the active theme. This is an example of modifying a file that is not currently served to the client browser in an attempt to evade detection. We have no reason to believe that the Duster theme was used for anything but coincidence.

[20/Jul/2013:02:29:40 "GET /wp-admin/theme-editor.php
[20/Jul/2013:02:29:41 "GET /wp-admin/load-scripts.php?c=1&load%5B%5D=admin-bar,hoverIntent,common&ver=3.5.2
[20/Jul/2013:02:29:41 "GET /wp-admin/load-scripts.php?c=1&load%5B%5D=jquery,utils&ver=3.5.2
[20/Jul/2013:02:29:48 "POST /wp-admin/theme-editor.php
[20/Jul/2013:02:30:01 "GET /wp-admin/theme-editor.php?file=footer.php&theme=duster
[20/Jul/2013:02:30:19 "POST /wp-admin/theme-editor.php
[20/Jul/2013:02:30:22 "GET /wp-admin/theme-editor.php?file=footer.php&theme=duster&scrollto=9456&updated=true
[20/Jul/2013:02:30:38 "GET /wp-content/themes/duster/footer.php

They then went on to install one of their own themes, which doesn’t appear in your wp-admin dashboard:

[20/Jul/2013:02:31:00 "GET /wp-admin/theme-install.php
[20/Jul/2013:02:31:01 "GET /wp-admin/load-scripts.php?c=1&load%5B%5D=admin-bar,hoverIntent,common,theme&ver=3.5.2
[20/Jul/2013:02:31:05 "GET /wp-admin/theme-install.php?tab=upload
[20/Jul/2013:02:31:31 "POST /wp-admin/update.php?action=upload-theme
[20/Jul/2013:02:32:12 "GET /wp-admin/load-scripts.php?c=1&load%5B%5D=admin-bar,hoverIntent,common,customize-base,customize-loader&ver=3.5.2
[20/Jul/2013:02:32:43 "GET /wp-content/themes/Super_Real
[20/Jul/2013:02:32:44 "GET /wp-content/themes/Super_Real/
[20/Jul/2013:02:32:50 "GET /wp-content/themes/Super_Real/File_M
[20/Jul/2013:02:32:50 "GET /wp-content/themes/Super_Real/File_M/
[20/Jul/2013:02:32:55 "GET /wp-content/themes/Super_Real/File_M/F_M.php

Lastly, being unsuccessful with the previous attempts, they modified the main theme, specifically the index.php file and were able to push their changes to the root of the WordPress install using the default load of theme files when a site is rendered:

[20/Jul/2013:02:33:01 "GET /wp-admin/theme-editor.php
[20/Jul/2013:02:33:26 "GET /wp-admin/theme-editor.php?file=index.php&theme=twentytwelve
[20/Jul/2013:02:33:38 "POST /wp-admin/theme-editor.php
[20/Jul/2013:02:33:41 "GET /wp-admin/theme-editor.php?file=index.php&theme=twentytwelve&scrollto=9456&updated=true
[20/Jul/2013:02:33:47 "GET /
[20/Jul/2013:02:34:06 "POST /

This is significant because if you look at the other attempts you notice that the attacker was failing. In both attempts, prior to the last one, the attacker was attempting to modify files to allow a backdoor to be injected. Unfortunately for them, disabling php execution made it difficult to be successful, rendering their URL requests as unavailable on each request.

This is not speculation, it’s facts based on the server error logs:

[Sat Jul 20 02:30:38 2013] [error] [client] client denied by server configuration: /home/[domain]/wp-content/themes/duster/footer.php
[Sat Jul 20 02:30:38 2013] [error] [client] File does not exist: /home/[domain]/forbidden.html
[Sat Jul 20 02:32:44 2013] [error] [client] client denied by server configuration: /home/[domain]/wp-content/themes/Super_Real/index.php
[Sat Jul 20 02:32:44 2013] [error] [client] File does not exist: /home/[domain]/forbidden.html
[Sat Jul 20 02:32:50 2013] [error] [client] client denied by server configuration: /home/[domain]/wp-content/themes/Super_Real/File_M/index.php
[Sat Jul 20 02:32:50 2013] [error] [client] File does not exist: /home/[domain]/forbidden.html
[Sat Jul 20 02:32:55 2013] [error] [client] client denied by server configuration: /home/[domain]/wp-content/themes/Super_Real/File_M/F_M.php
[Sat Jul 20 02:32:55 2013] [error] [client] File does not exist: /home/[domain]/forbidden.html

Being unable to get the shells to work, the attacker modified the main index file of the active theme – Twenty Twelve. This was important because the index file would be loaded by default when WordPress loads, in this instance they turned the main theme into the shell. Using that, they used the shell they uploaded to upload another shell at the root.

You can see this here:

[20/Jul/2013:02:33:41 "GET /wp-admin/theme-editor.php?file=index.php&theme=twentytwelve&scrollto=9456&updated=true
[20/Jul/2013:02:33:47 "GET /
[20/Jul/2013:02:34:06 "POST /

You then see the backdoor file appear at the root, XfX.php, and subsequent requests to verify that one the file is there and second to apply POST requests against the same file:

[20/Jul/2013:02:34:11 "GET /XfX.php
[20/Jul/2013:02:34:15 "POST /XfX.php
[20/Jul/2013:02:34:24 "POST /XfX.php
[20/Jul/2013:02:34:28 "POST /XfX.php

When you navigate to the file you see:

Sucuri - Backdoor

In case you’re wondering, that one file allows them to do exactly what I described above. The attacker can inject files, make modifications, execute server commands and other similar nefarious acts against your website and server.

Closing Thoughts

In this case study the results of the attack were less than exhilarating. It came down to a basic defacement, which for the most part causes no real irreversible damage to the website visitors. If you maintain solid backups, recovering from a defacement is often fairly straight forward for the website owner.

If you are a client and don’t have backups you should look into using our Website Backup solution.

The real challenge however comes into play with what else the attacker did. While the defacement was less than exciting, watching how the attacker went about injecting various backdoors is very interesting. Although unable to execute php within the wp-content directory they were able to use the default loading of the theme files to execute their injection, placing it in a directory in which PHP execution is allowed, the root of the site.

Looking back however you can quickly identify at a minimum three critical things that every website owner is able to do, in a layered defense approach, to avoid a similar attack:

  1. Password strength and uniqueness
  2. IP WhiteListing or Two Factor Authentication
  3. Disabling of Theme / Plugin Editors
  4. Use of a Web Application Firewall (WAF)

In this approach, the attacker would have gone through a series of defenses that would have likely deterred the attack to the point where they would move on to another target. For a more in depth discussion on the various things you can do within your environment you can read one of our hardening articles – Cutting Through the BS. But here is a quick breakdown of what I would have employed if I was trying to avoid a similar attack:

  1. Use of a random generator and password manager – LastPass
  2. IP Whitelist through CloudProxy and Two Factor Authentication through Duo Security
  3. Disabling of Theme / Plugin Editor – via wp-config.php
  4. Use of CloudProxy as the Web Application Firewall

Hope you find this information helpful.

  1. Excellant read, Tony. Any indiciation why they went through the effort for a seemingly “not important” site (no offense)? I assume all of this wasn’t automated.

    The thought of disabling theme/plugin editor hasn’t accorded to me, but if clients will never use it seems best to turn it off (at least in my cases).

    1. It could have been the name of the domain that caught their attention, it could have been a normal scan of the interwebs that led them to the site. Hard to say, don’t think anyone can provide insight into that unfortunately. Could have been nothing more than something of interest as they surfed the web. Very speculative though…

      I am a big fan of disabling the theme and plugin editor, too many attacks happen via that method once wp-admin is gained. And you’re right, your average website owner doesn’t even need it.

      1. Many sites publish their theme, plugins and sometimes even the WordPress version in the sites meta info or in the file paths referenced by the theme’s HTML. If you were a hacker and knew certain things had vulnerabilities, wouldn’t that be the sort of thing you’d search for to find suitable targets?

  2. I just protected my wp-login.php agains bruteforce attacks and won a lot
    – no bruteforce attacks
    – got full server performance (bruteforces on wp-login.php f*ck your server badly

  3. I just protected my wp-login.php agains bruteforce attacks and won a lot
    – no bruteforce attacks
    – got full server performance (bruteforces on wp-login.php f*ck your server badly

  4. Surprised these attacks have not changed much since about 2005 when they were common with other PHP/MySQL CMS apps that were popular then. Also surprised they are not fully automated and seem to have no purpose other than screwing around.

  5. Thank you for sharing Tony.

    One thing that comes to mind though when I noticed #3 in your closing:

    Disabling of Theme / Plugin Editor – via wp-config.php

    Once the attacker is already in, it’s possible to upload a FTP plugin and get access to the root and undo that line of code you would have added to wp-config.php

  6. Brilliant post guys, limit login attempts is another plugin thats great for security on WP, along with Securi and also restricting access to admin via htaccess based on permitted ip’s which i wrote a post about on my blog if any body is interested.

  7. Sadly I found this article because it appears that my wordpress site might have been attacked by this. I can’t log in. When I try, I get the word FORBIDDEN and nothing else on the screen. My website is still up and from what I can tell, nothing has changed from a visitor’s perspective. I just don’t know how to clean this up. I like what perezbox says below about disabling the theme and plugin editor. I’m not using Twenty Twelve, although it is still a theme loaded on the site. Its just disabled. And as soon as I get it cleaned up, I will use the list of 1 – 4 things above to deter such activity in the future. HELP PLEASE!

  8. A blog on security hacked by brute forcing passwords – an attack vectors of 90s and

    you nonchalantly write that your password was weak 🙂

  9. Whether you have good security is how hackers can find vulnerabilities and penetration. their job is. you are very good, but the hacker is probably better than thieves again

Comments are closed.

You May Also Like