MageCart attack on Newegg

Information Security Asked by IntegrateThis on February 8, 2021

I am reading about an attack that occurred during August of this year conducted by the group MageCart through the use of “card skimming” to steal credit card info from Newegg users. While reading about it using the sources listed below, it seems that MageCart hackers were able to insert malicious javascript code inserted during the Checkout step. A window.onload() function implementation would take credit card information and send it to a server associated with the group:

“Volexity was able to verify the presence of malicious JavaScript code limited to a page on presented during the checkout process at Newegg. The malicious code specifically appeared once when moving to the Billing Information page while checking out. This page, located at the URL URL, would collect form data, siphoning it back to the attackers over SSL/TLS via the domain ” (source :

But my question is, how did they go about putting the malicious code there in the first place?

From another source : “Volexity believes that the Newegg website may have been compromised and actively facilitating financial theft for over a month. A key date in the Magecart attacks against Newegg come from the registration data of the domain. The domain was registered on August 13, 2018 at approximately 16:36 UTC via Namecheap. This indicates the attackers had likely already compromised the Newegg website and were preparing to launch attacks. WHOIS information form the domain shows it was registered with privacy protection” Source : (

What does “compromised the Newegg website” mean? Does this mean they had access to the php files on the server that stored the Newegg code and that they manually added their javascript snippet?

One Answer

I doubt we'll get to know the exact details of how they were able to put the malicious JavaScript on For that to happen, would likely need to provide the public with undisclosed information about their private infrastructure.

Speaking in general terms, the answer is that... something was insecure on their server or within their software. There are virtually unlimited possibilities of how this may have happened.

The following detail is interesting:

A key date in the Magecart attacks against Newegg come from the registration data of the domain

This implies that the forensics team at Volexity were not able to determine when the attack began using data found on's server. For instance, files that had been touched may have had their timestamps reverted to their pre-modified dates. Their estimate of when the compromise began is based on a domain registration date... but maybe the attacker had been using a less convincing domain for a long time before deciding to switch to

A few common possibilities are below.

SQL Injection

An attacker may be able to discover enough about your database schema to learn that the contents of a given table/column are inserted into every page without sanitization. The attacker may then discover an SQL Injection point and be able to INSERT a script tag into the given table/column. The software would then happily include the attacker's malicious JavaScript on the page.

Phishing for admin credentials

The administrative portion of the website may openly allow script tags to be included in the site's layout in some way. This could include general template editing (ability to make changes to the website's HTML using an editor) or it could be something like an admin tool that allows you to upload payment images for the checkout pages (technically, this is the same as the first example).

The software might even allow an admin to simply upload a JavaScript file that would automatically be included on the website.

Providing value

Any third party JavaScript that you include on your website has the ability to be malicious. One could simply advertise a service for advanced ecommerce analytics to get their malicious code included on your site. Then the site owner would do the hard work for you.

Unsecured image uploads

Images can contain executable code. Some sites allow users to upload photos with their product reviews. If allowed this, but did not sanitize the images, then an attacker would be able to get their executable code on the server easily. Once on the server, the attacker would need to cause the server to "run" the image as code. This can be done if your server is misconfigured or if your software has a security hole that would allow the image to be included as code. The malicious executable would then run with the same permissions as the webserver (or worse). At that time the software could append code to an already included JavaScript file on the server.


Writing software and making it secure are very different tasks. Sometimes a company puts emphasis on adding features because the folks that run the company are primarily interested in their profits. The idea that labor should be invested in securing their software never even crosses their minds until after a breach has taken place.

Often the employees who might be responsible for securing their software are inexperienced, underpaid, overworked, or inherit insecure systems from previous employees. When no one has the job of securing your server / software, vulnerabilities find their way in.

The method(s) an attacker may use to compromise a site is usually multi-faceted and may not be completely understood even after the compromise is discovered. Hiring a forensics company can be helpful, but their abilities may be limited due to the server's configuration (for instance, logs may only be stored for a short period of time).

Answered by Aaron Cicali on February 8, 2021

Add your own answers!

Ask a Question

Get help from others!

© 2024 All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP