Manually Identifying an X-Cart Credit Card Skimmer

During a recent investigation, a new client came to us reporting that their antivirus had detected a suspicious domain loading on their website’s checkout page. We regularly receive reports like these, as this is a telltale indicator of a credit card skimmer infection.

Our research and remediation teams frequently find credit card skimmers on Magento websites, and more recently on WordPress — however, in this case the customer was using a lesser known eCommerce solution known as X-Cart. W3techs.com estimates X-Cart to have a CMS market share of less than 0.1%, whereas they rank WordPress and Adobe-based platforms such as Magento with a 64% and 1.6% market share respectively.

In the spirit of security education, we’ll outline the process used to manually investigate and detect a credit card skimmer on a compromised X-Cart environment, along with some steps you can take to mitigate risk for your own sites.

Manual Detection of the X-Cart Credit Card Stealer

Before we get started, it’s important to note that JavaScript based credit card skimmers are loaded and executed by the website visitor’s web browser itself, and are often engineered to capture sensitive form inputs and exfiltrate the data to a remote server. Because the exfiltration is performed on the visitor’s browser, this makes it easier to identify compared to a skimmer that’s running on the server side.

Nearly every modern web browser offers a developer tools functionality, which can be used to gain additional insight into exactly what’s happening when you’re visiting a website. The Network feature handily logs every single request your browser makes when visiting a given page — and by using this, we can see what’s going on “in the background”.

Our client had already identified the malicious domain as hxxps://metahtmlhead[.]com, which helped give us a starting point for our investigation. The next step was to identify any malicious requests in our developer tools.

JavaScript malware can make requests to third parties to exfiltrate sensitive data without the website visitor ever knowing – unless they’re monitoring their network traffic, in which case requests to a suspicious server are immediately clear:

Did you know? 
It’s not uncommon for JavaScript malware to detect the presence of having your browser’s developer tools open, and refuse to execute if so. You can combat this by using system network monitoring tools instead, or even by detaching the developer tools from your current browser window.

Once we’d identified the malicious request in our developer tools, we were able to check the request initiator in the same window to determine exactly which line of code the request originated from.

While the initiator may usually be a file, such as /cart.php or /analytics.js, the initiator in our case was VM338:1. The “VM” prefix typically indicates that the JavaScript was executed through the eval() function, a common tactic by malware authors. We can mouseover the initiator to see the execution chain.

For example, an eval() statement loading from line 5 of a website’s index file would appear like this:

By following the chain on the suspicious requests loading on the customer’s cart.php file, we identified the infection loading from an eval() statement buried roughly 3,000 lines into the website’s HTML source code:

With the originating code in hand, this allows us to search the website files and database to determine exactly where it’s placed on the server. A search for the string eval(decodeURIComponent(‘(function yielded results: this infection had been appended to a core X-Cart file with the path ./skin/common_files/check_cc_number_script.tpl.

The template file check_cc_number_script.tpl was originally intended to validate the inputted credit card details — to ensure, for example, the CVV field wasn’t left empty before the checkout was submitted. The attacker’s injection of malicious code into this file is all that’s needed to cause the website to send any credit card details inputted into the checkout page to a malicious server.

Automated Detection & Mitigation Steps

There’s no doubt that manually detecting and removing a credit card skimmer can be a lot of work, and it’s not feasible for a business owner to dedicate hours per day manually keeping tabs on everything that’s loading on their website.

If you’re looking for an automated solution, Sucuri’s website security monitoring scans your environment on a routine basis and looks for credit card skimming infections just like these. Whenever issues are discovered, you’ll be notified immediately via our customizable alert system so that investigation and remediation can begin.

For site owners who need a hand with cleanup, our website malware removal services can assist you with detecting and removing any credit card skimmers, backdoors, or other malware infections found in your site’s environment.