Malware writers can be really ingenious when it comes to obfuscating their code. And let’s face it, in today’s anti-malware push, they have to; the slightest variation will often trigger warnings that will make it look suspicious in turn shortening its life-span.
When we talk about obfuscation the first thing we think is base64 encoding, gzinflate or any other built-in function that will help making the code illegible for the average user, but they’ll often stick out to the trained eye.
With that in mind, obfuscating the malware code to look like good code is the best approach to make it last longer.
At first glance it may be a good code, right? Just some color arrays to make Joomla work correctly…
But, that function init_colors($colors) is actually converting those arrays into a string. Before that, you can find a call to preg_replace that consolidates all those arrays into:
Which decodes to:
This filename is not encoded, it is stored with this strange name.
Opening the strange file you find a complex spam tool, here is a quick snippet:
The most interesting part is that it is logging all access, if it’s a bot or a human, and it decides if the spam code will be shown based on the referrer quality, language and other variables to improve the SEO attack.
If you’re wondering what it’s showing, you can see it here:
Other thing is that the code was tailored specially for the site, using fullpaths for all includes, instead of relative paths as usual.
This shows us that using scripts to find base64 encoded strings are not as effective (or they never were) as most people think and finding spam is getting more and more complicated.