The Segway cyber attack explained

TL;DR: Segway favicon booctstrap Magecart skimmer

• A payload in a favicon: A favicon should serve pixels, not payloads. Segway's attackers hid a Magento skimmer inside a favicon file that pointed to booctstrap[.]com, and every threat feed was late again.
• Full payload inspection: The malicious script rendered as fake copyright text in the footer while quietly loading a favicon-hosted skimmer from booctstrap[.]com to grab card fields. cside inspects the full payload of every third-party script before the browser executes it.
• Verify every domain: If your Magento store loads any script by name from a design partner or plugin, verify each domain today. If you cannot verify them all, put runtime script analysis in front of the store before the next attacker hides a skimmer in an image asset.

Short on time? See cside's in-browser Magecart and skimmer blocking. It covers everything below in one deployment.

In January 2022, the Segway web store suffered a web supply chain attack - also often referred to as a Magecart attack. In these types of attacks, malicious JavaScript code is added that loads from the client-side, known as third-party scripts.

Many common tools are third-party scripts. Things like analytics, captchas and more. But this avenue can also be used for malicious reasons, as was the case here.

In this attack on Segway, their store is set up on Magento. The attackers targeted vulnerabilities in the CMS itself or one of the plugins installed on the Segway site. After breaching that, they added the JavaScript which appeared to display as the site's copyright, but was actually used to load an external favicon.

Inside that favicon file, a malicious domain 'booctstrap[.]com' was placed. As can be seen from this image from Malwarebytes who broke the news on this attack:

That domain loaded the malicious third-party JavaScript code which aimed at capturing people's credit card details.

As seen most recently in the Polyfill attack of 2024.

The way not to secure against this

Threat feeds are still the most relied upon solution to solve this issue, but we'd argue that it's not the preferred way. Fundamentally, they don't know what they don't know. Attackers register a new domain, and without having to rewrite any code, the attack is back up again. For days, or sometimes weeks, until it's spotted again and the thread feeds update their registries.

cside was designed to stop these web supply chain attacks before they happen.

By putting these third-party scripts in a proxy and analyzing the full code payload before it loads, we spot malicious code like this example. We block it, stopping it from affecting the user, and alert the website owner of the potential attack.

We also save the code of the scripts so the website owner can see it after the event and solve the underlying problem.

These client-side attacks get too little attention. If other security measures fail, like they did in the Segway case, this attack could still have been caught. Monitoring exactly what happens in the user's browser would have caught and stopped the data exfiltration.

Regulation

As seen in this case, e-commerce is often a target. And regulation is catching up, with PCI DSS 4.0 where monitoring of third-party scripts on payment pages is now required (by March 2025). While we applaud this, we urge you to do this on all pages across your entire website. Back in April 2024, we explained in length why not doing so still puts your site at significant risk.

Next to other issues explained in that post, bad actors could exploit compromised scripts on your site to hijack user sessions, impersonate users, and perform unauthorized actions, potentially bypassing two-factor authentication and still bypassing your payment portal protection that way.

You can use cside to monitor scripts on all pages and be compliant for that part of PCI DSS 4.0. And, you can protect your site against these types of attacks with cside.

Get started in minutes for free.