A WooCommerce credit card reader injected into random plugin files


It’s that time of year again! While website owners should always be on guard, the holiday season is when online scams and credit card theft are most prevalent. E-commerce website administrators need to be extra vigilant, as this case will demonstrate. This story begins in much the same way as many others we discuss on this blog: A client came to us noting that a number of his clients reported that unauthorized activity had taken place on their credit cards soon after making a purchase on their website. Our initial scans were clean, so it was time to do some research to find the source!

Hide from detection

Ecommerce credit card skimmers are especially different from most of the website infections we deal with. The most common infections we see are spam, malicious redirects, and phishing. These are usually very obvious, and attackers often don’t even really try to hide their malware. Infections involving credit card theft, on the other hand, tend to be well hidden and may require a lot of research to find. The longer the infection stays hidden the more attackers are able to steal credit card numbers, so it really pays off for them to take the time to create a well-hidden injection. Sometimes it’s just a single line of code injected into files or database:

Malicious javascript loading from known credit card skimmer domains

see the source:

The first thing to do in such a survey is to examine the source code of the website’s payment page. As we have already written, javascript injections are often designed to load only on URLs containing certain strings such as “to verify“,”a page“, or similar. We went ahead and added an item to our cart and navigated to the checkout page. We didn’t notice any weird content loading, and even manually inspected each file upload. javascript on the page and arrived empty-handed.This tends to suggest that the credit card reader malware is running on the backend through PHP, rather than in the client’s browser.

Newspapers newspapers newspapers

This case is a prime example of the importance of monitoring file integrity. Fortunately, our client has installed our server side scanner on their website. This service will run once per day and will keep an accessible log of all website files that have been added or changed in the environment. This is especially useful if you have an approximate time frame as to when reports of credit card theft started to occur. Our client informed us that these started at the end of October, so we had something to work with.

Journal Analysis

It may take a bit of a keen eye and a bit of experience to read these logs properly, but once you know how to analyze file changes due to plugin and theme updates, you can start to see them. questionable file changes:

Questionable changes to file integrity

Plugin and theme updates will appear in fairly large bundles, so they can usually be skipped. However, when a single file or a few files in the file structure are changed on their own, this is when we need to capitalize our sherlock and take a look at the code.

Checking our client’s server-side scan logs revealed exactly that, so let’s take a look!

CC Skimmer injected into plugin files

Attackers know that most WordPress security plugins contain a way to monitor the integrity of core files (i.e. files in the wp-admin and wp-includes directories). This makes any malware injected into these files very easy to spot, even by less experienced web administrators. The next logical step for them would be to target plugin and theme files. It’s not the first time we’ve seen this, but what was quite fascinating about this particular infection was the way the code was written to appear completely harmless. It wasn’t until we separated the code using more advanced methods that the payload was discovered.

Backdoor injection

Before we take a look at the swiper itself, let’s take a quick look at the backdoor that was injected into the site’s files.


This particular line:

$u = get_users( array('role' => str_replace('c', '', 'cacdmcinisctractcocrc')));

At first glance, it looks like garbage, but when the str_replace function is used and all instances of the letter vs are removed, we get a simple:


The same goes for “fadmfifnisftrfatorf”, except in this case it uses the letter “f”.

The way it works is pretty simple – it retrieves a list of administrator users, and if it finds any, it will set the authorization cookie and the current user’s login to one of those users. The way this backdoor works is a great reminder of the importance of securing your wp-admin admin panel: even if this backdoor were injected, if the wp-admin zone is restricted to certain IP addresses, for example, it wouldn’t. to be able to do anything.

Abused Wp-smush plugin to add Skimmer

One of the files that displayed in the server-side scanner logs was the following:

./wp-content/plugins/wp-smushit/wp-smush.php (old size: 16965; new size: 25398)

Content has been added to this file – Why? This inspection justified.

Please note that these affected plugins may not themselves be vulnerable! They were most likely simply chosen by the attackers to inject their malware into.

Comparing this file to the original from the WordPress repository, we can see that a bit of code has been added to it:

Code differences between the new copy of the legitimate plug-in file and the modified file on the victim’s website.

At first glance, it appears harmless and does not contain any of the typical encoding or obfuscation techniques that we see so frequently with malware. In fact, nothing here looks malicious at all! However, while checking the differences, I noticed the following snippet:

Why does this plugin refer to WooCommerce?

Why would a plugin designed for image optimization refer to WooCommerce at all? Something went wrong here. In total, over 100 lines of code have been added to this file. There are a few variables that don’t seem to be defined anywhere, so there’s more to this code than it looks:

Let’s see if we can get them to produce something interesting, shall we?

Using get_defined_vars () to get hidden variables

PHP has a get_defined_vars () function which will return an array of each variable defined in the defined code. A useful tip for handling such code is to take advantage of it in conjunction with PHP’s print_r function.

DISCLAIMER: Care should be taken when dealing with any code suspected of being malicious. Make sure to use a secluded sandbox environment!

Once we have isolated the code that does not belong to the actual plug-in file and tweak the code a bit, all we need to do is add the following to the bottom of the file and l ‘run in a sandbox:

Which gives this:

The giveaway is the $ stylesheet variable which refers to a questionable domain. Running a quick whois on this domain shows that it was registered very recently, possibly with the express intention of exfiltrating the stolen credit card details from the victim’s website:

$ whois array-slice.page
Domain Name: array-slice.page
Registry Domain ID: 47C791B75-PAGE
Registrar WHOIS Server: whois.nic.google
Registrar URL: http://www.tucows.com
Updated Date: 2021-10-23T07:04:29Z
Creation Date: 2021-10-06T16:36:52Z
Registry Expiry Date: 2022-10-06T16:36:52Z

We can also see that it is hosted on an Alibaba server in Germany:

Which is certainly unrelated to our client’s website which operates primarily in North America.

The fun doesn’t end there, however, as there’s one more injection we need to look at!

Swiper injected into the 404 page plugin

Another of the files that warranted an inspection was the following:


The following server-side scan log was found on the same day as the previous file we just looked at:

./wp-content/plugins/404page/inc/class-404page.php (old size: 52515; new size: 55688)

When we do a diff comparison between the original plugin file and the infected one, you can see a bunch of code added from line 218 onwards. At first glance, this looks quite normal:

Most of the credit card skimmers we come across are heavily encoded and use complicated obfuscation techniques and are generally fairly easy to spot once you see them. This is not the case in this case. All we see here is what appears to be normal plugin code referencing thumbnails and comments.

What do we get when we apply the same logic as the previous file and print the variables for inspection?

print_r (get_defined_vars ());

A number of different variables are returned here, but the biggest giveaway this other credit card reader has is the $ thelist variable as you can see here:

This refers to a different URL on the same domain as the last file. The $ message variable is also important here because it has the value of file_get_contents and is executed in conjunction with the malicious domain variable, thereby grabbing whatever attackers choose to serve from that domain.

Secure your website!

If you operate an e-commerce website, be sure to be extra careful during the holiday season. This is when we are seeing attacks and compromises on ecommerce sites at their highest volume as attackers are poised to make handsome profits from stolen credit card details.

Make sure you follow security best practices, beef up your admin dashboard, and ideally place your website behind a firewall service!


About Author

Comments are closed.