Magecart threat actor rolls out convincing modal forms

To ensnare new victims, criminals will often devise schemes that attempt to look as realistic as possible. Having said that, it is not every day that we see the fraudulent copy exceed the original piece.

While following up on an ongoing Magecart credit card skimmer campaign, we were almost fooled by a payment form that looked so well done we thought it was real. The threat actor used original logos from the compromised store and customized a web element known as a modal to perfectly hijack the checkout page.

While the technique to insert frames or layers is not new, the remarkable thing here is that the skimmer looks more authentic than the original payment page. We were able to observe several more compromised sites with the same pattern of using a custom-made and fraudulent modal.

This skimmer and associated campaigns represent one of the most active Magecart attacks we have been tracking in recent months.

**Smooth checkout **

We identified a compromised online website for a Parisian travel accessory store running on the PrestaShop CMS. A skimmer we previously identified as Kritec, was injected and loading malicious JavaScript that altered the checkout process. In the following section, we will compare the checkout process when the skimmer is active and when it is not.

Fraudulent payment form

What we see here is the use of a ‘modal’ which is a web page element displayed in front of the current active page. The modal disables and grays out the background so that the user can focus on the presented element instead. This is an elegant way for website owners to keep their customers on the same web site and have them interact with another form.

Figure 1: Compromised store loads fake payment modal

The problem is that this modal is entirely fake and designed to steal credit card data. It may sound hard to believe given everything matches to the original brand and feel of the site. Before digging further into why it is fraudulent, we will take a look at the same online store when the skimmer has been disabled.

Actual (real) payment form

In order to view this legitimate sequence, we first had to block the skimmer when requesting the e-commerce page. In our case, we simply blocked the connection to the malicious domain where the skimmer is hosted. As a result, the website will display what the original payment form should be (prior to the compromise).

Figure 2: Legitimate payment form when same store is not compromised

The actual payment flow for this merchant is to redirect users to a third-party processor hosted by Dalenys, now part of Payplug, a French payment solutions company. So rather than display a modal, it loads the webpage for the payment processor to allow the user to enter their banking information. Once that is validated, it will take them back to the merchant page.

Malicious modal

The malicious modal is built very cleanly and contains an animation that displays the store’s logo in the middle and then moves it back up. We have to give credit where credit is due: this is a very well done skimmer that is actually a smoother user experience than the store’s default. We should also note that the malware author is not only well versed in web design, they also use proper language (French) for each form field.

Figure 3: A closer look at the fake modal

However, we noticed a small mistake in the hyperlink for Politique de confidentialité (terms of use). That link redirects to the terms of use for Mercardo Pago, a payment processor used in South America. It is likely the threat actor copied the data from a previous template and did not notice their mistake. This is just a detail, and does not affect the functionality of the skimmer at all.

We can try to look for this erroneous hyperlink within the skimmer source code in order to confirm that the modal was created by the threat actor. The skimmer is rather complex and heavily obfuscated but we can see that HTML content is generated dynamically and goes through a decodeURIComponent routine.

Figure 4: Extracting code from the skimmer to reveal connection with the modal

If we step through the code until the modal is loaded, we can grabbing the Base64 value corresponding to the HTML content. One we have it, we can convert it to plain text and finally see the reference to mercadopago, that is proof that the skimmer is the one rendering this beautiful modal. In fact, we can see the whole thing is an iframe called v.ECPay:

Figure 5: The iframe created by the skimmer to display the modal

Full payment flow

We recreated the payment flow from the perspective of a customer shopping via that compromised store. We can see that upon selecting the credit card payment option, the malicious modal is loaded and will harvest their payment card details.

A fake error is then displayed briefly “votre paiment a été annulé” (your payment was cancelled) before the user is redirected to the real payment URL:

Figure 6: Payment process flow with the skimmer active

On the second attempt, the payment will go through and victims will be unaware of what just happened.

The skimmer will drop a cookie which will serve as an indication that the current session is now marked as completed. If the user was to go back and attempt the payment again, the malicious modal would no longer be displayed (instead the real payment method by the external processor Dalenys will be used).

Figure 7: Cookie dropped by skimmer once data has been stolen

Ongoing, covert campaigns

We now believe this Kritec skimmer is part of the same compromises with injections into vulnerable websites where malicious code is placed within the Google Tag Manager script. It is possible multiple threat actors are involved in those campaigns and customizing skimmers accordingly.

While many hacked stores had a generic skimmer, it appears the custom modals were developed fairly recently, maybe a month or two ago. The threat actor is using different domains to host the skimmer but names them in a similar way: [name of store]-loader.js.

We crawled several thousand e-commerce sites and found more fraudulent modals, in different languages.

Figure 8: A Dutch e-commerce site with the fake modal

Figure 9: A Finnish e-commerce site with the fake modal

Discerning whether an online store is trustworthy has become very difficult and this case is a good example of a skimmer that would not raise any suspicion.

If you are a Malwarebytes customer, you will get a notification and block when attempting to make a purchase from a store that has been compromised by this skimmer.

Figure 10: Skimmer being blocked by Malwarebytes

Indicators of Compromise

Domain names

genlytec[.]us
shumtech[.]shop
zapolmob[.]sbs
daichetmob[.]sbs
interytec[.]shop
pyatiticdigt[.]shop
stacstocuh[.]quest

IP addresses

195.242.110[.]172
195.242.110[.]83
195.242.111[.]146
45.88.3[.]201
45.88.3[.]63

YARA rule

rule kritecloader
{
strings:
$string = “’fetchModul’”
$string2 = “’setAttribu’”
$string3 = “’contentWin’”
$string4 = “’zIndex’”

condition:
all of them
}

Whether you are visiting an online store from home or while at work, web protection is a critical layer in your overall defense. Malwarebytes Premium for consumers and Endpoint Protection for businesses provide real-time protection against threats like Magecart.

TRY NOW