Overview

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.

Potential Impact

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.

Mitigation

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.

Implementing strong content security policy headers on your site will control what domains can communicate with your site and what the domains are allowed to do. Proper configuration can prevent XSS by having the browser stop all JavaScript that does not come from a server defined in the policy. This will prevent any attempt to exfiltrate stolen data.

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.

Technical Overview

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 1 was identified in 2015. The creation dates on some domains attributed to this group suggest it may have formed in 2014. The original Magecart skimmer used JavaScript embedded into e-commerce sites. The skimmer copied any payment forms and send it to a drop server. The drop server served a dual purpose, also hosting the skimmer. The basic structure of the skimmer is still in use today.

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.

This group’s skimmer does a better job of hiding from detection. Its servers return a 403 error if you send a request without the proper user-agent or referral from a victim store. Requests from a victim store coming from something other than a checkout page get a benign JavaScript file that doesn’t affect the functionality of the web store. Additionally, this group sometimes uses two-part scripts, with a long benign section that can run thousands of lines followed by the skimmer.

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.

This group appears to have started with the same common Magecart as the other groups. It then used a free obfuscation service provided by javascriptobfuscator.com to hide the script’s purpose. In one case, the breach of Shopper Approved, the group forgot to obfuscate. This error allowed researchers to identify key features of the script. Like the other groups, this group also checks the URL against a list predefined list to see if the URL is a checkout page. Over time the group adds URLs to this list. If the script identifies that it is on a valid checkout page, it will then start to collect the desired information that is extracted by the clk function.  Once the data is extracted the script base 64 encodes the data and sends it via POST to the drop server.

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.

Supporting Information

• https://www.trendmicro.com/vinfo/us/threat-encyclopedia/web-attack/100/oscommerce-mass-compromise-leads-to-datastealing-malware-infections
• https://blog.trendmicro.com/trendlabs-security-intelligence/new-magecart-attack-delivered-through-compromised-advertising-supply-chain/
• https://cdn.riskiq.com/wp-content/uploads/2018/11/RiskIQ-Flashpoint-Inside-MageCart-Report.pdf
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

↑