Meet the Threat: The Inside Workings of Magecart Breaches
By Eric Ford
Magecart has been attributed to at least six different cybercriminal elements that have placed digital credit card skimmers. The breaches at Ticketmaster, British Airways, and Newegg were caused by Magecart and lead to successfully intercepting thousands of consumer credit cards. One important detail is that online card skimming did not begin with Magecart. It has been occurring since at least 1999.
The high profile breaches of Ticketmaster and Newegg show how the impact can be significant and devastating. Attackers can steal not only credit card data but also personal information. If the infection is allowed to sit on an e-commerce website it potentially could affect millions of shoppers daily. If you are a small to medium sized e-commerce retailer who has been breached by Magecart in the past may lead to a significant decrease in online sales due to fear of the breach occurring again leading to a significant loss in sales revenue.
As the media coverage of Magecart breaches continues, consumers may be less inclined to use smaller web retailers for fear that they may not be able to properly protect the user’s information. There have been instances in the past were Magecart groups have successfully exfiltrated just more than payment card data. In the case of the VisionDirect.co.uk breach, the group was able to not only infect the main site but also the retail site for seven other European countries.
This breach demonstrated that the group was not only skimming for payment card data but also admin credentials and user login details.
Routine web application scanning of both internal and external code will help identify any malicious scripts and hardening against XSS. Note that traditional VM scanning does not typically find these types of compromises.
It is also important to proactively monitor websites or applications for signs of malicious activities such as unauthorized access and modification, data exfiltration, and execution of unknown scripts by actively monitoring the weblogs internally or through an MSSP. In addition to scanning code, you can also prevent suspicious outgoing connections.
Infrastructure that stores and manages sensitive data deserves extra attention. This includes regularly applying patches and software upgrades; disabling, restricting, updating and/or mitigating outdated components and/or third-party plugins; and strengthening authentication credentials in accordance with CIS/NIST guidelines.
Even though there are six or seven known threat actors associated with Magecart, the list is not all-inclusive. Many more criminal elements exist that also use Magecart. This report aims to provide the TTPs and the necessary mitigation steps to thwart attacks.
Threat Group 1
Threat Group 2
RiskIQ believes that groups 1 and group 2 are the same group because both groups used the same website with different logos for a reshipping scam. In this scam, the group fools job seekers into purchasing and shipping items to Eastern Europe where they can be resold. This was a separate campaign from its skimming campaigns.
The skimmer used the following elements to work: The first element used a timeout function that once passed would restart and run through the script again. Also, the skimmer would check to see if it was on a payment page by evaluating the URL location and inspect the form fields to see if data has been inputted. If the skimmer determines that data was entered, it extracts the data and sends it to a drop server at js-save.link via a POST request. The drop server also hosts the script.
Threat Group 3
First seen in 2016, group 3 operates similarly to the other groups but it does not target high-end stores. This group’s skimmer evaluates any forms on the page to see if they hold payment information. The script lists field IDs that map to payment forms. The script looks for generic field names such as cardNumber but is also smart enough to look for known payment processing companies. This makes the script website agnostic. This group targets payment processing companies in Latin America, indicating a focus on that region.
Every 700 milliseconds the skimmer runs through the script and goes through a three-step process to collect data. These steps can be enabled or disabled by the use of global flags. The skimmer looks for a generic form named billing or shipping. If it finds one, it parses the data and stores it locally in the browser under _billing123 or _shipping123. Next, the skimmer matches and extracts any field names from its payment processing list. This ensures that the name and address are collected even though it may be on a different page. Finally, it formats the data as a JSON object and sends it to a drop server via a POST request. Keeping the data in local storage allows the group to confirm that all desired information is available before it is sent. So far this is the only group that employs this method.
Threat Group 4
Threat Group 4 is more advanced and has been around since 2017. This group carefully places its skimmer to focus on mass compromises. It doesn’t avoid targeting altogether but specializes in mass compromise. This group tries to blend in with normal web traffic by using conventions that resemble the victim’s domains, ad providers, and other infrastructure. They will also change the appearance of both the skimmer and any URLs used. This group seems to have started with financial institution malware, then progressed into retail credit card skimming.
The script for the skimmer is so extensive we will only go over the overall basic functionality. The skimmer validates any payment data, then sets variables for basic information including the destination server. The URL is constructed by first matching the schema of the victim URL, then selects a random drop server from a predefined list, removes the web store’s hostname and appends saveOrder to it. Finally, the destination URL combines the schema, server hostname, and path created previously. Also, the group uses several validation features to ensure that payment information is being collected.
Unlike previous groups, this group’s script uses techniques to prevent analysis. The script checks for developer toolbars and also looks for a slowdown in execution to see if the code is being analyzed.
Threat Group 5
First identified in 2016, this group, like group 4, focuses on volume but will occasionally target a specific victim. This group targets third-party service providers like banner advertising services, website analytics or additional services. This will allow attackers to execute scripts on the page. They specialize in targeting service providers for online merchants but any third-party service provider could fall victim to this group.
Threat Group 6
Threat Group 6, identified in 2018, is probably the most known as it targets very well known websites such as British Airways and Newegg. By targeting well-known sites the group can ensure that they get a large volume of card data by the sheer volume of traffic to these sites.
Because the group targets well-known sites, they have a good understanding of the payment process and the skimmer that is used is simpler than the others. This group’s skimmer is cleaner and harder to detect, partly because it has certain sections specifically customized for each victim and how its payment form is formatted.
Threat Group 7
Also identified in 2018, this group does not have a well-defined operation and targets any e-commerce website it deems worthwhile. Unlike group 6, this group targets lesser-known sites and instead of using a server to inject and collect the data, it uses compromised sites as proxies. Because of this, it is much harder and more time-consuming to take down this group.
This group’s skimmer is built for each target and uses GET request to exfiltrate the payment data in images. Because this group does not use a server, the script resides on the victim’s website. The script uses two variables to identify compromised websites to use as proxies and the script runs every 500 milliseconds. The skimmer first checks to see if there is an ID for the checkout review. If there is an ID and the form is active and completed, the skimmer extracts the data.
The script base-64 encodes the data as one long string with each data point separated by the pipe symbol ( | ). Once all the data is ready to be exfiltrated, the script creates two images that have the source URL set to the compromised website with the stolen data appended to the URL.