Akamai Researchers Uncover Fresh Magecart Campaign Exploiting 404 Pages.

The Research Intelligence group at Akamai discovered a new concealment trick used by threat Actors in A Magecart campaign that abuses 404 pages.

Roman Lvovsky in an article Published on the 9th October, 2023 stated that:

“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.”

Akamai revealed that a diverse array of websites, including those within the food and retail sectors, have become focal points for the Magecart web skimming campaign. What sets this discovery apart are the three remarkably sophisticated concealment techniques employed, previously unseen in the field. These techniques entail the artful manipulation of a website’s 404 error page, serving as a clandestine refuge for malicious code. This innovation introduces distinctive hurdles in terms of detection and counteraction.

Furthermore, the emergence of two prominent obfuscation techniques signifies the evolving strategies embraced by threat actors to navigate the landscape of detection and maintain their persistence.


In the recent rise of web scheming techniques, organizations are required to take the cybersecurity more seriously, while exploring numerous advanced techniques to protect itself from evolving threats.

Roman Lvovsky stated that:

“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 Magecart exploitation enables Threat actors, embark on their nefarious journey by skillfully leveraging existing vulnerabilities present in their chosen web targets. In addition to this, they employ tactics akin to infiltrating the third-party services seamlessly integrated with these websites.


Research findings by cybersecurity experts at Akamai disclosed that:

“All the victim websites we detected were directly exploited, as the malicious code snippet was injected into one of their first-party resources.”


In specific situations, threat actors executed the injection of malicious code directly into the HTML pages, while in other instances, these codes were surreptitiously obfuscated within one of the first-party scripts, seamlessly integrated as a component of the website’s functionality.



Mirroring typical Magecart campaigns, the attack framework of this operation comprises three primary components (See Figure-1 Below). These are:

  • The Loader
  • Malicious attack code.
  • Data exfiltration.


                                                                               Figure-1: Magecart Attack Framework. Image-source: Akamai



  • The Loader:

Consists of short obscure JavaScript codes, that executes and is responsible for loading the actual malicious code of the attack.

  • The Malicious Attack Code:

This is the actual JavaScript code which executes the attack, and it also detects sensitive inputs, read the data, disrupts checkout process, and inject fake forms.

  • The Data exfiltration:

This is the threat actor method of transmitting stolen information to the C2 (Command-and-Control) server, belonging to them.


Roman further elaborated that:

“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.”

Roman also described that the discovery from the campaign, reveals three variations of the attack. This indicates that the attack has evolved, and threat actors have employed more techniques to invade detection, and disrupt cybersecurity experts mitigative steps.


The first two variations are said to be of similar fashion, with only minor differences which exist in the loader. However, the third version which is unique; enables threat actors to utilize the default 404 error page to hide the malicious code, a technique never seen before.


Variation One Loader:

In an analysis of the variation one, Akamai discovered that the threat actor injected a malicious HTML image tag with an onerror attribute into the website exploited. The strategic brilliance unfolded further, as the ‘src’ (See Figure-2 Below) attribute of this image tag was intentionally left void. This calculated move served a dual purpose: thwarting any immediate network requests and, ingeniously, sidestepping a trigger for an inline ‘onerror’ callback. Concealed within this callback, the meticulously engineered JavaScript code awaited its moment to stealthily execute its ominous designs.

This method of utilizing image tags for the sole purpose of executing the JavaScript code is one that is not popular, which makes it a more sophisticated approach. Threat actors using this technique, are able to bypass security measures such as network scanners that analyze network traffic (which are not triggered in this scenario). A deadly approach comprises of the obfuscated code executing within the context of the page and masquerading as a native third-party script seamlessly initiated by the webpage.


Variation One Loader-Figure-02.png
Figure-2: Variation One Loader – Formatted HTML image tag with onerror attribute holding the malicious code of the Loader. Image-source: Akamai




The decoded runtime, shows that after the hidden Base64-encoded code runs, it turns into regular JavaScript and sets up a secure line of communication called a WebSocket channel (See Figure-3 Below). This establishes a bidirectional communication between the web browser and the attacker’s command-n-control (C2) server.

Magecart attackers have lately been using WebSockets, which are a stealthier and more versatile way to communicate. It allows attackers to use one network channel for many tasks, like sending parts of their attack between the server and the browser and even sneaking out stolen data in some situations.

The code also has a smart trick called bot detection. The bot detection, checks if the user’s browser is being controlled by automation, if it is, the code stops running. This is a tactic to dodge security systems that could spot the attack.


                        Figure-3: The decoded runtime consisting of the JavaScript code found in the Variation one loader. Image-source: Akamai




