During a recent investigation we uncovered another credit card skimmer leveraging a web socket connection to steal credit card details from an infected PrestaShop website.

While PrestaShop is not the most popular eCommerce solution for online stores it is still in the top 10 most common ecommerce platforms in use on the web, and clocks in at just above 1% of all websites (over 60,000 in total).

Attackers are not discerning with what platforms they attack. If a website is identified as a potential source to steal and sell credit card details on the black market then you can be sure that the website will be a target.

In this case our client was experiencing an antivirus warning when accessing their website (a common symptom of Magecart / card stealing malware). Specifically, the malicious domain here below was trying to load:

cd[.]iconstaff[.]top

It didn’t take long to find out what was causing it by inspecting the source code, lodged at the very bottom of the page:

But the real question was: How was it being placed there? Searching through the files and database for strings such as WebSocket turned up nothing, so this was a little trickier to locate than usual. In this post, we’ll review web sockets, skimmer malware, and how we were able to locate the source of this card stealer infection.

What is a web socket?

Before we get into the investigation let’s first quickly review web sockets, what they are, and why attackers use them in carding attacks. A previous post on this blog goes into more detail if you’d like to read more!

Essentially, a web socket is a direct connection between a client and a server, with continuous traffic flow being established in both directions. Unlike a basic http/https connection where there is a request from the client, followed by a response from the server, web socket traffic is continuous and goes in both directions at the same time:

This is useful for services such as finance and online gaming which require a lot of real-time conversation between clients and servers, where a clunky old HTTP connection would not quite suffice.

Attackers have also adopted the use of web sockets for the purpose of obfuscation. Analysing web socket traffic is more challenging than regular HTTP/HTTPS traffic, and not all analysis tools even support it at all. Specialised tools and know-how are required to dig into this sort of traffic. They’re also fit for the purpose of pilfering credit card details from infected checkout pages as we will see here.

The Investigation

As I mentioned previously, searching for strings of what we saw in the view-source turned up nothing. Many credit card skimmers can easily be found in an infected database simply by searching for things like <script or other portions of the plain-text injection.

Base64 encoded strings are also frequently used by attackers, but even querying for PHNjcmlw (<scrip in base64 encoded format) left us empty handed. Taking it a step further, thinking maybe the payload was reversed using strrev, searching for wlmcjNHP (the same string but backwards) also turned up nothing.

So, we went back to the basics. Credit card skimming malware can’t be injected just anywhere on a website into random files, it needs to load on the checkout page. For this reason, skimmers are oftentimes injected into core CMS files, theme files, certain areas of the database, or – in the case of WooCommerce WordPress websites – malicious plugins.

In this case, checking the theme files and extensions did yield a webshell:

Removing this should help prevent reinfections so we’re not entirely empty handed here, but it’s not the skimmer that we were looking for.

So let’s briefly review the basic steps of how a PrestaShop website works and start at the beginning, shall we?

1. index.php

The first file that loads in any PHP based website is the primary index.php file in the docroot:

./index.php

Different CMS platforms have different index files suited to load the rest of the core CMS platform, and are usually pretty basic. In the case of PrestaShop, the file is very simple and loads the config.inc.php file from the corresponding directory:

2. config.inc.php

Next, we have the config.inc.php file located within the config subdirectory.

./config/config.inc.php

This file is a lot more complicated than the previous one, and includes configuration rules such as the maximum allowed file size that can be uploaded to the website. It, too, includes/requires other files from within the environment:

So why don’t we take a gander inside that autoload.php file?

3. autoload.php

Sure enough, lodged at the bottom of this file was our skimmer:

./config/autoload.php

Note the version number of Prestashop here. According to the release archive 1.7.4.2 was released way back in 2018. A common folly of website owners is to get “stuck” in old versions of their CMS platform, oftentimes due to a highly customised code base which may not be compatible with newer versions of their CMS or even just PHP. It’s no surprise that a lot of these websites end up with security issues: One of the most important jobs of a website administrator is keeping the code base up to date. Reviewing the list of CVEs for Prestashop reveals a rich and storied history of critical security vulnerabilities, so take this as a lesson to keep your website up to date!

Malware Analysis

Now for the fun part: Let’s take apart this malware and see how it works!

Let’s start by removing the hex encoding to get a more readable sample to analyse here:

Here we can see the JavaScript code that gets injected and executed in the victim’s browser during the checkout process.

We can see that it’s using fromCharCode to obfuscate this string here:

93,89,89,16,5,5,73,78,4,67,73,69,68,89,94,75,76,76,4,94,69,90,5,71,21,89,69,95,88,73,79,23

This is a popular obfuscation technique especially favoured by threat attackers such as Balada.

However, using a regular deobfuscater on this just outputs rubbish. So what’s the trick here?

If you look carefully at the end of that string in the screen capture, you’ll see the number 42. This is actually a sneaky XOR value. XOR is a lightweight, simple obfuscation technique that essentially just shifts the values of a string. When we apply the XOR value of 42 to the above string we get the following:

119, 115, 115, 58, 47, 47, 99, 100, 46, 105, 99, 111, 110, 115, 116, 97, 102, 102, 46, 116, 111, 112, 47, 109, 63, 115, 111, 117, 114, 99, 101, 61

Which, when we put it through trusty ole’ Uncle Jim’s fromCharCode deobfuscator, we get our web socket payload:

wss://cd[.]iconstaff[.]top/m?source=

Do you operate an ecommerce site? We can help!

As an ecommerce website owner, ensuring robust security measures is crucial. You definitely don’t want a call from Visa or Mastercard identifying your site as a hotspot for stolen cards. Here are some practical steps to fortify your ecommerce site against credit card skimmers:

1. Regular Updates: Outdated software is a primary target for attackers who exploit vulnerabilities in old plugins and themes. Avoid this by consistently updating your site and applying the latest security patches. Alternatively, deploy a Web Application Firewall (WAF) for virtual patching.
2. Admin Account Management: Weak admin passwords are a gateway for attackers. Regularly review all admin accounts to ensure their validity and update passwords frequently. Make sure to use strong, unique passwords to bolster security.
3. File Integrity Monitoring: Implement file integrity monitoring to detect any unauthorized changes to your website files. This serves as an early warning system for rapid response to potential threats.
4. Web Application Firewall: A website firewall can effectively block malicious traffic and prevent hacking attempts from reaching your server.

If your site is compromised, don’t hesitate to contact us for 24/7 support. Our security analysts can clean up infections and help protect your online business.