The holiday shopping season is just around the corner, and it’s the time of year the eCommerce website owners need to be most on their guard. Credit card stealing malware, commonly referred to as “MageCart”, is most rampant during the holiday shopping season. Attackers are always aiming to maximize their profits. As such, they know that if they focus their time and efforts at the last quarter of the year they’ll have more stolen card details to sell on the dark web when the time comes to cash in on their ill-gotten gains.

We’ve dug through our SiteCheck and malware remediation logs to identify some of the most commonly identified card skimming attacks over the course of the last few months. In today’s post we’re going to perform a malware analysis of the most common MageCart injections identified so that eCommerce website owners can better understand the risks, and (hopefully) protect themselves, their websites, and their customers from attackers.

Let’s get started, shall we?

WebSocket skimmer

In checking the most common MageCart injections since August 1st of this year, this web socket skimmer tops our SiteCheck detections, having been identified on 432 websites. WebSocket card skimming infections appear to be getting more and more popular these days, even though the attackers need more specialised server software installed in order to administer them.

Identified eCommerce CMS platforms include WordPress, Magento and OpenCart. There are quite a few variations of this malware and portions of it appear to contain randomised characters, but they all start with the following string:

<script>const …

The full injection looks like the following:

Not all variations of this malware use the same characters, but they do use the same format and encoding. We can see the WebSocket loading some characters obfuscated with the fromCharCode function (one of the attackers favourites, it seems). However, simply entering that string into a simple fromCharCode deobfuscator returns only gibberish. In the above sample we also observe the following string:

const bzpy = 42

This is, in fact, an XOR value. Readers of this blog are likely familiar with XOR encryption: A simple additive cipher which can be reversed by applying the same value to the string. In this case, when we apply the number 42 as the XOR value we get our exfiltration domain:

wss://cdn[.]iconstaff[.]top/common?source=

This is not the first time we’ve noticed the number 42 used as an XOR cipher in malware injections (in fact, I think at this point I’ve lost count). This number actually pops up a lot in various tech and programming contexts! It is in fact a geeky nod to Douglas Adams well-known novel The Hitchhiker’s Guide to the Galaxy, famously being referenced as “the Answer to the Ultimate Question of Life, the Universe, and Everything“.

jquery hex skimmer

Next up we have a hex-encoded skimmer identified on both Magento and WordPress, with roughly equal distribution between the two platforms. This has been flagged on 325 separate ecommerce websites since August 1st. Readers of this blog will recall that there’s been a steady trend over the last years of attackers “recycling” MageCart malware originally intended for Magento and porting it over to WooCommerce websites.

The first samples of this malware that we identified were lodged inside of the core_config_data database table in Magento (where miscellaneous scripts such as Google Tag Manager and Facebook tracking pixels are often placed by the website owner) and, interestingly, loaded inside <svg tags (scalable vector graphic) and executed in the victim’s browser using the onload function:

The malicious JavaScript creates a fake payment overlay on top of the checkout page, with payment details submitted by customers intercepted by the attackers.

Now that we are seeing more of these infection on websites using WooCommerce the most commonly identified file/path this was injected into was the following WordPress core file:

./wp-includes/js/jquery/jquery.min.js

Here’s a snippet of what the injection looks like at the bottom of one of these WordPress jquery files:

But what on earth is this doing? Let’s try to take it apart! To decode this, we need to coax this JavaScript into spitting out what’s hiding behind the hex encoding. In order to do that we first need to substitute this:

new Function (n)()

To a simple console log:

console.log(n)

And, once we run this (in a safe, isolated sandbox of course) we get the following:

Would you look at that! Another web socket using the number 42 as the XOR value. In fact, this code looks remarkably similar – dare I say nearly identical – to the first sample we worked with. The primary difference being the exfiltration domain, in this case:

wss://cpeciadogfoods[.]com/common?source=

I’m willing to bet that these are probably the same MageCart threat actors as our previous sample, although I suppose it’s also possible they could be copycats. Attribution is a difficult game in this business.

r.blob skimmer

This one was initially identified on a WooCommerce store but, naturally, eventually found on other eCommerce platforms as well. This injection clocked in at 293 detections since August 1st. Our first discovery of this malware appeared as a lengthy base64 chunk of code in the database:

Note the “woocommerce_checkout” shortcodes that it is lodged between. Now, the fact that the content is base64 encoded is not, actually, itself suspicious. Some visual website builder plugins save all of their data in this format in the database, that’s just how they work (which is the case here). However, if you see some sketchy domain loading on your checkout page, it does add an additional step to locating where it’s coming from since you cannot query the database directly for it.

