Magecart-aanvallen uitgelegd: hoe webskimming in de browser werkt

Kort samengevat: hoe Magecart-aanvallen werken

• Echte slachtoffers, echte crews: Minstens zeven aanvallersgroepen die JavaScript injecteren op betaalpagina's. British Airways (380k records), Ticketmaster, Newegg, Warner Music.
• Draait voorbij de WAF: De aanval draait nadat je WAF de pagina goedkeurt, in dezelfde JavaScript-context als je checkoutformulier.
• De regels die het sluiten: 6.4.3 en 11.6.1 sluiten dat gat. Verplicht sinds 31 maart 2025 voor iedereen die iets met een betaalpagina te maken heeft.

Weinig tijd? Bekijk cside's in-browser Magecart- en skimmerblokkering. Dit dekt alles hieronder in één deployment.

De aanval in drie zetten

Elke skimmingcampagne, ongeacht welke groep hem draait, komt neer op dezelfde levenscyclus. Strip de branding eraf en je houdt drie zetten over.

De rest van dit artikel loopt elke zet op volgorde door, want die volgorde is precies wat de aanval onzichtbaar maakt.

Zet 1: hoe de code op de pagina komt

De aanvaller moet ervoor zorgen dat zijn JavaScript wordt uitgevoerd in de browser van de bezoeker. Hij heeft drie veelvoorkomende routes naar de pagina, waarvan geen enkele de logica van je origin-server hoeft aan te raken.

1. Een zelf-gehost bestand. Hij krijgt schrijftoegang via een kwetsbare plugin, een verouderd CMS of een gestolen adminlogin, en voegt dan een paar regels toe aan een JavaScript-bestand dat je al uitlevert. De wijziging is klein en vaak verstopt in legitieme code, dus een diff valt niet op.
2. Een third-party-script. Hij compromitteert een leverancier wiens script je rechtstreeks laadt met <script src>, zoals een analytics-, chat- of A/B-test-widget. Nu wordt de skimmer vanaf het domein van de leverancier uitgeleverd aan elke klant die je pagina laadt, en hij staat nooit in je repository om gevonden te worden. Daarom is het beveiligen van third-party-scripts een vak apart.
3. Een tag-manager. Hij neemt een Google Tag Manager-container of iets vergelijkbaars over en voegt één tag met de skimmer toe. Elke site en pagina die die container gebruikt, draait nu die code, inclusief checkoutpagina's waar de tag niets te zoeken heeft.

De third-party- en tag-managerroutes schalen, en dat maakt ze de gevaarlijkste. Eén gecompromitteerde leverancier zaait skimmers uit over elke site die hem vertrouwt, en een script dat jij hebt goedgekeurd kan een ander script binnenhalen dat je nooit hebt gereviewd: het fourth-party-probleem. Dit is de vorm van supply-chain-risico die PCI DSS 4.0.1 vereiste 6.4.3 en 11.6.1 aanpakt door een inventaris en autorisatie van elk script op een betaalpagina te eisen. De Ticketmaster-inbreuk van 2018 volgde precies dit pad: de skimmer bereikte de checkout via het gecompromitteerde chatbotscript van een leverancier, niet via Ticketmasters eigen code (Wikipedia-samenvatting van het incident uit 2018).

Zet 2: hoe de skimmer je formulier leest

Zodra het script draait, is het lezen van het formulier gewone webontwikkeling die tegen je wordt ingezet. Het lezen en wijzigen van de DOM is hoe elk modern framework werkt, dus de acties van de skimmer lijken op normaal paginagedrag. Een skimmer doet doorgaans één of meer van de volgende dingen:

• Leest inputwaarden direct. Het selecteert de kaartnummer-, expiry-, CVV- en naamvelden op hun id-, name- of autocomplete-attributen en leest .value rechtstreeks uit de DOM.
• Koppelt event-listeners. Het haakt input, keyup, change of blur op de betaalvelden, zodat het elke toetsaanslag vastlegt, zelfs als de gebruiker nooit indient.
• Kaapt het submit-pad. Het wikkelt de submithandler van het formulier in of haakt in op de "betaal"-knop, en stelt de volledige payload samen op het moment dat de gebruiker de transactie bevestigt.
• Patcht netwerkprimitieven. Geavanceerde skimmers overschrijven fetch, XMLHttpRequest.prototype.send of navigator.sendBeacon om het echte betaalrequest te lezen terwijl je eigen code het verstuurt.
• Legt een vervalst veld overheen. Sommige varianten injecteren een namaak-betaaliframe bovenop het echte, zodat de shopper kaartgegevens rechtstreeks in het invoerveld van de aanvaller typt. cside's eigen analyse van een Magecart-campagne vond een namaak-betaalframe dat bij checkout werd ingevoegd via één geobfusceerde regel JavaScript, het soort wissel dat een server-side scan nooit opmerkt.

