Quatre sniffeurs JavaScript qui vous guettent dans les boutiques en ligne

Pratiquement chacun d'entre nous utilise les services de magasins en ligne, ce qui signifie qu'il risque tôt ou tard de devenir la victime de sniffeurs JavaScript — un code spécial que les malfaiteurs intègrent sur un site pour voler des données de cartes bancaires, des adresses, des identifiants et des mots de passe des utilisateurs.

Près de 400 000 utilisateurs du site et de l'application mobile de la compagnie aérienne British Airways, ainsi que les visiteurs du site britannique du géant sportif FILA et du distributeur américain de billets Ticketmaster, ont déjà souffert des sniffeurs. PayPal, Chase Paymenttech, USAePay, Moneris — ces systèmes de paiement et bien d'autres ont été compromis.

L'analyste de Threat Intelligence Group-IB, Viktor Okorokov, explique comment les sniffeurs s'intègrent dans le code d'un site et volent des informations de paiement, ainsi que quels CRM ils ciblent.

« Menace cachée »

Il se trouve que pendant longtemps, les sniffeurs JS sont restés en dehors du radar des analystes antivirus, et les banques et systèmes de paiement ne les considéraient pas comme une menace sérieuse. Et c'est complètement en vain. Les experts de Group-IB ont analysé 2440 magasins en ligne contaminés, dont les visiteurs — environ 1,5 million de personnes par jour — étaient exposés à un risque de compromission. Parmi les victimes se trouvaient non seulement des utilisateurs, mais aussi des magasins en ligne, des systèmes de paiement et des banques ayant émis des cartes compromises.

Rapport Group-IB a été la première étude sur le marché darknet des sniffeurs, leur infrastructure et les méthodes de monétisation rapportant des millions de dollars à leurs créateurs. Nous avons identifié 38 familles de sniffeurs, dont seulement 12 étaient connues des chercheurs auparavant.

Concentrons-nous en détail sur quatre familles de sniffeurs étudiées durant l'enquête.

Famille ReactGet

Les sniffeurs de la famille ReactGet sont utilisés pour voler des données de cartes bancaires sur des sites de commerce en ligne. Un sniffer peut fonctionner avec de nombreux systèmes de paiement différents utilisés sur le site : une valeur de paramètre correspond à un système de paiement, et certaines versions détectées du sniffer peuvent être utilisées pour voler des identifiants, ainsi que pour dérober des données de cartes bancaires à partir des formulaires de paiement de plusieurs systèmes de paiement, ce que l'on appelle un sniffer universel. Il a été établi que dans certains cas, les attaquants mènent des attaques de phishing contre les administrateurs des magasins en ligne dans le but d'accéder au panneau d'administration du site.

La campagne utilisant cette famille de sniffeurs a débuté en mai 2017, et les sites de gestion CMS et les plateformes Magento, Bigcommerce, Shopify ont été attaqués.

Comment ReactGet s'intègre dans le code d'un magasin en ligne

En plus de l'injection « classique » du script via un lien, les opérateurs des sniffeurs de la famille ReactGet utilisent une technique particulière : grâce à un code JavaScript, ils vérifient si l'adresse actuelle à laquelle l'utilisateur se trouve respecte certains critères. Le code malveillant ne sera exécuté que si la sous-chaîne correspond à l'URL actuelle checkout ou onestepcheckout, onepage/, out/onepag, checkout/one, ckout/one. Ainsi, le code du sniffer s'exécutera au moment où l'utilisateur passera à la page de paiement et saisira les informations de paiement dans le formulaire sur le site.

Ce sniffer utilise une technique non standard. Les données de paiement et personnelles de la victime sont collectées ensemble, encodées à l'aide de base64, puis la chaîne obtenue est utilisée comme paramètre pour envoyer une requête au site des malfaiteurs. Le plus souvent, le chemin vers le portail imite un fichier JavaScript, par exemple resp.js, data.js et ainsi de suite, mais des liens vers des fichiers images sont également utilisés, GIF et JPG. La particularité est que le sniffer crée un objet image de taille 1 par 1 pixel et utilise le lien obtenu précédemment comme paramètre. src images. Cela signifie qu'une telle requête pour l'utilisateur apparaîtra comme une demande d'image ordinaire. Une technique similaire a été utilisée dans les sniffeurs de la famille ImageID. De plus, la technique utilisant une image de 1 sur 1 pixel est appliquée dans de nombreux scripts d'analyse en ligne légitimes, ce qui peut également induire l'utilisateur en erreur.

