Skimmer SVG 1×1 Magecart sur Magento: DLP et conformité RGPD

Le 8 avril 2026, Sansec révèle une campagne Magecart contre ~100 boutiques Magento: un skimmer carte bancaire caché dans une image SVG 1×1, avec exfiltration vers 23.137.249.67 (IncogNET, NL). Voici comment une DLP bien réglée répond aux articles 32 et 44‑49 RGPD.

Les faits

Le 7–8 avril 2026, l’équipe forensique de Sansec documente une attaque de type web‑skimming visant près d’une centaine de sites e‑commerce Magento. Le mécanisme : l’attaquant injecte un élément <svg width="1px" height="1px" onload="..."> contenant, en base64 (via atob()) et exécuté par setTimeout, tout le code malveillant. Lors du clic sur “Payer/Checkout”, un faux surcouche “Secure Checkout” capture en temps réel les numéros de carte (validation Luhn), l’adresse de facturation et autres champs, puis exfiltre les données sous forme JSON chiffrées par XOR + base64 vers des domaines contrôlés par l’attaquant.

Sansec attribue vraisemblablement l’intrusion initiale à la vulnérabilité PolyShell affectant Magento/Adobe Commerce (exécution de code et prise de contrôle non authentifiée). BleepingComputer confirme les éléments clés, précisant qu’Adobe n’avait pas encore publié de correctif “production” au 8 avril (seule une version pré‑release était disponible). L’infrastructure d’exfiltration est hébergée chez IncogNET (AS40663) aux Pays‑Bas ; l’hébergeur indique ensuite avoir désactivé le compte incriminé.

IOCs publics (extrait Sansec):

• IP d’exfiltration: 23.137.249.67 (IncogNET, NL)
• Chemin: /fb_metrics.php
• Clé locale navigateur posant un marqueur: _mgx_cv
• Domaines d’exfiltration: statistics-for-you[.]com, statistics-renew[.]com, morningflexpleasure[.]com, reusable-flex[.]com, goingfatter[.]com, wellfacing[.]com

Points techniques saillants pour la défense : charge utile 100% inline (pas d’appel de script externe), POST “no‑cors” via fetch() avec repli en iframe, balise SVG quasi invisible 1×1, leurres d’UX crédibles et redirection vers le vrai paiement après vol des données – autant d’éléments qui contournent des contrôles superficiels.

Sources : Sansec (recherche avec IOCs), BleepingComputer (synthèse et mise en contexte).

Le cadre légal qui s’applique

• RGPD — article 32 (sécurité du traitement) : obligation de mettre en œuvre des mesures techniques et organisationnelles appropriées, proportionnées aux risques, incluant la prévention de la divulgation non autorisée et le contrôle des transferts de données en sortie du SI (EUR‑Lex).
• RGPD — chap. V, articles 44‑49 (transferts internationaux) : tout transfert vers un pays tiers ou une organisation internationale ne peut intervenir que sous conditions (décision d’adéquation, Clauses Contractuelles Types + mesures supplémentaires, dérogations strictes). Les responsables doivent “connaître leurs transferts” et vérifier les accès/flux effectifs, pas seulement l’hébergement nominal (EDPB Recos 01/2020; CNPD – transferts).

Conséquence pratique : une exfiltration automatique de données de paiement (PAN, CVV, adresse) par script skimmer constitue à la fois un manquement à l’article 32 et, si les données quittent l’EEE ou sont consultées depuis un pays tiers, un transfert au sens des articles 44‑49 — même si l’application “principale” est hébergée en Europe. Le cadre du RGPD insiste sur la réalité des flux et des accès, pas seulement l’emplacement du serveur.

La solution technique à déployer

DLP (Data Loss Prevention) bien configurée, en complément des patchs/WAF et des contrôles front‑end (CSP), permet de détecter et bloquer l’exfiltration de données personnelles sensibles depuis vos navigateurs, serveurs web et postes métiers.

• DLP réseau sortant (egress) : inspection des flux HTTP(S) vers Internet, avec signatures content-aware pour schémas carte (PAN avec Luhn, BIN, formats IBAN), données d’identité (nom+adresse+CP), et règles ad hoc sur des patterns d’ofuscation (XOR “script” + base64, POST no‑cors). Blocage / mise en quarantaine sur domaines/IP d’IOC et sur chemins suspects (/fb_metrics.php), domain age court, ASN non‑attendu.
• DLP endpoint / navigateur : contrôle de contenu avant envoi par champs web, détection de form‑grabbing, et politiques empêchant la transmission de “numéros de carte” vers des origines non autorisées. Intégrations via agents EDR/XDR et extensions managées.
• DLP mail & API : si vos équipes échangent des justificatifs clients, le moteur DLP doit empêcher l’expédition hors domaine/EEE de pièces contenant PAN/CVV et déclencher une revue DPO quand un flux inhabituel est détecté.
• Gouvernance des flux : cartographier les destinations autorisées (liste blanche fournisseurs/PSP, socles de monitoring, anti‑fraude, archivage), journaliser les tentatives bloquées et tenir un registre des flux de données personnelles transfrontières exploitable par le DPO.

