Woo Skimmer Uses Style Tags and Image Extension to Steal Card Details

This post starts the same way many others do on this blog, and it will be familiar to those who keep up with website security: A client came to us having been notified by their payment processor that credit cards were being stolen from the checkout page of their eCommerce website. The question of course was how? During this investigation we uncovered a very interesting (and in fact, creative) way that threat actors were pilfering credit card details from this compromised website.

In this post we’ll reveal how we uncovered the malicious injection, perform some analysis on the unorthodox (although not entirely unique) ways the attackers concealed their injection and payload, how exactly it worked, and – as always – go over some ways in which eCommerce website administrators can protect themselves from becoming victims from such an attack.

Let’s get started!

Inspecting Checkout

One of the very first things that is to be done while performing a MageCart investigation is to inspect the checkout page. This usually involves simulating a transaction on the website by adding an item to the cart, navigating to the checkout page, and inspecting the code. Although, it should be mentioned that this method only works for JavaScript (rather than PHP) based skimmers.

Ensuring that we’re inspecting the checkout page is important because most carding malware attempts to stay hidden by only appearing on urls which contain the string “checkout”. This way the malware doesn’t load on every page (it doesn’t need to in order to accomplish what it wants to do) and is more easily concealed from the website owner and from external scanners. After all, it’s not often that an eCommerce store administrator is going to be purchasing products from themselves.

Now we have an item in our cart and have navigated to the page which asks us to enter in the payment details:

At this point we need to do 2-3 things to check if anything is amiss:

1. Check for any strange JavaScript loading on the page
2. Analyse the web traffic for any suspicious requests
3. Inspect the source code of the checkout page

For those of you who aren’t familiar, by right-clicking a webpage and selecting view-source, you can peek “behind the scenes” at some of the attributes and formatting which make up the web page that displays within your browser.

In this case, that was the first step in revealing how the client’s customers’ cards were being stolen. We came across this questionable item while scrolling through the source:

This is some very peculiar looking code, and at first glance it’s not immediately apparent what it’s even doing. Note the <style (rather than <script) tags – more on that later.

The way that the malware was injected into the checkout page was actually pretty straightforward: All the attackers did was simply edit the checkout page source, either from wp-admin (using a compromised administrator user) or directly through the database:

Which is a great reminder of why securing your wp-admin panel is of the utmost importance!

Reverse Engineering the Malware

So, now we must ask: How exactly was this gibberish code stealing credit card details? It doesn’t seem to reference anything obviously related to credit cards (such as numbers, expiry dates, or anything else you might expect).

Of particular note is this string right here lodged in the centre of the sample:

%/spuenlmrt-rbpotepw.ao-eoo-ee1dukc/tc/cd-ci%leeitilntonpwpxgls-do%

This, of course, looks like absolute rubbish. But in fact, it’s actually a heavily obfuscated string and the key to determining how this works. The malware uses a custom scrambling mechanism utilising character substitutions and shuffling.

By taking the obfuscation logic and running it in reverse we can unscramble the characters back into their original order and are met with this:

/wp-content/uploads/cropped-rec-unlimited-logo-1.webp

Well, well, well! Let’s take a look at that “image” file and see what we find:

Again, pretty incomprehensible at first glance. However, one important thing of note is the chunk of data at the very top which doesn’t seem to match the rest:

This is typically what an (actual) image file looks like when opened in a text editor. In fact, this was legitimate image data. When opening this file in a regular image viewing program we were met with a copy of the infected website’s custom favicon! This serves a sneaky and important purpose: when the website administrator is scrolling through their media library in WordPress this file would simply show up as their friendly-neighbourhood favicon for their website and not arouse any suspicion. Credit where credit is due, that is nice attention-to-detail. We won’t include the favicon here for privacy reasons, though, of course.

Fake Payment Overlay

The contents inside of the .webp “image” file were pretty huge and there was a lot of obfuscated content to parse. However, the closer you look, the more it starts to seem like a comprehensive payment portal, albeit an obfuscated one. Strings such as the following were even readable in plaintext:

credit
expiry
CVV
company
HolderFirst
HolderLast
Name
SendData
GetCCInfo

As well as hard-coded references to the payment processor that it was imitating.

So, that begs the question – why would the attackers split up their payload like this? Why not just put the fake payment gateway directly into the WooCommerce checkout page? Well, to stay more hidden, of course!

When checking the view-source of an infected eCommerce website certain variants of MageCart JavaScript are painfully obvious to spot. For example, this code was found on the checkout page of an infected Magento website:

Big chunks of heavily obfuscated JavaScript like this stick out like a sore thumb, and it’s really not at all hard to spot. By keeping their main payload sequestered off into a separate file hidden from view, they can keep their visible payload in view-source more discreet and not as immediately obvious.

Style Tags

One final detail of this malware has not yet been explained: The <style tags. How can malware execute as JavaScript without <script tags?

This is not actually the first time that we have seen this. Three years ago we also posted about a credit card skimmer which used style tags (albeit in a different fashion). But, how exactly does this work?

Style tags are normally used to include CSS in HTML documents – however they can also have event attributes such as onload, which is exactly what is happening here:

<style onload="var _$_a10a=(function

Onload will execute a script once a web page has finished loading all of its content. So, the fact that the regular <script tags are missing doesn’t mean that it cannot execute JavaScript in a similar way in the victim’s browser as they are inputting their credit card details into the fake payment form.

Ultimately, this was a very well thought out and detailed skimming attack. There were no obviously malicious domains loading scripts on the checkout page, the footprint within the checkout page was overall quite minimal, and the main payload (in addition to the file location being concealed with some complicated character substitution) was cleverly hidden behind the website’s favicon image.

Protect Your Website!

If you operate an eCommerce website then security should be given priority from day one. The last thing that you want is to get in hot water with payment processors after having been identified as a common point of purchase, let alone having to potentially pay hefty fines for having a carding attack gone unresolved.

Be sure to operate your website with security best practices in mind:

• Use 2 factor authentication whenever possible
• Protect your wp-admin panel
• Use robust passwords
• Regularly update and maintain all software (plugins, themes, core files)
• Use a website firewall

As always, if you’ve found yourself a victim of an attack or even just want to be proactive and improve your website security, we’re always here to help!