The holidays are always a busy time for ecommerce stores. Dealing with an influx of Christmas shoppers, holiday sales and inventory, shipping, and at times, also hackers. Today’s investigation starts out much like many others, with our client reporting an antivirus warning appearing only on their checkout page, of course at the worst possible time right around the end of December.
What first seemed to be a routine case of credit card theft turned out to be a much more interesting infection that leveraged both font, favicon and other less-commonly used files to pilfer credit card details. After running our regular checks for script tags, dodgy third party content and modified core/plugin files and coming up empty handed, it was time to perform a more in-depth analysis of what was going on.
Questionable <div Tags on Checkout
Since whatever was loading here was setting off the antivirus alarms it had to be loading through the browser. This was likely to be JavaScript and not any backend/PHP infection, since those cannot be detected by client-side security programs.
Manually inspecting all of the JavaScript files loading on the checkout page didn’t yield any results, so for the time being we were left scratching our heads. However, one of our analysts was able to spot some questionable content by viewing the source of the checkout page:
This is some very peculiar code, and seemed to be JavaScript even though there weren’t any script tags. At face value it didn’t seem to be decipherable. Upon querying the database for the simple string “cs1” we found it within the “checkout” page of the wp_posts table, so we’re starting to get warmer here.
Taking apart that JavaScript, once we log the functions in a sandbox browser console we can start to understand that the strings are merely rearranged. Once they are put together in the correct order and the code beautified it starts to make much more sense:
Wait a second…a .woff file? What exactly is that, and why is this dodgy JavaScript referencing it?
The Web Open Font Format is a font format for use in web pages. WOFF files are OpenType or TrueType fonts, with format-specific compression applied and additional XML metadata added.
This doesn’t quite add up. There’s no reason for obfuscated JavaScript to be playing with a font file, so let’s dig a little deeper.
Time for an Intensive Scan
When dealing with web-based malware the overwhelming majority of the time we are dealing with PHP, JavaScript, and HTML files. Every so often, though, we’ll come across malicious payloads that leverage different and sometimes unorthodox file types. Since the above code is referencing a font file it was time to dig a little deeper into the way this infection operated. Sure enough, some obfuscated JavaScript code was detected in that .woff “font” file:
So, how exactly do we know that this is a credit card skimmer? For starters, it uses exactly the same type of obfuscation that we are accustomed to seeing in skimmer files. Moreover, once we beautify things and make it a little more readable it becomes obvious:
Here we see the JavaScript pilfering such details as:
- CC number
- CVV
- First and last name
- Expiration date
It’s also gathering some details not always seen in such skimmer files like the victim’s user agent and language.
Credit card details alone are not sufficient to use a stolen credit card number, so further down the file we also see the typical additional information being stolen:
- Address
- Postal / Zip code
- City
- Company
- Region
Bonus Login and Cookie Stealer
Interestingly, there was another .woff file as well as a favicon .ico also lodged within the file structure both injected with malicious JavaScript. This time, both files included font and icon data and at first glance seemed perfectly legitimate. The favicon file matched the victim website’s legitimate favicon image as well as domain name (which we won’t share here in this post), suggesting this was a targeted attack. The other .woff file was also a fully functional font, despite containing a malicious JavaScript payload:
Not a very interesting font, though, unfortunately. When we view the source of the font file there is similar malicious JavaScript appended onto the bottom which contains both another credit card skimmer as well as a cookie stealer used for hijacking login sessions:
This was also using some unorthodox methods to load into the victim’s browser, again lacking customary <script tags:
We see some similar JavaScript code appended onto the bottom of a favicon .ico file as well:
Once we unpack some of this code, we can see the classic atob( function (base64 decode) being used:
And when we decode that from base64, we can see a known malware domain that has been involved with malware attacks for the better part of a year:
cdn-bootstrapcdn[.]com
Varied File Extensions to Hide Payload
This is not the first time that a bogus favicon has been used in a skimming attack, and certainly not the first time image files have been used. Font files have also been found to be used in MageCart attacks by other security researchers, but it’s certainly not something that we see every day. We’ve been tracking similar infections since about 2019.
Attackers will almost always try to reinfect environments once they manage to gain a foothold. This is particularly true of targeted skimming attacks. In checking our cleanup logs for this website it seems the attackers came back over and over again, leveraging different file types in each subsequent reinfection. We also found .gif and .css files with JavaScript skimmers appended onto the end, and loading through the database wp_posts and wp_options tables in similar but varied ways.
You also may have noticed that the payload .woff files reside within several of the ./wp-content/uploads directories, rendering them undetectable to a core file integrity check (present in almost all WordPress security plugins).
Attackers are always finding new and creative methods to hide their payloads. Web security scans tend to focus on files that make up the core of a website structure like .php or .js so it only makes sense that some of the more crafty attackers would find new file extensions to exploit and find creative ways to inject that content into victim browsers.
In Conclusion
Fortunately, once our client placed their website behind our firewall service and, crucially, used it to add an extra level of authentication to their wp-admin panel, the attackers have not been able to return since.
This case is a very good example of how MageCart threat actors are increasingly targeting WordPress websites using WooCommerce, a trend which we first observed in the last months of 2019 and early 2020. Ecommerce site owners should take steps to harden their wp-admin administration panel and make it more difficult for attackers to compromise these environments.
Denis Sinegubko
Luke Leal
John Castro
Cesar Anjos
Ben Martin
Victor Santoyo
John Booker