Analyse des versions

L'analyse des domaines actifs utilisés par les opérateurs de sniffeurs ReactGet a permis de découvrir de nombreuses versions différentes de ces sniffeurs. Les versions diffèrent par la présence ou l'absence d'obfuscation, et de plus, chaque sniffeur est destiné à un système de paiement spécifique qui traite les paiements par carte bancaire pour les magasins en ligne. En parcourant la valeur du paramètre correspondant au numéro de version, les spécialistes de Group-IB ont obtenu une liste complète des variations de sniffeurs disponibles, et en examinant les noms des champs de formulaire que chaque sniffeur recherche dans le code de la page, ils ont déterminé les systèmes de paiement ciblés par le sniffeur.

Liste des sniffeurs et des systèmes de paiement correspondants

Sniffeur de mots de passe

L'un des avantages des sniffeurs JavaScript fonctionnant côté client est leur universalité : le code malveillant intégré sur le site peut voler des données de tout type, qu'il s'agisse de données de paiement ou de connexions et mots de passe de comptes utilisateurs. Les spécialistes de Group-IB ont découvert un exemple de sniffeur appartenant à la famille ReactGet, destiné à voler les adresses e-mail et les mots de passe des utilisateurs du site.

Intersection avec le sniffeur ImageID

Lors de l'analyse d'une des boutiques infectées, il a été établi que son site avait été infecté deux fois : en plus du code malveillant du sniffeur de la famille ReactGet, un code du sniffeur de la famille ImageID a été découvert. Cette inter-connexion peut être un témoignage du fait que les opérateurs responsables de l'utilisation des deux sniffeurs appliquent des techniques similaires pour injecter du code malveillant.

Sniffeur universel

Lors de l'analyse d'un des noms de domaine appartenant à l'infrastructure des sniffeurs ReactGet, il a été établi que le même utilisateur avait enregistré trois autres noms de domaine. Ces trois domaines imitaient des domaines de sites réellement existants et avaient été précédemment utilisés pour héberger des sniffeurs. L'analyse du code de trois sites légitimes a révélé un sniffeur inconnu, et une analyse plus approfondie a montré qu'il s'agissait d'une version améliorée du sniffeur ReactGet. Toutes les versions précédemment suivies de ce type de sniffeurs ciblaient un système de paiement spécifique, c'est-à-dire qu'une version spéciale de sniffeur était nécessaire pour chaque système de paiement. Cependant, dans ce cas, une version universelle du sniffeur a été découverte, capable de voler des informations à partir de formulaires relatives à 15 systèmes de paiement différents et modules de sites de commerce électronique pour effectuer des paiements en ligne.

Ainsi, au début de son fonctionnement, le sniffeur recherchait des champs de formulaire basiques contenant des informations personnelles de la victime : nom complet, adresse physique, numéro de téléphone.

Puis, le sniffeur recherchait à travers plus de 15 préfixes différents correspondant aux divers systèmes de paiement et modules pour les paiements en ligne.

Ensuite, les données personnelles de la victime et les informations de paiement étaient rassemblées et envoyées vers un site contrôlé par l'attaquant : dans ce cas précis, deux versions du sniffeur universel ReactGet ont été découvertes, situées sur deux sites piratés différents. Cependant, les deux versions envoyaient les données volées vers le même site piraté. zoobashop.com.

L'analyse des préfixes utilisés par le sniffeur pour rechercher des champs contenant les informations de paiement de la victime a permis de déterminer que cet échantillon de sniffeur était ciblé sur les systèmes de paiement suivants :

• Authorize.Net
• Verisign
• First Data
• USAePay
• Stripe
• PayPal
• ANZ eGate
• Braintree
• DataCash (MasterCard)
• Realex Payments
• PsiGate
• Heartland Payment Systems

Quels outils sont utilisés pour voler les informations de paiement

Le premier outil découvert lors de l'analyse de l'infrastructure des attaquants sert à obfusquer des scripts malveillants chargés de voler des cartes bancaires. Sur l'un des hôtes des attaquants, un script bash utilisant la CLI du projet a été trouvé. javascript-obfuscator pour automatiser l'obfuscation du code des sniffeurs.