Conditioneel serveren is wat het stil houdt

De skimmer vuurt niet voor iedereen. Hij beperkt zichzelf, zodat de mensen die hem het waarschijnlijkst zouden betrappen (namelijk security-teams, scanners en bots) het kwaadaardige gedrag nooit te zien krijgen:

• Padbeperking. Veel skimmers activeren zichzelf alleen op URL's die overeenkomen met een checkout- of loginpatroon, waardoor de code overal elders slapend blijft.
• Automatiseringsdetectie. Het uitlezen van navigator.webdriver geeft true terug in headless en geautomatiseerde browsers, waardoor de skimmer schone code kan tonen aan een scanner en de echte payload aan een shopper. Geavanceerdere varianten zoeken naar Selenium-globals of lekken via het Chrome DevTools Protocol (CDP) Runtime om geïnstrumenteerde browsers te herkennen.
• Eenmaal per sessie vuren. Eén keer exfiltreren voorkomt dubbele netwerkruis die in een log zou kunnen opvallen.

Die wapenwedloop escaleert ook aan de kant van de aanvaller: cside's Future of Web Security 2026-onderzoeksrapport zag playwright-stealth in 2025 ongeveer vertienvoudigen, automatisering die is gebouwd om navigator.webdriver en vergelijkbare checks te omzeilen. Dezelfde ontwijkingstechniek die de tooling van een aanvaller voor verdedigers verbergt, verbergt ook een skimmer voor die van jou. Bovenop dit alles is de code meestal geobfusceerd, wat de bedoeling tijdens een handmatige review verhult.

Zet 3: hoe de data vertrekt

Vastleggen heeft voor de aanvaller geen waarde zolang de data hem niet bereikt. Exfiltratie is één enkel uitgaand request vanuit de browser, en de aanvaller heeft daarvoor verschillende stille methodes.

Drie eigenschappen maken dit lek van buitenaf vrijwel onmogelijk op te merken. Het request is HTTPS, dus versleuteld net als al je andere verkeer. De bestemming is meestal een typosquat- of net geregistreerd look-alike-domein dat aanvoelt als een echte leverancier. De British Airways-skimmer exfiltreerde naar baways.com, waardoor het niet opvalt in een log. En de payload is klein en vaak base64-gecodeerd, waardoor hij aanvoelt als een routinematige telemetriemelding. Cruciaal is dat dit request rechtstreeks van de browser naar de aanvaller gaat; het passeert nooit je origin, je WAF of je betaalgateway. Dat is precies de reden waarom de diefstal onzichtbaar is voor de server.

Waarom je server, WAF en processor het nooit zien

Zet de drie zetten samen en de blinde vlek is duidelijk. De code laadde in de browser, las het veld in de browser, en stuurde de kopie vanuit de browser naar een derde domein. Je backend zag alleen de legitieme, geautoriseerde transactie.

• Een web application firewall inspecteert requests die op je origin binnenkomen. Het exfiltratierequest komt daar nooit aan, dus de WAF heeft niets om te inspecteren.
• Een SIEM verzamelt server- en infrastructuurlogs, en de skimmer genereert geen serverevent. Fraudemonitoring signaleert aankoopanomalieën, maar de echte aankoop verliep precies zoals verwacht.
• Een betaalprocessor zoals Stripe of Adyen beveiligt de transactie die hij ontvangt. Als je kaartvelden op je eigen pagina staan, leest een skimmer ze al voordat de processor er ooit bij betrokken is, en je pagina blijft, ongeacht de processor, zelf het bewijs voor PCI DSS 4.0.1 6.4.3 en 11.6.1 verschuldigd.

De aanval speelt zich af in een runtime die je server-side stack niet kan bereiken. Een client-side probleem vraagt om een client-side verdediging.

Hoe browserlaag-monitoring elke zet vangt

Detectie moet zitten waar de skimmer draait. cside bewaakt scripts en gedrag in de browser, dus elke zet laat een signaal achter waarop het kan reageren.

