How to avoid becoming the next victim of a Magecart attack

Jan. 17, 2019
Make sure your web servers and the software running on them have the latest security updates

Magecart attacks have left a string of victims in its wake and seem poised to do even more damage soon. Generic versions of a card skimmer—the primary tool used in the attack—have been found on hundreds of websites. And now, just this week, researchers found that a group within the Magecart crime family has evolved the malware. With this evolution, Magecart can skim data not just from website visitors, but also from site administrators, which can allow the perpetrators to escalate attacks and infiltrate organizations

Let’s take a look at how these attacks are taking place and what organizations can do to better protect themselves.

The security industry, led by research from RiskIQ and Volexity, first became aware of Magecart threat actor behavior almost three years ago. Like other cyber-attack methods, Magecart attacks have morphed into new variants.  More recent variations of Magecart’s malicious code surfaced in June when Ticketmaster reported that customer data had been breached due to a partner company being attacked. An announcement from British Airways followed on September 6. Data belonging to about 380,000 customers (the number was later revised upwards) who had used the airline’s website and the application had been compromised. Shortly thereafter, Newegg confirmed that they had also been compromised. Other high-profile victims have included Cathay Pacific and Sotheby’s. And this past December revealed the new variant noted above, which goes deeper than ever into organizations, targeting those with admin privileges. The new group that RiskIQ has identified as “Magecart Group 12”, and according to Trend Micro has impacted more than 277 self-hosted shopping cart websites in the cosmetic, healthcare and retail apparel markets as well as ticketing sites for tours and air travel.

According to RiskIQ and Volexity, here’s how a Magecart attack is executed:

  1. An attacker obtains write access to a web application’s source code. This access is obtained by using stolen or easily compromised credentials, or by exploiting known vulnerabilities.
  2. The attacker inserts a “digital card skimmer” into the front-end of a target web application. A digital card skimmer is script that steals payment information. As we’ve seen this week, the skimmer can easily be adapted to steal other data as well.
  3. When a customer interacts with the infected web application (specifically, submits information via a payment or login form), the script is downloaded and executed on the client side. The script intercepts the data and sends it to the attacker. In the case of payment forms, the transaction processes, the business is paid, and the customer receives their purchase - the crime is committed without either the originating business or the victim knowing payment details were compromised.

Why Magecart is Effective

Before we look at how organizations can better protect themselves against Magecart attacks, it helps to understand why traditional security measures have been ineffective. In a typical data breach, data is exfiltrated from servers on the organization’s network. Traditional security tools like Web Application Firewalls (WAF) and Data Loss Prevention (DLP) systems monitor the data coming in and going out of the servers in an effort to stop this type of data exfiltration.

Magecart, however, steals customer data before it ever gets to the organization’s network or servers. It doesn’t matter what infiltration method is initially used; Magecart alters the web app’s code so that the end user’s browser sends data directly to the attacker’s website. WAF and DLP systems don’t monitor the front end of your applications. Nor do traditional security tools watch what the browser sends to other websites. In fact, web app code itself is often left unprotected.

As with any attack, detection time is critical. The longer it takes for an organization to discover an active skimmer, the greater the number of customers impacted and the greater the damage to the business. In some of the incidents mentioned above, the skimmer has operated on the website for many months. In addition to known security best practices, like strong authentication and software patching, organizations need to put checks and balances in place to limit damage if an attacker gains access to the system. They also need to have a layered defense and the ability to quickly detect and remediate any breach that does occur. Let’s take a closer look at what all of this looks like in the case of a Magecart attack.

Early Detection

In most of the high-profile incidents, the Magecart attack was highly targeted. For example, the British Airways attackers registered a domain, which they used to collect credit card data sent from the card skimmer, six days before the skimmer itself started working. The skimmer was then custom-fit to the specific payment form used on the BA website and app.

This all indicates the attackers first initiated a reconnaissance phase to gain access to the BA website and app. This phase delivered the necessary intelligence for the attackers to determine how the website was structured, how to collect the desired payment data, and how to hide their presence. Detecting an attack during the reconnaissance phase offers a window of opportunity to learn that your system has been compromised and mitigate coming attacks before they have any impact.

To protect your organization during the reconnaissance phase, you should:

  1. Make it extremely difficult to analyze your web applications by obfuscating the code.
  2. Be alerted when bad actors are in the reconnaissance phase.
  3. Create a remediation plan to harden web app code to improve protection.

Detect Unauthorized Code Changes

The Magecart skimmer is just a few lines of code that are injected into a payment form or a supporting resource. Organizations must be able to detect these changes to prevent this new form of stealing large volumes of credit card transaction details.

An effective strategy for detecting unauthorized code changes involves a variety of protection mechanisms, from checksums and code tampering protection to detecting web page code injections (DOM tampering). These mechanisms can identify code modification, notify the organization, and help mitigate its impact—all in real time.

As part of a layered security approach, these protection capabilities complement and protect each other. If attackers manage to decipher your obfuscation technique or bypass your integrity checks, other protection mechanisms will still be triggered. Additionally, and most importantly, protections have integrated alerting capabilities to provide insights into the attackers’ strategy and the information they might be after.

Closing the Loop

The real-time information provided from the attacks in progress, from reconnaissance to tampering attempts, should be integrated into your SOC and fraud prevention systems to help your security adapt to zero-day threats. This threat data will help you understand your risk posture and enable you to more effectively respond to real-time, in-the-wild threats.

Don’t Forget Third-party Code

Third-party code isn’t entirely to blame for Magecart, but it does introduce added risk. It’s not always possible to scrutinize someone else’s code, and one breach can have a ripple effect that includes you.

Fortunately, the tactics described above can be used to protect third-party code running on your website, be it from partners or open-source libraries. It’s also a good idea to carefully vet your partners. Find out if they protect their code using the same techniques. Remember, any code running on your website reflects on your organization and has the potential to impact your customers.


The Magecart attacks highlight an area that is often left unprotected: the client side and web application code. Organizations must extend security best practices to include their client side. A layered defense that includes mechanisms to prevent analysis of code, to detect and react to unauthorized modification of code, and to correlate events into the larger security picture while partnering with trusted third-parties, can help shore up defenses against Magecart and similar code modifying attacks.

About the author: Matan GK is the Director of Product Management at Arxan Technologies.