Référentiels : ISO/IEC 27001:2022 Annexe A.8.12 (prévention des fuites), A.8.16 (monitoring), A.8.23 (sécurité des données applicatives) ; NIST CSF 2.0 PR.DS (Data Security), DE.AE (détection d’événements) ; CIS Controls v8 n°3 (Data Protection) et n°13 (Network Monitoring & Defense).

Comment Luxgap déploie cela

• Notre SOC managé 24/7 : nous intégrons les IOCs Sansec (domaines, IP 23.137.249.67, chemins, artefacts _mgx_cv) dans le SIEM/XDR, corrélons avec vos logs web/CDN/WAF et vos egress‑firewalls, et mettons en place des détections de patterns (XOR “script”, base64, POST no‑cors) spécifiques aux skimmers. Découvrez notre SOC managé 24/7.
• Notre gouvernance ISO 27001 : atelier “cartographie des transferts” avec le DPO pour aligner la DLP sur le RGPD chap. V : listes blanches de destinations autorisées, preuves de proportionnalité (art. 32), conservation des journaux exportables pour la CNPD.
• Notre dark web monitoring : surveillance des canaux où se revendent jeux de cartes/credentials, alerte corrélée avec vos événements DLP pour accélérer la qualification d’incident et, si besoin, la notification art. 33 RGPD. En savoir plus sur notre surveillance du dark web.

Cas concret au Luxembourg ou en UE

Une place de marché B2C, soumise au RGPD et opérant en multilingue UE, détectait ponctuellement des abandons de panier inexpliqués. En 6 semaines, nous avons : (1) déployé une DLP egress avec dictionnaires PAN/Luhn et règles “C2 skimmer” (POST no‑cors, domaines jeunes/non‑PSP, chemins type /metrics//analytics), (2) ajouté des IOC‑feeds Sansec/BleepingComputer, (3) aligné la liste blanche des seules destinations de paiement (PSP, anti‑fraude) et (4) activé la télémétrie navigateur côté poste support. Résultat : plusieurs tentatives d’exfiltration bloquées automatiquement, preuve d’absence de transferts non autorisés exploitable par le DPO, et un plan de remédiation serveur (patch PolyShell + CSP “form‑action/script‑src” restrictif).

Premiers pas concrets

1. Bloquez les IOCs dès aujourd’hui : 23.137.249.67, les 6 domaines Sansec, le chemin /fb_metrics.php. Ajoutez des règles “POST vers domaine non approuvé” sur données PAN/CVV.
2. Chassez les artefacts : recherchez <svg ... onload= avec atob() dans vos gabarits/JS, et la clé locale _mgx_cv côté front. Vérifiez qu’aucune surcouche “checkout” JS inconnue n’intercepte les clics.
3. Cartographiez vos transferts (EDPB étape 1) : dressez la liste des destinations egress autorisées pour données perso (PSP, KYC, anti‑fraude), distinguez EEE vs pays tiers, consignez dans votre registre RGPD et paramétrez la DLP en conséquence.
4. Mettez à jour et segmentez : appliquez le correctif Magento/Adobe Commerce dès disponibilité, isolez l’hébergement paiement, et durcissez CSP (notamment form-action, connect-src, script-src).
5. Testez votre détection : simulez un POST sortant contenant un PAN factice (format de test) vers un domaine “leurre” ; vérifiez l’alerte DLP/SIEM, l’escalade SOC et la capacité DPO à répondre sur art. 32 et chap. V (voir le RGPD).

Aller plus loin

Besoin d’un accompagnement opérationnel et conformité combinés ? Contactez‑nous via la page prise de contact.

Sources officielles

• Actualité et IOCs : Sansec — SVG Onload Tag Hides Magecart Skimmer (07/04/2026) ; BleepingComputer — Hackers use pixel‑large SVG trick to hide credit card stealer (08/04/2026).
• Règlementaire : RGPD art. 32 et chap. V (EUR‑Lex) ; EDPB Recommandations 01/2020 — mesures supplémentaires pour transferts ; CNPD (LU) — Dossier “Transferts internationaux”.