Need cloud computing? Get started now

Magecart Attack Disguised as Google Tag Manager

Roman Lvovsky

Written by

Roman Lvovsky

February 15, 2023

Roman Lvovsky

Written by

Roman Lvovsky

Roman Lvovsky is a Security Researcher with extensive experience in client-side threats, browser internals, and JavaScript attack vectors. He is a member of the Akamai Security Intelligence Group and focuses his research on various client-side threats, such as web skimming and Magecart attacks. He has a solid background in software engineering, with a specialization in JavaScript and web development.

The recent attack aimed to steal sensitive information from visitors on checkout pages and forms.

A new sophisticated Magecart web skimming campaign has been discovered on several ecommerce websites. Magecart attacks are a type of cybercrime that specifically targets online retailers. These attacks involve injecting malicious JavaScript code into the payment pages of websites, which captures customers’ sensitive information as soon as it is input and sends it to the attacker's server. This information can include credit card numbers and personal details.

The recent attack aimed to steal sensitive information from visitors on checkout pages and forms. The attackers were able to inject a malicious inline JavaScript code into the targeted websites by exploiting a vulnerability. The skimmer used techniques such as impersonating a legitimate third-party vendor, like Google Tag Manager, and hiding the malicious code through Base64 encoding. 

The attack is ongoing on some websites, and resembles the recent attack on Canada’s largest alcohol retailer.

Attack overview

Impersonating a known vendor code

The skimmer injects a malicious code as an inline script (a script that is embedded inside HTML, not loaded from an external file) that resembles a Google Tag Manager code snippet (Figure 1). This allows the attacker to disguise the malicious code as a legitimate script by hiding it behind a known vendor. We have previously encountered multiple Magecart campaigns that have employed this evasive technique, making detection more challenging.

Additionally, the skimmer uses Base64 encoding to obfuscate any URLs or keywords that could reveal the malicious code. This further helps conceal the presence of the skimmer.

Figure 1 shows an example of a Google Tag Manager snippet impostor Fig. 1: Google Tag Manager snippet impostor

Using WebSockets and eval function

In this instance, the inline snippet serves only as a loader and not as the actual attack code. The loader includes a condition that triggers the attack only on checkout pages, thereby allowing the skimmer to operate discreetly and load the full malicious code only on targeted, sensitive pages that are relevant to the attack.

Once the Base64 encoding of the loader code is decrypted, the revealed JavaScript code is short and simple, performing just two steps: creating a new WebSocket connection with the attacker's command and control (C2) server, and setting up a listener function that will run the code received from the C2 with the "eval" function (Figure 2).

Figure 2 displays the encoded code that was hidden inside the Google Tag Manager snippet shown in Figure 1. Fig. 2: The encoded code that was hidden inside the Google Tag Manager snippet.

The use of WebSockets and the "eval" function in Magecart attacks is considered an advanced technique as it allows the malicious code to run within the context of the page as a first-party script, making it harder to detect by the researchers, security services, and scanners that may be operating on the targeted website (Figure 3). This method helps the attackers remain covert in their activities and less detectable than traditional XHR requests or HTML tags.

Figure 3 shows another variation of the loader from the same skimmer with the use of WebSockets. Fig. 3: Another variation of the loader from the same skimmer with the use of WebSockets

Carrying out code checks

The initiation of the socket connection allows the browser and the C2 server to exchange data at any moment. The first message sent by the attacker's C2 server to the page (Figure 4) contains JavaScript code that is immediately executed by a listener function specified in the loader code.

The code carries out two checks.

  1. It verifies if a WebSocket connection has been established via a global variable defined in the loader code.
  2. It determines if the page is a checkout page containing a submit button.

If these checks pass, the attacker's code sends a message to the C2 server with the URL of the current page. In response, the C2 server returns the appropriate malicious code tailored to the specific target page.

The fact that the C2 server waits for a page URL before returning the attack code suggests that this campaign operates through a dynamic framework capable of simultaneously running and supporting numerous websites and pages.

Figure 4 is an example of WebSocket connection with the skimmer's C2 server. Fig. 4: WebSocket connection with the skimmer’s C2 server

Obfuscating the code

Figure 5 depicts the actual attack code as it was obtained from the C2 server after validating the URL. The code is heavily obfuscated, making it challenging to determine its underlying logic and the progression of the attack. Magecart skimmers often employ obfuscation techniques to make it difficult for security experts to decipher the attack code and comprehend its entire flow.

Figure 5 shows the obfuscated attack code sent by the C2 server via the WebSocket connection. Fig. 5: The obfuscated attack code sent by the C2 server via the WebSocket connection

Clearing up the code

The use of a deobfuscation tool makes the situation clearer and reveals the intention behind the attack. As shown in Figure 6, the code contains a vast array of keywords designed to identify sensitive fields on the targeted page and establish a counterfeit payment form under the attacker's control. 

The ultimate objective of the attacker is to steal personal information from unsuspecting visitors who interact with the infected page and fill out the fake form injected by the attacker's code.

