# Sucuri Blog **[blog.sucuri.net/2021/07/magecart-swiper-uses-unorthodox-concatenation.html](https://blog.sucuri.net/2021/07/magecart-swiper-uses-unorthodox-concatenation.html)** Ben Martin July 7, 2021 MageCart is the name given to the roughly one dozen groups of cyber criminals targeting ecommerce 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](https://www.exinent.com/magento-2-0-migration-cost-and-timelines/) 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](https://blog.sucuri.net/2021/03/magento-2-php-credit-card-skimmer-saves-to-jpg.html) 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: Some very ugly but cleverly written PHP code using multiple types of obfuscation 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: Complete rubbish 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: Ok, now we’re getting somewhere! ----- 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: ```