Magecart Campaign Hijacks 404 Pages to Steal Data

The collection of cybercriminal groups behind the infamous Magecart payment-card theft campaigns have come up with a previously unseen technique to hide their credit card skimming code, escaping notice for several weeks and infecting major e-commerce sites, including significant brands in the food and retail industries.

The obfuscation technique hides JavaScript code in a comment in a targeted site’s 404 default page, Akamai stated in an advisory on Oct. 9. Other pages on the site have been modified only slightly to include a call to a nonexistent folder (“icons”), which triggers the 404 error, thus fetching the malicious page.

The entire attack code is contained in a comment with a specific placeholder, so the attacker’s script can retrieve it, Roman Lvovsky, a security researcher at Akamai, explained in the company’s advisory.

“This concealment technique is highly innovative and something we haven’t seen in previous Magecart campaigns,” he said. “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.”

Hiding in 404 Pages: A Tactics Evolution

Magecart attacks are a category of post-exploitation techniques for skimming credit card information and other user data from websites using obfuscated JavaScript, hijacking of forms, and malicious redirects. The embedded code often escapes notice by hiding in the complexity of modern websites, which rely heavily on third-party components, open source Web frameworks, and code obfuscated to protect intellectual property. Cybercriminals groups can hide their malicious content by either inserting it among the other obfuscated code or by compromising a third-party source of code or content.

Over the summer, for example, a Chinese-speaking threat group compromised Web-facing applications to skim credit card numbers in the Asia-Pacific region, and more recently, North American and Latin America, in a campaign dubbed “Silent Skimmer.”

The payload hides the original credit-card form, overlaying it with a fake one. Source: Akamai

Similar to techniques hiding code in CSS files and images, adding code to the comments of a default 404 page escapes notice because many of the scanners used to detect attacks today were not designed to search such pages, says Ben Baryo, a cybersecurity researcher with Human Security, a bot- and fraud-protection service.

“While most scanners might report a missing resource, it’s likely that a 404 response won’t be analyzed,” he says. “This detection evasion technique is mostly useful against synthetic scanners — which tend to ignore content in requests that aren’t returning 200 OK HTTP code — and manual inspections.”

Magecart Code Obfuscation & Overlays

The modification to the default 404 pages are part of the Magecart campaign’s efforts to deliver a payload — typically, the display of a fake form to collect credit card details — and maintain persistence. The cybercriminals used a fake form overlaying an original page’s credit card information form to grab financial details from the targeted user, according to Akamai’s advisory.

“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,” Akamai’s Lvovsky said, adding: “Submitting the fake form initiates an image network request to the attacker’s C2 [command-and-control] server, carrying all the stolen personal and credit card information as a Base64-encoded string in the query parameter.”

A 404 page is typically a first-party object — meaning that it resides on the same server as the home page and not a third-party service. This helps the attacker bypass some security measures, such as Content Security Policy (CSP) headers, he said.

Yet while the technique results in hard-to-discover modifications, it is not necessarily stealthy, says Human Security’s Baryo. Because the 404 attack is kicked off by a call to the nonexistent “icons” resource, the technique could be considered noisy, which Magecart groups attempt to avoid.

“We haven’t seen this particular technique in the wild,” he says. “We do not generally see other groups following this approach as this delivery method attracts unwanted attention as to why a nonexistent resource is being loaded on a particular page and by which script.”

Could PCI DSS Solve Magecart?

The Payment Card Industry (PCI) Security Standards Council has attempted to solve the problem of Magecart attacks with the latest version of its Data Security Standard (DSS), which bolsters two security requirements to protect payment pages. Requirement 6 (“Develop and Maintain Secure Systems and Software”) directs e-commerce sites to use secure development and maintenance to ensure that unauthorized code can’t be injected into websites, while Requirement 11 (“Test Security of Systems and Networks Regularly”) charges website owners to conduct ongoing monitoring of systems and networks to detect changes.

Online merchants — even ones that outsource all storage, processing, and transmission of account data to payment service providers — will have to abide by the PCI-DSS 4.0 requirements, says Jeff Zitomer, senior director of product management for Human Security.

“Modern websites … source code at runtime from across the Internet to deliver critical business functionality,” he says. “This forever-changing Nth-party code bypasses traditional security controls and enjoys nearly unlimited access in the browser, [allowing] attackers [to] exploit this attack surface through malicious script attacks.”

The standard is currently considered a best practice but will become mandatory in early 2025.