Today’s story starts much the same as many others on this blog: A new client came to us reporting that credit card details were being compromised from their checkout page. The website owner had even been contacted by a major credit card company who had identified their domain as a “common point point of purchase” of reportedly compromised cards. Thus begins our investigation into tracking down the culprit.

Magecart infections in OpenCart

Magecart is the nickname given to web-based malware that harvests credit card data from compromised ecommerce websites. It has been around since roughly 2015 when cyber criminal groups began exploiting vulnerabilities within the Magento ecommerce platform. Since its inception it has also evolved to target other CMS platforms as well, including OSCommerce, WordPress / WooCommerce, and — as we will see today — OpenCart.

Attackers will target whatever ecommerce websites that they can. In 2021, Magecart infections detected by SiteCheck in WooCommerce WordPress environments actually overtook (and eventually eclipsed) Magento. Furthermore, they’ve evolved from being primarily JavaScript infections (detectable in the browser and by antivirus programs) to backend, PHP infections; primarily malicious plugins in WordPress / WooCommerce environments. This makes research into MageCart infections challenging for researchers who do not have access to the backend code of a compromised website.

Today we will investigate one such backend PHP infection which tampered with an otherwise-legitimate payment gateway.

Process of elimination: investigating the OpenCart ecommerce malware

The first thing to do when investigating such an infection is to investigate the checkout page. Quite often this type of malware (if it’s JavaScript based) will only load once the user has placed one or more items into the shopping cart and navigates to the checkout page.

Although sometimes well-hidden, these JavaScript variants of MageCart are usually pretty easy to spot, particularly if you’re using a script-blocker browser plugin such as NoScript. In some cases, they try to impersonate commonly used JavaScript like Google Tag Manager, or may even be found lodged within GTM scripts themselves.

In this case, it seems that nothing suspicious was located on the checkout page itself. So, we turned our investigation to the backend file structure.

Establishing a time frame

One of the most important pieces of data when conducting an investigation into a compromised eCommerce store is when did the reports of credit card theft begin?

These investigations are oftentimes a needle-in-a-haystack type situation, but if you know roughly when the theft started happening then at least you sort of know what the needle even looks like, and roughly which part of the haystack to begin your search.

Reports from credit card companies are also notoriously delayed; it takes a while for multiple reports of compromised cards to come in and for the fraud analysts to connect the dots and establish the “common point of purchase”. By the time the store owner is contacted, the theft may have been occurring for several months already — which was the case for this particular incident.

Once we were able to establish a time frame as to when it started we were able to track down the culprit of where the credit card skimmer was hiding.

Empty lines of code reveal compromised OpenCart payment module

It seems that the attackers had manually modified one of the key files responsible for the processing of payment information on their OpenCart website; this is very similar to another credit card skimmer that we recently wrote about.

Lodged below several dozen empty lines of the end of the legitimate payment processing code was the malware:

./catalog/controller/extension/payment/authorizenet_aim.php

Scrolling down the code revealed what kind of information the malware was gathering.

The malware is grabbing all the usual suspects that skimmer malware like to gather, including:

• Credit card number
• Expiration date
• CVV
• Name
• Address
• Country

But it’s also harvesting information like the user agent of the victim’s card, their email address, IP address and phone number. Most likely attackers were logging the user agent in order to filter out unwanted bots pretending to make orders and ensure that the details they were stealing were all from legitimate customers.

Stolen credit card details dumped in plisio/cache directory

Oftentimes skimmers will hard-code a third party server or website where these stolen details are exfiltrated to. However, in this case attackers preferred encrypt and dump the stolen credit card details into a directory on the website itself:

We can see the target directory in the above screenshot:

./system/library/plisio/cache

The details are encoded using the following methods:

• Converted to JSON format
• Encoded using base64
• Compressed using zlib with ZLIB_ENCODING_DEFLATE

The malware then uses file_put_conents to dump the intercepted payment details into a bogus “cache” directory for an unrelated payment gateway “Plisio” which allows ecommerce websites to accept payments in cryptocurrencies such as Bitcoin. The target website did have Plisio installed and was accepting crypto payments, so this may have been an attempt by the attackers to have a veneer of authenticity.

Sure enough, when navigating to that directory we found quite a few examples of stolen credit card details dumped into randomly named files.

All the attackers would have to do is use something like wget to grab the stolen information, or take it from the server directly if they still had access.

How to protect your website from skimmers

The holiday season is just a few months away, and credit card skimming attacks tend to increase around the shopping season. If you are an ecommerce website owner, remember to keep security as a high-priority in order to protect not only your website and its reputation, but your clients and their information as well.

Some steps you can take to protect your site from skimmers include:

• Keep your website software fully up-to-date and patched, including core CMS and extensible components.
• Regularly scan your website for malicious code, blocklisting, and errors.
• Employ file integrity monitoring and server side scanning to detect indicators of compromise and malware on the server level.
• Secure your administrator panel with 2FA to help protect against brute force.
• Use long, complex, and unique passwords to mitigate password guessing.
• Install a website firewall to stop bad actors and virtually patch known vulnerabilities.

If you suspect that your website is already compromised or you’ve gotten complaints from customers about credit card fraud after using your site, then we can help! Get in touch with our website security specialists for quick malware cleanup and remediation.