Magecart Attack Disguised as Google Tag Manager
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.
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).
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.
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.
- It verifies if a WebSocket connection has been established via a global variable defined in the loader code.
- 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.
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.
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.
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.
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).
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.
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.