“Magecart” is a collective of cybercriminal groups that have injected digital credit card skimmers into e-commerce and payment websites as early as 2015, with greater force since 2018.
Magecart attacks work by injecting 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). Attackers then send these details to attacker-controlled drop servers, without the victimized end-users or companies knowing.
Despite a strong push from the Cybersecurity industry to raise awareness of how Magecart operates, its harmful outcomes, and how to properly mitigate it, 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 worked by injecting malicious code into the Modernizr JavaScript library the company loaded 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 they analyzed the scripts the company used 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.
Without a real-time monitoring security solution, 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 ran a custom-built module on its payment pages developed by an external company—Inbenta. Ticketmaster was not breached directly; instead, attackers breached Inbenta and placed a malicious skimmer in the module sourced to Ticketmaster.
The Ticketmaster breach resulted in credit card theft affecting 40,000 victims. What sets this attack apart is that it remained active for 5 months before being caught.
3. Newegg Breach
Few details are known about this late-2018 Magecart attack, mostly because it was a first-party breach.
Most likely, like the BA breach, malicious actors disguised themselves behind drop servers mimicking Newegg at neweggstats.com.
An analysis of the attack details that it was performed by placing the credit card skimmer in the payment-processing page’s source code — not in a script. It then captured credit card details much like the BA attack, detecting events linked to the submit button, serializing the data, and sending it to the drop server.
In total, even though this attack wasn’t performed via a third party, it still took 5 days to detect and remove the malicious code from Newegg—a grim figure considering 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
In May 2019, the iconic American business magazine Forbes faced a Magecart attack that also collected 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 suggests a third party perpetrated the attack, although this was never disclosed. It remained active for a few days.
5. National Baseball Hall of Fame Breach
While the Baseball Hall of Fame website does not generate enormous traffic, and this incident likely did not affect a massive number of victims, it stands apart 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 could detect submitted credit card details by monitoring the ID co-billing form, then send them to a drop server.
6. 17,000 Domains Hit By a Single Magecart Attack
Most Magecart incidents so far show clear signs that attackers targeted specific victims, learning about the external scripts they used or simply placing the skimmer directly in 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 used this approach to breach 17,000 domains at once, including websites from the top 2,000 Alexa rankings, according to an analysis.
To do this, attackers automated scans of misconfigured Amazon S3 buckets, inserting the skimmer into unprotected JavaScript files they found.
7. Magecart Supply Chain Attack Through “Shopper Approved”
Despite the reach of the “Spray and Pray” approach mentioned above, misconfigured Amazon S3 buckets may seem like an isolated instance that attackers leveraged. However, a more prevalent, scalable, and replicable approach is web supply chain attacks.
With this approach, attackers target popular scripts used by multiple companies, such as widgets or analytics services.
By breaching these providers (which often lack proper security systems) and injecting the skimmer into the sourced script, attackers ensure the malicious code travels 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 because they can 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 security is lacking and why enterprises like Newegg and Forbes are caught off guard. Summing up this knowledge, here are some of the main takeaways:
- 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 into what code is being served to their users. - 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. - No company is too big, and no company is too small.
Different Magecart groups go after distinct company profiles. Some groups refine their approach to take down enterprises like British Airways, while others run “shotgun” attacks that infect thousands of websites, regardless of company size. - Companies are still losing the race.
Despite the security industry’s best efforts, and even with solutions that properly mitigate Magecart attacks, new incidents are reported almost weekly. The potential bounty of a Magecart attack is still too big for the relatively small effort required. - Too much is at stake.
$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.
