Retailers are on high alert during holiday season of Magecart attacks, which implant malicious computer code into websites and third-party suppliers of digital systems to steal credit card info. Earlier this month, a researcher reported that the Magecart gang used a new technique for hijacking PayPal transactions during checkout. (Justin Sullivan/Getty Images)
Cybercriminals engaging in Magecart schemes are becoming increasingly adept at hiding payment skimmers within innocuous-looking website files and features, as evidenced by two recently discovered schemes in which attackers concealed their malware inside social media buttons and CSS files.
These two campaigns planted and executed the skimmer’s code on the client side. However, the threat that’s particularly growing in stature is the server-side skimmer attack, said the man who reported these two attacks, Willem de Groot, founder of SanSec (Sanguine Security) in the Netherlands.
“We expect this trend to continue in the next year,” said de Groot, noting that server-side skimmers are already responsible for 65 percent of all e-commerce attacks.
Client-side attacks
Late last month, the SanSec Threat Research Team reported that Magecart actors attacked multiple compromised websites with skimmer code, hiding the malware in what looked like buttons intended to share content via social media services such as Facebook, Google, Instagram, Pinterest, Twitter and YouTube.
“While skimmers have added their malicious payload to benign files like images in the past, this is the first time that malicious code has been constructed as a perfectly valid image,” SanSec stated in a Nov. 26 company blog post.
First observed on websites last September, the malware payload was reportedly introduced in the form of an html .svg element, which essentially acts as a container for Scalable Vector Graphics-based graphical images that can be found on websites. The malware also includes a decoder, which interprets and executes that payload and can be hidden in a secondary location to further avoid detection.
“The result is that security scanners can no longer find malware just by testing for valid syntax,” the blog post said.
Then on Dec. 9, SanSec reported on another clever scheme via Twitter: “After finding skimmers in SVG files last week, we now discovered a #magecart skimmer in [a] perfectly valid CSS,” the tweet read. “It is parsed and executed during checkout. Malware loaded from cloud-iq[.]net,” which is a lookalike domain imitating CloudIQ, a free, cloud-based software as a service solution. A CSS, or cascading style sheet (CSS) file used to format webpage contents.
According to BleepingComputer, the skimmer code, which was found in three online stores, evaded detection because automated security scanners don’t typically scan CSS files. The script was designed to run only when customers enter their information. Upon checking out, the consumers would reportedly be redirected to a new page that would loads and parse the malicious CSS code.
“Digital skimmers are constantly evolving new methods to evade detection by scanners,” noted Ameet Naik, security evangelist at PerimeterX. “While scanners are a useful tool for analyzing a website for vulnerabilities, attacks such as these can fly under the radar, leading to weeks-long infections that leak thousands of credit card numbers from e-commerce sites. These credit card numbers are sold on the dark web, fueling an endless cycle of payment fraud with costs ultimately borne by the online merchants.”
In an interview, De Groot told SC Media that webstore operators, to combat such client-side skimmer threats, should “one, deploy application code to read-only storage; two, run server-side malware scanners to monitor the database and system processes; [and] three, use a vulnerability monitor to keep track of issues with third-party e-commerce components.
“Businesses need full runtime visibility into their customer-facing websites to detect and stop such attacks,” said Naik, noting that traditional application security approaches like static code analysis are ineffective. “Runtime analysis using client-side application security solutions can catch the malicious script in the act by observing behavioral signals and flagging anomalies.
Server-side attacks
But client-side security solutions won’t stop Magecart attacks that target back-end applications and take place on the server side – a tactic that DeGroot has seen steadily rise in popularity.
“Until recently, the battle between criminals and security researchers was in the browser,” said de Groot. “Payment thieves inject their malware using JavaScript. Because by its very nature JavaScript code is publicly exposed, these kind of injections are usually discovered quickly. However, we observe that attacks have been shifting towards e-commerce back-end applications this year. When malware code is hidden on the server or even databases, it is completely invisible to any outsiders.”
SanSec reported on such a case in a Dec. 2 blog post, noting that hackers in the last few months added a security flaw to more than 50 e-commerce websites running on Magento 2.2 and then exploited it before Black Friday in order to inject a backdoor and introduce a “hybrid skimming architecture, with front and back end malware working in tandem.”
The skimmer can be added to a static JS file on disk, SanSec reported, and is designed to display a fake payment form that “sends all of the intercepted data to ‘/checkout.’” This is almost identical to a normal transaction flow, so security monitoring systems will not raise any flags.” Next, on the server side, an added payload handler “collects the payment data and saves it to a discrete location for later retrieval” via a generic POST request.
Ben Baryo, cybersecurity researcher at PerimeterX, said that website admins “must continue to scan their back-end applications to detect and remove any malicious code lurking on the site.”
Attacks on the server-side won’t work against every store, however. Baryo noted that payment card transactions “are typically handled directly by third-party payment processors and the credit card numbers never reach the server side of the merchant.”