Recently a client of ours was reporting a bogus checkout page appearing on their website. When trying to access their “my-account” page an unfamiliar prompt appeared in their browser soliciting credit card billing information:
This form was foreign to our client and was clearly placed during a website compromise. Interestingly, the website itself doesn’t even accept payments at all. If this was an attempt at a targeted credit card theft infection (as quite a few of them are) then the attackers best choose more carefully next time!
Locating the infection was easy enough when navigating to the page where the reported payment gateway was located. Using the outstanding FireFox plugin NoScript we are able to see the bogus domain trying to load JavaScript on the page:
It’s very common for credit card swiping domains to impersonate JQuery, a very common open-source JavaScript library used on countless websites.
In viewing the source of the webpage no instance of “apiujquery” was anywhere to be seen. Sure enough, the attackers were using an obfuscation technique often seen with credit card skimmers: atob
The atob JavaScript function takes a base64 encoded string and decodes it. In this case, it was our payload:
//apiujquery[.]com/ajax/libs/jquery/3.5.1/jquery-3.11.0.min.js?i=
This domain was registered on August 8th of this year using the Eranet registrar:
$ whois apiujquery[.]com Domain Name: APIUJQUERY.COM Registry Domain ID: 2631247943_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.eranet.com Registrar URL: http://www.eranet.com Updated Date: 2021-08-03T17:46:52Z Creation Date: 2021-08-03T17:46:52Z
Unlike many malicious domains the attackers didn’t bother to hide their DNS behind a CDN or reverse proxy. We can see that it is hosted at an OVH Virtual Private Server located in France:
$ host apiujquery.com apiujquery.com has address 51.178.8.230
Using Maltego with the VirusTotal extension we can also see that this domain is involved with distributing an Android Trojan:
Four vendors currently flag this as malicious:
Finding the Source
Back to the issue at hand! The question remained: Where was the infection hiding within the website?
Most commonly JavaScript injections like this are located in the database. In WordPress environments like this one these are typically injected into the wp_options table by the use of Widgets from the wp-admin dashboard. In this case, no such injection was present.
Querying the file system instead we were able to locate the malware injected into the theme’s header.php file:
Credit card skimmer injected into the header.php file of the website’s WordPress theme
That was enough to eliminate the infection, but there was more here to check out before we consider the case closed. Most notably, this infection was coupled with a malicious user lodged in the database:
With the user name “yoseftyrnauer” and an email address with an @gamil.com address. Whether this was a typo or an attempt at giving the impression of a GMail account, we’ll never know!
Analysing the Source
This all begs the question: What exactly is located at that bogus JQuery file? Normally JavaScript files are viewable in plain text in your web browser (which also makes JavaScript easier to work with for most security researchers who often do not have access to the back end of the websites/servers. PHP is a different beast entirely!).
In this case it seems that the attackers wanted to avoid prying eyes and blocked this file from the public:
403 Forbidden means somebody doesn’t want us to see this
However, we know that this file can be read from the infected website, right? With some basic wget tomfoolery we were able to download the file to our local sandbox by spoofing the referrer to match the page on the infected site where the credit card theft was occurring:
Let’s take a look, shall we?
Malicious Javascript
The bulk of this javascript file is just formatting and styling. Once we arrive at the bottom we can see the main content of the payload:
The top of the screen capture above shows the input fields listed in plain text (credit card details, address, etc).
Additionally, we see that the atob function is used extensively here to set triggers as to when the javascript is executed. When decoded from base64 we see the following:
order checkout commande cart direccion minha-conta account checkout compra registreren orderby critcart descartables
If any of these words are used in a URL on the target website the malware will load. This explains why the malware was triggered by the “my-account” URL on our client’s website even though the website did not handle credit card details or accept payments.
In addition to English we also see the usage of French, Portuguese, Spanish and Dutch terms, suggesting that this malware is likely targeting European websites.
Source of the Infection
In checking the files that were modified around the estimated date of the compromise no backdoors or additional malware was found. The website did have over a dozen administrator users, however, so it’s likely that the source of the infection was a brute-forced admin account. Once the attackers have established a foothold into the admin area they are able to edit files using the built in file-editor, which is enabled by default.
WordPress website owners can protect themselves against these types of attackers by hardening their wp-admin panel and avoiding the usage of default, out-of-the-box configurations. We recently released a guide on how to protect your WordPress website from attacks without the need for any paid features or services.
You can also sign up for our website firewall and remediation services if you’d like a hand in protecting your website from attackers!
