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 secure.newegg.com 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 https://secure.newegg.com/GlobalShopping/CheckoutStep2.aspx URL https://secure.newegg.com/GlobalShopping/CheckoutStep2.aspx, would collect form data, siphoning it back to the attackers over SSL/TLS via the domain neweggstats.com " (source : https://www.volexity.com/blog/2018/09/19/magecart-strikes-again-newegg/).

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 neweggstats.com 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 : (https://www.volexity.com/blog/2018/09/19/magecart-strikes-again-newegg/

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?

1 Answer 1


I doubt we'll get to know the exact details of how they were able to put the malicious JavaScript on newegg.com. For that to happen, newegg.com 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 neweggstats.com domain

This implies that the forensics team at Volexity were not able to determine when the attack began using data found on newegg.com'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 neweggstats.com.

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 newegg.com 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).

  • This is a fantastic answer. Here is a somewhat naive question, if the authors of the javascript related to the compromised "Check-Out Page" regularly monitored the diffs of modifications using Version Control software, would that be a practical method of stopping un-waranted modifications? Commented Sep 26, 2018 at 23:03
  • Unfortunately it's more complicated than that. If the "Unsecured Image Uploads" method was a factor, those images would not be in a Version Control system. Commented Sep 26, 2018 at 23:04
  • Maybe the attacker first gained access to their servers, then installed malware to modify the HTTP responses at the network level. This could leave no trace of compromise within the ecommerce software itself. Commented Sep 26, 2018 at 23:12
  • 1
    Great answer, but you forgot "compromised a third party already loading Javascript into the cart," such as the recent Ticketmaster compromise. Attackers are finding it easier to take advantage of third parties with less stringent security than the actual target.
    – gowenfawr
    Commented Sep 26, 2018 at 23:22
  • Nope, didn't forget that one... it's covered under "There are virtually unlimited possibilities of how this may have happened." :) Commented Sep 27, 2018 at 0:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .