Since 2020 considerable attention has been spent analysing the emergence of MageCart malware within WordPress environments which most commonly affects sites using WooCommerce. As demonstrated in a previous post WordPress has quickly become the most commonly affected CMS platform for credit card skimmers due to the CMS’ popularity and ease-of-use.
In fact, so far this year WordPress has begun to eclipse other CMS platforms in the prevalence of skimming malware:
According to our data nearly 60% of all skimmers externally detected by our SiteCheck tool were targeting WordPress CMS so far this year. Below is a graph showing the prevalence of different CMS platforms affected by skimmers in the last period, updated with the most recent data:
In a previous post we examined the three most common malware signatures relating to credit card skimmers. Malware which impacts large numbers of websites tend to get the most attention but less common infections can still have an impact on a lot of people. To elaborate further on these infections today we’ll shine light on some of the less common credit card skimmers that we have found in compromised WordPress environments.
The Ultimate Goal: Remaining Undetected
Before we dive into specific examples it’s important to keep in mind that attackers spend a considerable amount of time crafting new pieces of credit card skimming malware. They do this to remain undetected for as long as possible and maximise the number of credit card details that they can pilfer from unsuspecting eCommerce customers.
As we explained in our 2021 Hacked Website Report when describing credit card skimmers:
Hacker groups are actively developing and customizing their malware. Each variation
is distributed to a small number of sites, but the overall number of affected sites is
significant.
We can distill this statement in the following manner:
If an attacker reuses the same malware across many websites the chances of it being detected by security scans increases dramatically. However, if they specially craft a specific payload for a small number of sites they tend to stay hidden for much longer.
Skimmer Attaches Into Plugin Data
The first example that we have is credit card skimming malware which functions in a similar way to the Simildon malware that we wrote about earlier this year. Except in this example the malware actually inserts itself into an existing plugin within the website file structure.
Here below we can see it injected into the masks-form-fields plugin, and calls WooCommerce checkout functions:
We can see that the malware uses the strrev function to obfuscate the exfiltration destination, which is:
hxxps://simplessl[.]icu
So, when the order details are being processed by the website, it is simultaneously sending the data using cURL to the malicious exfiltration domain to be later sold on the black market.
Payment Information Stealer Loads Through Bogus Plugin
While this example technically does not steal credit card information, it does pilfer billing information, addresses, and other information entered into checkout pages in much the same way that the previous example does. This malware is a combination of a backdoor and skimmer.
Interestingly, there is no clear exfiltration destination. Instead, the malware actually allows the attackers to display stolen information right in their browser from the victim website when using the correct URL parameters.
The payload is loaded as a malicious plugin within a compromised WordPress environment:
We have detected this malware a number of times in plugin files like the following:
./wp-content/plugins/WSI/wsi.php ./wp-content/languages/plugins/wpmulti.php
We can see that the malware is using heavy obfuscation, but when we decode, here is a portion of the payload:
We can see it referencing wp-load.php so it can use WordPress functions to work with the WordPress database without having to worry about credentials and other low level stuff. We can also see that it echos the stolen billing information into json format and makes it accessible to the attackers if the correct password (checked against a specified MD5 sum) is provided in the URL string.
For example:
www.hackedwebsite[.]com/wp-content/plugins/WSI/wsi.php?key=hackerpassword&usersorders
The compromised details would be displayed right in the attacker’s browser for easy access.
Skimmer Lodged in WordPress Database
The next example we have is some obfuscated JavaScript lodged into a database table entitled wp_snippets:
As you can see, it loads in an unorthodox way using <style> tags rather than the traditional <script> tags.
While this infection doesn’t make our top list, we’ve been tracking variants of this infection for several years. In fact, this particular malware is known to affect Magento sites as well as WordPress.
Once deobfuscated we see that the JavaScript loads an image filled with credit card skimming code, extracts the JavaScript code hidden inside (at the end of) the file, and executes it.
./wp-content/plugins/revslider/public/assets/assets/transparent.png
The majority of credit card skimmers employ a variety of features to avoid detection.
In this case, the malware uses a more “traditional” skimming JavaScript obfuscation which seems to be the unofficial “gold standard” of these attackers. When we pull back the obfuscation we see the skimmer payload indicating all of the usual credit card payment information:
As a second evasive maneuver, the skimmer also leverages the not-so-uncommon feature of hiding itself if it detects that devtools or Firebug (a popular debugging browser extension) is running.
Hiding a skimmer payload inside of an image file is a tactic that we have seen used on other eCommerce platforms and has been increasingly seen targeting WooCommerce as well.
Skimmer Modifies Legitimate WordPress Plugin Files
Some of the most well-hidden and advanced skimmer infections that we’ve seen targeting WordPress sites actually modify existing plugin files to make their code look like it’s supposed to belong within the file structure.
For example, this very well-thought-out skimmer lodged within an existing plugin file:
./wp-content/plugins/members/members.php
The added (malicious) code highlighted in red appears completely innocuous. At first glance, it is properly formatted and indented and contains no obfuscation whatsoever.
However, the first line of it links directly into WooCommerce, which this plugin normally doesn’t do in this way:
add_action( 'woocommerce_billing_fields', function( $address) {Further down the file we can see that the attacker very cleverly hid their exfiltration destination in plain sight:
When everything is strung together in the final analysis the credit card details are spirited away to the following exfiltration domain:
nested-page[.]net
All in all we found a total of seven different already-existing plugins had been modified in this manner on the compromised site:
./wp-content/plugins/amr-shortcode-any-widget/amr-shortcode-any-widget.php ./wp-content/plugins/insert-headers-and-footers/ihaf.php ./wp-content/plugins/members/members.php ./wp-content/plugins/google-analytics-for-wordpress/googleanalytics.php ./wp-content/plugins/unsafe-mimetypes/unsafe-mimetypes.php ./wp-content/plugins/widget-logic/widget_logic.php ./wp-content/plugins/wd-google-maps/wd-google-maps.php
Multiple different administrator account creators and bypass scripts had been inserted alongside the skimmer to allow attackers to maintain access long after initial infection had occurred.
./wp-content/plugins/amr-shortcode-any-widget/amr-shortcode-any-widget.php
But Ben, couldn’t the website owner just update their plugins to get rid of the infection?
I hear you ask, and you would be correct!
Unsurprisingly, the attackers thought of this ahead of time. Inside each of these modified plugins was a reference to a database table entitled site_transient_update_plugins which locked the components and prevented them from being updated from the wp-admin panel:
All in all, we have seen this particular malware on only a small number of higher-value eCommerce websites.
Even though the total number of affected websites is very small this doesn’t necessarily mean that the malware is ineffective. Keep in mind: The fewer number of websites that the attackers use any particular payload on the less chance of it being detected by security software designed to protect the website from malware.
New Variants to Evade Detection
Attackers are constantly writing new malware to avoid detection. The longer they are able to keep their payload on the website the more credit card details they are able to steal.
In fact, our 2021 Threat Report also indicates that over one quarter of all new PHP malware signatures that our research team generated over the course of the year was specifically for skimming malware:
Attackers are clearly spending a lot of time and effort to stay hidden in order to make more money selling stolen credit card details on the black market. PHP backend malware is also invisible to the website visitor as well as most other #MageCart security researchers looking to investigate compromised websites.
In Conclusion
With credit card skimming malware trending upwards in recent years (particularly in WordPress environments) it’s more crucial than ever for eCommerce website administrators to treat security as a high priority.
If you operate an eCommerce website (or any website, for that matter) please consider the following:
- Keep your website software up to date to minimise vulnerability risks
- Place your admin dashboard under 2FA
- Use strong and robust passwords
- Employ file integrity monitoring
- Place your website behind a firewall service
Furthermore, due to the increasing number of PHP malware found on the backend we strongly encourage webmasters to set up website monitoring that is able to scan the site for infection at the server level.
As always, if you think you have a credit card skimmer on your website or need a hand protecting your site from malware we’re always happy to help clean up malware and secure your site.
Cesar Anjos
Juliana Lewis
Liam Smith
Celise Davison
Tony Perez
Fioravante Souza
Mohit Jawanjal