The first part of Figure 6 shows the attack code after deobfuscation.
The second part of Figure 6 is the attack code after deobfuscation. Fig. 6: Attack code after deobfuscation

Inserting fake forms for third-party providers

Some targeted stores outsource their payment process to a third-party provider. When customers provide personal information, they are redirected to the third-party vendor to enter their credit card information and complete the transaction. The skimmer cannot access the third-party vendor to obtain the end user's credit card information.

Instead, the skimmer creates a fake credit card form on the page before redirecting the customer to the third-party vendor (Figure 7). When the user clicks on the fake "Checkout" or ”Submit Payment” button, the skimmer sends all the collected data to its C2 server and allows the user to continue with the legitimate payment flow by redirecting to the real third-party vendor payment page.

Figure 7 is an example of a fake form created by the skimmer. Fig. 7: Fake form created by the skimmer

If the targeted website does not redirect to a third-party payment page, the skimmer will not create a new form. Instead, it will add JavaScript listeners to all the sensitive personal inputs on the checkout page and payment forms. Once the user submits the information, the skimmer will extract the data and send it to its C2 server using WebSockets messages.

In both cases, the skimmer encrypts the extracted data to make it difficult for researchers and security services to detect any unusual network activity initiated by the skimmer (Figure 8).

 

Figure 8 is an example of the skimmer's encrypted message sent via WebSocket connection. Fig. 8: Example of the skimmer’s encrypted message as sent via WebSocket connection

Attack similarities

During the investigation, we found several websites that were victims of the attack. We cannot confirm that all of them are related to the same campaign, but there were similarities among the cases that suggest the use of the same Magecart framework. In some instances, indicators such as the inline loader of the attack was disguised as a fake Google Tag Manager with encoded parameters that concealed any signs of the skimmer were found on multiple victim websites. 

The domains used by the attacker varied from website to website and, in most cases, the actual attack code was fetched by the loader code on relevant pages only to make the attack more discreet and harder to detect.

Summary of the attackers’ techniques and capabilities

  • Impersonate a known vendor code snippet like Google Tag Manager

  • Use Base64 encoding to hide any indicators of the attacker like URLs and domains

  • Use WebSockets for all the communication between the browser and the C2 — pulling the attack code and exfiltrating the data 

  • Execute the attack code with “eval” to make the script look like an organic first-party script

  • Use obfuscation techniques to make it difficult for researchers to understand the code

  • Inject fake forms to collect data before redirecting to legitimate third-party payment service pages

Gain protection with Akamai Client-Side Protection & Compliance

Our team tested the recent Magecart attack against Client-Side Protection & Compliance and the attack was immediately recognized and mitigated — and detailed information was provided for troubleshooting (Figure 9). 

Client-Side Protection & Compliance is purpose-built to protect against web skimming, formjacking, and Magecart attacks. It provides visibility into the script execution behavior of a web page and collects information about the different scripts running on the page, including their actions and their relationships with other scripts. 

By combining this data with a multilayered detection approach — including heuristics, risk scoring, artificial intelligence, and other factors — Client-Side Protection & Compliance is able to quickly detect and defend against client-side threats.

Figure 9 shows Akamai Client-Side Protection & Compliance's detailed troubleshooting information. Fig. 9: Akamai Client-Side Protection & Compliance's detailed troubleshooting information

Conclusion

Magecart skimmers are constantly evolving and becoming increasingly sophisticated. The use of advanced methods of evasion and obfuscation by the skimmer described in this post highlights the difficulties in detecting these types of attacks. 

The ongoing game of cat and mouse demands a comprehensive security solution to detect and prevent attacks. Failure to implement such a solution can result in serious harm to customers whose privacy may be compromised and cause significant damage to a business's reputation, as well as yield major fines. 

New requirements contained within the latest Payment Card Industry Data Security Standard (PCI DSS v4.0) now make in-browser security an absolute must for any organization that processes payment cards online. 

Find out more

Akamai Client-Side Protection & Compliance can help you meet these new requirements by providing an inventory of all scripts running on your site, visibility into script behavior, and defense against the most sophisticated of script-based attacks.

IOCs

The following indicators of compromise (IOCs) are presented to help the community detect the malicious activity and skimmers described in the blog:

  • yachtbars[.]fun

  • app-stat[.]com

  • Magento-cdn[.]net

  • nebiltech[.]shop

  • Rithdigit[.]cyou

  • Antohub[.]shop

  • Okqtfc1[.]org

  • jquery-node[.]com


Learn more about gaining visibility into script behavior and protection against client-side attacks with Akamai Client-Side Protection & Compliance.



Roman Lvovsky

Written by

Roman Lvovsky

February 15, 2023

Roman Lvovsky

Written by

Roman Lvovsky

Roman Lvovsky is a Security Researcher with extensive experience in client-side threats, browser internals, and JavaScript attack vectors. He is a member of the Akamai Security Intelligence Group and focuses his research on various client-side threats, such as web skimming and Magecart attacks. He has a solid background in software engineering, with a specialization in JavaScript and web development.