Hackers are using increasingly sophisticated techniques to hide malicious code on e-commerce websites with the goal of stealing payment card details. Known as web skimmers, these malicious scripts have led to major breaches at online retailers over the past year and will very likely continue to cause problems for some time to come.
Hacking into e-commerce websites and stealing credit card details from databases goes back 15 years or more. However, as the security of both physical and online transactions increased over time, the attacks have shifted to the point of entry rather than stored records.
Over the past year, security professionals have investigated and tracked an increasing number of malicious actors that specialize in compromising websites and injecting malicious obfuscated scripts to steal card details as users are entering them into payment pages. One of the most prolific such gangs is called Magecart and is actually an umbrella organization with different subgroups.
Magecart a leading web-based card skimming threat
Magecart has been responsible for recent card breaches on websites belonging to high-profile companies like British Airways, TicketMaster, Newegg, Feedify, Shopper Approved, as well as sites belonging to numerous smaller online merchants. Its members are known for using stealthy and clever techniques to make their injections hard to detect, sometimes even compromising various third-party services providers who already have their legitimate code loaded into websites.
Researchers from security firm RiskIQ have recently analyzed two attacks attributed to Magecart that were discovered in the company’s historical dataset obtained from crawled websites. Both of those attacks highlight how these attackers are adapting to defenses change their tactics accordingly.
One was a website compromise that, according to RiskIQ’s data, took place in October 2018 and affected MyPillow.com, a US-based bedding merchant. At first, attackers registered a similarly named domain called mypiltow.com and loaded their skimming script from it into the compromised website to blend into all the other local scripts the site was already loading. They even went to the trouble of getting an SSL certificate for their rogue domain to avoid triggering mixed-content warnings in users’ browsers.
The original skimming code ran for a short period of time before being discovered and removed. However, the attackers retained their malicious access to the site or gained access again and returned that same month with a new attack implementation. They registered a domain name called livechatinc.org, which is very similar to livechatinc.com, a legitimate live chat support service used by merchants on their websites including by MyPillow.com.
“The attackers played a brilliant game the second time they placed a skimmer on the MyPillow website, adding a new script tag for LiveChat that matched a script tag usually inserted by the LiveChat scripts,” the RiskIQ researchers said in their new report. “The Magecart attackers went even further by proxying the standard script returned from the real LiveChat service and appended the skimmer code below it.”
The second attack lasted longer and was eventually discovered and removed from the website on November 19, according to RiskIQ. There have been no other detections since then, the researchers said.
“I can confirm there was an attempted breach on the mypillow.com website on October 5,” said Mike Lindell, CEO of MyPillow, in an emailed statement. “It was caught immediately. MyPillow hired a third party to investigate. They found no indication that the breach was effective or that any customer’s information was compromised. MyPillow reported the attempted breach to the authorities and has increased security on our website. Our customers and their security are my number one priority.”
Web-based card skimming attacks changing techniques
The second incident involved another merchant called Amerisleep.com, whose website was originally compromised in 2017, then again in December 2018, according to RiskIQ’s data. That security breach is ongoing, even though attackers have changed techniques a few times, the researchers said.
During the 2017 attack, which lasted from around April to October, the attackers injected skimming scripts through a PHP backdoor and changed their custom domain for the scripts a few times over that period. Then the site was clean until December 2018, when a new compromise occurred and the MageCart hackers decided to host and load their skimming script directly from a GitHub repository they registered in Amerisleep’s name.
Later, in January they changed their techniques again to custom domains but added conditional checks in the skimming script so that it only got triggered on the payment pages. Amerisleep.com did not immediately respond to a request for comment.
“With the increased efficiency of credit-card skimming groups, the time it takes for a large number of consumers to have their data stolen, seemingly out of nowhere, is decreasing quickly,” the RiskIQ researchers said. “Magecart has capitalized on the fact that the security controls of small companies who provide services to enhance the websites of global brands are far less developed than the security controls of the global brands themselves.”
Advice to reduce risk from web-based card skimming attacks
Online merchants should invest in products that can provide visibility over unauthorized changes made to their websites and more importantly, they should scrutinize all third-party scripts they choose to load into their websites, whether for advertising, visitor analytics or other purposes. Attackers like MageCart obfuscate their scripts to bypass automated detection, but the presence of obfuscated code on the website in the first place can serve as a red flag and be the reason for further investigation.
Some technologies like Subresource Integrity (SRI), which is supported by modern browsers, can be used to mitigate some of the risks from third-party scripts. They allow websites to provide visitors’ browsers with cryptographic hashes for the third-party resources they serve so that if those resources are modified on the server side, browsers will refuse to load them.