So our Malicious Page of the Month for September is out now. Going over the details of the document, I wanted to re-visit an old habit I had back in the days of putting code to the test – especially when the code in subject is simple, and has been signature to hell by every security vendor already… You guessed it right – code obfuscation (or more precisely – the de-obfuscating function).
So here are the basics – index.php is a highly malicious page being served by a crimeware toolkit somewhere (see the MPOM for the specifics). It contains a de-obfuscation function (df) and a call to it with a long parameter that looks like garbage, but then open up to some nice exploit code.
Running it through our friends at VirusTotal – here is what comes up (not a competitive analysis, no one is responsible for the results, etc, etc…):
OK, that’s pretty decent – 15 out of 32 (database unreachable is not a malicious detection – on previous runs it came up with nothing)… Now, wondering what makes these things really tick, let’s neutralize the malicious part of the file. Let’s just completely make it useless – and pass an empty string to the de-obfuscating function. This should obviously not be blocked, since the end-result is non-malicious, and these obfuscators are being used for harmless code as well.
Aha! Someone does not like this coding… So what really happened is that the de-obfuscation function is the one being scrutinized, and not the malicious code that end up running on the machine. So to our final step in the game – play a bit with the function, make it look nice and just change a couple of parameter names. No functionality change, just a bit of cosmetics (function name change to asda, 2 parameters changed names, code got through tidy…):
Conclusion – don’t believe everything you see… it may actually not be that bad… just make sure you take a close look at what’s really going on under the hood
Leave a Reply