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

Every day we find many Magento credit card stealers injected into different files: modules, core files, themes. Magento database is not an an exception.

For example, this credit card stealer was found in the core_config_data table. The obfuscated database injection begins with the following code:

Read More ...

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:

Read More ...

With the outburst of mobile-only malware, we’re seeing a lot of mobile-devices targeted campaigns in last years. There are lot of ways how to make sure that the malware / redirect will be activated only on such a device, including mobile-platform UserAgent detection and similar.

Our analyst Douglas Santos noticed, however, one unbelievably simple method. What’s the main difference between mobile and your computer? Yes, the screen size…

<script type="text/javascript"> 
if (screen.width <= 480) {
window.location = "http://malicious-domain-replaced.com/43ee0b11-0ec3-4bcf-b6a7-7f14895df667";

The redirect was activated only when the site with it was opened on a small screen (which is a really nice indicator of a mobile device).

Mobile times are here and the attackers know that. We should be aware of our devices security and that each of us is targeted through our little electronic friends. As webmasters, we should know that if we don’t see malware on their sites maybe it’s just because the malware targets a different device. Stay safe!

Pop-up ads are annoying. Unfortunately many sites rely on them to pay for their operational expenses and even to make some extra cash. However when you see pop-ups on your own site and you never added such ads yourself, you know that something is wrong.

Recently, an owner of a vBulletin forum asked us to help remove unwanted popups from their site. We noticed that web pages made requests to is[.]gd/KHoxPa and is[.]gd/a8nxlP, which in turn loaded ad scripts from onclickads[.]net and go.pushnative[.]com.

Upon further investigation, we found the following code injected into clientscript/yui/yuiloader-dom-event/yuiloader-dom-event.js:

Read More ...

Recently we wrote about how hackers hijacked payment process on an ecommerce site and redirected customers to a fake checkout page on a third-party site. This sort of attacks is not limited to online stores. Even non-commercial sites may be affected.

This week we cleaned a compromised site where hackers managed to upload backdoors and quite a few other malicious files. At first it looked like typical infection. But there was an interesting detail.

Read More ...

Some people are unfamiliar with the Drupal CMS, it doesn’t enjoy the popularity that some others do like WordPress and Joomla, but it's a powerful CMS none the less. Compared to the way WordPress is structured, Drupal is a big monster! There are lots of included files, modules, and of course… a lot of places for malware to hide.

Read More ...

In order to avoid detection and maintain access to compromised websites, attackers use different techniques to hide their malicious code.

During our cleanup investigation we identified an interesting malicious code that pretended to be a legit Joomla core file. In this particular case the attackers based their malware on the libraries/application/application.php file from the 1.5.26 version.

The malware acts like a regular backdoor, allowing arbitrary command execution on affected websites.

Here is a snippet of the code that reveals the backdoor:

Read More ...

During an incident response process performed in our client’s website, one of our analysts found a very interesting web shell. Our tools detected a suspicious file called "./v8.php" and after some time decoding it, we found out that it was a backdoor giving full shell access to the attackers.

Read More ...

We wrote multiple times about various attacks on e-commerce sites that try to steal credit card details of their customers. In most cases, all such attacks need is the shortest moment when the site processes the payment details. It can be an injected JavaScript that steals your data as you enter it in the order form. Or it can be a server side script that builds itself as a middleman between the code that receives the data from user and the code that sends that data to a secure payment gateway. Note, in both of these scenarios e-commerce sites don’t even try to save the credit card information on their servers. The mere fact that they have the payment form on their own domain is enough for hackers to hijack it once they break into the site.

However, hijacking a payment form means that hackers can only steal details of ongoing payments. They have to wait for people to buy something from the compromised sites. But if hacked sites use really poor security practices and save all the payment details on their own servers, the attackers can easily steal credit card details of their customers without having to wait for new victims.

For example, in some versions of PrestaShop, there are standard tables (ps_payment_cc and ps_order_payment) for storing all credit card information (card number, expiration, card holder, etc.). Unfortunately, some PrestaShop payment modules indeed save credit card details in the database, so hackers just couldn’t help taking advantage of this.

Read More ...

Recently we cleaned a site that had a malicious wp-page.php file at the root of the WordPress site. It was responsible for pharma spam doorways created on this site. The file was quickly located and deleted. To our surprise, when we loaded that wp-page.php in a browser to verify that the problem was resolved, the malicious content was still there. And the headers stated that it was not a cached page.

We checked the file on server - indeed it was there with a very fresh modification date. We deleted the file again and a few seconds later the file was recreated. This behavior was typical for malware that used cronjobs to reinfect sites. However, when we checked the user’s crontab, we didn’t find any suspicious cron jobs there.

Read More ...