Pour détecter Magecart en temps réel, surveillez les scripts pendant qu'ils s'exécutent dans de vraies sessions d'acheteurs et alertez au moment où l'un d'eux accroche un champ de formulaire, s'attache au bouton submit, ou ouvre une destination sortante qui n'était pas dans la baseline de la page. Un scan périodique extérieur ne dit que ce que la page a renvoyé à un scanner, à un emplacement de scan, pendant une fenêtre de scan. Les skimmers modernes sont construits pour éviter exactement ça.
L'écart temporel est tout le problème. Un scanner tourne toutes les quelques heures ou une fois par jour depuis un crawler fixe. Un skimmer tourne dans la seule session qui l'intéresse : un vrai porteur de carte, dans une région ciblée, sur un appareil ciblé, au checkout. cside ferme cet écart en observant les mêmes sessions que l'attaquant cible et en capturant ce que chaque script fait au runtime, donc un changement malveillant remonte pendant que l'exposition est vivante, pas après l'arrivée d'un rapport forensique d'un réseau de cartes.
Pourquoi les scanners ratent les skimmers conditionnels
Les payloads Magecart portent de plus en plus de logique de garde. Ils décident s'ils s'activent avant de voler quoi que ce soit, ce qui signifie qu'une charge propre ne prouve rien.
Conditions d'évasion courantes qui battent le scan extérieur :
- Géociblage : le payload ne s'active que pour des IPs dans certains pays et sert du code bénin ailleurs. Un scanner crawlant depuis une région de datacenter hors cible ne le déclenche jamais.
- Filtrage appareil et UA : le skimmer ne tourne que sur de vrais profils navigateur mobile ou desktop et se supprime face aux signatures headless ou crawler.
- Fenêtrage temporel : l'activation est limitée à certaines heures, donc un scan qui tourne au mauvais moment ne voit rien.
- Filtrage par état de session : le code attend un panier rempli ou une route de checkout avant de s'armer, ce qu'un scan synthétique qui charge une URL n'atteint jamais.
- Checks anti-automatisation : le payload inspecte
navigator.webdriver, l'absence de timing d'input ou l'absence d'événements de pointeur et reste dormant quand il détecte une session automatisée.
Chaque condition est un filtre qui exclut les scanners par conception. L'attaquant n'a pas besoin de battre la signature de votre outil de monitoring ; il lui suffit de reconnaître que le visiteur n'est pas un client qui va payer dans le segment cible. C'est bien plus facile, et un instantané statique du fichier ne peut pas capturer une décision que le code prend au moment de l'exécution.
Ce que le monitoring runtime voit qu'un scan ne verra jamais
Le scan extérieur compare des contenus de fichiers ou des hashes. Le monitoring runtime observe le comportement dans un navigateur vivant, ce qui est une surface différente et plus large.
| Signal | Scan périodique extérieur | Monitoring runtime navigateur |
|---|---|---|
| Payload conditionnel qui se cache des crawlers | Voit la version bénigne | Voit la version servie à la vraie session ciblée |
| Lectures DOM / champs de carte et de login | Non observées | Observées quand le script accède au champ |
| Hooks d'événements sur submit, keydown ou change | Non observés | Capturés quand le listener s'attache |
| Nouvel endpoint d'exfiltration au clic de paiement | Manqué sauf si capturé en pleine requête | Signalé contre la baseline de destinations de la page |
| Compromission d'une origine vendor déjà autorisée | Hash/origine paraissent toujours autorisés | Le changement de comportement le signale indépendamment de l'origine |
| Payload obfusqué assemblé au runtime | Le fichier statique paraît inerte | Visible dès qu'il s'exécute et agit |
Les comportements qui comptent dans un skimmer numérique ne sont pas dans le fichier au repos. Ils arrivent quand le script tourne : il atteint le DOM, lit value sur l'input du numéro de carte, enregistre un handler sur l'événement submit du formulaire, puis assemble un payload et l'envoie avec fetch, XMLHttpRequest ou navigator.sendBeacon vers un domaine look-alike à l'instant où l'utilisateur clique sur payer. Observer l'exécution est le seul point d'observation qui voit cette séquence.
Le cas le plus difficile pour les outils basés sur hash est la compromission de chaîne d'approvisionnement. Un script vendor de confiance reçoit une nouvelle version d'apparence légitime depuis une origine CDN autorisée. Le hash est nouveau mais valide ; l'origine est sur votre allowlist. Rien dans le fichier ou sa source ne paraît mauvais. Ce qui paraît mauvais, c'est le comportement : un script qui auparavant rendait un widget lit désormais un champ de paiement et poste vers une destination qu'il n'a jamais contactée. Le monitoring runtime établit la baseline de ce que chaque script fait, donc un changement comportemental déclenche une alerte même quand l'origine et la signature restent dans la politique.
Un plan opérationnel pour la détection en temps réel
L'objectif est de raccourcir l'intervalle entre changement malveillant et confinement, et de conserver une preuve qui survive à une revue forensique.
- Monitorez la production depuis de vraies sessions d'acheteurs, sur produit, panier et checkout, pas seulement l'étape de paiement, et pas depuis un crawler synthétique.
- Établissez la baseline du comportement de chaque script : quels nœuds DOM il lit, quels champs de formulaire il touche, quelles destinations il contacte. L'écart par rapport à cette baseline est votre signal primaire.
- Alertez sur les nouvelles destinations d'exfiltration au moment où un script contacte un domaine absent de l'ensemble de destinations établi de la page.
- Alertez sur les nouveaux hooks de formulaire : un listener qui s'attache à un champ de paiement ou d'identifiants, ou au bouton submit, sur un script qui ne l'a jamais fait.
- Capturez le payload lisible et les timestamps par session pour reconstruire ce qui a tourné, dans quelles sessions, et quelles données étaient en scope.
- Routez les alertes comportementales de haute sévérité directement vers la réponse à incident avec l'identité du script, les pages affectées et la destination déjà attachées.
Les étapes 2 à 4 sont ce qui convertit la visibilité runtime brute en quelque chose sur lequel un analyste peut agir en minutes au lieu de faire l'ingénierie inverse de JavaScript obfusqué après coup.
Comment cside s'insère
cside instrumente de vraies sessions d'acheteurs et observe les scripts tiers et first-party pendant qu'ils s'exécutent. Il capture le comportement runtime qu'un scanner ne peut pas atteindre : accès aux champs de formulaire, hooks d'event-listener sur les inputs de paiement et de login, et requêtes sortantes vers des destinations hors baseline de la page. Comme la détection tourne dans les mêmes sessions que l'attaquant cible, un skimmer conditionnel qui se cache des crawlers remonte au moment où il agit sur un vrai visiteur.
Quand le comportement d'un script dévie, cside signale ce qui a changé, où il a tourné, quels champs il a touchés et où les données sont allées, avec des timestamps par session et le payload lisible préservé pour l'investigation. Cela donne au responsable du résultat le contexte pour contenir l'exposition pendant qu'elle est encore vivante, et une traîne de preuves pour les questions qui suivent. La même télémétrie de couche navigateur alimente la capture appareil et IP réelle, la détection agents IA et automatisation, et les signaux comportementaux proxy/VPN via la plateforme cside.
