Anti-Malware , Cybercrime , Fraud

Magecart Card-Stealing Gang Hits 'Shopper Approved' Plug-In

Supply Chain Hack Targets Customer Rating Plug-In Used by Thousands of Sites
Magecart Card-Stealing Gang Hits 'Shopper Approved' Plug-In

A notorious group of payment card-stealing gangs called Magecart has been tied to another series of online attacks.

See Also: Fraud Prevention for Banks: Top 10 Tech Requirements to Evaluate

The latest known victim is Shopper Approved, an e-commerce service based in Ogden, Utah, that enables sites to gather local reviews, merchant reviews and product reviews from their customers.

Shopper Approved has confirmed the attack by Magecart, saying it first learned about the potential incident on Sept. 17 from security firm RiskIQ.

"Fortunately, we were able to quickly detect and secure the code related to the incident. We also put additional security measures in place to help ensure that this doesn't happen again," Scott Brandley, CEO of Shopper Approved, says in a security alert on the company's website. "After a thorough investigation, we were able to determine that only a very small percentage of our clients were involved, and we have already reached out to those clients directly in an effort to help them remediate any issues."

Security alert posted to the Shopper Approved website

RiskIQ says it tipped off Shopper Approved to the attack by Magecart on Sept. 15. Magecart, it says, is an umbrella organization - likely composed of six separate groups - that specializes in what it calls "digital skimmer" software, referring to malicious code that gets injected into a site and is then used to sniff or intercept any payment card data entered by an e-commerce website customer.

Researchers, including those from RiskIQ, have previously tied Magecart to attacks against ticket-selling giant Ticketmaster, U.K. airline British Airways as well as e-commerce site Newegg.

The attack against Shopper Approved mirrored the attack against Ticketmaster, RiskIQ says, in that it didn't attempt to directly hack any single online store. "Instead, it attempted to skim payment information from multiple online stores at once by compromising a widely used third party," Yonathan Klijnsma, a threat researcher at RiskIQ who's been tracking Magecart attacks for several years, says in a blog post.

Hackers Struck Outside Office Hours

In the case of the Shopper Approved attack, Klijnsma says that the attackers struck on Sept. 15 - a Saturday - and that RiskIQ reached out to the business the same day "via email, phone and even LinkedIn to see if we could help provide them with information to remediate it."

The timing of the attack may have been designed to ensure that the exploit lasted as long as possible, because Shopper Approved's website says it is only open from Monday to Friday, 8:30 am to 4:30 pm U.S. Mountain Time.

No one at the business appears to have been in the loop over the weekend to receive or act on RiskIQ's Saturday tipoff.

"On Monday, September 17th at 15:03:01 GMT [9:30 am Mountain Time] the skimmer code was removed from the site-seal script," RiskIQ says. "Since then, we have been in frequent contact with Shopper Approved, which launched a full-scale internal investigation in addition to engaging a leading forensics firm to help find out exactly how this happened and who was affected."

Shopper Approved CEO Brandley says in a statement: "RiskIQ helped significantly limit the impact caused by Magecart - and for that, we will be forever grateful."

Automated alert seen by RiskIQ on Sept. 15, 2018, as a result of its website crawling engines

Target: Supply Chain

Researchers say this continues to be Magecart's frequent modus operandi: Hack a widely used service, then use that to try and inject attack code into the hundreds or thousands of sites that use the service. Ticketmaster, for example, says that it was hacked after attackers planted malicious code into its automated customer support chatbot software from Inbenta Technologies. Inbenta confirmed the attack, but countered that Ticketmaster should never have been using its JavaScript software on a payment page.

Klijnsma says via Twitter that Magecart Group 5 hacked Shopper Approved, "which is the same group behind the Ticketmaster breach." He adds that the group focuses "solely on compromising third parties - the supply chain of the web if you will," noting that "with this MO their reach is very big.

Indeed, last month another Magecart victim was Feedify, a website push notification service, ZDnet reported. The intrusion was discovered on Sept. 11 by a security researcher known as Placebo, who alerted Feedify.

But U.K. security researcher Kevin Beaumont said the attackers had re-infected Feedify at least three times after the site's administrators had expunged attack code.

Feedify, based in Indore, India, didn't immediately respond to a request for comment.

