The Art of Concealment: A New Magecart Campaign That’s Abusing 404 Pages
Executive summary
The Akamai Security Intelligence Group detected a Magecart web skimming campaign that is targeting an extensive list of websites, including large organizations in the food and retail industries.
This campaign stands out because of its three advanced concealment techniques, one of which we had never seen before — specifically, manipulating the website’s default 404 error page to hide malicious code — that poses unique challenges for detection and mitigation.
The other two obfuscation techniques showcase the evolving tactics that attackers are using to avoid detection and lengthen the attack chain.
As web skimming attacks become increasingly sophisticated, organizations must remain vigilant and explore advanced approaches to protect against these evolving threats.
Introduction
A new, sophisticated, and covert Magecart web skimming campaign has been targeting Magento and WooCommerce websites. Some of the victims of this campaign are associated with large organizations in the food and retail industries.
According to the evidence we’ve uncovered, this campaign has been active for a couple of weeks, and in some cases, even longer. This campaign managed to surprise us with a high-level concealment technique that we had not previously encountered.
The new campaign
Magecart attacks typically begin by exploiting the vulnerabilities in the targeted websites or by infecting the third-party services that these websites are using. In this campaign, all the victim websites we detected were directly exploited, as the malicious code snippet was injected into one of their first-party resources.
In some instances, the malicious code was inserted into the HTML pages; in other cases, it was concealed within one of the first-party scripts that was loaded as part of the website.
Like in many other Magecart campaigns, the attack infrastructure of this campaign consists of three main parts: loader, malicious attack code, and data exfiltration (Figure 1).
Loader — Short, obscure JavaScript code snippets responsible for loading the full malicious code of the attack
Malicious attack code — The primary JavaScript code that executes the attack; it detects sensitive inputs, reads the data, disrupts the checkout process, and injects fake forms
Data exfiltration — The method used to transmit the stolen data to the attacker's command and control (C2) server
Fig. 1: Magecart attack infrastructure
The purpose of separating the attack into three parts is to conceal the attack in a way that makes it more challenging to detect. This allows for the activation of the full flow of the attack only on the specifically targeted pages; that is, because of the obfuscation measures used by the attacker, the activation of the full attack flow can only occur where the attacker intended for it to execute. This makes the attack more discreet and more difficult to detect by security services and external scanning tools that might be in place on the targeted website.
Although most Magecart campaigns share similarities in terms of their flow and stages, what sets one campaign apart from another are the various concealment techniques that attackers employ. These techniques are used to obscure the attack’s infrastructure; conceal traces; complicate detection and reverse engineering; and, ultimately, prolong the attack.
3 variations of the campaign
We found three different variations of this campaign, demonstrating the evolution of the attack and the improvements the attackers made over time to prevent detection and mitigation of this campaign:
The first two variations are quite similar, with only minor differences in the loader part.
The third version is unique because the attackers used the website's default 404 error page to hide their malicious code; this is a creative concealment technique that we hadn't ever seen before.
Let’s take a closer look at the technical details of the three variations of this novel campaign.
Variation one
Our research began when we noticed some suspicious code snippets, detected by our threat intelligence monitoring tools, on a major company's website. Upon analyzing these snippets, we found that they were maliciously encoded JavaScript loaders, which were still present and active on the website. This discovery led us to investigate further, revealing the entire campaign with its variations and impact on numerous websites.
The variation one loader: The tip of the iceberg
The skimmer successfully injected a malformed HTML image tag with an onerror attribute into the exploited website (Figure 2). This attribute contains an obfuscated Base64-encoded malicious loader code snippet. The intentionally empty src attribute of the image tag is designed to prevent network requests and trigger the execution of an inline onerror callback containing the obfuscated malicious JavaScript code snippet.
Using image tags for the purpose of executing JavaScript code is a less common and more sophisticated technique. It can help the skimmer bypass security measures such as external scanners that typically analyze network traffic, which are not triggered in this specific case. The obfuscated code will execute within the context of the page and run as if it were a native first-party script initiated by the page itself.
Fig. 2: Variation one loader — an improperly formatted HTML image tag with an onerror attribute containing malicious loader code
Decoded loader code — Runtime
Once the obfuscated Base64-encoded code is executed at runtime, it transforms into plain JavaScript and becomes responsible for initiating a WebSocket channel (Figure 3). This channel serves as a bidirectional communication link between the browser and the attacker's C2 server.
The use of WebSockets in Magecart attacks has been observed in several recent campaigns. WebSocket is considered to be a quieter and more flexible method of communication, allowing the attacker to utilize a single network channel for various purposes. This includes sending different parts of the attack from the C2 server to the browser (and vice versa), as well as facilitating data exfiltration activities in certain scenarios.
Another noteworthy aspect of the code is bot detection, which checks if the user agent is under automation control. If this is the case, the code terminates its execution. This is a clever anti-bot technique aimed at evading external security scanners and sandboxes that could potentially detect the attack.
Fig. 3: The runtime-decoded JavaScript code of the variation one loader
Websocket communication flow
Once the WebSocket channel is established, the first message is sent from the attacker's C2 server to the browser. This message is transmitted as a Base64-encoded string, containing a one-line JavaScript command that instructs the browser to send back the current URL of the page.
The purpose of this step is to enable the C2 server to determine whether the current page is a checkout (sensitive) page or any other noncheckout page. This way, the attacker can adjust the next steps accordingly.
This straightforward server-side validation enables the attacker to activate the attack only on the relevant targeted pages, thereby avoiding potential exposure on nonsensitive pages. This is yet another example that highlights the efforts the skimmer takes to evade detection by security services and external scanners.
When the C2 server identifies a checkout page URL, the flow proceeds to the next stage. In this step, another message is sent to the browser. It is a long Base64-encoded string, which contains the entire attack code. Once decoded, a lengthy and obfuscated JavaScript code is revealed (Figure 4).
This code is responsible for carrying out various malicious activities on the targeted sensitive page, with the goals of reading the user's sensitive personal and credit card data and transmitting it back to the skimmer's C2 server.
Subsequent obfuscated data exfiltration messages containing the sensitive stolen data gathered by the malicious code are sent from the browser to the C2 server. As mentioned earlier, using the same WebSocket channel for both loading the full malicious code and exfiltrating stolen data makes the process quieter and involves fewer network requests than more traditional communication methods like XHR, fetch, or HTML resource requests.
Fig. 4: WebSocket flow on checkout pages
Variation two
The variation two loader: Same lady, new dress
The main difference between variation one and variation two is in the loader component. In variation two, the skimmer inserts an inline script with a code snippet that closely resembles the Meta Pixel code snippet, a well-known Facebook visitor activity tracking service, with a few additional lines inside it (Figure 5).
These added lines are the actual loader part, while the Meta Pixel code surrounding is a misleading cover to make it appear as if it’s a legitimate and unsuspicious code snippet.
This concealment technique, which makes the malicious code snippets appear to be well-known services like Google Tag Manager or Facebook, has gained popularity in recent Magecart campaigns. It allows skimmers to evade static analysis by external scanners and researchers.
Fig. 5: Variation two loader — inline script disguised as Meta PIxel code snippet with a malicious loader inside it
Request for an image
When we carefully inspected the suspicious lines within the fake Meta Pixel code snippet, it seemed to fetch a PNG image from the website's own directory. The network request appeared to be a typical request for an innocent image hosted on the website. However, when we examined the actual content of this image, it became clear that it was not as innocuous as it seemed (Figure 6).
Fig. 6: Network image request for an image that has been tampered with by the attacker and contains malicious code
Malicious JavaScript code snippet within an image binary
The binary data of the PNG image contains a Base64-encoded string appended to the end of the image binary file (Figure 7). This string is then extracted, decoded, and executed by the loader code snippet (Figure 8). The decoded string represents a JavaScript code snippet that is identical to the one found inside the onerror attribute of the loader in variation one.
The subsequent steps of the flow remain unchanged. This code snippet transforms into plain JavaScript code at runtime, the code initiates the WebSocket channel to the attacker's C2 server, and the rest of the sequence follows as previously described.
Fig. 7: The binary data of the image that contains the concealed malicious code
Fig. 8: The malicious code, which was initially encoded in Base64 and concealed within the image, becomes apparent after decoding
Variation three
Now, let's talk about the best part. Although we've seen similar attacks, this one is unique and really surprised us.
The variation three loader: Same, same, but totally different
At first glance, this loader appears similar to the loader in variation two, but you'll see (as we did) that it's an entirely different scenario. In some instances, this loader is disguised as Meta Pixel code snippet, as seen in variation two (Figure 9). But in other cases, it is injected within random inline scripts on the page (Figure 10).
The first notable aspect of this loader is a fetch request to a relative path called 'icons'.
Fig. 9: Variation three loader — a malicious code snippet concealed within a code snippet that mimics the appearance of Meta Pixel
Fig. 10: Variation three loader —- a malicious code snippet concealed within an arbitrary inline script
A 404 error? Really?
After the loader is executed, the attack sends a fetch request to /icons, which is a relative path that doesn't actually exist. This request led to a "404 Not Found" error (Figure 11). Upon analysis of the HTML returned in the response, it seemed like the default 404 page of the website (Figure 12). This was confusing and made us wonder if the skimmer was no longer active on the victim websites we found.
Fig. 11: Request initiated by the loader to a nonexistent path that returns 404 error
Fig. 12: Default error page HTML
Never underestimate the loader
We took a step back and reanalyzed the loader, and we found the missing piece of the puzzle. The loader contained a regex match for the string "COOKIE_ANNOT", which was supposed to be performed on the 404 error page returned as part of the icons request.
So, we searched for this string within the returned 404 HTML, and voilà! We discovered a comment hidden toward the end of the page that contained the "COOKIE_ANNOT" string (Figure 14). Next to this string, a long Base64-encoded string was concatenated. This encoded string represents the entire obfuscated JavaScript attack code. The loader extracts this string from the comment, decodes it, and executes the attack, which is designed to steal the personal information entered by users.
We simulated additional requests to nonexistent paths, and all of them returned the same 404 error page containing the comment with the encoded malicious code. These checks confirm that the attacker successfully altered the default error page for the entire website and concealed the malicious code within it!
Fig. 13: Loader variation 3 - regex match for the string "COOKIE_ANNOT".
Fig. 14: The malicious encoded comment that was hidden within the error page HTML
Data exfiltration
Fake form
In contrast to variations one and two, the attackers employed a different common data exfiltration technique in variation three — injection of fake form (Figure 15). This technique is typically utilized when the skimmer lacks access to sensitive inputs.
This can occur when a website uses a third-party payment service that implements the payment form within a third-party iframe or an external page. To bypass such scenarios, the attacker creates a fake form that closely resembles the original payment form and overlays it — a technique that is gaining more popularity. This is exactly how stolen data is exfiltrated in variation three.
Fig. 15: The fake form injected by the malicious code
When the user submits data into the attacker's fake form, an error is presented, the fake form is hidden, the original payment form is displayed, and the user is prompted to re-enter their payment details (Figure 16).
Fig. 16: The fake form is hidden and the user is prompted to re-enter their information
Image request with stolen data
Submitting the fake form initiates an image network request to the attacker's C2 server, carrying all the stolen personal and credit card information as a Base64-encoded string in the query parameter (Figure 17). When decoded, this string reveals the true intent of the request and the entire flow of the attack becomes clear.
Fig. 17: Image network request with the stolen data included as a Base64-encoded string query parameter
Lessons learned from variation three: The 404 case
This concealment technique is highly innovative and something we haven't seen in previous Magecart campaigns. The idea of manipulating the default 404 error page of a targeted website can offer Magecart actors various creative options for improved hiding and evasion.
In some of the cases we've identified, the malicious loader had already been removed from the affected websites' pages at the time of writing. However, the malicious comment in the default 404 page remained, potentially allowing the skimmer to easily reactivate the attack. This highlights the complexity of detecting, and the importance of mitigating, this approach.
The request to the first-party path leading to the 404 page is another evasion technique that can bypass Content Security Policy headers and other security measures that may be actively analyzing network requests on the page. This undoubtedly ranks as one of the more sophisticated Magecart strategies we've encountered recently.
Akamai Client-Side Protection & Compliance versus the skimmer
As part of our research into this campaign, we conducted a simulation of this skimmer against Akamai Client-Side Protection & Compliance, our solution that analyzes runtime JavaScript execution behavior to defend against JavaScript threats and mitigate client-side attacks.
The solution successfully detected the sophisticated skimmer and triggered a high-severity event for immediate mitigation. In a real-world scenario in which Client-Side Protection & Compliance is enabled on a particular web page, Figure 18 illustrates the alert the website owner would receive so they could rapidly investigate the threat and respond in real time with various mitigation options.
Fig. 18: Client-Side Protection & Compliance simulation alert after detecting the skimmer
Conclusion
This campaign reinforces the fact that web skimming techniques are constantly evolving. They are becoming more sophisticated, which makes detection and mitigation by static analysis and external scanning increasingly challenging. Threat actors in this domain consistently find better methods with which to conceal their attacks within victim websites and evade various security measures that could expose them.
The level of complexity highlighted in this research should remind organizations to remain vigilant and attentive to web skimming attack vectors and actively seek new and advanced approaches to deal with these types of attacks.
IOCs
Pmdresearch[.]com
secures-tool[.]com
adsometric[.]com
cngresearch[.]com
