Case Study: Complexities of “simple” malware

You know when you pull a string on a sweater and it just keeps going and going? You wonder when or if it will ever stop? From time to time, that’s how malware can feel. Even if you’re not a website security expert, it’s important to understand just how complicated hackers are willing to make their attacks in order to infect your website and 1,000′s of others at the same time.

What does complex malware look like?

Recently, our remediation team member Guilherme Scaldelai alerted me to an interesting infection that he had found on one of our client’s sites. Instead of just being some simple injection placed within the site code, the malware was systematic and meant to integrate with the structure of the site. This is what it looks like when malware gets complex. Let’s look at it step by step.


In this case, what is really interesting is that we didn’t just catch the result of the infection (infected files), but we also caught the infector (the script which infected them) as well. Let’s take a look at the infector functions to see what they actually do.

First, I’d like to thank the author of this malware for leaving the function names as they are and not obfuscating any of the code. I would have found all of this anyways, but this takes away a step.

As I read the names of the functions, the tapestry began to fit together. The most interesting functions are updateWormSource(), analyzePossibleIndexes(), addHtaccessRule($indexFileName) and checkParentDirectoryForWebsites() (pretty literal function name, there). The detailed analysis of all of this would be much too long for a blog post (1159 lines of code), so here is the simplified description.

When this malware is activated (probably from outside), it analyzes the environment it finds itself in and gets several system variables like site root path, host address and others. After this, it checks whether it has write permissions and starts to analyze the possible main “entry point” files. Here’s the code snippet.

Picture of malicious code

The next step is to rewrite the main index file (one of those on the picture above), and replace it with its own code, which backs up the original index file and serves it under certain circumstances. It actually creates backups of all the sys variables it got earlier, including all the paths and its own code inside the infector’s body. Finally, it has backdoor functionality as well by listening for commands from outside using a simple GET function. Here are the commands with the actual payload removed:


That’s a pretty nifty trick. Remember, this is just the infector and main processing script.
There are other interesting facts about the code—for instance, it’s written in objects and it checks for lots of other things–but describing all the other functionality is out of the scope of this post.


Let’s have a look at the actual payload. First, it’s important to understand that this malware functionality can be updated, so what I’m looking at here may just be this generation of this specific malware. In next generations, it could have completely different functionality. For example, instead of serving spam (like you’ll see in next paragraph) it could delete site files, focus on data mining or do almost anything else.

Here, the crafted index file doesn’t just contain some static spam links or spam redirections, but is also able to “listen” to commands from outside as well (via GET again). Take a look at the commands:


Here again, the full analysis of this malware would take 20,000 words as this part of the malware is 642 lines of code.

In short, by displaying the payload–various SPAM links—the malware is able to get them online from their “home” sites, which are part of their configuration and, per usual, these sites are changing all the time. For now, I found these sites, but can only guess at how many are out there:

The content of these sites is simple enough, just a white page with this picture of a cartoon worm:

What you see on these infected websites

There is PHP code making sure the correct content is served to the various requests, like getting new spam content for a particular site or new config variables, and they are, evidently, storing this info.
While analyzing this malware, I tried to craft several requests to these “home” sites which had the actual infected (and cleaned by us) website in them and got a long list of spam. When I tried a non-infected site, I got a “false” response, which could mean that this infection is part of some bigger, spam-distributing network. And why not? There is a lot of money in spam nowadays.

Finally, I was able to get a list of other websites infected by this malware, or, at least, other websites hosting the spam content by using a manually crafted request, and the network appears to large. We are processing these results right now and if we find anything, we’ll publish it here.

Malware removal: part art, part science, lots of work

At Sucuri, we’re committed to making the web a safer place, and we do that website by website and injection by injection. The injection that I’ve taken you through today was certainly complicated, but it’s important that everyone associated with a website understand that it was also fairly common. Our detection and removal methods are constantly evolving because we’re constantly being sent new malware examples at Sucuri Labs.

Much like doctors are constantly observing the flu virus mutate and evolve, we are constantly seeing the same with malware. As we get better at removing certain injections, hackers respond by making their code harder to find or embedding it within layers upon layers of code. Their hope is that the website owner or malware specialist will miss the injection or will give up when they see that they have to read 1,000’s and 1,000’s of lines of code to find something malicious, and this is why malware removal is art, science and perspiration.

As a malware researcher, I consider malware removal an art because I’m able to see patterns in code and get to the bottom of problems quickly. It’s a science because there are certain indicators that have to be present for malware to work, but then more than anything, it’s perspiration. It takes a lot of effort to keep looking through another line of code when neither art nor science has helped you to find it, but in the end, it’s worth it because we’ve uncovered another layered tactic used to distribute malware.

The goal for any spammer or hacker is to make their network as large as possible and to do that, they’ve got to make sure website owners can’t figure out how to find or erase the malicious code. For the DIY’ers out there, who get excited about cleaning their own websites, when you don’t share new and interesting injections, your fight against malware will go unnoticed so please share any interesting injections you come across with us. After all, we’re researchers at heart and are as excited as ever to do our part to make the internet safer for everyone with you.

For those of you who have been the victim of a hacked site, and don’t feel that you have the requisite knowledge to fix it yourself, let our team do it for you. We might even find something interesting enough to write about.

Read more: Case Study: Complexities of “simple” malware

Incoming search terms

Story added 19. June 2014, content source with full text you can find at link above.