Neapolitan Backdoor Injection

Most of us are familiar with Neapolitan ice cream: a flavour whose distinguishing characteristic is not one single flavour but several. Many also know it as the ice cream which your roommate eats all of the chocolate, leaving you with the paltry remains of the notably less popular vanilla and strawberry flavours. While cleaning a WordPress website of malware I recently came across an injection which I think can best be described as Neapolitan.

When attackers compromise a website in almost all cases one of the first things they typically do is plant one or more backdoors on the website. This is performed in order to maintain access even after the webmaster has changed their passwords or patched vulnerable software, resulting in many reinfections and very frustrated website owners to say the least.

Data from last year’s hacked website report shows that backdoors are the most common type of malware we see on a daily basis:

This is due to the fact that no matter what sort of payload the attackers want to deliver (be it malware, spam, or whatever else) they will always benefit from having a backdoor planted on the website. Some backdoors are quite simple and straightforward while others are large, ugly chunks of encrypted code.

Backdoor Detection Prevention

One technique that attackers use to hide their backdoors is obfuscation—playing with and altering their code in order to avoid detection from malware scanners.

Let’s take a basic example: A common function used in backdoors is the eval function, which allows arbitrary execution of PHP code. Any basic server-side security scan will search a website file structure for this function. Not all code that contains eval is malicious, of course, but it’s used quite commonly by attackers.

So what can bad actors do to avoid detection? One simple technique they can employ is called concatenation:

“e” . “v” . “al”

The server interprets this as ‘eval’, but if you search your file structure for ‘eval’ this string will not be detected.

This technique can be used/abused in extreme and bizarre ways, as seen below in a sample taken from a backdoor found on a compromised website.

This of course begs the question: What if the defenders catch onto your obfuscation technique? If all of your backdoors look the same, it doesn’t really matter how obfuscated or cool looking the code is; you can find all the back doors with one simple grep command.

Using the example above, I would search the file system for something like this:

“.””.””.””.””.”

This combination of quotations and periods is not a common string used in legitimate code and a clear indicating characteristic of a malicious injection. So, from the perspective of the attackers, what is the next logical step to avoid detection? The answer of course is to use multiple variations of the same code; the more diverse the better.

Backdoor Variability

Recently, I worked on a WordPress website in which over 30 separate variations of multiple backdoors were found, some of them bearing no resemblance to each other at all. This is important, because if you clean 99 backdoors from a website and miss 1, the website is still going to get reinfected (assuming the website is not protected by a firewall, of course).

After performing a WordPress core integrity check I found multiple modified files, each of them containing different backdoors.

Let’s take a look at the first backdoor I found. In this example, it was a wp-blog-header.php core file from WordPress that was compromised:

Now let’s take a look at what I found in the website’s index.php file:

Clearly another backdoor, but this one bears no resemblance to the one shown previously. It uses different functions and works in a totally different way.

Searching a file system for any identifying characteristics of the previous backdoor would leave this one totally undetected. Notice the big empty chunk of space right after the opening <?php tag: This is intended to hide the malicious code.

If you are viewing the file in a text editor that does not have word wrap enabled, you would need to scroll way over to the right-hand side in order to see anything; simple but effective. We see this sneaky technique all the time — so make sure you enable word wrap while manually checking files or use a command line text editor like VIM.

But wait, there’s more! Here’s what I found in wp-includes/class-wp-session-tokens.php:

Another backdoor, again completely different from the others. This one uses an interesting assortment of characters and strings, but in the end just sends a POST request to the server.

Using the example above, you could grep your filesystem for gD5 or fj9u, two small strings that would not likely be found in any other files. However, that wouldn’t detect this variation here in wp-includes/class-wp-widget-factory2.php:

Similar in structure, but containing few of the same strings. Note the ‘2’ at the end of the file name. The file wp-includes/class-wp-widget-factory.php is indeed a WordPress core file, but class-wp-widget-factory2.php is not. The contents of the files are identical, barring this backdoor of course.

What advantage does this give the attacker? It means that even if you update WordPress or replace your core files, this file will not be touched and will remain on the server awaiting the commands of the attackers.

Here we have another variation found in wp-includes/class-wp-user-query_backup.php here:

Again, the filename was adjusted in order to help prevent its removal.

Notice any pattern here within the backdoor code itself? Sort of but not really? That’s because there isn’t much of one. And that’s not everything we found!

Within wp-admin/includes/class-plugin-upgrader-skin.php I found this code:

This is a somewhat more ‘traditional’ looking backdoor, however, we found multiple variations of it scattered throughout the website’s core WordPress files.

And yet another type of backdoor found here in wp-includes/ms-default-constants.php:

We found several variations of backdoors using the array_filter function seen above as well, which has also been strewn among core files.

Most backdoor injections that we come across contain a few variations, but it’s not so common to find over a dozen of them during a single cleanup, not to mention abusing so many different functions.

So far, all of the above backdoors were located just by performing an integrity check of WordPress – but what about the other files on the server? Not satisfied with just the integrity core check, I decided to dig a little deeper on the server. But what to look for?

Backdoor Micro-Patterns

I took another look at these backdoors and had an idea: Why not use some very small strings from these files to see if I could detect anything else? I reviewed the code again, and decided on some simple but (probably) unique strings to scan the file system for:

}/*
$/*
${"
'}))?
<=$
&&$
( ${
*/))
/{"
: @$
:@/*
;@(
@${
@${@
@($
@(($
@((@
@/*
@@@
](${
@'_COOKIE'
array('options'
{@'
{@J}
@register_shutdown_function
T_POPSF
filter_var($
fj9u
gD5
array_filter (array
if(!empty($_FILES
if($_REQUEST[re_password
array_filter( array
if($_SERVER[HTTP_ACCEPT_CHARSET
array_filter(array
tcw940
xesi
{ @"
{/*
{@"

Sure enough, these queries yielded 15 new backdoors that were previously undetected.

Remember: If you find one backdoor on a server, there is a good chance there are quite a few more. If you were an attacker would you put all your eggs in one basket? Unlikely.

Computer security is often characterised as a constant arms race between attackers and defenders, each trying to outsmart the other in an endless cycle. We should expect to continue to see more and more cases of attackers using complex variations in their malicious code to avoid detection.

Finding Backdoors

So this all begs the question: What is a website owner to do? When cleaning a website, how can you find all these backdoors without leaving it open to attackers?

There is no easy answer to this question, but it all begins with file integrity monitoring. One of the most useful features of our Sucuri WordPress security plugin includes this functionality. It monitors core files and notify you of any changes, including mismatches between fresh core files and the ones on your website. It also notifies you of any modifications to existing files, as well as any files that have been added (or removed) from the WordPress core.

Remember: Not all malicious code is going to get detected by a security scan. The attacker’s job is to avoid detection as best and as long as they can; new malicious code gets written every day. For this reason, it’s important to utilize good file integrity monitoring and monitor any changes to your environment (OSSEC HIDS is also an effective solution to this if you have a VPS or dedicated server).

Another simple technique you can employ is to check your server for any recently modified files. If you have an SSH connection established, you can run the following command:

$ find ./ -type f -mtime -15

This will show any files modified within the last 15 days. Choose whichever number you want, but remember the further you go back the more noise that’s going to get generated. If you can find the last modified date of one of the backdoors, chances are most of them were injected around the same time. Remember though, time stamps can be spoofed.

Of course, the best thing to do is prevent the attackers from injecting the backdoors in the first place. Make sure all software on your website is updated frequently and all passwords used are robust and complex. Better yet, put your website behind a firewall service to shield your website from attacks.