Magecart attacks – the threat continues to rise

By Andrew Wortley, Head of Audit & Certification, Blackfoot


Back in November 2016 Blackfoot issued a press release relating to Magecart injecting key loggers into direct post and I-Frame e-commerce payment pages to harvest payment card details.

Attackers targeted sites based on several popular e-commerce platforms including Magento, Powerfront and OpenCart, and several payment processing services including Braintree and VeriSign.

At the time Magecart infection was found on more than 100 e-commerce sites.

Unlike other e-commerce breaches seen in the past, a successful Magecart attack involved only a small change to the site code. This change points to JavaScript hosed on a separate site controlled by the criminals. When a customer visits the payment page, the criminals JavaScript is loaded along with the merchant’s payment page, and a keylogger or form scraper silently harvests the customers payment card details. The attack does not rely on criminals breaching the site and remaining undetected for a long time while they discover and exfiltrate data, it can all happen very quickly. The malicious JavaScript does not reside on, nor is it run from the merchant’s e-commerce site.

Magecart infection succeeded through reliance on insecure development processes exploiting vulnerabilities in the e-commerce platforms, or by obtaining site administrator credentials.

What is the threat?

Because Magecart silently harvests payment card details, a compromised e-commerce site could go undetected for weeks or months, allowing the criminals to gather a large number of payment card details until they are ready to cash out.

The criminals have taken steps to avoid detection and raising suspicions. The JavaScript may not execute on every checkout, which prevents customers and staff noticing anomalous behaviour. Additionally, criminals may detect client sessions running from within the merchant’s IP address ranges, or from an IP address belonging to known payment industry or information security organisation, in which case the JavaScript may not execute to avoid detection.

What is the impact?

The impact of a Magecart or similar breach is significant to merchants. There are costs in terms of forensics, remediation, breach fines and reduced revenue resulting from loss of reputation.

Note that whilst the Magecart campaign is focused on stealing payment card data, any web form data would be vulnerable to the same attack. This creates an additional GDPR risk to both personal data and sensitive personal data.

Latest position on Magecart

Magecart has evolved in various guises ever since, with the online payment skimming operations run by Magecart fraudsters continuing to increase in 2019.

In 2018 there were a number of high-profile Magecart type attacks against NewEgg, Sotheby’s, Vision Express UK, British Airways and Ticketmaster.

The Magecart name was once used to describe the group running these attacks. However, with as many as 12 major identifiable criminal syndicates now utilising this type of attack vector, the Magecart nickname is just as likely to refer to the common techniques that are employed by these organised gangs.

In late 2018 Yonathan Klijnsma, threat researcher for Risk IQ, is quoted as saying “With the number of criminal groups operating these skimming campaigns, it’s likely one of the biggest threats facing e-commerce right now”.

The excellent work done by the Card Brands and PCI Security Standards Council to reduce Retail F2F POS fraud through the use of Chip and Pin based credit/debit cards has shifted card fraud increasingly to e-commerce.

A renowned security expert Bob Rudis at Rapid7, has a similar view:

“Attackers still want payment card data, since they have their own playbooks full of successful steps they can take to turn digits into dollars. Rather than abandon all this coin, they’ve refocused their efforts to the server side.”

Recommended steps to mitigate the risk of a Magecart type attack

  • Implement a robust SSDLC methodology, including a rigorous deployment authorisation process.
  • Minimise JavaScript/styles from third parties, and where possible place risk assessed versions on your hosting servers.
  • Eliminate tags on payment pages.
  • Keep e-commerce platform patched and updated.
  • Protect administrator access with multi-factor authentication.
  • Set permissions on application artefacts to read-only after deployment.
  • Raise alerts if out-of-process permission changes are made.
  • Perform regular infrastructure pen tests against the hosting environment.
  • Perform regular web application pen tests.
  • Use File Integrity Monitoring (FIM) to detect changes on the web server.
  • Conduct mystery shopping from random locations outside of the company..
  • Consider reverse proxy to test outbound traffic.
  • Train support staff to understand that reports of anomalous website behavior might indicate a breach.
  • Conduct social media monitoring to look for reports of anomalous behaviour and fraud


Recommended Blogs:

The cost of a data breach
Reviewing the EmuParadise Breach
PCI DSS: Looking ahead to v4.0

Magecart infection was found on more than 100 e-commerce sites