Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Magecart is an umbrella name for cybercrime actors that stole payment-card data by injecting malicious code into online checkout pages or compromising scripts used by merchants. The seven-group map in RiskIQ and Flashpoint’s 2018 report is a useful historical snapshot—not a complete or permanent roster of Magecart actors. Later Group-IB reports identified many more JavaScript-sniffer families, and attribution labels have continued to evolve.
What Magecart means—and why the name covers multiple groups
Magecart was not a single organization with one fixed membership or attack method. The name came to describe multiple actors and campaigns focused on payment-card theft from e-commerce sites. RiskIQ and Flashpoint’s 2018 report organized activity into seven numbered groups, while treating Groups 1 and 2 as one lineage in its taxonomy. Those labels help compare the operations described at the time, but they should not be read as an exhaustive list or a definitive current attribution system.
The scale of later research illustrates the difference between a group taxonomy and the wider threat. Group-IB reported 38 JavaScript-sniffer families in 2019 and at least 96 in a 2020 follow-up. A sniffer family is not necessarily the same thing as a criminal group: tools may be reused, campaigns may overlap, and later investigators may revise links between actors.
The seven groups in the 2018 snapshot
The table summarizes the distinctions reported for the seven labels. Store counts are contemporaneous reporting estimates, not a combined total. The underlying sources do not establish a first-seen date for every group or comparable details for every technical and monetization category.
#1 Best Overall
| Group | Access pattern and notable behavior | Reported scale or target | Infrastructure or monetization detail |
|---|---|---|---|
| Groups 1 and 2 | Broad, often automated compromise of online stores; payment-page skimming | Not stated as a comparable count (RiskIQ/Flashpoint, 2018 report) | Associated with reshipping schemes; Groups 1 and 2 were combined as one lineage in the report’s taxonomy |
| Group 3 | Direct store compromise; inspected payment forms and field names rather than relying only on a checkout URL | More than 800 online stores, attributed in SC Media’s 2018 reporting | Technical summaries describe anti-analysis checks and a geographic emphasis on payment processors in Latin America |
| Group 4 | Large-scale, comparatively stealthy store compromise | More than 3,000 stores, attributed in SC Media’s 2018 reporting | Methods were described as blending malicious code into victim sites; a specific monetization route is not stated in the cited reporting |
| Group 5 | Supply-chain compromise through third-party services embedded by merchants | Not stated as a comparable count (SC Media, 2018 reporting) | Linked in reporting to the Ticketmaster incident; a specific monetization route is not stated here |
| Group 6 | Associated with high-profile e-commerce targets | British Airways and Newegg were named in contemporaneous reporting; no comparable store count is stated | MITRE ATT&CK maps FIN6 to Magecart Group 6 and describes payment-card theft for sale on underground markets |
| Group 7 | Targeted worthwhile e-commerce sites without a sharply defined victim profile | At least 100 stores after its 2018 emergence, attributed in SC Media’s 2018 reporting | Used compromised websites as proxies for injection or stolen-data drops, complicating takedown |
Groups 1 and 2: one lineage in this taxonomy
RiskIQ and Flashpoint’s report presents Groups 1 and 2 together as a lineage rather than two wholly separate entries. The operation was associated with broad, often automated store compromises and payment-page skimming, alongside reshipping schemes. That grouping is specific to the report’s classification; it does not establish that every later campaign using similar techniques belonged to the same actor.
Group 3: form-aware collection
Unlike a skimmer that assumes a particular checkout URL, Group 3’s reported code inspected payment forms and field names. That approach could help it locate card details when a merchant’s checkout layout differed. Technical summaries also describe anti-analysis checks and a geographic emphasis on payment processors in Latin America. SC Media attributed more than 800 compromised online stores to the group in 2018; that figure belongs to its contemporaneous reporting, not a current count.
Group 4: scale and stealth
Group 4 was described as both large-scale and comparatively stealthy, with methods intended to make malicious code blend into victim websites. SC Media attributed more than 3,000 compromised stores to the group in 2018. That is a reported attribution from that period, not a verified lifetime total.
Group 5: compromise through a supplier
Group 5’s distinguishing approach was to target third-party providers—such as customer-support, advertising, analytics, or other services whose scripts were embedded on merchant sites. A compromise at a supplier could expose many storefronts without separately breaking into each merchant. Contemporaneous reporting linked this model to the Ticketmaster incident.
Recommended Free Tools
Group 6: high-profile targets and card resale
British Airways and Newegg were associated with Group 6 in contemporaneous reporting. MITRE ATT&CK maps FIN6 to Magecart Group 6 and describes payment-card theft followed by sale on underground markets. The mapping is an attribution reference, not proof that every incident involving those companies or every card-stealing campaign was conducted by the same actors.
Group 7: compromised sites as proxies
Identified in 2018, Group 7 was reported to target e-commerce sites considered worthwhile rather than a narrowly defined type of victim. Its infrastructure stood out: researchers said, “Instead of using a dedicated host for the injection and the drop, this group uses compromised sites as proxies for its stolen data.” Using compromised websites in this way could make it harder to identify and take down the infrastructure. SC Media reported at least 100 affected stores after the group’s emergence in 2018.
Rank #3
How Magecart attacks stole payment data
A typical attack put malicious client-side JavaScript—or related code—into the payment flow. When a customer entered card details, the code captured information from the checkout form and sent it to infrastructure controlled by the attackers. Some skimmers looked for specific form fields; others could inspect a page to find payment inputs rather than depending solely on a known checkout address.
In a supply-chain attack, the malicious code arrived through a third-party script the merchant had included for a legitimate service. The customer still entered payment details on the merchant’s site, but the compromised supplier’s code could observe or collect them. This means the relevant security boundary extends beyond the store’s own application: embedded scripts, content-management systems, service providers, and outbound connections can all affect a checkout.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Who was affected—and what the reported numbers mean
Named targets and incident figures show the range of Magecart-related activity, but they measure different events and scopes. They should not be added together or treated as one estimate of total victims.
- Group 3: SC Media attributed more than 800 online stores to the group in 2018.
- Group 4: SC Media attributed more than 3,000 stores to the group in 2018.
- Group 7: SC Media reported at least 100 stores after the group emerged in 2018.
- British Airways: Group-IB reported in 2019 that a JavaScript sniffer infecting the airline’s website and mobile app affected 380,000 victims.
- Fila: Group-IB reported in 2019 that at least 5,600 customers were potentially exposed.
- UltraRank: Group-IB counted infections across 691 websites and 13 third-party providers over five years in its 2020 reporting.
These figures use different definitions—such as stores attributed to a group, people affected in an incident, or websites and providers involved in a campaign. None is a substitute for a consistent count of Magecart victims across all actors and years.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How the stolen data became a criminal business
Payment skimming fit into a wider criminal economy that included skimmer kits, compromised e-commerce sites, stolen-card shops, and services supporting those operations. MITRE’s FIN6 profile describes stolen payment-card data being sold on underground markets. Group-IB’s UltraRank reporting shows another model: one actor combined supply-chain compromise with operating its own card shop.
Group-IB reported that the ValidCC card shop averaged $5,000–$7,000 per day during a sampled week in 2019. This was a reported average for that specific shop and week—not a typical income figure for Magecart groups or an annual revenue estimate.
Free tools Windows power users keep installed
One-click scans. No signup required.
Best Value
How online stores can detect and reduce Magecart risk
Because payment skimmers can arrive through a merchant’s own code or a supplier’s script, detection needs to cover the whole checkout path. These controls help make unexpected changes and data flows easier to find:
- Inventory third-party scripts. Record which services load on checkout pages, who owns each dependency, and why it is needed. Treat every embedded JavaScript provider as part of the payment security boundary.
- Monitor checkout changes. Alert on unexpected modifications to payment pages, scripts, and content-management components. Review both authorized releases and changes that do not correspond to a deployment.
- Check script integrity and behavior. Use integrity controls where they fit the service’s update model, and investigate scripts that change unexpectedly or behave differently on checkout pages.
- Watch outbound requests. Look for payment-page traffic sent to unfamiliar destinations, especially when a request appears only after a customer enters payment details.
- Investigate suppliers as well as the store. If a third-party script is implicated, assess the provider’s infrastructure and other affected services instead of limiting the investigation to the merchant’s server.
- Track actor aliases cautiously. Threat-intelligence reporting can help connect infrastructure and campaigns, but names and attributions change. Validate current indicators and behavior rather than treating an old group label as conclusive.
These measures support detection and investigation; they do not by themselves establish that a payment environment is compliant or immune to compromise.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
