How Retailers Should Address Magecart Web Skimming Attacks

In my previous article about Magecart web skimming attacks, I recapped some of the noteworthy victims of this cybercriminal collective and how attackers managed to breach them.

Today, security teams in retail are mostly aware of this threat, however, navigating the different technologies and products that claim to be effective towards Magecart isn’t an easy task. In all likelihood, these security teams will eventually analyze one or more of these tools, which begs the question: How should they test whether a specific approach is effective against Magecart attacks?

A Magecart Mitigation Checklist for Retail

As I’ve mentioned before, I’ve been fortunate enough to have directly worked with the security teams of several retailers in implementing solutions to tackle Magecart. And when these teams started monitoring the client-side of their retail websites, they found a number of red flags. One global retailer discovered that every two weeks, a new marketing script was being added to the payment page without proper security vetting. Others found that, on the payment page, sensitive data was being sent through XHR to unvetted third parties.

With this firsthand experience in mitigating Magecart attacks, I’ve gotten a clear picture of the actual tests and verifications that retailers should put in place when assessing a Magecart mitigation product. Let’s go through each of those tests:

• The product can detect and block the addition of “click” or “submit” event handlers to the page. One very common type of malicious behavior in Magecart skimmers is the addition of form-related event handlers (for example, of an onmouseover event).
• The product can detect and block the addition of elements to a page, such as forms. Today, there are numerous examples of advanced web skimmers that add fake credit card payment forms or new buttons to a page. This type of DOM tampering is also malicious behavior and a common indicator of Magecart attacks.
• The product can detect and block the removal of elements from a page, such as a div and its child nodes. In contrast to the previous topic, Magecart attackers can also remove content from the page, for instance, to divert users from the legitimate payment flows and lead them to a compromised form.
• The product can detect and block the modification of page content, namely, editing element attributes or changing element visibility. Similar to the tactic of removing page elements, attackers can try to modify them to trick users, for example by hiding a loading spinner.
• The product can detect and block sensitive data collection and its exfiltration. This is, of course, a pivotal test when it comes to web skimming. After intercepting the payment form, Magecart attackers always need to send the captured data out to their drop server. Detecting and blocking these suspicious outbound network events is a key step to prevent the attack from succeeding.

All of the technical tests detailed above should provide a good way to filter out different products. However, then there's the matter of ensuring that the product can be easily integrated/managed and that it won’t interfere with end users’ experiences. To that extent, we should consider the following verifications:

• Require a complete website inventory. One of the best weapons against Magecart attacks is visibility. An inventory of all the scripts and network connections that take place in any given user session makes it easier for security teams to learn what’s normal behavior and what’s not.
• Avoid approaches that rely on bots. A year ago, this perhaps wouldn’t be a problem; however, several Magecart skimmers today are using bot detection techniques. These are very effective at keeping the skimmer hidden from approaches that visit the page continuously to check for skimmers.
• Avoid solutions with limited compatibility. Depending on the approach, some solutions may have critical incompatibilities with some browsers and browser versions. For example, SRI isn't compatible with Internet Explorer nor with Safari for iOS.
• Avoid approaches that impact page performance. In e-commerce, page performance is a key driver of sales. To avoid losing customers to poor loading times or other user experience issues, the approach should leave a minimal footprint in performance.
• Avoid high-maintenance solutions with difficult integration. Integrating a solution that requires significant refactoring of current systems or substantial maintenance and configuration effort will lead to problems further down the road.
• Avoid approaches that are only signature-based. While there's value in using signatures, solely relying on them will result in very limited detection capabilities. Magecart attacks are constantly evolving, and new exploits won't be detected by these signature-only approaches. Optimal solutions look for behaviors instead.
• Check if the defense code is tamper-resistant. The defense code will often run alongside potentially malicious code on the client-side. To prevent interference from the malicious code, the defense code must be able to prevent tampering attacks.

Looking Ahead

Even in the current landscape of fast-evolving Magecart attacks, this checklist should stand the test of time. A key takeaway here is understanding that a suitable solution to tackle Magecart should detect and block the source of the attack in real time, regardless of the attack’s approach.

I’m hopeful to see more retailers take a stand against this threat. Magecart attacks show no signs of slowing down, and it’s up to retailers to keep millions of shoppers secure.

Chief technology officer and co-founder of Jscrambler, Pedro Fortuna has extensive experience in academia and as a security researcher.