Another recent victim of Magecart was the online portal of Cancer Research UK, a charity that runs a number of shops in the U.K., the Sunday Telegraph reports, citing information shared by RiskIQ. The hackers have not been tied to any payment card data theft from physical stores, but only the online portal, which sells T-shirts, cancer treatment and aftercare support products as well as Christmas cards.

Other recent Magecart victims have included furniture retailer Aria, home care and nursing supplier Countrywide Healthcare and publishing house Faber & Faber, the Sunday Telegraph reported.

Massive Impact

"Thousands of companies" have been directly or indirectly hit by Magecart infections, Beaumont said in a blog post. To help defenders, he's released an endpoint threat hunter organizations can use to scan their endpoints for signs of a Magecart injection.

"The basic technique is this: insert JavaScript - either through third parties or by hacking websites - to post [HTML] credit cards off to attackers' websites," Beaumont said. "This doesn't trigger retailer systems because the card data goes directly from the customer system to the attackers," thus bypassing such defenses as web application firewalls and data loss prevention systems.

Tripwire Detected

Dutch security researcher Willem de Groot has also been tracking the Magecart attacks, including reverse-engineering the group's attack code. He says another recent victim of the group was gadget and accessory e-commerce vendor TechRabbit.

On Sept. 22, TechRabbit announced that between Feb. 22, 2017, and May 22, 2018, an "intruder viewed or stole a subset of customer payment records for purchases made on the Tech Rabbit website." Stolen information included full payment card numbers, security codes and dates of expiration, as well as customers' first and last names, mailing address, email address and telephone number, according to the business, which is based in Union, New Jersey.

On Thursday, de Groot noted that Magecart had adapted its attack code to include a tripwire, designed to detect if security researchers were attempting to interact with the attack code.

"Back in 2016, Magecart skimmers would evade detection by sleeping if any developer tools were found running," de Groot says in a blog post. "Now, Magecart sounds the alarm when it finds you snooping around and collects a fingerprint of you on an external server."

The code is designed to give the attackers a view as to who might be investigating. "When developer tools are open and you start debugging, the tripwire will send your time zone, IP, browser and a whole lot of other info about you to an external URL," he says. Such information could potentially be used to create hard-coded IP blocks to try and curtail future research efforts, he adds.

On Tuesday, meanwhile, de Groot warned that TechRabbit's website appeared to have once again been infected with form-scraping code planted by Magecart, designed to harvest the exact same type of information that the group previously stole.

TechRabbit didn't immediately respond to a request for comment. An automated email reply read: "We have received your message; however we are currently out of the office observing the upcoming Jewish holidays. Sit tight and be assured that you will hear back from us within 2-4 business days."

Cache Flush Required

Researchers expect these types of attacks to continue because they're effective at harvesting large quantities of profitable payment card data.

"Magecart groups are carrying out a full-scale assault on e-commerce and show zero signs of stopping," says RiskIQ's Klijnsma. "These attacks are only getting more and more traction as the groups learn how to become more effective."

With such attacks in mind, all e-commerce firms should put in place specific defenses. "Word to the wise: If you own an e-commerce company, it's a best practice to remove the third-party code from your checkout pages whenever possible," Klijnsma says. "Many payment service providers have already taken this approach by prohibiting third-party code from running on pages where customers enter their payment information."

In addition, any organization that suffers a Magecart-type attack, after expunging the bad code, needs to ensure that it flushes its content delivery network cache. "Many websites use CDN services for caching, and we've noticed that often the skimmer code will be cached in the CDN and stay active there long after the skimmer is cleaned up from an affected site," Klijnsma says. "As a site owner, be sure to purge any caching you are performing after your organization is hit with a skimmer like this."


About the Author

Mathew J. Schwartz

Mathew J. Schwartz

Executive Editor, DataBreachToday & Europe

Schwartz is an award-winning journalist with two decades of experience in magazines, newspapers and electronic media. He has covered the information security and privacy sector throughout his career. Before joining Information Security Media Group in 2014, where he now serves as the Executive Editor, DataBreachToday and for European news coverage, Schwartz was the information security beat reporter for InformationWeek and a frequent contributor to DarkReading, amongst other publications. He lives in Scotland.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.eu, you agree to our use of cookies.