# Sucuri Blog

**[blog.sucuri.net/2021/07/stylish-magento-card-stealer-loads-without-script-tags.html](https://blog.sucuri.net/2021/07/stylish-magento-card-stealer-loads-without-script-tags.html)**

Ben Martin July 28, 2021

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](https://labs.sucuri.net/blacklist/info/?domain=siteanalitic.space)
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](https://blog.sucuri.net/2021/06/credit-card-theft-types-of-swipers.html)
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](https://blog.sucuri.net/2021/06/credit-card-theft-types-of-swipers.html)
administration panel which is where a lot of these attacks originate. We can also help protect
your ecommerce website from attacks and hacks.


-----