Recently, a client’s customers were receiving a warning from their anti-virus software when they navigated to the checkout page of the client’s ecommerce website. Antivirus software such as Kaspersky and ESET would issue a warning but only once a product had been added to the cart and a customer was about to enter their payment information. This is, of course, a tell-tale sign that there is something seriously wrong with the website and likely a case of credit card exfiltration.
Checking the source code of the website showed that there was clearly some dodgy javascript code on their checkout:
Google Tag Manager Scripts
At first glance it appears to be a Google Tag Manager script (a popular service used on many websites). In the past we have seen how Google Tag Manager’s script can be used to hide malicious content. Could this be the same?
Attackers commonly place code in a way that makes it look legitimate and innocent. Sometimes they even abuse GTM itself to surreptitiously exfiltrate credit card details, making it impossible to identify without using traffic inspection software or confirming which GTM scripts belong and which ones the site owner doesn’t recognise.
A regular googletagmanager script call does not include any obfuscation, base64 encoded content or concatenation. However, we see a little bit of base64 encoded content here that decodes to the following:
The domain a42[.]buzz has been blocklisted by us since January so this clearly indicates that this is malicious in nature and we’ll need to find how it’s loading.
How to Find the Malware
In the above example our initial scans did not pick up anything. Remember: it’s the attacker’s job to evade detection so they are writing new malware all the time. In this case, querying the files and database for “Google Tag Manager” or “atob(” (atob is the javascript instruction to decode base64 encoded strings and is common on javascript injections) also returned nothing.
Checking Recently Modified Files
One of the first things that we will do in such a compromise is to check for recently modified files. Sometimes it can take a surprisingly long time for a compromise to be identified so I will typically start with files modified in the last few months. If nothing is found then I will go as far back as six months or a year.
You might wonder how someone would check all those files! It seems overwhelming at first but you can remove a lot of noise by parsing out all of the obvious plugin and theme updates. They will appear in batches with a very similar (if not identical) last modified date. It’s not a perfect method but proves to be useful in some cases. What you are left with is (hopefully) a small handful of files that were modified at very different times and dates.
Attackers will often spoof the last modified date on a file to make it appear as though it hasn’t been touched in years but these files should still show up when running an SSH command such as mtime. If you are not familiar with the SSH shell you can also spot check recently modified files through FTP with a program like Filezilla but this is significantly more cumbersome, not as reliable, and you will be relying on those last modified timestamps that I just mentioned. Attacks can sometimes even go unnoticed for multiple years before the website owner is made aware that their environment is compromised.
Even after checking many recently modified files we were left empty handed.
Checking the Database
So where was this hiding? It turned out to be hiding in plain sight in the database. Base64 encoding is one of the most popular encoding techniques that attackers will employ to hide their payloads, and that is exactly what they were doing here:
It’s unclear whether or not this was a deliberate attempt by the attackers to evade detection or if this is simply the way that the plugin/theme stores its data (resulting in a happy accident for the attackers). In any event it created some additional steps for us to locate the malware.
Encoding Base64
The way that we were able to find it eventually (big ups to @liamsmith86 for the assist here) was by base64 encoding <!– Google Tag Manager –> and querying some of the strings. The full encoded string is:
PCEtLSBHb29nbGUgVGFnIE1hbmFnZXIgLS0+
And we queried the database for a few snippets of that until we found it lodged on the checkout page.
Let’s break down this malware shall we?
Analysis of a Woocommerce Credit Card Swiper
Step one of course is to decode the base64 chunk, resulting in this (what we saw loading on checkout earlier):
Taken at face value it appears to be GTM but of course this is bogus. When decoding that base64 string this is precisely the same code that we found in the source code earlier:
Here we see some javascript loading from a domain that we have been blocklisting since January of this year. Now let’s take a look at what’s actually in that javascript! Navigating to the payload on the malicious website we find the following:
We can see that the payload is under yet another layer of obfuscation. Using a free online tool we can “unpack” this p,a,c,k,e,d javascript to find the main, deobfuscated credit card swiper. Here is a snippet:
At the top there we can clearly see two more malicious domains referenced. We have seen these domains used for credit card exfiltration in the past and originally found them in October of last year on an OpenCart website. Over the last few years we have seen an increasing trend of the same credit card swiping malware and exfiltration domains used across different CMS platforms.
Looking at malicious domains
Let’s break down these domains a little bit to see if we can understand them a bit better:
a42[.]buzz Registrar: Porkbun Creation Date: 2020-09-16 IP: 5.188.62.36 Hosting provider: Petersburg Internet Network Hosting Hosted in: Russian Federation
All the other domains on this IP are also malicious and contain the same malicious script:
zerr[.]club badger[.]uno commv[.]club 9gag[.]uno 8words[.]xyz 64bitss[.]club 221u7[.]cyou 114oo[.]icu 5x5x5[.]cyou 404p[.]icu
The next domain found in the payload:
googleanalytics[.]icu Registrar: Porkbun Creation Date: 2020-07-09 IP: 103.73.67.186 Hosting provider: HostHatch Hosted in: Hong Kong
(As a Canadian I will never know if this is July 9th or September 7th.)
Again, all the other domains here are malicious and contain that malicious javascript:
sxjump[.]uno sxfnc[.]uno sxint[.]uno sxgear[.]uno sxhit[.]uno sxbet[.]uno sxerr[.]uno sxamp[.]uno sxdmp[.]uno sxcad[.]uno
And finally:
shopstatanalytics[.]store Registrar: NameCheap Creation Date: 2020-07-08 IP: 176.123.3.85 Hosting provider: Alexhost Srl Hosted in: Moldova
Same story with this server:
sygna[.]club syidim[.]club syjet[.]club syhire[.]club syfer[.]club sydne[.]club syamoto[.]club syberian[.]club sycamor[.]club syenna[.]club
It’s interesting to see a little bit more information and context to the domains being used to exfiltrate credit card details of unsuspecting customers.
So this brings us to our last point: How did this credit card swiper find its way onto this website?
How the Credit Card Swiper Got into the Website
Without going down the forensics rabbit hole there’s no way to know for certain. However I have a pretty good guess that this was the result of a compromised wp-admin account. Once the attackers find their way into the wp-admin panel they can really do whatever they want:
- Place malicious javascript code in the posts/pages/widgets
- Modify a file to be a backdoor and easily upload their payload
- Use a file manager plugin to upload a backdoor or more malware
- Post spam or other unwanted material
- Anything else you can imagine they’d want to do
How to Prevent Hacks
At risk of sounding like a broken record I would urge any WordPress site owners out there to take their website security seriously. The most straightforward thing that you can do is to place some additional protections on your wp-admin panel using a security plugin of your choice. Some options for that include:
- Two factor authentication
- IP access restrictions
- CAPTCHA
- A limit on the number of failed authentications before lockout
- All of the above!
Of course this makes it a little bit more inconvenient to administer your website but the potential repercussions of a site compromise are devastating and the benefits far outweigh the annoyance of entering an additional code when logging in. Of course, our firewall is a great tool to help secure your wp-admin area (or other admin areas if you are using a different CMS other than WordPress). It’s also a good idea to keep close tabs on the activity of your admin area which you can do with our WordPress plugin:
This can help you detect suspicious activity on your website and learn a little bit more about the threat actors behaviour in the event that you do get compromised. Remember: don’t install every security plugin under the sun thinking you will be more protected. This is much like installing multiple antivirus programs on a computer: They’re usually trying to do similar things at the same time and “wires get crossed” so to speak. In a WordPress environment this is a recipe for locking you out of your own website.
Of course, the best way to prevent a compromise in the first place is to become a customer of ours!
