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.
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
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.
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.
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!