On 20 March 2020, Claire's closed all of its roughly 3,000 physical stores worldwide as COVID lockdowns took hold. The following day, somebody anonymously registered claires-assets.com.
They had correctly worked out that everything was about to move online. The skimmer went live on the checkout between 25 and 30 April and was removed on 13 June — six to seven weeks of live card skimming. The sister brand Icing was hit with the same malware. It was found by security firm Sansec, who notified Claire's.
A day after Claire's closed its 3,000 stores, an anonymous party registered claires-assets.com. Later, Claire's got hacked.
- Sansec, June 2020
This was not a supply chain attack
The malicious code was appended to app.min.js — a legitimate, first-party file, hosted on Claire's own servers. The attackers had write access to the store's own code.
The malware was added to the (otherwise legitimate) app.min.js file. This file is hosted on the store servers, so there is no “Supply Chain Attack” involved.
- Sansec, June 2020
That matters more than it might sound, because it defeats the most common way people think about this risk. An audit of third-party vendors would have found nothing: there was no hostile third party. A Content Security Policy that constrains where scripts may load from would have permitted this file without hesitation, because it came from exactly where it was supposed to come from.
What still gives the attack away is not the source of the script but the destination of the data. claires-assets.com had never received anything from that checkout before. Scoping connect-src and img-src to the hosts a checkout genuinely needs would have blocked it, and Data Watch would have reported the new destination the first time it was used.
The stolen data left disguised as an image
The exfiltration is the best teaching moment on this page. The skimmer hooked the checkout form's submit button, serialised the entire form — card details, name, address, contact details — base64-encoded it, and appended it as query parameters on a request for an .svg image on the attacker's domain.
There was no suspicious XHR and no obvious POST to a strange API. In a network tab it looks like a page loading a logo. Somebody scrolling through requests by hand would very likely pass straight over it, and that is presumably the point.
A control watching the destination does not care how the request is dressed up. An image request to a host that has never served this page an image, carrying several hundred bytes of encoded payload, is the same alert as a POST would have been.
At which point would you have found out?
Set the timeline out and the question answers itself. The domain was registered on 21 March. The attackers had write access to store code by late April, roughly four weeks later. The skimmer then ran until 13 June. From the attacker's first move to the malware being removed is close to three months, and the discovery came from outside the company.
Sansec were explicit that the Salesforce Commerce Cloud platform itself was not compromised, and no customer count, card count or fine has ever been made public — so the honest answer to "how bad was it" is that nobody outside Claire's knows. The answerable question is the one about time: on your own checkout, how many weeks would a new destination go unnoticed?
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.
