Recently one of our analysts, Weston H., found a very interesting credit card stealer in a Magento environment which loads a malicious JavaScript without using any script tags. In this post I will go over how it was found, how to decode it and how it works!

One of our clients was reporting that one of their website visitors was receiving a warning from their antivirus program when navigating to their checkout page:

Calls were being made to a known malicious domain that was already blacklisted by multiple vendors for distributing malware and involvement in carding attacks:

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

Credit Card Stealer in a Magento Website

In a previous post I outlined the different types of card stealers that can infect ecommerce websites. PHP, being a server side programming language, cannot be seen directly by antivirus 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:

<script

Here’s an example of why we look for such strings in the database:

To load JavaScript in the visitor’s browser the attackers usually need to start and end their injection with these tags, and often inject them into the “miscellaneous scripts” or “widgets” section of the admin panel.

While there were plenty of <script tags in our client’s database none of them seemed malicious.

Next was to check the checkout page. Once we loaded an item into the cart and navigated to the checkout we could see the JavaScript loading from that blocklisted domain but it was nowhere to be seen in the source code. Even searching for a common carding function such as atob( that attackers use to base64 encode their payloads returned nothing. So now what?

Upon a manual review of the source of the checkout page my colleague noticed this JavaScript:

At first glance it looks like some sort of obfuscated JavaScript related to animation, which isn’t all that uncommon to see and often looks malicious when it’s really quite benign.  However, upon closer inspection we uncovered that this was actually the payload of the infection.

De-Obfuscating Malicious JavaScript

Let’s take apart this code and see what lies behind the obfuscation shall we? First of all, let’s clean up this code so that it’s not all in one big chunk so we can better understand what we are looking at:

The malware can be broken down into three main parts:

• Obfuscated payload
• Decryption function
• Execution and decryption call

In most injections that we see like this we can simply 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 break down each individual function we can utilise the console.log feature of the browser development console in a sandbox environment like so to de-obfuscate the injection:

The “checkout” function is a dead giveaway here and we can see that it is appending JavaScript from the known carding domain pictured above:

Security researchers have uncovered roughly 60 carding domains related 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 are likely registering more as you read this article.

Conclusion

Attackers are always thinking up new ways to hide and obfuscate their malware. This example showed a creative use of animation CSS styles and the onanimationstart event handler. It allowed the attackers to avoid the use of simple <script tags, which is the first thing that us security analysts check when searching for a javascript injection in Magento environments. This isn’t the first time we have seen such a sneaky credit card swiper and it certainly won’t be the last.

If you are an ecommerce website owner I would highly recommend following the steps I laid out in a recent post with respect to securing your website environment, specially the administration panel which is where a lot of these attacks originate. We can also help protect your ecommerce website from attacks and hacks.