Blog

At RiskIQ, we track many different Magecart groups. We continually observe evolutions in the techniques they employ to skim card data and obfuscate the code that they use for that purpose. These skimmers are becoming increasingly capable, fulfilling a variety of functions to optimize the work of the operators that deploy them. 

On January 24th, we first became aware of a new Magecart skimmer, which we dubbed MakeFrame after its ability to make iframes for skimming payment data. We initially flagged it with our machine learning model for detecting obfuscated code. 

Since then, we have captured several different versions of the skimmer, each sporting various levels of obfuscation, from dev versions in clear code to finalized versions using encrypted obfuscation. So far, RiskIQ has observed MakeFrame on 19 different victim sites. 

In some cases, we've seen MakeFrame using compromised sites for all three of its functions—hosting the skimming code itself, loading the skimmer on other compromised websites, and exfiltrating the stolen data. There are several elements of the MakeFrame skimmer that are familiar to us, but it's this technique in particular that reminds us of Magecart Group 7.

The following is our analysis of this unique skimmer and the process we followed to attribute this skimmer to Magecart Group 7.

On Thursday, February 20th, around 3 pm GMT, criminals RiskIQ identifies as Magecart Group 8 placed a JavaScript skimmer on the international website for blender manufacturer NutriBullet, nutribullet.com. Our systems caught the cyber attack as it happened and continue to detect new developments.

After multiple attempts to contact NutriBullet and receiving no response*, RiskIQ decided to initiate the takedown of the attacker exfiltration domain with the help of AbuseCH and ShadowServer. Group 8 operators were using this domain to receive stolen credit card information, and its takedown prevented there being new victims.

On March 1st, we observed the skimmer had been removed, but on March 5th, around 7 pm GMT, the cyber attackers placed a new skimmer on the NutriBullet website. We again scrambled to get the infrastructure neutralized. Unfortunately, the criminals still have access to NutriBullet's infrastructure and can continue to replace the skimmer domain in the code to make it work again. Again on March 10th, the cyber attackers were back with another skimmer in yet another script on the NutriBullet website. Until NutriBullet acknowledges our outreach and performs a cleanup, we highly advise against making any purchases on the site as customer data is endangered.

As with all breaches, RiskIQ’s technology and researchers will continue to keep a close eye on the breach and work to take down any additional domains stood up by the criminals. 

The First Skimmer

A recent blog post by Jacob Pimental and Max Kersten highlighted Magecart activity targeting ticket re-selling websites for the 2020 Olympics and EUFA Euro 2020, olympictickets2020.com and eurotickets2020.com respectively. These sites were compromised by a skimmer using the domain opendoorcdn.com for data exfiltration. With RiskIQ data, our researchers built on the previous reporting to identify more skimming domains used by the attackers, as well as additional compromised sites. RiskIQ can also now attribute all these cyberattacks to Magecart Group 12. 

The obfuscation and skimming code we observed on opendoorcdn.com matches that used by Magecart Group 12, whose skimmer and obfuscation techniques we analyzed in our blog posts, "New Year, Same Magecart: The Continuation of Web-based Supply Chain Attacks" and "Magento Attack: All Payment Platforms are Targets for Magecart Attacks." However, there are differences in the techniques employed by Group 12 in these more recent compromises, which we'll break down here.

In those blog posts, we noted that Group 12 employed base64 encoded checks against the URL looking for the word "checkout" to identify the proper page on which to load their skimmer code. This encoding masked both the check itself and the skimmer URL. Quoting from our May 1st, 2019 report:

"Most of Group 12's injections occur with a pre-filter on the page—a small snippet of JavaScript that checks to see if they want to inject their skimmer on the page. Here's what it looks like:"

Magecart Group 12's script tag from RiskIQ's May report

RiskIQ continuously investigates incidents of digital crime as we observe them on the web. Monitoring changes to crime groups and the evolution of their tactics is essential to continue to detect them effectively and stay ahead of the bad guys. With Magecart, we followed the crime syndicate's first group and carefully analyzed its skimming code. As new Magecart groups materialized with unique code and tactics, we built on our Magecart base knowledge to get better and better at detecting Magecart and other forms of web skimming.

In this article, we will discuss our insights into a criminal group that maximizes their profit by working in two ecosystems that are typically distinct: phishing and web skimming. By leveraging a tactic with which they had tons of experience, phishing, they could double-dip into one with which they had less expertise, web skimming.

By combining tactics, this group was playing with a full deck when it came to stealing financial data—introducing Full(z) House.

Here, Malwarebytes published an article highlighting a small piece of this group's activity in card skimming.

Introduction

LNKR is malware that uses browser extensions for Chrome to track browsing activities of users and overlay ads on legitimate sites. Using extensions to add code that executes in a user's browser is a common and lucrative monetization technique on the internet, where spyware, adware, and other browser-based nuisances have thrived since the early days. 