• Injecteren toont zich als een nieuw of gewijzigd script. cside onderhoudt een scriptinventaris en signaleert toevoegingen, wijzigingen en gemanipuleerde third-party-tags zodra ze verschijnen, niet pas weken later in een frauderapport.
• Vastleggen toont zich als gedrag. Onverwachte listeners op betaalvelden, code die inputs leest die hij niet zou moeten lezen, en overrides van fetch of sendBeacon zijn runtime-afwijkingen ten opzichte van een bekend-goede baseline.
• Exfiltreren toont zich als een bestemming. cside brengt uitgaande requests naar domeinen die niet op je allowlist staan aan het licht, de kenmerkende zet van een skimmer die probeert te ontsnappen.

Omdat cside in echte browsers draait in plaats van in een clean-room-scanner, verbergt conditioneel serveren de skimmer niet zoals bij een headless crawler. Diezelfde zichtbaarheid levert het bewijs dat PCI DSS 4.0.1 verlangt: een geautoriseerde inventaris van betaalpaginascripts voor 6.4.3, en alerting bij ongeautoriseerde wijzigingen aan scriptinhoud en headers voor 11.6.1, beide verplicht sinds 2025-03-31.

Verder lezen op cside

• Wat is online card skimming?
• Wat is Magecart: complete gids en preventiestrategie
• Formjacking vs Magecart vs digital skimming
• Wat zijn digital skimmers?
• De grootste Magecart-aanvallen uit de geschiedenis (tot nu toe)
• cside client-side security

Bekende Magecart-incidenten (2018 tot 2024)

Het Magecart-ecosysteem is een losse federatie van minstens zeven verschillende groepen (door RiskIQ genummerd van Group 1 tot en met Group 12) die gedeelde TTP's gebruiken. De onderstaande publieke meldingen zijn de referentiegevallen die klanten en QSA's aanhalen bij het bepalen van de scope van PCI DSS 4.0.1 §6.4.3- en §11.6.1-controles.

• British Airways (2018). Ongeveer 380,000 betaalkaartrecords geëxfiltreerd over 15 dagen via een gecompromitteerd script dat werd geserveerd op de checkout- en mobiele-app-pagina's. Boete van de Britse ICO verlaagd van £183M naar £20M.
• Ticketmaster UK (2018). Kaartgegevens van ~40,000 klanten blootgesteld nadat het klantenservicescript van Inbenta, geserveerd vanaf een third-party CDN, werd aangepast om de betaalpagina te skimmen. ICO-boete van £1.25M.
• Newegg (2018). 15 regels geïnjecteerde JavaScript legden gedurende 35 dagen alle kaartgegevens vast die naar checkout/payment.aspx werden verstuurd. Toegeschreven aan Magecart Group 4 door RiskIQ.
• Warner Music Group (2020). Meerdere e-commercesites die door WMG in de VS en het VK werden geëxploiteerd, drie maanden lang gecompromitteerd, gericht op checkoutdata op het Volusion-platform.
• Segway (2022). Aanvallers gebruikten een kwaadaardige Magento-extensie om betaalformulieren te skimmen, gemeld door Malwarebytes.
• Kaiser Permanente (2024). 13.4M leden op de hoogte gebracht nadat third-party analytics- en trackerscripts op pagina's voor leden gevoelige informatie hadden blootgesteld, aansluitend op dezelfde Magecart TTP-klasse.
• Polyfill.io supply-chain (2024). Na een eigendomswisseling begon cdn.polyfill.io kwaadaardige code te serveren aan >100,000 sites die de library insloten, gemeld door Sansec. Fastly, Cloudflare en Google grepen in op netwerkniveau.
• Adobe Commerce / Magento Cosmicsting (CVE-2024-34102). Server-side XML-deserialisatiefout gebruikt om client-side skimmers te planten bij honderden Magento-merchants gedurende 2024 en tot in 2025.

Elk bovenstaand geval omzeilde de server-side verdediging van de merchant en manipuleerde code die de browser uitvoerde. Dat is precies het gat waarvoor PCI DSS 6.4.3 (script-autorisatie en -integriteit) en 11.6.1 (change detection op de betaalpagina) zijn geschreven.

Gerelateerd lezen

• How Polyfill.io hit 490k websites (browser supply-chain attack)
• What is formjacking?
• Online credit card skimming
• Third-party scriptmonitoringplatformen: de 5 beste opties vergeleken