During alert monitoring, ThreatLabZ researchers came across multiple cases of shopping sites being compromised and injected with a skimming script. This injected script looks for the payment method and personally identifiable information (PII) and captures supplied financial information which is then sent to an adversary-controlled gate server even before the user hits the submit form. There have been multiple reports published related to Magecart activity, and ThreatLabZ has blogged about the hacker group’s activities in the past. (Read previous blogs from September 2018 and July 2019.)
In this blog, we will provide an overview of the current skimming campaigns with an analysis of those that use compromised sites to host the skimmer code and those that use newly registered domains.
The following screen capture shows the Magecart hits we observed over the last 90 days. The activity appears to be fairly consistent week to week, with a spike at the end of the analysis period, and we believe it is likely to continue.
Figure 1: Hits on compromised sites over 90 days (x-axis=date, y-axis=hits)
Most of the impacted websites are in the shopping category. The following graph shows the cloud-wide statistic for the number of unique domains per category for the sites impacted.
Figure 2: URL categories of impacted sites (x-axis=URL category, y-axis=unique domain counts)
This Magecart-based skimming campaign did not reveal any novel tactics, tools, or procedures, but it seems to be more structured in terms of the scripts being used across multiple compromises, similar gate URL parameter patterns, and the algorithm used for data encoding.
The cycles we observed were generally the same, but we did see some differences. Some use obfuscation to hide the script injection code and use another compromised site for hosting the skimmer script, while others make use of newly registered domains for skimmer script hosting. Regardless of the loading script, the skimmer code possesses little to no obfuscation.
Compromised site loads skimmer code from another compromised site
The following image shows a Fiddler session to demonstrate the skimming chain.
Figure 3: Fiddler session for Magecart skimming
In these skimming campaigns, we can see compromised sites sending captured payment information to domains that are either newly registered or compromised and under the control of an adversary. In the following example, the gate site is compromised as well and was registered on 2013-03-19.
Figure 4: Example of injected script and skimmer code
The way this skimmer code operates is to wait for the user to fill in the personal information and payment method and capture it all before the user hits the submit button. This captured information is then encoded using the Base64 algorithm and sent to the gate URL in a GET request.
Figure 5: Skimmer script sending base64 encoded PII and Payment Information GET Request
Compromised site loads skimmer code from a newly registered domain
As shown in the image below, the skimming script is being hosted on a domain registered just 10 days before this analysis.
Figure 6: Compromised site leveraging skimmer script from a newly registered domain
All the skimmer scripts we’ve identified so far are similar, and we observed the following common gate URL pattern:
Figure 7: Skimmer script differences
We saw multiple cases where the same skimmer code locations were being used in multiple compromised sites, including:
The image below shows examples of skimmer code locations being used for multiple compromised sites.
Figure 8: The same skimmer code locations used in multiple compromised sites
Magecart has been successful for years because attackers have improved their techniques for injecting malicious code and hiding it from detection. Now, we are seeing attackers able to steal payment card information before it is even submitted. Zscaler ThreatLabZ actively tracks such campaigns and protects customers from skimming and other types of data-stealing attacks.
|Common skimmer JS URL patterns|
|Bad domains||Creation date|