Kacy Zurkus looks at the common tactics contributing to recent Magecart attack success and explores how to defend against them
The hacker groups using Magecart attacks have been indiscriminate in their widespread offensive strategies, successfully victimizing organizations from British Airways to Ticketmaster, Feedify and Newegg with skimming attacks.
Earlier this year, RiskIQ identified bad actors attacking the supply chains of e-commerce sites around the globe. Going after the supply chain was not only efficient but quite effective for the threat actors, enabling them to successfully access thousands of victims at a time.
One of the hacking groups was also responsible for inserting malicious JavaScript into the code of Shopper Approved, a customer rating plugin. In the British Airways attack, the attackers veered from the previous pattern of infecting a third-party software provider and instead targeted the carrier itself.
Again, attackers successfully compromised Newegg in a stealthy attack in which they were able to avoid detection by registering – and then certifying with Comodo – a domain similar to the primary newegg.com domain on which a back-end server storing skimmed card information was hosted.
Having tracked the activity of malicious actors using Magecart attacks for a few years now, RiskIQ has surmized that the attackers appear not to be a singular group, but a collection of several different groups.
The skimming attacks start with a very generic step: breaching the organization they targeted.
Diverse Groups, Targeted Attacks
As diverse as the hacking groups are, they are all highly targeted in their attacks. A stylistic element that links the various groups together, despite the multiple methods of operation (MO) used by different actors, is that they are all quite consistent in grabbing content from payment pages, according to Yonathan Klijnsma, head researcher at RiskIQ.
“The way they do this varies from group to group. Some groups grab any form [of information], others explicitly look for payment information and validate this first,” says Klijnsma. This key MO is potentially one reason why Magecart attacks remain successful.
The skimming attacks start with a very generic step: breaching the organization they targeted. Whether it’s by using default credentials or credentials from public and non-public data breaches, attackers gain access relatively easily. Some might exploit outdated server software, while others exploit outdated CMS installations like older installs of Magento.
“Once inside they will, depending on what the payment process is, inject themselves on the right pages or simply inject their skimmer code on any page. Many skimmer implementations manually check if a visitor is on the checkout page and if payment information is available,” Klijnsma explains.
Another reason why Magecart attacks are so successful is that attackers are often easily able to identify a vulnerability in web applications, which are, unfortunately, rife given how little attention web app developers give to security and privacy, argues Chris Olson, CEO of The Media Trust. Even when developers make updates and patches available, website operators often delay, if not forego them altogether. Too often operators fail to scan their sites in real time, making a bad situation even worse given that bad actors often modify their tactics, as has been the case in many of the Magecart attacks.
“Relying on scanning experts with the most extensive malware data is key because attacks are often modified in order to escape detection by weak scanners,” Olson says. “Modification tactics range from obfuscating code, which enables malware to elude conventional anti-malware tools, to arresting an attack when the presence of a known expert’s technology is detected.
“Having this scanning done by experts would enable them to closely monitor all the known and unknown third parties that execute code in their digital ecosystem, and identify any unauthorized activities that heighten the risk of a data breach and regulatory infringement.”
"Attacks are often modified in order to escape detection by weak scanners”
Continued Success
In analyzing the myriad attacks, a few fundamental issues have come to light, revealing factors that contribute to the continued success of the Magecart attacks. One factor is that companies, industries and standards continue to ignore the significant risks that third-party code suppliers pose, according to Olson.
“Security and risk professionals would rather perform checks on whether they’ve been hit than take the more proactive approach of preventing these attacks from happening again. The only way to do this is to continuously scan their sites and mobile apps in order to identify any unauthorized code and, when needed, terminate them.”
What poses another problem is that website owners only know a fraction of all the third-party code that executes within their ecosystem but outside the purview of their IT security team. “They have no incentive to know these direct and indirect third parties because the information security standards around applications and the handling of credit card payments fail to recognize the risks third parties pose. PCI, NIST and ISO standards, for instance, do not require knowing third-party code,” Olson says.
Moreover, most organizations lack visibility into their internet-facing attack surface, leaving them unable to determine whether they’ve been breached. According to Klijnsma: “Many organizations simply lack visibility into the client-side of their sites, so they’re unaware of their vulnerabilities and if they’ve been breached. It’s a fertile ground for Magecart attacks in the e-commerce space, especially amongst the huge number of small and mid-sized online stores.”
Preventing the Attacks
The good news is that attacks can potentially be prevented through good security practices, but also by performing additional integrity checking. One option, Klijnsma explains, is to monitor your server for any kind of file modifications. One approach RiskIQ takes here is that it monitors all resources, be it locally hosted or remote, and whenever there is a change it notifies customers about this change, which can then be marked as benign or not.
“For consumers, get your bank to issue new cards but also look into setting up additional verification steps on your payment account,” Klijnsma advises. “Keep in mind that banks don’t always have those added steps enabled by default, but you can add a second step to your payment process where you have to provide additional proof for the payment. When using additional verification steps, even when your card is skimmed, payments cannot go through as the attackers cannot perform the second step of verifications in two-factor authorization (2FA) such as one-time passwords (OTP).”
When security practices and the standards that govern them fail to account for internal vulnerabilities introduced by third parties, bad actors are able to bypass security measures through trusted connections, which is why Olson says companies should take a proactive approach to digital security by knowing all their direct and indirect third-party code suppliers and monitoring all their activities by continuously scanning digital assets in real time.
“They should work with all their third parties on terminating code that violates their digital policies. Also, they should test their web apps to ensure they are not vulnerable to attacks involving cross-site scripting or SQL injections.
“Developers should restrict user input by restricting text to a certain number and range of characters. They should write code that checks to ensure that data without the proper format is never inserted directly into the HTML content that comprises the web application,” Olson concludes.