7 Biggest Magecart Attacks To Date, Lessons Learned

“Magecart” is a collective of cybercriminal groups that have been injecting digital credit card skimmers on e-commerce and payment websites as early as 2015, but in stronger force since 2018.

The modus operandi behind Magecart attacks is to inject malicious JavaScript code into the target company’s payment page. This code actively listens to events that happen on the page and collects credit card details whenever a user submits them in a form (event hijacking). These details are then sent to attacker-controlled drop servers, without any awareness from the victimized end-users and companies.

Despite a great push from the Cybersecurity industry to spread awareness of how Magecart operates, its nefarious outcomes, and how to properly mitigate them, new attacks keep emerging almost every week.

Today, we will focus on some of the most notorious Magecart attacks to date, to understand how they worked and how we can learn from them. Because the outcome of most Magecart attacks was not publicly disclosed, we also explore attacks with distinct approaches.

1. British Airways Breach

The Magecart attack on BA was achieved by injecting malicious code into the Modernizr JavaScript library that the company was loading on its website and mobile app.  This malicious code remained active and undetected for 15 days, stealing the credit card details of 380,000 BA customers.

An analysis by RiskIQ shed light on the attack mechanics. Specifically, the malicious skimmer contained 22 lines of JavaScript that listened to the mouseup and touchend events on the webpage (which indicate when a "Submit" button is pressed on a credit card payment form), serialized the submitted credit card data, and sent it as a JSON file to an attacker-controlled drop server mimicking BA: baways.com.

This analysis highlights that attackers specifically targeted British Airways. This meant that they analyzed the scripts being used by the company on its payment page and exploited one in a way that wouldn't raise suspicion. Because the skimmer was inserted into a trusted script, it likely didn't trigger any response from network defenders.

The lack of a real-time monitoring security solution meant that the attack wasn't caught promptly.

2. Ticketmaster Breach

This mid-2018 incident is another great example of an attack aimed at specific companies.

Ticketmaster was running a custom-built module on its payment pages which was developed by an external company — Inbenta. Ticketmaster was not breached directly; instead, attackers breached Inbenta, placing their malicious skimmer on the module sourced to Ticketmaster.

The Ticketmaster breach resulted in 40,000 victims of credit card theft. One thing that sets this attack apart from the rest is that it remained active for 5 months before being caught.

3. Newegg Breach

Not a lot of details are known about this late-2018 Magecart attack, mostly because it was a first-party breach.

Most like what happened in the BA breach, malicious actors disguised behind drop servers mimicking Newegg, neweggstats.com.

An analysis of the attack details that it was performed by placing the credit card skimmer on the source code of the payment processing page — not on a script. It then captured credit card details in a very similar fashion to the BA attack, detecting the events linked to the submit button, serializing data, and sending it to the drop server.

In total, and even though this attack was not performed via a third party, it still took 5 days to detect and remove the malicious code from Newegg — a grim figure considering that the website would have received around 8.4 million visitors during that time frame.

Shortly after the breach, a collection of 500,000 American credit card details was put for sale on the Dark Web.

4. Forbes Breach

Jumping straight into May 2019, the iconic American business magazine Forbes faced a Magecart attack which also collected other customer data such as names, phone numbers, and addresses.

As reported by security researcher Troy Mursch, attackers exfiltrated this data by sending it to the fontsawesome.gq drop server (clearly mimicking the widely used Font Awesome service) through a WebSocket connection.

The analysis of the attack leads to the belief that it was perpetrated through a third party, although this was never actually disclosed. It remained active for a few days.

5. National Baseball Hall of Fame Breach

While the website for the Baseball Hall of Fame does not generate an enormous amount of traffic nor did this incident likely result in a massive number of victims, it sets itself apart from others because it remained undetected for a staggering 6 months.

Diving deeper into the attack mechanics, an analysis shows that, much like the Newegg attack, this was a first-party data breach.

Magecart actors inserted a malicious script disguised as a Google service, served from the domain googletagstorage.com. This script was capable of detecting submitted credit card details by monitoring the ID co-billing form and then sending them to a drop server.

6. 17,000 Domains Hit By a Single Magecart Attack

Most of the Magecart incidents presented so far display clear signs that attackers had specific victims in mind, learning about the external scripts that they used or simply placing the skimmer directly on the payment page's source code.

However, some Magecart groups opt for a completely distinct "spray and pray" approach, using skimmers that are generically activated on payment pages regardless of the website where they're found. This is typically achieved by using regular expressions such as onepage|checkout|onestep. With this approach, attackers can grab all data inserted into payment forms, including personally identifiable information.

A July 2019 Magecart attack followed this approach to breach 17,000 domains at once, including websites from the top 2,000 Alexa rankings, as an analysis shows.

To achieve this, attackers found a way to automate the scanning of Amazon S3 Buckets with misconfigurations, inserting the skimmer into unprotected JavaScript files found within.

7. Magecart Supply Chain Attack Through "Shopper Approved"

Despite the great reach of the "Spray and Pray" approach mentioned above, misconfigured Amazon S3 Buckets could be seen as an isolated instance that attackers were able to leverage. However, a more prevalent, scalable, and replicable approach has been pursued via Web Supply Chain Attacks.

With this approach, attackers go directly after popular scripts that are sourced to multiple companies, such as widgets or analytics services.

By breaching these providers (which often lack proper security systems) and placing the skimmer into the sourced script, attackers ensure that the malicious code makes its way down the Web supply chain and is served on multiple websites.

This is precisely what happened in the supply chain attack on Shopper Approved, a shop rating widget used by thousands of websites.

In September 2018, Magecart attackers inserted the skimmer into the Shopper Approved script certificate.js. Much like every other Magecart skimmer, it collected credit card data and sent it to a drop server.

Magecart web supply chain attacks are especially dangerous due to their ability to remain undetected by network defenses. Because they are initiated by a component of the system that is trusted by default (the script provider), security measures such as a Web Application Firewall (WAF) fail to properly address the attack.

Lessons Learned

Today, Magecart is still one of the biggest threats to the E-Commerce sector and to every website that processes payments.

Analyzing past Magecart attacks is crucial to understanding what is lacking security-wise and why enterprises like Newegg and Forbes are being caught off-guard. Summing up this knowledge, here are some of the main takeaways:

1. Visibility is everything.
   Magecart attacks only thrive because they aren't detected quickly. Some attacks have lasted 5 to 6 months, making it clear that companies have zero visibility of what code is being served to their users.
   
   

2. Client-side security is a must.
   At the core of every Magecart breach is attackers' ability to monitor and hijack events that happen on the client side of payment pages. Companies lack proper investment in client-side security and are sitting ducks to code poisoning attacks — not only Magecart but every other Web Supply Chain Attack.
   
   

3. No company is too big, and no company is too small.
   Different Magecart groups go after distinct company profiles. If some groups choose to refine their approach to take down enterprises like British Airways, others perform "shotgun" attacks that infect thousands of websites, regardless of the company size.
   
   

4. Companies are still losing the race.
   Despite the best efforts of the security industry and even with solutions that ensure the proper mitigation of Magecart attacks, new incidents are being reported almost weekly. The potential bounty of a Magecart attack is still too big when compared to the relatively small required effort.
   
   

5. There's too much to be lost.
   $230 million — this is what the Magecart attack on British Airways cost their business, and this only represents the GDPR fine. When we add to the equation the loss of trust from customers and stakeholders, Magecart inflicts a wound that can take years to heal, if ever.

If you wish to learn how our Webpage Monitoring technology detects and mitigates Magecart attacks in real time, schedule a meeting with us.