Between 14 August and 18 September 2018, the billing page at secure.newegg.com carried a payment skimmer. It ran for roughly 35 days, and it was found by two external research firms — RiskIQ and Volexity — rather than by Newegg.
The attack has been attributed to Magecart Group 6, the same group behind the attacks on British Airways and Ticketmaster. What makes this one worth reading alongside those is that the code had been refined in between.
Eight lines of code
Volexity's analysis compared the payload directly with the one used against British Airways. It had been cut down to a fraction of the size, and it did the same job.
The attackers have managed to minimize the size of the script even more, from 22 lines of code in the British Airways attack to a mere 8 lines for Newegg, 15 if the code is beautified.
- Volexity, September 2018
The mechanics are worth understanding because there is nothing clever about them. The script bound itself to the checkout button and listened for both mouseup and touchend — deliberately covering desktop and mobile, so no customer was missed. On either event it serialised every field on the payment form, converted it to JSON, and posted it to a server the attackers controlled.
That is the whole attack. No exploit chain on the page, no obfuscation worth the name. Eight lines that ran on a checkout for five weeks.
The padlock stayed green throughout
The exfiltration domain, neweggstats.com, was registered on 13 August 2018 — the day before the skimmer went live. On the same day the attackers obtained a TLS certificate for it, so the stolen card data left the browser over a properly encrypted connection to a host with a valid certificate.
It is worth being blunt about what that means. Every automated check of the transport was satisfied. The connection was encrypted, the certificate was valid, and the browser showed nothing unusual. Encrypted says nothing about authorised. The question that mattered was not whether the connection was secure, but whether that destination had any business receiving a customer's card details — and nothing on the page was asking it.
A destination that had never been seen before
This is the point at which the attack was detectable from the first day rather than the thirty-fifth. A checkout page that had never sent data to neweggstats.com started sending data to neweggstats.com. Nothing else about the page changed in a way a person would notice.
That is exactly the signal Data Watch exists to raise: not "is this connection encrypted", but "is this a destination this page has ever used before". A new host receiving form data from a payment page is a small number of alerts, and it is the alert that matters.
This is also the class of attack a Content Security Policy stops outright. A connect-src directive scoped to the hosts a checkout legitimately talks to would have refused the request, and the skimmer would have collected nothing for five weeks while telling us it was there.
How we can help
You don't need a mature Content Security Policy to benefit from our tooling. To use Script Watch or Data Watch, you can start auditing the JavaScript running on your pages, and the destinations receiving data from them, with a single line of code or config.
Once that is deployed we establish a baseline for your site, and then alert you to anything that changes. The most damaging feature of a Magecart attack is rarely its sophistication — it is how long it runs before anybody notices. Reach out to sales@report-uri.com if you would like a demo or a trial with no commitment.
