Stylish Magento Card Stealer loads without script tags

Recently, one of our analysts, Weston H., found a very interesting credit card thief in a Magento environment that loads malicious JavaScript code without using script tags. In this article I will explain how it was found, how to decode it and how it works!

One of our customers reported that one of their website visitors received a warning from their antivirus program when they navigated to their payment page:

Calls were made to a known malicious domain that was already blacklisted by several vendors for distribution of malware and involvement in carding attacks:

This certainly indicated that a card thief was present somewhere on our client’s website.

Credit Cards Thief in a Magento Website

In a previous article, I described the different types of card thieves that can infect e-commerce websites. PHP, being a server-side programming language, cannot be seen directly by anti-virus programs, so this infection must be JavaScript and visible to the browser.

Our first step in locating such an infection is to query the database for the following string:

Here is an example of why we are looking for such strings in the database:

To load JavaScript into the visitor’s browser, attackers typically need to start and end their injection with these tags, and often inject them into the “various scripts” Where “widgets“admin panel section.
Although there have been a lot of tags
Then you had to check the payment page.  Once we loaded an item into the cart and navigated to the checkout, we could see JavaScript loading from that stuck domain, but it wasn’t appearing anywhere in the source code.  Even looking for a common carding function such as a to B ( that attackers use to encode their payloads in base64 returned nothing.  And now?
During a manual review of the source of the payment page, my colleague noticed this JavaScript:

At first glance, it looks like some sort of obfuscated JavaScript related to animation, which is not that rare to see and often looks malicious when it’s really benign.  However, upon closer inspection, we found out that this was actually the payload of the infection.
Malicious JavaScript De-obfuscation
Let’s take this code apart and see what’s behind the obfuscation, right?  First, let’s clean up this code so that it’s not all in one big chunk so that we can better understand what we’re looking at:
The malware can be broken down into three main parts:

Obscured payload
Decryption function
Execution and decryption call

In most of the injections we see like this, we can just remove the concatenation ‘,’ and run it through a base64 decoder, but this injection was more complicated and actually required us to manually log the individual functions.
Once we have broken down each individual function, we can use the console.log feature of the browser development console in a sandbox environment like this to de-obscure the injection:

The “to verify“The function is a dead giveaway here and we can see that it adds JavaScript from the known carding domain shown above:

Security researchers have discovered around 60 domains of carding linked to these attackers, including some of the following:
blockanalist[.]space 
analiticsblock[.]space
analiticsblock[.]site
analistnetwork[.]space
analistnetwork[.]site
siteanalitics[.]space
siteanalitic[.]space
site-analitics[.]site
site-analitic[.]space
site-analitic[.]site
They probably register more as you read this article.
Conclusion
Attackers are always devising new ways to hide and obscure their malware.  This example shows a creative use of CSS animation styles and the onanimationstart event handler.  This allowed attackers to avoid the use of simple tags.
If you are an eCommerce website owner, I highly recommend that you follow the steps I outlined in a recent article regarding securing your website environment, especially the admin panel which is at the origin of many attacks.  We can also help you protect your e-commerce website from attacks and hacks.