Threat hunters from IBM X-Force Incident Response and Intelligence Services (IRIS) identified malicious activity attributed to a financially motivated cybercrime faction known as Magecart Group 5 (MG5).
Our research revealed that MG5 is likely testing malicious code designed for injection into benign JavaScript files loaded by commercial-grade layer 7 (L7) routers. These routers are typically used by airports, casinos, hotels and resorts, to name a few. X-Force IRIS believes MG5 is currently targeting users shopping on U.S. and Chinese websites.
Additionally, we found that MG5 has likely devised an attack scenario in which it could inject its malicious payment card stealing code into a popular open-source JavaScript library. This open-source code is provided as a free, licensed tool designed to help make websites compatible with mobile browsing. By infecting that code, MG5 can potentially infect and compromise the data of mobile device users that install booby-trapped apps and then shop online.
Please note that X-Force IRIS has not discovered any vendor compromise. What we are seeing are MG5 attack tactics, techniques and procedures (TTPs) targeting resources produced by said vendors. An actual attack would require further steps on MG5’s part.
Targeting Commercial-Grade, L7 Routers
What started as a threat hunting activity ended in analysis of malicious test code X-Force IRIS believes was written by a Magecart faction — more specifically, Magecart Group 5.
In our findings, we have come to suspect that MG5 prepared the code for injection into a specific type of router that’s used for providing commercial Wi-Fi connectivity to numerous users — think of all the users connecting to hotel or free airport Wi-Fi. These routers are a special type of commercial-class layer 7 router, designed to control and manipulate various layers of the OSI model, specifically the application layer.
L7 routers are network devices that integrate routing and switching capabilities. As such, they can pass traffic and make forwarding and routing decisions on other layers of the OSI model, such as layer 2 or layer 4, but use richer information that’s inherent to layer 7. The router can reside in the same virtualization server as other business-critical IT infrastructure components, which means a compromise there can be used to pivot to other parts of the zone.
When it comes to internet connectivity, L7 routing and the devices designed with that protocol are often used in captive portal scenarios, allowing hospitality customers to connect to the internet under the conditions of the provider (payment, terms and conditions, or viewing ads). To implement the provider’s policies, these routers can allow their operator to control the content delivered to the entire user population connecting to that router.
But while they offer notable benefits, popular routers in this category can also present risky features when it comes to information security — content filtering, redirection to interstitial pages, payload rewriting and traffic shaping are just a few of those features. Compromising the web resources that an L7 router loads (e.g., JavaScript files used for traffic shaping) can potentially allow an attacker to use these features maliciously against the user population that connects to it.
Captive Portals and Captive Potential Victims
By way of example, let’s consider the use of L7 routers in the hospitality sector.
Wi-Fi is the No. 1 amenity requested by hotel guests, whether they come for business or pleasure. Since this is such a highly used amenity, service providers have to offer it to their guests, even if it is a cost center to their operation.
With a slim information technology team to manage the infrastructure on site, hotels most often choose to outsource the Wi-Fi service — some in compliance with the top-level brand’s policies, and others contracting vendors locally — which makes for very patchy security, if any.
When offering Wi-Fi service, most vendors do not support proxying adverts or JavaScript injection. So why do we often see ads when we connect via captive portals? That’s because Wi-Fi vendors looking to make extra profit from third parties may offer the hotel a discounted price for the Wi-Fi operation if it allows midstream ads to run before guests connect. And since it makes business sense, many hotels agree to lower operational costs.
What they may not know is that this is exactly where cybercrime groups like Magecart thrive: Ads, JavaScript injections and a massive number of captive users who come and go would find it hard to point to where they lost their financial data.
Having access to a large number of captive users with very high turnover — such as in the case of airports and hotels — is a lucrative concept for attackers looking to compromise payment data. We believe that MG5 aims to find and infect L7 router libraries with malicious code and possibly inject malicious ads that captive users must click on to eventually connect to the internet.
The compromise can therefore be twofold:
- Guest payment data can be stolen when they browse through a compromised router; and
- Malicious ads can be injected into webpages viewed by all connected guest devices, including those who pay to use the internet and those connecting to a hotel’s free Wi-Fi hot spots.
Swipe Right or Left — Your Data’s Gone
Another finding from X-Force IRIS with regards to code being tested by Magecart Group 5 concerns open-source mobile app code that’s offered to app developers for free. The code provides a library-agnostic touch slider to allow developers to build touch galleries for their app projects.
MG5 has likely infected copies of this code, ensuring that any ecommerce site using the slider will end up serving the attackers’ malicious code, leading to the compromise of data belonging to those using the finished product.
This strategy is well in line with MG5’s TTPs: compromising a third-party platform to affect a large user base without the added effort.
Magecart Group 5 Basics
What’s known as Magecart today started as the name of web-based skimming malware. The term Magecart has since evolved into the name of a modus operandi used by at least 38 different cybercrime factions that target e-commerce sites by compromising their carts, checkout pages or web logic, depending on the group and its campaign tactics.
Common to all Magecart-using factions is the use of online skimming attacks to steal payment card data from unsuspecting shoppers. With more than 38 groups identified so far, each group can be different in its actual M.O. Some operate drop-shipping scams, fake reshipping companies or drop mules, while others may steal data in real time or compromise a shop’s backend.
Among these various factions, Magecart Group 5 is considered to be among the most prominent. It also differs in its targeting strategy and attack tactics. Unlike other online skimmer groups that directly compromise their target’s shopping cart platforms, Magecart Group 5 focuses on targeting third-party services used by e-commerce websites by injecting skimming code to JavaScript libraries they provide.
Previous research by RiskIQ’s Yonathan Klijnsma and Jordan Herman suggests that Magecart Group 5 is the perpetrator of publicized attacks on multiple IT supply chain companies that allegedly resulted in large-scale compromises.
Mitigation Tips: Prevent Access to Data
Magecart groups have already compromised hundreds of thousands of merchants. In a sense, the ability to target users stems from third-party risk that attackers are leveraging. Here are some tips from our team to mitigate the risks of Magecart attacks.
E-Commerce Retailers (Server-Side)
- Avoid insecure third-party code (e.g., using Adminer versions released earlier than v4.7.0).
- Use extension blacklists.
- Implement code/file integrity checks, especially for any JavaScript files loaded from external third-party providers.
E-Commerce Retailers (Client-Side)
- Use strong content security policies (CSP). This free tool can help.
- Work on the most prominent web application issues that attackers prey on. You can start with OWASP’s Top 10 list.
Banks and Card Issuers
- Similar to other card compromises, look out for Common Point of Compromise and investigate to revoke and reissue cards as needed.
- Use the controls you would use for CNP fraud.
- Educate merchants about Magecart Groups and encourage them to:
- Look at their code and change their DevOps viewpoint when it comes to security;
- Adopt a zero trust model with JavaScript/JScript to block access to sensitive data in web forms;
- Ensure only vetted scripts can access data; and
- Educate users about card security and reviewing their statements regularly to report potential fraud.
Download the research to learn more about MG5
Threat Hunt and Discovery Analyst
Principal Consultant, X-Force Cyber Crisis Management, IBM
Malware Reverse Engineer, IBM Security