“Magecart” – A Platform Agnostic Threat

Over roughly the past five years, there has been a dramatic evolution of client-side website attacks which now plague both website administrators and visitors. Although the fundamental technique which these attacks use is as old as web browsers themselves “Magecart attacks,” as they have come to be known, have exploded in popularity. The term “Magecart” is a combination of the words “Magento,” which is an ecommerce platform currently owned by Adobe, and “shopping cart,” which is the part of that platform which was originally exploited to perform this sort of attack. 

Magecart was first used to describe one particular group of attackers. Over time, the term grew to encompass 16 different, independently operated groups of hackers who exploited websites using the same technique. Today, the term Magecart is used to describe both those original attack groups, the many new groups which adopt this technique as their primary means of attack, independent and less skilled attackers who purchase the means to perform these attack, as well as the attack itself. Additionally, the security community has begun the coalesce around the terms “eskimming,” “formjacking,” and “clickjacking” as additional ways to describe a client-side website attack. 

In the years since the term Magecart was coined, there have been many attacks which rely on the same technique to exploit websites that do not use Magento at all, and many which do not operate under an ecommerce model at all. Today, the term is somewhat generic, like the common usage of “Xerox” to mean any photocopying technology. 

In September of 2020, one attack group included in the Magecart umbrella returned to their roots, so to speak, and compromised thousands of websites using the Magento platform by exploiting a common vulnerability and embedding JavaScript within the website to defraud visitors (which are the basic mechanics of how this attack is perpetrated). There are a handful of reasons for this, including the expertise those attackers have gained compromising the Magento platform for years, Adobe’s recent decision to end support and updates for older versions of Magento, as well as remaining install base of Magento sites which is not insignificant. 

Given this news, it seems at first blush that this remains a Magento-only problem, which unfortunately leads many to think that if they are not a Magento shop they do not need to worry about Magecart. Unfortunately, that is not the case. 

As described above, the technique used to execute a Magecart (or “formjacking,” or “eskimming,” etc. attack, all terms are interchangeable here) is to embed harmful code within the JavaScript a website uses to make its webpage interactive once it is loaded into the visitor’s browser. There are many ways to accomplish that goal, such as: 

• Compromising the platform the website itself uses, as was the case in the September 2020 attack. In that attack, the platform compromised was in fact Magento, however, there have been many high-profile and widespread attack campaigns waged against website application platforms like WordPress, Salesforce’s Heroku, web server applications themselves, etc. Attack the technology which serves content to the browser is a universal technique no matter what that technology is.
• Exploiting a hosting provider or content delivery network. This technique has been used against Amazon’s S3 web storage service, content deliveries devoted to hosting JavaScript code for multiple independent sites and even hacked Github repositories. Another way to think of this technique is as a “well-poisoning” attack — by embedding an attack payload within a resource accessed by multiple independent websites the attackers can gather successfully compromise many, many targets with minimal effort
• Exploiting a 3rd party vendor to ‘sideload’ the attack into a website. In this scenario, the attacker breaks into the servers owned by a 3rd party vendor to a given website. These vendors often provide services like analytics, marketing, customer support and other business services which a company needs to include on its website but which it is unlikely to develop in house. By compromising one of these vendors and embedding a payload within that vendor’s code, the attacker thereby gains access to any of that vendor’s customers’ websites, and all of those customers’ visitors. 

As illustrated above, there are a myriad of ways to actually execute a Magecart attack, the majority of which do not involve the Magento ecommerce platform at all. 

Because JavaScript — irrespective of its source, whether first-party, 3rd-party, embedded by an attacker or legitimately included — has no internal security controls, no notion of permission, and no way to limit access to the web page in the browser and the information contained therein, this attack is possible irrespective of platform, configuration, industry or existing security protocols.

Like many common terms, the origin of the word “Magecart” is a combination of history and necessity, and like many common terms it has grown to encompass a number of meanings beyond its specific origins. Because of the immense growth of Magecart attacks over the past five years, it unfortunately seems clear that the term will only become more commonly used and become a more important part of any security professional’s lexicon.