Following the Trail of Malicious JavaScript

Magecart and similar web-skimming groups have turned e-commerce platforms like Magento and WordPress into prime hunting grounds. Obfuscated JavaScript is their weapon of choice, quietly injected into checkout pages to steal payment details in real time. These scripts rarely appear obvious as they hide behind layers of encoding, string manipulation, and dynamic execution, making them difficult to spot.

In this post, we'll walk through how these scripts work, how to examine their obfuscation with tools like CyberChef using our custom sandbox and analysis environment, and how to recognise the tell-tale patterns that reveal a skimmer hiding in plain sight.

We'll compare two attack flows/techniques, with website 1 involving code embedded directly on the site, whereas website 2 is a little stealthier and code is hosted on legitimate infrastructure (Google)

Website 1 - Malicious JavaScript embedded directly into the page

TL;DR - User visits a website, the website has been compromised (either directly modified via hosting account, site content manager etc) or exploited plugin, the JavaScript executes in the browser, and establishes a websocket with a remote host.

Selecting 'cart/:556' takes us to Debugger > Thread, and then displays line 556.

We can quickly see 'const pdng' which looks rather suspicious.

A quick CyberChef operation converting from decimal and XOR'ing each value by 42 (value of tsn), gives us our websocket host

How could this happen?

1. Website is outdated, plugin/code/something else is exploited, code is injected.

2. Website (WordPress & Woocommerce) login has been compromised, code is injected.

3. Website's hosting account has been compromised and code has been injected on each page.

Website 2 - Malicious Google Tag Manager (GTM) containers

TL;DR - User visits a website, the website loads a Google Tag which contains malicious JavaScript, JavaScript is executed client side, opens a websocket with a remote host and upon each action (entering a field, submitting a page, etc) credentials are sent via the socket.

Let's start with some basics.

What is Google Tag Manager? It's a standalone platform which allows you to manage Google Tags. Google Tags are pieces of code which are embedded on your site, allows you to track analytics and metrics, ad performance^[1], but importantly.. triggers actions.

What does a legitimate tag look like?

Here's what the default code for a tag looks like.

After you enter this on the parent page (or each page you want to monitor/embed actions into), you can define actions and variables in Google Tag Manager. In this example, we've created a tag, defined custom HTML/JS, and it will be embedded/triggered on each page during initialisation.

The victim's website

This is what the initial request would look like for a standard user, when browsing the victim's site.

User visits website > Site calls remote Google Tag/Javascript > Script is loaded into browser > executed

Selecting 'line 582 > injectedScript' in inspection tools, we can identify the first stage of the originating script. This takes us to the debugging function in the console.

We can quickly see the embedded JavaScript embedded as a variable inside the Google Tag Container.

The original snippet on the page which calls the actual GTM script.

What's interesting is the two consts which are defined, but then window.ww calls "mefz ⇒ mefz ^ pteo" - is this an XOR operation? We can run a quick XOR operation in CyberChef to check.

First we enter our string of numbers (including commas) from itl. We want to convert this from decimal, and then apply our XOR function (using the value of pteo = 42).

How could this happen?

Without knowing much more about the website, there would be a few attack paths;

1. Website is outdated, plugin/code/something else is compromised, GTM code is injected

2. Website's actual Google Analytics/Tag Manager account is compromised, and a malicious tag has been created/uploaded.

3. Website's hosting account has been compromised, website pages/content management system has been compromised, and GTM/JS snippet has been inserted on each page.

So, who cares?

Card-not-present (CNP) fraud now makes up 92% of all card fraud in Australia, costing $785 million in FY24^[2]

FY24 Australian Payment Fraud Statistics

While domestic protections are improving, attackers are pivoting to overseas merchants, where fraud rates are more than 12x higher. This matters because web-skimming and malicious JavaScript campaigns like Magecart are a primary enabler of these attacks.

We should care because the attack surface isn’t limited to “big targets.” Any vulnerable Magento, WordPress, or custom checkout can be weaponised. What we should be doing better;

1. Monitoring website source code/code bases for unauthorised changes.

2. Use Content Security Policy (CSP) and Subresource Integrity (SRI).

3. Routinely scan, update, patch, and harden platforms like Wordpress, Woocommerce, Magento etc.

The above can be achieved using a free Cloudflare plan, with added benefits like geo-filtering, CSP, web application firewall, etc.

[1] https://developers.google.com/tag-platform/tag-manager

[2] https://auspaynet.com.au/insights/blog/Fy24Cardfraud