Let’s chuck this into a decoder and see what we get:

All right, a little bit better but still not all the way there! Astute readers will recognise this as “URL encoding“. Just to bring everyone up to speed real quick: URL encoding is a method of encoding characters such that the address bar in your browser can interpret and run/query them properly. So as a quick example, you cannot use spaces in a web address; instead, it gets converted to %20.

Every character will have an associated URL encoded value, such that no matter what language you speak or alphabet that you use you can still use your web browser and interact with the web with everybody else.

Anyway, back to business. Let’s go ahead and convert those URL encoded values into something us mere humans can read properly:

This, I think, is the most straightforward of all of the skimmers that we’ve reviewed so far (at least it was the easiest to decode). We can see that atob JavaScript function in the top of the screen shot, which converts the base64 encoded values into the following:

So, in summary, if the URL contains the string “checkout” but does not include “cart” it will load the skimmer and exfiltrate the card and customer details to that kondigit domain.

Of course, on other platforms such as Magento, these injections would likely just be plaintext <script tags in the database and we wouldn’t have to go through the business of peeling back the base64 and URL encoding at all.

Smilodon reloaded

Two years ago we reported that the MageCart hacking group Smilodon had shifted their operations from Magento over to WordPress. In our 2023 Threat Report we also concluded from our internal data that Smilodon was in the top three most common credit card skimmers identified in compromised eCommerce websites, primarily taking the form of malicious WordPress plugins. Since these skimmers are PHP based they cannot actually be identified externally or seen by antivirus programs, which is likely one of the primary reasons they’ve been adopted by these attackers.

Today, we see these attackers have refined their malware even further. Instead of using standardised names such as wpputty and wpzip, they’ve now opted to go with randomised names instead, for example:

./wp-content/plugins/sytaqanyxen/sytaqanyxen.php
./wp-content/plugins/adixiraqeh/adixiraqeh.php
./wp-content/plugins/ikytigy/ikytigy.php
./wp-content/plugins/ylapecadag/ylapecadag.php

These variants have been around for a couple of years as well but are still in active use today. In fact, it’s our most commonly detected PHP based skimmer infection.

The malware is actually quite complicated, and itself warrants its own dedicated blog post to take it apart. But for now, take a look at the primary plugin file here:

./wp-content/plugins/odekytyvyx/odekytyvyx.php

We can see that the malware is using some concatenation to include another adjacent php file:

include(__DIR__ . "/dac" . "olag" . ".php");

Would actually be loading a file called “dacolag.php” – let’s take a look inside that other file:

This is just the first few lines. Other than a few standard PHP functions like file_get_contents it just looks like gibberish. Further down the file we see this:

Again, we see the usage of concatenation to load a third file:

"/ass" . "ets/i" . "mages/" . "yqeji" . "j.png"

Which is actually loading:

/assets/images/yqejij.png

Now, let’s check this fourth file – the “image” file yqejij.png:

This is just the very top of a massive chunk of what – at first glance – appears to be base64 encoded content. However, when putting this through a standard base64 decoder, it produces nothing but rubbish.

Turns out, there are some additional steps to take to decode this. In fact, there are about five items in total in the assets/images directory, all with png and gif file extensions which all contain similar huge chunks of encoded content – each of them serving a different purpose in this credit card skimming plugin (in fact, it’s a full suite of tools including a web shell!).

However, we’re going to leave it at that for today, and we’ll continue with the analysis of the most recent iteration of the Simildon skimmer in an upcoming post!

Mitigation steps

As the holiday season approaches it’s probably a decent idea for eCommerce website owners to do a security review of their websites. After all, you don’t want to be in hot water with Visa or Mastercard a few months from now having been identified as a common point of purchase for stolen credit cards!

Take a few minutes to review this list to ensure the security of your eCommerce website:

• Is two factor authentication enabled on the admin panel for all admin users?
• Do all admins have strong, robust passwords?
• Are the plugins, themes, CMS core files and extensions up to date?
• If your website is Magento are all available security patches installed?
• Does your website reside in a secure hosting environment?

You can also check out some of our eCommerce-focused security guides here:

• WooCommerce security guide
• Introduction to Magento Security
• What is MageCart?
• WooCommerce Security for Store Owners
• How to Secure your Online Store

If you ever suspect that your eCommerce website has been compromised – for example, if customers are reporting stolen card details after having used your website, or if you or your customers are receiving antivirus warnings on checkout, then we can definitely help sort the issue out!