Le deuxième outil détecté est destiné à générer le code chargé du sniffer principal. Cet outil génère du code JavaScript qui vérifie si l'utilisateur se trouve sur la page de paiement en recherchant dans l'adresse actuelle de l'utilisateur des chaînes checkout, panier et ainsi de suite, et si le résultat est positif, le code charge le sniffer principal depuis le serveur des attaquants. Pour dissimuler l'activité malveillante, toutes les chaînes, y compris les chaînes de test pour déterminer la page de paiement, ainsi que le lien vers le sniffer, sont codées à l'aide de base64.

Attaques de phishing

Au cours de l'analyse de l'infrastructure réseau des attaquants, il a été établi que souvent pour accéder au panneau d'administration de la boutique en ligne ciblée, un groupe criminel utilise le phishing. Les attaquants enregistrent un domaine visuellement similaire à celui de la boutique, puis déploient un faux formulaire de connexion au panneau d'administration Magento. En cas de succès, les attaquants auront accès au panneau d'administration du CMS Magento, ce qui leur permettra de modifier les composants du site et d'implémenter un sniffer pour voler des données de cartes de crédit.

Infrastructure

Famille G-Analytics

Cette famille de sniffers est utilisée pour voler les cartes des clients des boutiques en ligne. Le tout premier nom de domaine utilisé par le groupe a été enregistré en avril 2016, ce qui peut indiquer le début des activités du groupe au milieu de l'année 2016.

Dans la campagne actuelle, le groupe utilise des noms de domaine imitant de véritables services, tels que Google Analytics et jQuery, masquant l'activité des sniffers derrière des scripts légitimes et des noms de domaine ressemblant à des noms légitimes. Des sites fonctionnant sous CMS Magento ont été attaqués.

Comment G-Analytics est intégré dans le code de la boutique en ligne

La caractéristique distinctive de cette famille est l'utilisation de différentes méthodes pour voler les informations de paiement des utilisateurs. En plus de l'insertion classique de code JavaScript dans la partie cliente du site, le groupe criminel a également utilisé la technique d'insertion de code dans la partie serveur du site, à savoir des scripts PHP qui traitent les données saisies par les utilisateurs. Cette technique est dangereuse car elle complique la détection du code malveillant par des chercheurs externes. Les spécialistes de Group-IB ont découvert une version d'un sniffer inséré dans le code PHP du site, utilisant comme passerelle le domaine dittm.org.

Une version antérieure du sniffer a également été découverte, utilisant le même domaine pour collecter des données volées dittm.org, mais cette version est destinée à être installée sur la partie cliente du magasin en ligne.

Plus tard, le groupe a modifié sa tactique et a commencé à prêter davantage attention à la dissimulation de l'activité malveillante et à l'irréductibilité.

Au début de 2017, le groupe a commencé à utiliser le domaine jquery-js.com, se déguisant en CDN pour jQuery : lors de la visite du site des malfaiteurs, l'utilisateur est redirigé vers le site légitime jquery.com.

Et au milieu de 2018, le groupe a adopté le nom de domaine g-analytics.com et a commencé à déguiser l'activité du sniffer en un service légitime de Google Analytics.

Analyse des versions

Lors de l'analyse des domaines utilisés pour stocker le code des sniffers, il a été établi qu'il y avait un grand nombre de versions sur le site, qui diffèrent par la présence d'obfuscation, ainsi que par la présence ou l'absence de code inaccessibilité ajouté au fichier pour détourner l'attention et cacher le code malveillant.

Au total, sur le site jquery-js.com six versions de sniffers ont été identifiées. Les données volées sont envoyées à une adresse située sur le même site que le sniffer lui-même : hxxps://jquery-js[.]com/latest/jquery.min.js:

• hxxps://jquery-js[.]com/jquery.min.js
• hxxps://jquery-js[.]com/jquery.2.2.4.min.js
• hxxps://jquery-js[.]com/jquery.1.8.3.min.js
• hxxps://jquery-js[.]com/jquery.1.6.4.min.js
• hxxps://jquery-js[.]com/jquery.1.4.4.min.js
• hxxps://jquery-js[.]com/jquery.1.12.4.min.js

Un domaine plus récent g-analytics.com, utilisé par le groupe dans des attaques depuis le milieu de 2018, sert de stockage pour un plus grand nombre de sniffers. Un total de 16 versions différentes du sniffer a été découvert. Dans ce cas, la passerelle pour l'envoi des données volées était masquée sous un lien vers une image au format GIF: hxxp://g-analytics[.]com/__utm.gif?v=1&_v=j68&a=98811130&t=pageview&_s=1&sd=24-bit&sr=2560×1440&vp=2145×371&je=0&_u=AACAAEAB~&jid=1841704724&gjid=877686936&cid
=1283183910.1527732071:

• hxxps://g-analytics[.]com/libs/1.0.1/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.10/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.11/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.12/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.13/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.14/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.15/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.16/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.3/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.4/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.5/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.6/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.7/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.8/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.9/analytics.js
• hxxps://g-analytics[.]com/libs/analytics.js

Monétisation des données volées

Le groupe criminel monétise les données volées en vendant des cartes via un magasin clandestin spécialement créé, offrant des services aux carders. L'analyse des domaines utilisés par les attaquants a permis de déterminer que google-analytics.cm a été enregistré par le même utilisateur que le domaine cardz.vc. Domaine cardz.vc se réfère au magasin de vente de cartes bancaires volées Cardsurfs (Flysurfs), qui est devenu populaire à l’époque de l’activité de la place de marché souterraine AlphaBay comme un magasin de vente de cartes bancaires volées via un sniffer.

En analysant le domaine analytic.is, situé sur le même serveur que les domaines utilisés par les sniffers pour collecter des données volées, les spécialistes de Group-IB ont découvert un fichier contenant des journaux de Cookie-stiller, qui semble avoir été abandonné par le développeur par la suite. Une des entrées du journal contenait le domaine iozoz.com, qui avait été utilisé auparavant dans un des sniffers actifs en 2016. Ce domaine aurait été précédemment utilisé par un attaquant pour collecter des cartes volées via un sniffer. Ce domaine a été enregistré avec l'adresse email kts241@gmail.com, qui a également été utilisée pour enregistrer les domaines cardz.su et cardz.vc, liés au magasin de carding Cardsurfs.

D'après les données obtenues, on peut supposer que la famille de sniffers G-Analytics et le magasin souterrain de vente de cartes bancaires Cardsurfs sont gérés par les mêmes personnes, et que le magasin est utilisé pour la vente de cartes bancaires volées via un sniffer.

Infrastructure

Famille Illum

Illum est une famille de sniffers utilisée pour des attaques sur des magasins en ligne fonctionnant sous CMS Magento. En plus d'injecter du code malveillant, les opérateurs de ce sniffer utilisent également l'injection de fausses formulaires de paiement qui envoient les données à des passerelles contrôlées par des cybercriminels.

Lors de l'analyse de l'infrastructure réseau utilisée par les opérateurs de ce sniffer, un grand nombre de scripts malveillants, d'exploits, de formulaires de paiement falsifiés, ainsi qu'une compilation d'exemples de sniffers malveillants concurrents ont été observés. D'après les informations concernant les dates d'apparition des noms de domaine utilisés par le groupe, on peut supposer que le début de la campagne remonte à la fin de l'année 2016.

Comment Illum s'intègre dans le code du magasin en ligne

Les premières versions découvertes du sniffer étaient intégrées directement dans le code du site compromis. Les données volées étaient envoyées à l'adresse cdn.illum[.]pw/records.php, la passerelle étant codée à l'aide de base64.

Une version empaquetée du sniffer utilisant une autre porte a été découverte plus tard — records.nstatistics[.]com/records.php.

Selon rapport Willem de Groot, le même hôte a été utilisé dans le sniffer qui a été implanté sur le site du magasin, appartenant au parti politique allemand CSU.

Analyse du site des cybercriminels

Les experts de Group-IB ont découvert et analysé le site utilisé par ce groupe criminel pour stocker des outils et collecter des informations volées.

Parmi les outils découverts sur le serveur des cybercriminels, des scripts et exploits pour l'élévation de privilèges sous OS Linux ont été trouvés : par exemple, le script de vérification d'élévation de privilèges Linux, développé par Mike Czumak, ainsi qu'un exploit pour CVE-2009-1185.

Pour les attaques sur les magasins en ligne, les cybercriminels ont utilisé deux exploits : le premier capable d'injecter du code malveillant dans core_config_data en exploitant CVE-2016-4010, le second exploite une vulnérabilité de type RCE dans les plugins pour CMS Magento, permettant d'exécuter du code arbitraire sur le serveur web vulnérable.

Lors de l'analyse du serveur, différents échantillons de sniffers et de faux formulaires de paiement ont également été découverts, utilisés par les cybercriminels pour collecter des informations de paiement sur les sites piratés. Comme on peut le voir dans la liste ci-dessous, certains scripts ont été créés individuellement pour chaque site piraté, tandis qu'une solution universelle a été utilisée pour certains CMS et passerelles de paiement. Par exemple, les scripts segapay_standart.js et segapay_onpage.js sont destinés à être injectés sur des sites utilisant la passerelle de paiement Sage Pay.

Liste des scripts pour différentes passerelles de paiement

Hôte paymentnow[.]tk, utilisé comme porte dans le script payment_forminsite.js, a été découvert comme subjectAltName dans plusieurs certificats liés au service CloudFlare. De plus, un script a été trouvé sur l'hôte evil.js. Selon le nom du script, il pourrait avoir été utilisé dans le cadre de l'exploitation de CVE-2016-4010, permettant d'injecter du code malveillant dans le pied de page d'un site géré par CMS Magento. Comme porte, ce script a été appliqué par l'hôte request.requestnet[.]tk, utilisant le même certificat que l'hôte paymentnow[.]tk.

Formulaires de paiement frauduleux

L'exemple ci-dessous montre un formulaire de saisie des informations de carte. Ce formulaire était utilisé pour une injection sur le site d'un magasin en ligne et pour le vol des données de carte.

L'illustration suivante montre un exemple de faux formulaire de paiement PayPal utilisé par des cybercriminels pour l'injection sur des sites utilisant ce mode de paiement.

Infrastructure

Famille CoffeMokko

La famille de sniffers CoffeMokko, conçue pour voler les informations bancaires des utilisateurs des boutiques en ligne, est utilisée depuis au moins mai 2017. On suppose que les opérateurs de cette famille de sniffers appartiennent à un groupe criminel appelé Group 1, décrit par des spécialistes de RiskIQ en 2016. Les attaques ont ciblé des sites gérés par des CMS tels que Magento, OpenCart, WordPress, osCommerce, Shopify.

Comment CoffeMokko s'injecte dans le code des boutiques en ligne

Les opérateurs de cette famille créent des sniffers uniques pour chaque infection : le fichier du sniffer se trouve dans le répertoire src ou js sur le serveur des cybercriminels. L'injection dans le code du site se fait via un lien direct vers le sniffer.

Le code du sniffer contient de manière fixe les noms des champs du formulaire à partir desquels les données doivent être volées. De plus, le sniffer vérifie si l'utilisateur est sur la page de paiement en comparant une liste de mots-clés avec l'URL actuelle de l'utilisateur.

Certaines versions détectées du sniffer étaient obfusquées et contenaient une chaîne chiffrée où était stocké le tableau principal des ressources : c'est là que se trouvaient les noms des champs des différents systèmes de paiement, ainsi que l'adresse du portail vers lequel les données volées devaient être envoyées.

Les informations de paiement volées étaient envoyées à un script sur le serveur des cybercriminels via le chemin /savePayment/index.php или /tr/index.php. On suppose que ce script sert à transférer les données du portail vers le serveur principal, qui consolide les données de tous les sniffers. Pour camoufler les données envoyées, toutes les informations de paiement de la victime sont cryptées à l'aide de base64, puis plusieurs substitutions de caractères sont effectuées :

• le caractère « e » est remplacé par « : »
• le caractère « w » est remplacé par « + »
• le caractère « o » est remplacé par « % »
• le caractère « d » est remplacé par « # »
• le caractère « a » est remplacé par « - »
• le caractère « 7 » est remplacé par « ^ »
• le caractère « h » est remplacé par « _ »
• le caractère « T » est remplacé par « @ »
• le caractère « 0 » est remplacé par « / »
• le caractère « Y » est remplacé par « * »

Ainsi, les données codées à l'aide de base64 ne peuvent être décodées sans effectuer la transformation inverse.

Voici un extrait de code d'un sniffer qui n'a pas été obfusqué :