Communication flow in the WebSocket is initiated. Once the WebSocket connection is up, the attacker’s control server sends the first message to the browser. This message, encoded in Base64, contains a one-line JavaScript command telling the browser to report the current page’s URL.

This step helps the attacker decide whether the current page is a sensitive checkout page or something else. This way, the attacker can adapt their next moves accordingly.

The smart server-side check lets the attacker launch the attack only on the right targeted pages, reducing the risk of exposure on non-sensitive pages. It’s another example of how the skimmer takes steps to stay hidden from security services and scanners. When the C2 server confirms a checkout page, the process moves to the next stage. Here, another message is sent to the browser. It’s a lengthy Base64-encoded string containing the entire attack code. Once decoded, it reveals a long and tricky JavaScript code, (See Figure-4 Below).

Also, the code is in charge of carrying out harmful actions on the sensitive targeted page. Its goals are to pilfer the user’s sensitive personal and credit card information and send it back to the skimmer’s control server (C2-Server).

Afterward, more encoded messages carrying the stolen data are sent from the browser to the C2 server. Using the same WebSocket channel for both loading the malicious code and siphoning off the stolen data keeps the process discreet and requires fewer network requests compared to conventional methods like XHR, fetch, or HTML resource requests.”


                                                        Figure-4: Reveals WebSocket Communication Flow found in the checkout pages.



THE VARIATION TWO LOADER A Familiar Face in Fresh Attire:

Variation Two distinguishes itself from Variation One through its loader component. In this instance, the skimmer includes an inline script that cleverly mirrors the Meta Pixel code, a Facebook visitor tracking service. However, hidden within this guise are additional lines that actually function as the loader (See Figure-5 Below).

This technique of camouflaging malicious code to resemble trusted services, such as Google Tag Manager or Facebook, has become increasingly prevalent in recent Magecart campaigns. It serves as a tactic to evade detection through static analysis by external scanners and researchers.”


THE VARIATION TWO LOADER A Familiar Face in Fresh Attire - Figure 5.png
 Figure-5: The Variation 2 shows a malicious crafted inline script mimicking the meta-pixel code discovered in the loader. Image-source: Akamai


An Image Request is Made:

A closer inspection of the suspicious lines in the counterfeit Meta Pixel code, it appeared to be fetching a PNG image from the website’s directory.

The network request resembled a routine request for an innocent website image. But upon inspecting the image’s actual content, it became evident that it harbored hidden dangers (See Figure-6 Below).


An Image Request is Made-Figure-06.png
                                               Figure-6: Depicts a Network Image request, which has been altered by a threat actor. Image-source: Akamai.



A Malicious JavaScript code Hidden within an Image Binary:

The PNG image holds a hidden Base64-encoded string in its binary data, as shown (See Figure-7 Below). This string is later extracted, decoded, and run by the loader code snippet (See Figure-8 Below). The decoded string essentially contains JavaScript code that matches what was inside the ‘onerror’ attribute of the loader in Variation One.

Further analysis, indicates the process runs in a consistent manner. This code, once triggered, turns into regular JavaScript during runtime. It then sets up the WebSocket connection to the attacker’s control server (C2-Server), and the remaining steps unfold as described earlier.


                                         Figure-7: The Binary data concealing the malicious code. Image-Source: Akamai


A Malicious JavaScript code Hidden within an Image Binary-01.png
                                             Figure-8: The Decoded Binary Data revealing base64 content hidden in the Image. Image-Source: Akamai



The Variation Three Same Trickster, Different trick:

At a quick glance, this loader may resemble the one from Variation Two, but a closer look reveals a different story. In some cases, it pretends to be the Meta Pixel code snippet, just like in Variation Two (See Figure-9 Below). However, in other instances, it sneaks into random inline scripts on the page (See Figure-10 Below).

A key feature of this loader is issuing a fetch request, to a relative path named ‘icons’.


                                               Figure-9: Variation three A code-within-A-Code (Malicious Code) Mimicking Meta Pixel. Image-source: Akamai


                                                                Figure-10:  Variation three loader. Malicious code hidden inline within an arbitrary script



Following the loader’s execution, the attack initiates a fetch request to the non-existent /icons path, resulting in a “404 Not Found” error (See Figure-11 Below). Upon examining the HTML in the response, it appeared to be the default 404 page of the website (See Figure-12 Below). This is puzzling and raises questions about whether the skimmer had become inactive on the websites we investigated.


                                                                     Figure-11: Loader Making a request to a non-existent path. Image-Source: Akamai


                                                                        Figure-12: The Default error page HTML code snippet. Image-Source: Akamai



Don’t overlook the Loader’s significance:

A Detailed analysis of the loader, uncovered a crucial element. It turns out, the loader scans for the ‘COOKIE_ANNOT’ string within the 404-error page linked to the icons request.

Upon scouring the returned 404 HTML, hidden at the page’s tail; A discovery in a comment housing the ‘COOKIE_ANNOT’ string (See Figure-13 Below).


                                                             Figure-13: Variation 3 Loader ‘COOKIE_ANNOT’ regrex match. Image-Source: Akamai


Adjacent to it, a lengthy Base64-encoded string was appended. This encoded string holds the entire concealed JavaScript attack code. The loader retrieves, decodes, and executes this code, with a purpose to pilfer users’ personal data. (See Figure-14 Below)


Don't overlook the Loader's significance-01.png
                        Figure-14: Depicts the Malicious encoded comment that was hidden within the error page HTML. Image-Source: Akamai


Akamai Stated that:

“These checks confirm that the attacker successfully altered the default error page for the entire website and concealed the malicious code within it!”


Exfiltrating Victim’s Data:

Unlike variations one and two, variation three brings a fresh approach to exfiltrating victim’s data. In this case, the attacker’s resort to injecting a deceptive form (See Figure-15 Below). This tactic is often deployed when the skimmer can’t directly access sensitive inputs.


                                                                               Figure-15: The Fake form injected by the malicious code.


This situation arises when a website relies on a third-party payment service, utilizing a payment form embedded in an external iframe or page. To navigate these obstacles, the attacker fabricates a counterfeit form mirroring the genuine payment form and superimposes it – a method that’s gaining traction. This is the precise mechanism for siphoning off stolen data in variation three.

After users input their data into the attacker’s sham form, they encounter an error. The phony form vanishes, the authentic payment form reemerges, and users are instructed to re-enter their payment information (See Figure-16 Below)


Figure-16: The hidden fake form prompting users to re-enter their data. Image-Source: Akamai



Image Request Containing Personal and Credit Card Data:

Once the forged form is submitted, it triggers an image network request to the attacker’s C2 server. Within the query parameter, it conceals all pilfered personal and credit card data, cleverly encoded in Base64 (See Figure-17 Below). Upon decoding this string, the request’s true purpose unfolds, shedding light on the entire attack sequence.


             Figure-17: Image Network request revealing Personal data stolen, containing the base64 encoded strings. Image-source: Akamai


Key Takeaways from Variation Three-The 404 Scenario:

The key takeaways from the variation, is that the concealment method represents a remarkable innovation previously unseen in Magecart campaigns. The manipulation of a targeted website’s default 404 error page introduces novel opportunities for Magecart actors, enhancing their ability to hide and evade detection creatively.

In certain scenarios, it shows that, while the malicious loader had been eradicated from the affected websites, the malevolent comment within the default 404 page endured. This potential reactivation avenue underscores the intricacies of detection and underscores the significance of mitigation efforts.

The tactic of directing requests to the first-party path linked to the 404 page serves as an evasion method capable of circumventing Content Security Policy headers and other active network request scrutiny measures on the page. Undeniably, this stands as one of the more sophisticated strategies adopted by Magecart actors in recent times.”


Indicator Of Compromise (IOCs):

The indicator of compromise listed by Akamai, shows the following websites url are a tell sign, that the targeted users have been a victim of the Magecart attack

– Pmdresearch[.]com

– secures-tool[.]com

– adsometric[.]com

– cngresearch[.]com


Akamai Client Side Protection & Compliance VS Magecart Threat Actors:

The research on the campaign, of the skimmer against Akamai Client-Side Protection & Compliance, reveals Akamai tool are able safeguarding against JavaScript threats and client-side attacks. Akamai solution swiftly detected the advanced skimmer, signaling a high-severity event for instant action. In a live scenario with Client-Side Protection & Compliance active on a webpage, (See Image Below) portrays the security alert that website owners would receive, enabling them to promptly address the threat with real-time mitigation choices.


Akamai Client Side Protection & Compliance VS Magecart Threat Actors.png
                         Figure-18: Akamai Client-Side Protection & Compliance simulation alert on detecting the threat actors server communication.




This campaign, and discovery underscores the continual evolution and increasing sophistication of web skimming techniques, posing challenges for static analysis and external scanning. Threat actors adeptly conceal their attacks in victim websites and elude detection. Organizations must stay vigilant, actively seeking advanced methods to counter these evolving web skimming attacks.”




Put your comments below in the comment section on your thoughts about this.

Find this article and information helpful? Show some love and support  “Click-Here”
5 1 vote
Article Rating
Notify of
Inline Feedbacks
View all comments