Analysis of a WordPress Credit Card Swiper

While working on a recent case, I found something on a WordPress website that is not as common as on Magento environments: A credit card swiper injection.

Typically this type of malware targets dedicated ecommerce platforms such as Magento and Prestashop (due to their focus in handling payment information, which we have documented extensively in the past). With WooCommerce recently overtaking all other ecommerce platforms in popularity it was only a matter of time before we started seeing attackers target this platform more frequently.

Naturally, WooCommerce and other WordPress-based ecommerce websites have been targeted before, but this has typically been limited to modifications of payment details within the plugin settings. For example, forwarding payments to the attacker’s PayPal email instead of the legitimate website owner. Seeing a dedicated credit card swiping malware within WordPress is something fairly new.

The Heist

Our client came to us with reports that multiple customers had complained of fraudulent credit card transactions shortly after making a purchase on their website. To my surprise, our client was not using one of the usual ecommerce platforms that we see targeted, but WordPress and WooCommerce.

Fun fact: it hardly takes any time at all for stolen credit card details to be leaked online to blackhat web forums, and they are frequently sold for a pittance — sometimes as low as a couple of dollars. The returns on these stolen card details are low because attackers know that there is only a short window of time to use the information before the victims contact their vendors and cancel the card.

After performing the initial scan of their website and finding only generic backdoors and other malware, I knew there must be something else lurking here that needed to be uncovered. Sure enough, after performing an integrity check of the core files it didn’t take me long to find part of the infection:

It was lodged near the end of a JQuery file: ./wp-includes/js/jquery/jquery.js

Most JavaScript injections append the code at the very end of the file, but one quirk I noticed about this was that it was inserted before the ending jQuery.noConflict();

The JavaScript itself is a little difficult to understand, but one thing that is clear is that the infection saves both the credit card number and CVV (card security code) in plain text in the form of cookies.

With credit card swipers it’s common for attackers to simply include/append malicious javascript from a third-party website. This makes it easier to spot when using a script blocker such as NoScript (which I strongly recommend anybody concerned with their safety online should use), but when they modify a JavaScript file that is intentionally used on the site it’s not so easy to see. The fact that the malware lodged itself within an already existing and legitimate file makes it a bit harder to detect.

Let’s take a look at another infected file that was responsible for storing the payment details:

As is typical in PHP malware, several layers of encoding and concatenation are employed in an attempt to avoid detection and hide its core code from the average webmaster.

After peeling back the layers of the onion (so to speak) we find this:

The malware utilises the file_put_contents function to dump the details into two separate image files (one .png and one .jpg) within the wp-content/uploads directory structure. This is not at all uncommon for credit card swiper malware, but what was interesting was that both of these files had already been zeroed out by the time I checked them. Assuming the time stamp was accurate (which it may not be, as it’s easy enough to spoof) the contents were emptied before I had even started analysing the website. This suggests one of two things, either:

1) The client had found these files already themselves and cleared them out.

Or (a more likely scenario)

2) The malware had the ability to cover its own tracks and auto-cleared these files after the information had been acquired by the attackers.

Now, WordPress experts may have noticed that class-wp-rest-api.php is not actually a core file within this CMS platform. This file was added by the attackers and required on line 5988 of the ./wp-includes/functions.php file along with one added line of code, as we can see here:

Again, a very common method used by attackers to ensure that their malware loads on the website.

The Source?

One of the most common questions we receive from clients regarding their websites is, “How did the attackers get in?” Determining this for certain is a very deep rabbit hole and often hard to tell. Sometimes it is obvious (for example, when a client is impacted by a mass infection due to a known vulnerable plugin) but in a case like this it’s much harder to say for sure. It could have been a compromised wp-admin account, SFTP password, hosting password, or some piece of vulnerable software in the environment.

One thing I would recommend to everyone concerned about the security of their WordPress website is to disable direct file editing for wp-admin by adding the following line to your wp-config.php file:

define( ‘DISALLOW_FILE_EDIT’, true );

This even prevents administrator users from being able to directly edit files from the wp-admin dashboard. In the event of a compromised admin account this can make the difference between the attacker delivering their payload or not.

In Conclusion

The infection detailed above is the first case of this kind that I’ve found this year, but since working on this website, I have seen a handful of other cases, all with varying payloads. Some attackers have targeted WooCommerce, others target Stripe, but the fact remains that WordPress websites with ecommerce features and online transactions will almost certainly continue to be targeted going forward.

This case is a perfect example of why both file integrity monitoring and regularly checking the integrity of your core files is crucial to maintaining a healthy, secure website. This is something that both our free WordPress plugin can help with, and even more robust is our server-side scanner that is included in our paid services.

As the threat landscape continues to evolve and more and more of our daily lives and transactions are conducted online it can’t be stressed enough that website owners bear the responsibility of keeping their websites (and by extension, their clients) secure. Check out our web application firewall and security services if you’d like us to help you protect your website!