Analyse de l'infrastructure

Lors des premières campagnes, les cybercriminels enregistraient des noms de domaine similaires à ceux de sites légitimes de magasins en ligne. Leur domaine pouvait différer du légitime par un seul caractère ou un autre TLD. Les domaines enregistrés étaient utilisés pour héberger le code du sniffer, dont le lien était intégré dans le code du magasin.

De plus, ce groupe utilisait des noms de domaine rappelant le nom de plugins populaires pour jQuery (slickjs[.]org pour les sites utilisant le plugin slick.js), des passerelles de paiement (sagecdn[.]org pour les sites utilisant le système de paiement Sage Pay).

Par la suite, le groupe a commencé à créer des domaines dont les noms n'avaient aucun rapport avec le domaine ou la thématique du magasin.

Chaque domaine correspondait à un site sur lequel un répertoire a été créé /js ou /src. Dans ce répertoire, des scripts de sniffers étaient stockés : un sniffer pour chaque nouvelle infection. Le sniffer était intégré dans le code du site par un lien direct, mais dans de rares cas, les cybercriminels modifiaient un des fichiers du site et y ajoutaient du code malveillant.

Analyse de code

Premier algorithme d'obfuscation

Dans certains échantillons découverts de ce type de sniffer, le code était obfusqué et contenait des données chiffrées nécessaires au fonctionnement du sniffer : en particulier, l'adresse de la porte du sniffer, la liste des champs du formulaire de paiement, et dans certains cas, le code d'un faux formulaire de paiement. Dans le code à l'intérieur de la fonction, les ressources étaient chiffrées à l'aide de XOR avec une clé transmise comme argument de la même fonction.

En déchiffrant la chaîne avec la clé appropriée, unique à chaque échantillon, on peut obtenir une chaîne contenant toutes les chaînes du code du sniffer séparées par un caractère délimiteur.

Deuxième algorithme d'obfuscation

Dans des échantillons plus récents de ce type de sniffer, un autre mécanisme d'obfuscation était utilisé : dans ce cas, les données étaient chiffrées à l'aide d'un algorithme fait maison. La chaîne contenant les données chiffrées nécessaires au fonctionnement du sniffer était transmise comme argument de la fonction de déchiffrement.

En utilisant la console du navigateur, il est possible de déchiffrer les données chiffrées et d'obtenir un tableau contenant des ressources du sniffer.

Lien avec les premières attaques MageCart

Lors de l'analyse d'un des domaines utilisés par le groupe comme porte d'entrée pour collecter des données volées, il a été établi que ce domaine hébergeait une infrastructure destinée au vol de cartes de crédit, identique à celle utilisée par le Groupe 1 — l'un des premiers groupes, découvert par les experts de RiskIQ.

Sur l'hôte de la famille de sniffers CoffeMokko, deux fichiers ont été découverts :

• mage.js — un fichier contenant le code du sniffer Groupe 1 avec l'adresse de porte d'entrée js-cdn.link
• mag.php — un script PHP responsable de la collecte des données volées par le sniffer

Содержимое файла mage.js
Il a également été établi que les premiers domaines utilisés par le groupe derrière la famille de sniffers CoffeMokko ont été enregistrés le 17 mai 2017 :

• link-js[.]link
• info-js[.]link
• track-js[.]link
• map-js[.]link
• smart-js[.]link

Le format de ces noms de domaine correspond à ceux du Groupe 1, utilisés lors des attaques de 2016.

Sur la base des faits découverts, on peut supposer qu'il existe un lien entre les opérateurs des sniffers CoffeMokko et le groupe criminel Groupe 1. Les opérateurs de CoffeMokko auraient pu emprunter aux outils et logiciels de vol de cartes de leurs prédécesseurs. Cependant, il est plus probable que le groupe criminel derrière l'utilisation des sniffers de la famille CoffeMokko soit constitué des mêmes personnes qui ont mené les attaques dans le cadre des activités du Groupe 1. Après la publication du premier rapport sur les activités du groupe criminel, tous leurs noms de domaine ont été bloqués, et les outils ont été étudiés et décrits en détail. Le groupe a été contraint de faire une pause, de retravailler ses outils internes et de réécrire le code des sniffers afin de poursuivre ses attaques et de rester inaperçu.

Infrastructure

Source : habr.com