LNKR spreads via illegitimate browser extensions, which add malicious Javascript to web pages a user visits. This code allows LNKR to record browser sessions to identify frequently visited sites, and overlay ads from which threat actors can monetize. However, LNKR is a bit more robust than your average malicious browser extension—it also looks for pages to which a user has write-access and can edit. With this access, the cyber threat can inject JavaScript code directly on the site to spread beyond the limited scope of a browser extension. While we have not observed LNKR uploading any external JavaScript other than its own, the ability to inject JavaScript allows threat actors to upload any kind they want, including Magecart or other malware. 

Seeing the Cyber Threat

RiskIQ crawlers don't install extensions, but the data we collect from our global discovery platform gives us unique insight into the LNKR threat. We can use known LNKR command and control (C2) domains and our Host Pairs data set, to determine if there was any inventoried infrastructure making calls to these C2 domains

Host pairs are unique relationships between pages that are observed by RiskIQ when we crawl a web page. Each pair has a direction of child or parent and a cause that outlines the relationship connection. These values provide insight into redirection sequences, dependent requests, or specific actions within a web page when it loads. What makes this data set powerful is the ability to understand relationships between hosts based on details from visiting the actual page.

Old Magecart domains are finding new life in subsequent cyber threat campaigns, many of which are entirely unrelated to web skimming. 

Over the years, we’ve outed many Magecart web-skimming campaigns in reports that denoted IOCs, including malicious domains that cyber attackers used to inject web-skimming JavaScript into browsers or as a destination for the skimmed payment information. Large portions of these malicious domains have been taken up for sinkholing by various parties. However, some of them are kicked offline by the registrar, put on hold, and then eventually released back into the pool of available domains.

Here’s the catch: when these domains come back online, they retain their call-outs to malicious domains placed on breached websites by cyber attackers, which means they also retain their value to cyber threat actors. Bad guys are taking advantage of these domains coming back up for sale and purchasing them to be once again pressed into service for malicious purposes, whether that be more web skimming or for use in malvertising campaigns.

Hijacking JavaScript injections

Many website owners are never aware of an active skimmer threat on their site—RiskIQ found that the average Magecart skimmer stays on a site for over two months, and many stay there indefinitely. The entire lifecycle of these malicious domains—loading JavaScript to an infected website, going offline, and then coming back online again—can pass without the website owner having an inkling that something was wrong. 

On July 26th, ThreatConnect published an analysis of a coordinated phishing attack against Bellingcat, an investigative journalism website that specializes in fact-checking and open-source intelligence. Known for their work investigating Russia, Bellingcat researchers were carefully chosen targets, as stated by Bellingcat’s Eliot Higgins on Twitter. 

Highly focused, the phishing campaign targeted the digital security of only ten individuals, who have been identified by investigative journalist Christo Grozev. These include some researchers who do not work for Bellingcat but do investigate Russia.

ProtonMail, the email service used in the phishing attack, published a short statement, which included some fascinating details on the phishing attack from their perspective.

Introduction

In this article, we’ll explore a different angle to this campaign by analyzing it from the unique outside-in perspective of RiskIQ. RiskIQ data reveals multiple phishing campaigns involving different tactics beyond the analysis by ThreatConnect. 

On May 14th, RiskIQ covered the latest mass compromise of third-party web suppliers by a Magecart group. This initial report focused on seven of these suppliers, the scripts of which were injected with skimmer code, which possibly affected several thousand websites using their services. 

However, the actual scale of this campaign and the number of sites affected is much larger than previously reported. The actors behind these compromises have automated the process of compromising websites with skimmers by actively scanning for misconfigured Amazon S3 buckets. These buckets are un-secure because they are misconfigured, which allows anyone with an Amazon Web Services account to read or write content to them.

RiskIQ has been monitoring the compromise of S3 buckets since the beginning of the campaign, which started in early April 2019. We’ve been working with Amazon and affected parties to address Magecart injections and misconfigured S3 buckets as we observe them.

We wrote the following article to raise awareness around the security policies for Amazon S3 as well as web-skimming attacks in general.

Discovery of Misconfigured Bucket

Last weekend, security researchers surfaced new supply-chain attacks involving Magecart web-skimmers placed on several web-based suppliers, including AdMaxim, CloudCMS, and Picreel. The breaches were part of a large-scale attack that hit a breadth of providers simultaneously intending to access as many websites as possible.

Web-based supply-chain attacks, which compromise vendors that supply code that adds or improves website functionality, gives attackers access to a wide range of victims at once because the compromised code often integrates with thousands of sites. In this blog, we'll break down the Magecart skimming activity on these seven providers and detail when and how the compromises occurred, including how some of them could have been far worse.

A Widespread Campaign

As the timestamps below indicate, the majority of these compromises happened near the same day, Friday, May 10th.

Some of the targets in this campaign do not even process payments on their websites, showing that the attackers used a “shotgun” approach to great effect, compromising as many websites as they could knowing that at least some of them would be lucrative. RiskIQ found evidence of many other sites also being compromised, including: