What do you do if your WordPress website is hacked? Does your company have a procedure in place to deal with an intrusion or defacement? The damage can be long lasting and hard to recover from, unless handled properly, so this article aims at covering the topic in-depth! Its a “techy” article because of the subject nature but I aim to demystify some of the nonsense that surrounds the hacking process.

By some estimates, WordPress is used by 17% of the top 1 million websites! Even governments around the world use it in several instances.

It is starting to dwarf the competitors which makes it a good platform for developers and designers. WordPress is very well coded and great for business use but not all developers take the same care as the folk behind the most awesomest CMS around. The massive development community created around WordPress is both its boon and its bane!

There are many free and paid plugins, templates, and mods available but many are insecure at some point or another in their development cycle. Persistent hackers scan the internet for the vulnerabilities and use them to exploit a website. So, let’s crack on with some interesting stuff…

Main causes of a WordPress hack

In a perfect world all websites would look amazing, code would be secure, and functionality work as intended. The world is not perfect and Santa doesn’t exist (sorry, kids :P).

The main causes for a WordPress exploit are listed below:

  • The WordPress core files missing validation
  • Insecure server setup
  • Template vulnerabilities
  • Plugin vulnerabilities

It is almost impossible for us to mitigate against the first of the above possible vectors of attack. We don’t control how WordPress is developed, but it has a good track record for security so we have to rely on that.

The second item on the above list, insecure server setup, can be difficult to setup and depends on the server configuration which would require far more detail so we won’t cover that in this article. You should inform your hosting provider if you discover your website has been compromised to any extent, even if it may not seem important as they should review the incident as it may affect other customers.

Moving onto items three and four; the massive amount of plugins and templates available for WordPress is it’s single biggest weakness. WordPress has a process in place to verify the content of extensions and themes published on their website but can’t be expected to stop all problems and, fairly often, they don’t.

Even completely custom templates and plugins can have security holes which go undetected for months until a pesky hacker turns up and puts the right code into the right place.

So, why would someone try to hack your website?…

Reasons for exploitation and damage caused

Website hacking has moved on from the days of replacing pages with funny images or political messages; there are far more cunning things a potential hacker can get up to these days. Below is a list of common reasons someone may try to hack your website, in no particular order.

  • Stealing login details or other database information
  • Vandalise (“deface”)
  • Gain access to other websites on the same server or full server access (“root”)
  • Steal the server’s mail (“spools”)
  • Redirect visitors to another website (“malvertisement”)
  • Insert viruses
  • Insert advertising
  • Steal source code
  • Delete data
  • Store illegal files

I have probably missed a few out, but you should be scared enough by now and if you’re not just pretend they can force you to vote Tory!

Some of the above are fairly obvious to detect, such as exploitation to deface a website, but many can go unseen by the majority of visitors for a long time. “Black hat” SEO engineers — those who hack to earn money — often use very clever code to hide their actions from everyone except Google so it may take months for them to get detected!

All it takes is for a visitor to be able to insert a single quote in the wrong place or an ad hock administration script (“shell”) into your database or file system and all of your data could be exfiltrated and passwords sold within minutes. The best case scenario is probably a smart spammer inserting spammy links into your pages which could harm how it gets placed in Google’s search results or even banned altogether.

Back up everything

Yes, this section has it’s own subheading. Its that important!

The first step to recovering from getting hacked should always be to make a complete and fresh backup of the website in question. You should use phpMyAdmin to export the database and an FTP client to backup all of the serverside files.

We should also make a backup of “Raw Access Logs” on the server. This will show requests sent to your website usually indicating a point of attack and details about the attacker. There is a handy video guide available — youtube.com/watch?v=ALx-P_Vbw08 — if you use cPanel, which the majority of websites do. You should always inform your host of a website breach, especially if you can’t get access to the Raw Access Logs!

Note: Because the logs are stored in gzip format a program capable of opening it is required. 7-Zip works just fine and is free so I recommend using it.

I can’t stress this enough. Make a clean backup then zip it up or make another copy to work on. We aim to recover the website, not start again. If you make a mistake or something doesn’t work you can just restore from the full backup.

Once we have a full backup of both the database and the files we can continue.

Finding the point of attack

Now we have a backup and logs to trawl through we can proceed.

The first step I always follow is to use a tool called Sucuri site check. Enter your home page URL into the box, click “scan website” and wait for the magic to happen. After about 30 seconds you should see a Security report which shows several useful things worth noting. Be sure to check the “Website details” and “Blacklisting status” tabs for more details as they also contain vital information!

The next step is most beneficial for developers. If you have a basic understanding of the MySQL query process you can scan the logs for common attack attempts such as “UNION+SELECT”, “='”, or “or 1=1”. If you aren’t a coder it is probably best to let your system administrator, hosting provider, or development team handle this step.

So what can we do to find the fiendish fellow that has abused our beloved website? Let’s imagine a bad guy, or gal (usually, men because women don’t often hack computers… or fart), inserted a link to a competitor’s website at the very top of your WordPress blog. An obvious step should be to search for this code and remove it.

If our imaginary link was:

<a href="http://hacker.com">nasty website</a>

We should use a program to search the files in our backup for a part of the coder which has been inserted and viewable in the page source code (you can view a page’s source code by pressing CTRL+U while a webpage is open), usually the domain name – hacker.com. My favourite way to search an entire directory is to use NotePad++. Open NotePage++ and press Control+F to open the search box then click “Find in files” and select the directory containing the hacked website files and click “find all”… Then wait.

Searching for a hacker

This will hopefully return the file name and line number of the offending code. Most hackers have found ways to prevent detection of simple fixes such as this by using obfuscation and steganographic techniques. Obfuscation and steganography are just fancy ways of saying they hide code or make their code hard to read, usually using encryption.

So, if your searches don’t return any results we should move onto common methods to obfuscate code. Below is yet another list. This time it’s for things to search for to find our hidden code (one per line):


If you find obfuscated code using a search term above you can try to reverse engineer it using a tool such as the “Unobfuscate PHP Hack Code” tool.

It has to go if you decode it or not. So delete the suspicious block of code and continue searching. It can be hazardous deleting code you are not familiar with and are unsure how it may affect the rest of the site, so this is where the trusty backup should come in handy.

The code will usually be between “script” or “base_64_decode” tags.

The code may be hidden in the database or the files but will usually looks the same… Like complete nonsense compared to the rest. The process is fairly simple; search for some funky looking code, delete it, test it, replace if it doesn’t cause the expected change or messes the site up.

Repairing the damage

The only real way to prevent a similar attack occurring in the future is to make sure WordPress, installed templates, and all plugins are up-to-date. So log into your WordPress admin panel and update everything. It’s worth noting that there is a small chance your website may break at this point if you haven’t been updating it regularly. If your site does stop working, disable all plugins and enable them one-by-one to see which one caused the error. Again, this is where the super duper handy backup earns its keep.

Repairing your website may not be the end of your issues as it could affect SEO and lead to your site being blacklisted from Google or other reputable services. If the Sucuri site check / “Blacklisting status” tab had anything flagged as an issue it is well worth informing the site that the problem has been fixed and you are no longer forwarding visitors to pictures of something large and phallic.

Once you are sure all the malicious code has been removed you should change any passwords to accounts with elevated permissions — such as administrators or editors — which can be done in the WordPress admin panel. Updating the salts used in /wp-config.php should also be done now as they can be used to access various functions of the script, so generate new salts and simply replace the relevant lines in yousite.com/wp-config.php file.


Proactivity. It’s like radioactivity, but more awesome!

There are steps we can take to help avoid any of this being needed. If search for, and find, any of the terms below you could have an issue. The first is simple: keep WordPress, plugins and templates up-to-date!

  • = $_GET
  • = $_POST
  • $_POST . ‘.php
  • $_POST . “.php
  • $_GET[‘page’].’.php
  • $_GET[‘page’].’.php
  • $password = $_POST
  • $username = $_POST

These attack vectors could be validated elsewhere and is by no means an exhaustive list, but it’s usually not a good sign.

There are premium services available, such as VaultPress, which will scan your website and even fix them if exploited which can be very useful. There are also some very expensive solutions which are almost useless *cough* HackerSafe *cough*

So there we have it. Hopefully it helped to demystify the process of exploitation and the recovery therefrom.

It may sound haphazard and unprofessional, but that’s all us coders really do. We bash the away at the keyboard until something interesting happens.

An alternate parable of David Ives infamous quote:
“Three monkeys hitting keys at random on typewriters for an infinite amount of time will almost surely produce Hamlet”
… Is often elegantly said as:
“Three programmers hitting keys at random on typewriters for an infinite amount of time will almost surely produce the internet”

The problem is simple: there are a lot of monkeys and not much validation. Being proactive can help prevent the damage to an extent but never completely as the system is based on third-party code. It’s not hard to fix but requires constant attention which isn’t usually accounted for. I guess the moral of the story is to give us coders some slack as security is, at present, very much an added bonus for most projects and isn’t usually costed for. Code can be fixed if it breaks but should be reported to the relevant people as it may affect other businesses!