Your organization’s leadership is 12 times more likely to be the target of a security incident and nine times more likely to be the target of a data breach than they were last year. Find out how they can be protected.
Read the Datasheet
Gift Cardsharks: The Massive Threat Campaigns Circling Beneath the Surface
Learn about the attack group primarily targeting gift card retailers and the monetization techniques they use.
Get the Report
Threat Hunting Workshop Series
Join one of our security threat hunting workshops to get hands-on experience investigating and remediating threats.
Attend an Upcoming Workshop
Inside Magecart: New RiskIQ & Flashpoint Research Report
Learn about the groups and criminal underworld behind the front-page breaches.
Threat Hunting Guide: 3 Must-Haves for the Effective Modern Threat Hunter
The threat hunting landscape is constantly evolving. Learn the techniques, tactics, and tools needed to become a highly-effective threat hunter.
Over the past several months, we’ve published four reports on the digital credit card-skimming activities of Magecart—mainly regarding significant breaches like Ticketmaster, British Airways, and Newegg. In every publication, we noted that the six groups under Magecart have ramped up their operations, becoming more clever, and in many cases, sophisticated, with each attack.
However, a particularly problematic aspect of Magecart activities is that due to a general lack of visibility into the code running on most e-commerce sites, site owners and consumers are generally unaware when the third party’s code on that checkout page into which they’re entering their payment information has been compromised with Magecart’s skimming code.
In this blog, we’re disclosing what could have been another sizable Magecart attack against Shopper Approved, a customer rating plugin that integrates with thousands of e-commerce sites, had it not been for a few recent industry trends and fast detection and notification by RiskIQ. Below, we’ll provide analysis of this new attack and provide detail of when the Magecart attackers added the skimmer, where they added it, and the scope of affected websites.
Similar to the attack against Ticketmaster, this attack did not impact a single store directly. Instead, it attempted to skim payment information from multiple online stores at once by compromising a widely used third party. In this case, the actors compromised Shopper Approved, an organization that provides rating seals for online stores.
Early on the morning of September 15th, RiskIQ received an incident notification regarding Magecart. Although we’re notified hourly, this domain (and affected URL) caught our eye. Here is the incident detailing:
Fig-1 Magecart incident inside RiskIQ
Opening the associated page in the crawl data, we immediately see the Magecart skimmer in the code. Here is what the normal certificate.js file for Shopper Approved looks like:
Fig-2 Normal file without Magecart code
Here is the same script but with the Magecart skimmer added from our incident:
Fig-3 Appearance of the Magecart skimmer
An interesting aspect of this attack is that the above screenshot is not what the skimmer looked like when the actors first put it in—they made a mistake! At 04:35:07 GMT on September 15th, the actors modified the certificate.js script to include the skimmer, which looked like this afterward:
Fig-4 Modified script
Almost 15 minutes later, the actors came back at 04:49:59 GMT and modified the script again to make it look like the one shown in the screenshot before. They forgot to obfuscate their skimmer the first time, a small mistake, but it allowed us to view the clean skimmer code, which is a good reference point.
One other thing to note is that recently Feedify was also compromised, and a skimmer was also placed in their scripts that used the same drop server (where the cards are sent off to) as the one used in the Shopper Approved attack: info-stat.ws.
As soon as we detected the Magecart skimmer on Shopper Approved, we reached out to them via email, phone, and even LinkedIn to see if we could help provide them with information to remediate it.
On Monday, September 17th at 15:03:01 GMT, the skimmer code was removed from the site-seal script. 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.
One thing to note is the affected website count. While Shopper Approved is active on thousands of websites, only a small fraction of their clients were impacted. We believe three key factors contributed to this limited impact:
We’d like to note one final concern, the awareness of which can help limit the scope of future Magecart attacks. 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. As a site owner, be sure to purge any caching you are performing after your organization is hit with a skimmer like this.
Prior to publishing our findings, Scott Brandley, co-founder of Shopper Approved, provided the following remarks:
“On behalf of Shopper Approved, I want to personally thank the RiskIQ team for the diligence and incredible effort they’ve taken in helping us detect and secure our code in such a short amount of time,” said Shopper Approved co-founder and CEO Scott Brandley. “It is rare when you find a company like RiskIQ who genuinely helps people simply because it is the right thing to do. RiskIQ helped significantly limit the impact caused by Magecart – and for that, we will be forever grateful.”
Magecart groups are carrying out a full-scale assault on e-commerce and show zero signs of stopping. These attacks are only getting more and more traction as the groups learn how to become more effective. While initial attacks involved low-tier Magento stores, later attacks targeted CDNs to increase their reach. Now, Magecart operatives have learned to tune the CDNs they compromise to ensure that the only sites they hit are online stores. To achieve their goals, they will go after any analytics company, CDN, or any service supplying functionality to e-commerce websites.
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. Many payment service providers have already taken this approach by prohibiting third-party code from running on pages where customers enter their payment information.
We are keeping a very close eye on the activities of the Magecart groups and will continue to report publicly on them.
What’s in a #malvertisement? We found more #magecart and a 186% spike in drive-by delivery https://t.co/rsl9GGiRUZ
.@TechCrunch's @zackwhittaker found that thousands of MoviePass customer card numbers were exposed because a critical server was left unsecured. With @ydklijnsma and RiskIQ data in @passivetotal, he discovered the exposure began all the way back in May https://t.co/blde3p21dU
Can you spot the phish? In tomorrow's PassiveTotal Thursday, we’ll take a real-life #phishing page targeting a popular brand and break it down to show how it differs from the genuine. Register today: https://t.co/EP2q6On5vE #ThreatHunting
We're thrilled to welcome Dean Ćoza, who will lead our product and technology teams as RiskIQ Chief Product Officer. Read more about Dean's appointment here:
Check out the brand new @RiskIQ Threat Hunting course on @CybraryIT
Manage Your Attack Surface Management using the "Mark of the Web"
https://t.co/ZGDBGyecJr #cybersecurity #magecart #course #cybrary