Magecart groups have made many successful attacks on high-profile companies over the past two years. In a Magecart attack, attackers covertly inject credit card skimming code into the checkout pages of e-commerce websites to exfiltrate data on thousands of customers.
While some might only remember Magecart from the 2018 British Airways breach, one of these cybercrime groups breached the payment forms of retail giant Claire’s earlier this summer. And just a month or so ago, attackers breached the websites of eight U.S. cities through a third-party service.
If we zero-in on the targets of high-profile Magecart attacks, the average revenue of the victims sits just north of $2.1 billion. There’s another important metric of web skimming attacks that can’t go ignored. The Magecart skimmer remained active on Claire’s website for 50 days before being detected and removed. On average, companies take 22 days to uncover the actual attack. This huge lag largely explains why Magecart attacks are still such potent threats to every company that processes online payments.
Not surprisingly, several companies are actively looking for specific protection against this kind of web skimming attack, also known as “formjacking.” There’s enough evidence that web skimmers are evolving fast and more traditional security solutions such as a Content Security Policy or using Subresource Integrity (SRI) aren’t up-to-par.
So, when security teams look for and assess different products to tackle this important business problem, what specific features should they consider? And which tests should companies perform to best mimic a real-world Magecart skimmer?
Companies should start by understanding that they shouldn’t focus on preventing the actual infection from a web skimmer. There are so many possible ways for attackers to inject malicious code into the company’s platform that most security pros consider it a lost fight.
Better to acknowledge that an infection will likely occur at some point. Then, the clock starts ticking. Every minute that passes without the ability to detect and block the skimmer means thousands of infected user sessions. Consider a two-step process of detecting and blocking. The implemented product needs to detect signs of a web skimming infection in real-time and then deliver the ability to block this malicious behavior.
We recently finished a three-month proof of concept with a major airline that was testing several distinct approaches to mitigating Magecart attacks. As we went head-to-head with several competitors, we got a firmer understanding of the rigorous type of testing that companies should put in place when procuring a product.
So here’s a checklist of the tests required:
- Detect and block the addition of “click” or “submit” event handlers to the page. Security pros consider the addition of form-related event handlers (for example, of an onmouseover event) a common malicious behavior in Magecart skimmers.
- Detect and block the addition of elements to the page, such as forms. More advanced web skimmers add fake credit card payment forms to the page or new buttons to the page. Security pros also consider this sort of document object model (DOM) tampering a common indicator of malicious behavior.
- Detect and block the removal of elements from the page, such as a div and its child nodes. By removing content from the page, attackers can divert users from the legitimate flows in lieu of compromised ones.
- Detect and block the modification of page content, such as editing element attributes or changing element visibility. Much like removing elements from the page, modifying it lets attackers trick users, for example by hiding a spinner.
- Detect and block sensitive data collection and its exfiltration. Magecart attackers invariably need to send the captured data out to a drop server. Security teams need to detect this, namely by monitoring for outbound network events to unknown domains or even unexpected data to known domains.
We consider a product that passes all of these tests a good candidate in terms of raw capabilities. But security teams know that this just represents the beginning. Then, there are the important issues of performance, maintenance, flexibility and the security and resilience of the product itself.
Here are other points to consider:
- Require a complete website inventory. This improves visibility of the scripts and network connections that take place in any given user session, making it easier to learn what’s normal and to spot malicious behaviors.
- Avoid bot-based approaches. Some of the more advanced Magecart skimmers use bot detection techniques to avoid detection from approaches that visit the page continuously to check for skimmers.
- Avoid products with limited compatibility. Some products don’t work on all browsers and versions; for example, SRI isn’t compatible with Internet Explorer or with Safari for iOS.
- Avoid any type of impact on page performance. Online experts consider page performance an important driver of e-commerce sales; the solution should leave a minimal footprint in performance.
- Avoid high-maintenance products that are difficult to integrate. Integrating a product 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. These products will be very limited in terms of detection capabilities and will likely fail to detect new exploits. Optimal products look for behaviors instead.
- Look for tamper-resistant defense code. The defense code will often run alongside potentially malicious code. To avoid interference from the malicious code, the code itself must deter direct tampering attacks.
Magecart attacks are relevant to any e-commerce organization today. We’re confident that following these checklists will help any company that’s looking to protect itself against this growing business threat.
To help companies win this battle, we have decided to offer three-months of Magecart detection for free. This includes a full website inventory with details of infected scripts and suspicious network events.
Originally published on SC Magazine by Pedro Fortuna.