Obfuscation Through Legitimate Appearances

Recently, I analyzed a malware sample provided by our analyst Edward C. Woelke and noticed that it had been placed in a core WordPress folder. This seemed suspicious, since no such core WP file like it exists: ./wp-includes/init.php

Deceiving Appearances

I started with a standard analysis and my first thought was, this has to be a legitimate file! Nicely structured, with very legit-looking function names. It even used Object Oriented PHP, which doesn’t happen very often in the case of malware. However, after a second look, something didn’t seem right.

The code sample included function names referencing MIME formatting standard, often used in emails and HTTP headers, which seemed out of place:

In general, there’s nothing in this code that would raise a flag at first glance:

 public function init() {
    $documentDir=$_SERVER['DOCUMENT_ROOT'];
    $mimeDesc=$this->getMimeDescription($documentDir);
    $this->extendMime($mimeDesc);
    $this->prepareDir($mimeDesc);
  }

A Behavioral Analysis Revealed More

There were, however, signs of completely unrelated pieces, including parts of core WP paths. So, I began a deep-code analysis and things started to become more and more interesting.

After a behavioral analysis, it turned out that the sample code tried to load and execute something from somewhere in a way that appeared definitely to be malicious.

At that moment I was absolutely sure we had malware on our hands. But how exactly did it work? A third look was necessary.

I started with an analysis of all the functions in the file, revealing that the majority of them were not used at all and simply served as a distraction. These functions also gave the malware a more legitimate look, including the comments which mimicked the way standard WordPress code is written.

Fake Content was Obfuscating Malware

After removing all of the functions and commented lines that were not being used elsewhere in the file, the number of functions was reduced from 12 to just 7 and code lines were reduced from 336 to 86!

Only ¼ of the code was actually vital malware code, the rest was just fake content. This was a clever way to obfuscate the file and make it appear more legitimate.

Piece by piece, I started putting together the real purpose of these functions. Despite getting rid of the fake content, it was still not clear exactly what they did. It turns out that some of the functions were used simply to obfuscate some function names and their parameters. This would definitely trigger the attention of a researcher’s eye and probably even our scanning engine signatures.

Analysis of the “executing” function gave me the answer to what was going on here:

This malware was loading the content of an “image” file and executing its content – exactly the result of the behavioral analysis.

Unfortunately, I was not able to get this “image” file since it had been removed. Based on the client’s infected site behavior, it appears to have been a script redirecting a visitor to spam folders created by the attackers in the infected site’s structure.

Conclusion

In the world of malware, things might not always be as they appear. Often, a second, third, or even further review is needed to identify and understand the malware.

Attackers are doing all they can to prevent website users, administrators, and even malware researchers to easily identify the infection. And we, as researchers, are doing everything not to overlook even the smallest malicious file. It’s a constant fight and so far, the result is a draw, but we keep fighting.

If you believe that your website has been compromised or may be concealing malware, we’d be happy to help. Stay safe.