L'art de la dissimulation : une nouvelle campagne Magecart qui abuse des pages 404
Synthèse
Le groupe Security Intelligence d'Akamai a détecté une campagne de Web skimming Magecart qui cible une liste étendue de sites Web, y compris de grandes organisations dans les secteurs de l'alimentation et du commerce de détail.
Cette campagne se distingue par ses trois techniques de dissimulation avancées, dont l'une n'avait jamais été observée auparavant : la manipulation de la page d'erreur 404 par défaut du site Web pour dissimuler du code malveillant, ce qui pose des défis uniques en matière de détection et d'atténuation.
Les deux autres techniques de brouillage mettent en évidence les tactiques évolutives utilisées par les attaquants pour éviter la détection et allonger la chaîne d'attaque.
Alors que les attaques de Web skimming deviennent de plus en plus sophistiquées, les organisations doivent rester vigilantes et explorer des approches avancées pour se protéger contre ces menaces en constante évolution.
Introduction
Une nouvelle campagne de Web skimming Magecart sophistiquée et secrète a ciblé les sites Web Magento et WooCommerce. Certaines des victimes de cette campagne sont associées à de grandes organisations des secteurs de l'alimentation et du commerce de détail.
D'après les éléments que nous avons découverts, cette campagne est active depuis quelques semaines, voire plus longtemps dans certains cas. Elle a réussi à nous surprendre avec une technique de dissimulation de haut niveau que nous n'avions pas encore rencontrée.
La nouvelle campagne
Les attaques Magecart commencent généralement par l'exploitation des vulnérabilités des sites Web ciblés ou par l'infection des services tiers utilisés par ces sites. Dans cette campagne, tous les sites Web des victimes que nous avons détectés ont été directement exploités, l'extrait de code malveillant ayant été injecté dans l'une de leurs ressources de première partie.
Dans certains cas, le code malveillant a été inséré dans les pages HTML ; dans d'autres, il a été dissimulé dans l'un des scripts de base qui a été chargé dans le cadre du site Web.
Comme dans de nombreuses autres campagnes Magecart, l'infrastructure d'attaque de cette campagne se compose de trois parties principales : le chargeur, le code d'attaque malveillant et l'exfiltration des données (Figure 1).
Chargeur - Des extraits de code JavaScript courts et obscurs responsables du chargement du code malveillant complet de l'attaque
Code d'attaque malveillant - Le code JavaScript principal qui exécute l'attaque : il détecte les entrées sensibles, lit les données, perturbe le processus de paiement et injecte de faux formulaires
Extraction de données - La méthode utilisée pour transmettre les données volées au serveur de commande et de contrôle (C2) de l'attaquant
La séparation de l'attaque en trois parties a pour but de dissimuler l'attaque de manière à la rendre plus difficile à détecter. Cela permet d'activer le flux complet de l'attaque uniquement sur les pages spécifiquement ciblées. C'est-à-dire qu'en raison des mesures de brouillage utilisées par l'attaquant, l'activation du flux complet de l'attaque ne peut se produire que là où l'attaquant avait l'intention de l'exécuter. Cela rend l'attaque plus discrète et plus difficile à détecter par les services de sécurité et les outils d'analyse externes qui pourraient être en place sur le site Web ciblé.
Bien que la plupart des campagnes Magecart présentent des similitudes en termes de flux et d'étapes, ce qui distingue une campagne d'une autre, ce sont les diverses techniques de dissimulation employées par les attaquants. Ces techniques sont utilisées pour masquer l'infrastructure de l'attaque, dissimuler les traces, compliquer la détection et la rétro-ingénierie et, en fin de compte, prolonger l'attaque.
Trois variantes de la campagne
Nous avons trouvé trois variantes différentes de cette campagne, démontrant l'évolution de l'attaque et les améliorations apportées par les attaquants au fil du temps pour empêcher la détection et l'atténuation de cette campagne.
Les deux premières variantes sont assez similaires, avec seulement des différences mineures au niveau du chargeur.
La troisième version est unique, car les attaquants ont utilisé la page d'erreur 404 par défaut du site Web pour masquer leur code malveillant. Il s'agit d'une technique de dissimulation créative que nous n'avions jamais vue auparavant.
Examinons de plus près les détails techniques des trois variantes de cette campagne inédite.
Variante 1
Nos recherches ont commencé lorsque nous avons remarqué des extraits de code suspects, détectés par nos outils de veille sur les menaces, sur le site Web d'une grande entreprise. En analysant ces extraits, nous avons découvert qu'il s'agissait de chargeurs JavaScript encodés de manière malveillante, qui étaient toujours présents et actifs sur le site Web. Cette découverte nous a amenés à approfondir notre enquête, révélant l'ensemble de la campagne, avec ses variantes et son impact sur de nombreux sites Web.
Le chargeur de la variante 1 : La partie émergée de l'iceberg
Le skimmer a injecté avec succès une balise d'image HTML malformée avec un attribut onerror dans le site Web exploité (Figure 2). Cet attribut contient un extrait de code de chargeur malveillant brouillé et encodé en Base64. L'attribut src intentionnellement vide de la balise d'image est conçu pour empêcher les requêtes réseau et déclencher l'exécution d'un rappel onerror intégré contenant l'extrait de code JavaScript malveillant brouillé.
L'utilisation de balises d'image dans le but d'exécuter du code JavaScript est une technique moins courante et plus sophistiquée. Elle peut aider le skimmer à contourner les mesures de sécurité telles que les scanners externes qui analysent généralement le trafic réseau, qui ne sont pas déclenchés dans ce cas précis. Le code brouillé s'exécute dans le contexte de la page et comme s'il s'agissait d'un script natif de première partie lancé par la page elle-même.
Figure 2 : Chargeur de la variante 1 – Une balise d'image HTML mal formatée avec un attribut onerror contenant un code de chargeur malveillant
Code décodé du chargeur – Exécution
Une fois que le code Base64 brouillé est exécuté, il se transforme en JavaScript normal et devient responsable de l'ouverture d'un canal WebSocket (Figure 3). Ce canal sert de lien de communication bidirectionnel entre le navigateur et le serveur C2 de l'attaquant.
L'utilisation de WebSockets dans les attaques Magecart a été observée dans plusieurs campagnes récentes. WebSocket est considéré comme une méthode de communication plus silencieuse et plus souple, qui permet à l'attaquant d'utiliser un seul canal réseau à des fins diverses. Cela inclut l'envoi de différentes parties de l'attaque du serveur C2 au navigateur (et vice versa), ainsi que la facilitation des activités d'exfiltration de données dans certains scénarios.
Un autre aspect remarquable du code est la détection des bots, qui vérifie si l'agent utilisateur est sous le contrôle d'un automate. Si c'est le cas, le code met fin à son exécution. Il s'agit d'une technique anti-bot intelligente visant à échapper aux scanners de sécurité externes et aux sandboxes susceptibles de détecter l'attaque.
Figure 3 : Le code JavaScript décodé au moment de l'exécution du chargeur de la variante 1
Flux de communication WebSocket
Une fois le canal WebSocket établi, le premier message est envoyé du serveur C2 de l'attaquant au navigateur. Ce message est transmis sous la forme d'une chaîne codée en Base64, contenant une commande JavaScript d'une ligne qui demande au navigateur de renvoyer l'URL actuelle de la page.
L'objectif de cette étape est de permettre au serveur C2 de déterminer si la page actuelle est une page de paiement (sensible) ou toute autre page qui n'est pas une page de paiement. Ainsi, l'attaquant peut adapter les étapes suivantes en conséquence.
Cette validation directe côté serveur permet à l'attaquant d'activer l'attaque uniquement sur les pages ciblées pertinentes, évitant ainsi une exposition potentielle sur les pages non sensibles. Il s'agit là d'un autre exemple qui met en évidence les efforts déployés par le skimmer pour éviter d'être détecté par les services de sécurité et les scanners externes.
Lorsque le serveur C2 identifie l'URL d'une page de paiement, le flux passe à l'étape suivante. Au cours de cette étape, un autre message est envoyé au navigateur. Il s'agit d'une longue chaîne codée en Base64, qui contient l'intégralité du code de l'attaque. Une fois décodé, un code JavaScript long et brouillé est révélé (Figure 4).
Ce code est chargé d'exécuter diverses activités malveillantes sur la page sensible ciblée, dans le but de lire les données personnelles sensibles et les données relatives aux cartes de crédit de l'utilisateur et de les transmettre au serveur C2 du skimmer.
Des messages d'exfiltration de données brouillées contenant les données sensibles volées recueillies par le code malveillant sont ensuite envoyés du navigateur au serveur C2. Comme indiqué précédemment, l'utilisation du même canal WebSocket pour le chargement du code malveillant complet et l'exfiltration des données volées rend le processus plus silencieux et implique moins de requêtes réseau que les méthodes de communication plus traditionnelles telles que les requêtes de ressources XHR, de récupération ou HTML.
Figure 4 : Flux WebSocket sur les pages de paiement
Variante 2
Le chargeur de la variante 2 : Même dame, nouvelle robe
La principale différence entre la première et la deuxième variante réside dans le composant du chargeur. Dans la variante 2, le skimmer insère un script intégré avec un extrait de code qui ressemble beaucoup à l'extrait de code Meta Pixel, un service bien connu de suivi de l'activité des visiteurs de Facebook, avec quelques lignes supplémentaires à l'intérieur (Figure 5).
Ces lignes supplémentaires constituent la véritable partie du chargeur, tandis que le code Meta Pixel qui l'entoure est une couverture trompeuse destinée à faire croire qu'il s'agit d'un extrait de code légitime et peu suspect.
Cette technique de dissimulation, qui fait passer les extraits de code malveillant pour des services bien connus comme Google Tag Manager ou Facebook, a gagné en popularité dans les récentes campagnes Magecart. Elle permet aux skimmers d'échapper à l'analyse statique des scanners externes et des chercheurs.
Figure 5 : Chargeur de la variante 2 – Script intégré déguisé en extrait de code Meta Pixel avec un chargeur malveillant à l'intérieur
Demande d'une image
Lorsque nous avons examiné attentivement les lignes suspectes de l'extrait de code du faux Meta Pixel, nous avons constaté qu'il semblait chercher une image PNG dans le répertoire du site Web. La requête réseau semblait être une requête typique pour une image innocente hébergée sur le site Web. Cependant, lorsque nous avons examiné le contenu réel de cette image, il est devenu évident qu'elle n'était pas aussi anodine qu'elle le paraissait (Figure 6).
Figure 6 : Demande d'image réseau pour une image qui a été altérée par l'attaquant et qui contient un code malveillant
Extrait de code JavaScript malveillant dans une image binaire
Les données binaires de l'image PNG contiennent une chaîne codée en Base64 ajoutée à la fin du fichier binaire de l'image (Figure 7). Cette chaîne est ensuite extraite, décodée et exécutée par l'extrait de code du chargeur (Figure 8). La chaîne décodée représente un extrait de code JavaScript identique à celui qui se trouve à l'intérieur de l'attribut onerror du chargeur dans la variante 1.
Les étapes suivantes du flux restent inchangées. Cet extrait de code se transforme en code JavaScript simple au moment de l'exécution, le code initie le canal WebSocket vers le serveur C2 de l'attaquant et le reste de la séquence se déroule comme décrit précédemment.
Figure 7 : Données binaires de l'image contenant le code malveillant dissimulé
Figure 8 : Le code malveillant, initialement encodé en Base64 et dissimulé dans l'image, devient apparent après décodage
Variante 3
Parlons à présent de la meilleure partie. Même si nous avons déjà assisté à des attaques similaires, celle-ci est unique et nous a vraiment surpris.
Le chargeur de la variante 3 : À la fois identique et totalement différent
À première vue, ce chargeur semble semblable à celui de la deuxième variante, mais vous constaterez (comme nous l'avons fait) qu'il s'agit d'un scénario totalement différent. Dans certains cas, ce chargeur est déguisé en extrait de code Meta Pixel, comme dans la variante 2 (Figure 9). Mais dans d'autres cas, il est injecté dans des scripts intégrés aléatoires sur la page (Figure 10).
Le premier aspect notable de ce chargeur est une requête de récupération vers un chemin relatif appelé « icons ».
Figure 9 : Chargeur de la variante 3 – Un extrait de code malveillant dissimulé dans un extrait de code qui imite l'apparence de Meta Pixel
Figure 10 : Chargeur de la variante 3 – Un extrait de code malveillant dissimulé dans un script intégré arbitraire
Une erreur 404 ? Vraiment ?
Après l'exécution du chargeur, l'attaque envoie une requête de récupération à /icons,qui est un chemin relatif qui n'existe pas en réalité. Cette demande a abouti à une erreur "404 Not Found" (Figure 11). L'analyse du code HTML renvoyé dans la réponse a montré qu'il s'agissait de la page 404 par défaut du site Web (Figure 12). Cette situation est déroutante et nous a amenés à nous demander si le skimmer n'était plus actif sur les sites Web des victimes que nous avions trouvés.
Figure 11 : Requête initiée par le chargeur vers un chemin inexistant qui renvoie l'erreur 404
Figure 12 : Page d'erreur HTML par défaut
Ne jamais sous-estimer le chargeur
Nous avons pris du recul, réanalysé le chargeur et trouvé la pièce manquante du puzzle. Le chargeur contenait une correspondance d'expression régulière pour la chaîne "COOKIE_ANNOT", qui était censée être exécutée sur la page d'erreur 404 renvoyée dans le cadre de la demande d'icônes.
Nous avons donc recherché cette chaîne dans le code HTML 404 renvoyé. C'est là que nous avons découvert un commentaire caché vers la fin de la page qui contenait la chaîne "COOKIE_ANNOT" (Figure 14). À côté de cette chaîne, une longue chaîne encodée en Base64 a été concaténée. Elle représente l'intégralité du code d'attaque JavaScript brouillé. Le chargeur extrait cette chaîne du commentaire, la décode et exécute l'attaque, qui est conçue pour voler les informations personnelles saisies par les utilisateurs.
Nous avons simulé d'autres requêtes vers des chemins inexistants, et toutes ont renvoyé la même page d'erreur 404 contenant le commentaire avec le code malveillant encodé. Ces vérifications confirment que le pirate a réussi à modifier la page d'erreur par défaut de l'ensemble du site Web et à y dissimuler le code malveillant !
Figure 13 : Variante 3 du chargeur – Correspondance des expressions régulières pour la chaîne "COOKIE_ANNOT".
Figure 14 : Le commentaire codé malveillant masqué dans la page d'erreur HTML
Extraction de données
Faux formulaire
Contrairement aux variantes 1 et 2, les attaquants ont utilisé une technique d'exfiltration de données commune différente dans la variante 3 : l'injection d'un faux formulaire (Figure 15). Cette technique est généralement utilisée lorsque le skimmer n'a pas accès aux données sensibles.
Cela peut se produire lorsqu'un site Web utilise un service de paiement tiers qui implémente le formulaire de paiement dans une iframe tierce ou une page externe. Pour contourner de tels scénarios, l'attaquant crée un faux formulaire qui ressemble étroitement au formulaire de paiement original et le recouvre. Cette technique gagne en popularité. C'est exactement de cette manière que les données volées sont exfiltrées dans la variante 3.
Figure 15 : Le faux formulaire injecté par le code malveillant
Lorsque l'utilisateur soumet ses données dans le faux formulaire de l'attaquant, une erreur est affichée et le faux formulaire est masqué, le formulaire de paiement d'origine s'affiche et l'utilisateur est invité à saisir à nouveau ses données de paiement (Figure 16).
Figure 16 : Le faux formulaire est masqué et l'utilisateur est invité à saisir à nouveau ses informations
Demande d'image avec des données volées
L'envoi du faux formulaire déclenche une requête de réseau d'images vers le serveur C2 de l'attaquant, qui contient toutes les informations personnelles et de carte de crédit volées sous la forme d'une chaîne codée en Base64 dans le paramètre de la requête (Figure 17). Une fois décodée, cette chaîne révèle la véritable intention de la requête et le déroulement complet de l'attaque devient clair.
Figure 17 : Requête de réseau d'images avec les données volées incluses en tant que paramètre de requête de chaîne codée en Base64
Leçons tirées de la variante 3 : Le cas 404
Cette technique de dissimulation est très innovante et n'a jamais été utilisée dans les campagnes Magecart précédentes. L'idée de manipuler la page d'erreur 404 par défaut d'un site Web ciblé peut offrir aux acteurs de Magecart diverses options créatives pour améliorer la dissimulation et l'évasion.
Dans certains des cas que nous avons identifiés, le chargeur malveillant avait déjà été supprimé des pages des sites Web concernés au moment de la rédaction du présent rapport. Cependant, le commentaire malveillant de la page 404 par défaut est resté, permettant potentiellement au skimmer de réactiver facilement l'attaque. Cela met en évidence la complexité de la détection de cette approche et l'importance de l'atténuer.
La requête vers le chemin d'accès de première partie menant à la page 404 est une autre technique d'évasion qui peut contourner les en-têtes de la stratégie de sécurité du contenu et d'autres mesures de sécurité qui peuvent analyser activement les requêtes réseau sur la page. Il s'agit sans aucun doute de l'une des stratégies Magecart les plus sophistiquées que nous ayons rencontrées récemment.
Comparaison entre la solution Client-side Protection & Compliance d'Akamai et le skimmer
Dans le cadre de nos recherches sur cette campagne, nous avons effectué une simulation de ce skimmer par rapport à la solution Client-Side Protection & Compliance d'Akamai,notre solution qui analyse le comportement d'exécution de JavaScript pour se défendre contre les menaces JavaScript et atténuer les attaques côté client.
La solution a détecté avec succès le skimmer sophistiqué et a déclenché un événement de haute gravité pour une atténuation immédiate. Dans un scénario réel où la solution Client-Side Protection & Compliance est activée sur une page Web spécifique, la Figure 18 illustre l'alerte que recevrait le propriétaire du site Web afin qu'il puisse examiner rapidement la menace et réagir en temps réel en proposant diverses options d'atténuation.
Figure 18 : Alerte de simulation Client-Side Protection & Compliance après la détection du skimmer
Conclusion
Cette campagne renforce le fait que les techniques de Web skimming sont en constante évolution. Elles sont de plus en plus sophistiquées, ce qui rend la détection et l'atténuation par l'analyse statique et externe de plus en plus difficiles. Les auteurs de menaces dans ce domaine trouvent constamment des méthodes plus efficaces pour dissimuler leurs attaques sur les sites Web des victimes et échapper aux différentes mesures de sécurité.
Le niveau de complexité mis en évidence dans cette étude devrait inciter les organisations à rester vigilantes et attentives aux vecteurs d'attaque de Web skimming et à rechercher activement des approches nouvelles et avancées pour faire face à ces types d'attaques.
Indicateurs d'infection
Pmdresearch[.]com
secures-tool[.]com
adsometric[.]com
cngresearch[.]com
