Four JavaScript Sniffer That Will Show How Careful You Should Be With Online Purchasing!

Four JavaScript Sniffer That Will Show How Careful You Should Be With Online Purchasing!

Practically each of us uses the services of online stores, which means, sooner or later, the risk of becoming a victim of JavaScript sniffers – a special code that the attackers introduce to the site to steal bank card data, addresses, usernames, and passwords.

Almost 400,000 users of the site and the mobile application of British Airways, as well as visitors to the British site of the sports giant FILA and the American ticket distributor Ticketmaster, have already suffered from sniffers.

Threat Intelligence Group-IB analyst Viktor Okorokov talks about how sniffers are embedded in the site code and steal billing information, as well as what kind of CRM they attack.

Hidden threat

So it turned out that for a long time JS-sniffers remained out of sight of antivirus analysts, and banks and payment systems did not see them as a serious threat. And it is in vain. Group-IB experts analyzed 2440 infected online stores, whose visitors — a total of about 1.5 million people a day — were at risk of compromise. Among the victims were not only users but also online stores, payment systems and banks that issued compromised cards.

The Group-IB report was the first to study the darknet market of sniffers, their infrastructure and ways to monetize, bringing millions of dollars to their creators. We identified 38 families of sniffers, of which only 12 were previously known to researchers.

Let us dwell in detail on the four families of sniffers studied in the course of the study.

ReactGet Family

ReactGet family sniffers are used to stealing bank card data on online stores. The sniffer can work with a large number of different payment systems used on the site: one parameter value corresponds to one payment system, and some detected versions of the sniffer can be used to steal credentials, as well as to steal bank card data from payment forms of several payment systems at once, the so-called universal sniffer. It was found that in some cases, attackers carry out phishing attacks on administrators of online stores in order to gain access to the administrative panel of the site.

The campaign with the use of this family of sniffers began in May 2017, the sites under the control of CMS and platforms Magento, Bigcommerce, Shopify were attacked.

How ReactGet is embedded in an online store code

In addition to the “classic” implementation of the script by reference, the operators of the ReactGet family of sniffers use a special technique: using JavaScript code, it is checked whether the current address where the user is located meets certain criteria. Malicious code will be run only if the current URL contains the substring checkout or onestepcheckout, onepage/out/onepag, checkout/one, ckout/one. Thus, the sniffer code will be executed exactly at the moment when the user goes to pay for purchases and enters payment information in the form on the website.

This sniffer uses the non-standard technique. The victim’s payment and personal data are gathered together, encoded with base64, and then the resulting string is used as a parameter to send a request to the attacker’s website. Most often, the path to the gate imitates a JavaScript file, for example, resp.js, data.js, and so on, but also links to image files, GIF and JPG are used. The peculiarity is that the sniffer creates a 1 by 1-pixel image object and uses the previously obtained link as the image src parameter. That is, for a user, such a request in traffic will look like an ordinary picture request. A similar technique was used in ImageID sniffers. In addition, a 1 by 1-pixel image technique is used in many legitimate online analytics scripts, which can also mislead the user.

Version Analysis

Analysis of the active domains used by ReactGet sniffer operators allowed us to discover many different versions of sniffer of this family. Versions are distinguished by the presence or absence of obfuscation, and in addition, each sniffer is intended for a specific payment system that processes bank card payments for online stores. After reviewing the value of the parameter corresponding to the version number, Group-IB specialists received a full list of available variations of sniffers and the names of the form fields that each sniffer searches for in the page code determine the payment systems that the sniffer aims at.

Password Sniffers

One of the advantages of JavaScript sniffer working on the client side of the site is universality: the malicious code embedded on the site can steal data of any type, whether it is billing information or username and password from a user account. Group-IB specialists have discovered a sample sniffer belonging to the ReactGet family, designed to steal email addresses and passwords of users of the site.

Intersection with ImageID sniffer

An analysis of one of the infected stores revealed that his site had been infected twice: in addition to the malicious code of the ReactGet family sniffer, the code of the ImageID family sniffer was detected. This intersection may be evidence that the operators behind the use of both sniffers use similar techniques to introduce malicious code.

Universal Sniffer

An analysis of one of the domain names related to the infrastructure of ReactGet sniffers revealed that the same user registered three other domain names. These three domains imitated the domains of real-life sites and were previously used to host sniffers. When analyzing the code of three legitimate sites, an unknown sniffer was discovered, and further analysis showed that this is an improved version of the ReactGet sniffer. All previously tracked versions of sniffers of this family were aimed at any one payment system, that is, for each payment system a special version of the sniffer was required. However, in this case, a universal version of the sniffer was discovered, capable of stealing information from forms related to 15 different payment systems and e-commerce site modules for online payments.

So, at the beginning of the work, the sniffer searched for basic form fields containing the victim’s personal information: full name, physical address, telephone number.

Then the sniffer searched for more than 15 different prefixes corresponding to different payment systems and modules for online payments.

Then, the victim’s personal data and payment information were collected together and sent to the site controlled by the attacker: in this particular case, two versions of the universal ReactGet sniffer were found, located on two different hacked sites. However, both versions sent the stolen data to the same hacked zoobashop.com website.

The analysis of the prefixes that were used by the sniffer to search for fields containing the payment information of the victim made it possible to determine that this sample of the sniffer was aimed at the following payment systems:

  • Authorize.Net
  • Verisign
  • First data
  • USAePay
  • Stripe
  • Paypal
  • ANZ eGate
  • Braintree
  • DataCash (MasterCard)
  • Realex payments
  • Psigate
  • Heartland Payment Systems

What tools are used to steal billing information

The first tool found during the analysis of the infrastructure of the attackers serves to obfuscate malicious scripts responsible for the theft of bank cards. A bash script was discovered on one of the attacker’s hosts, using the CLI of the javascript-obfuscator project to automate the obfuscation of sniffer code.

The second detected tool is designed to generate the code responsible for loading the main sniffer. This tool generates a JavaScript code that checks whether the user is on the payment page by searching the current address of the user for checkout, cart, and so on, and if the result is positive, then the code loads the main sniffer from the attacker’s server. To hide malicious activity, all lines, including test lines for defining the payment page, as well as a link to the sniffer, are encoded with base64.

Phishing attacks

In analyzing the network infrastructure of the attackers, it was found that the criminal group often uses phishing to gain access to the administrative panel of the targeted online store. The attackers register a domain that is visually similar to the domain of the store and then unfolds on it a fake login form of the Magento administrative panel. If successful, attackers will gain access to the CMS Magento administrative panel, which allows them to edit the site components and implement a sniffer to steal credit card data.

G-Analytics Family

This family of sniffers is used to steal cards from online store customers. The very first domain name used by the group was registered in April 2016, which may indicate the start of group activity in mid-2016.

In the current campaign, the group uses domain names that mimic real-life services, such as Google Analytics and jQuery, masking sniffer activity with legitimate scripts and similar legitimate domain names. Attack suffered sites running CMS Magento.

How G-Analytics is embedded in the code of an online store

A distinctive feature of this family is the use of various methods of stealing the user’s payment information. In addition to the classic implementation of JavaScript code in the client part of the site, the criminal group also used the technique of introducing code into the server part of the site, namely PHP scripts that process user input. This technique is dangerous in that it makes it difficult for third-party researchers to detect malicious code. Group-IB specialists discovered a version of a sniffer embedded in the site’s PHP code, using dittm.org as the gate.

An early version of the sniffer was also found, using the same dittm.org domain to collect stolen data, but this version is already intended for installation on the client side of the online store.

Later, the group changed its tactics and began to pay more attention to the concealment of malicious activity and disguise.

In early 2017, the group began to use the domain jquery-js.com, disguised as a CDN for jQuery: when you go to the site of malicious users, the user redirects to the legitimate site jquery.com.

And in mid-2018, the group adopted the domain name g-analytics.com and began to disguise the activity of the sniffer under the legitimate Google Analytics service.

Version Analysis

During the analysis of domains used for storing sniffer code, it was found that the site contains a large number of versions that differ in the presence of obfuscation, as well as in the presence or absence of unreachable code added to the file to divert attention and hide the malicious code.

A total of six versions of sniffers were identified on jquery-js.com. These sniffers send stolen data to the address located on the same site as the sniffer itself: 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

The later domain g-analytics.com, used by the group in attacks since mid-2018, serves as a repository for more sniffers. A total of 16 different versions of the sniffer were found. In this case, the gate for sending stolen data was masked as a link to a GIF image: 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

Monetization of stolen data

The criminal group monetizes stolen data by selling cards through a specially created underground store that provides services to carders. Analysis of the domains used by the attackers made it possible to determine that google-analytics.cm was registered by the same user as the cardz.vc domain. Domain cardz.vc belongs to the store for the sale of stolen bank cards Cardsurfs (Flysurfs), which gained popularity even during the time of activity of the underground marketplace AlphaBay as a store selling bank cards that were stolen using a sniffer.

Analyzing the analytic.is domain located on the same server as the domains used by sniffers to collect stolen data, Group-IB experts discovered a file containing the cookie-stiller logs, which, it seems, was later abandoned by the developer. One of the records in the log contained the domain iozoz.com, which was previously used in one of the sniffers active in 2016. Presumably, this domain was previously used by the attacker to collect cards stolen with the help of a sniffer. This domain was registered at the email address kts241@gmail.com, which was also used to register the cardz.su and cardz.vc domains related to the card store Cardsurfs.

Based on the data obtained, it can be assumed that the G-Analytics family of sniffers and the underground store selling Cardsurfs bank cards are managed by the same people, and the store is used to sell bank cards stolen using a sniffer.

Illum family

Illum is a family of sniffers used to attack online stores running CMS Magento. In addition to introducing malicious code, the operators of this sniffer also use the introduction of full fake payment methods that send data to gates controlled by the attackers.

When analyzing the network infrastructure used by the operators of this sniffer, a large number of malicious scripts, exploits, fake payment forms, as well as a collection of examples with malicious competitor sniffers were noted. Based on the information about the dates of appearance of domain names used by the group, it can be assumed that the campaign began at the end of 2016.

How Illum is embedded in the online store code

The first detected versions of the sniffer were introduced directly into the code of the compromised site. The stolen data was sent to cdn.illum [.] Pw / records.php, the gate was encoded using base64.

Later, a packaged version of the sniffer was discovered using another gate – records.nstatistics [.] Com / records.php.

According to the report of Willem de Groot, the same host was used in the sniffer, which was introduced to the site of a store owned by the German political party CSU.

Analysis of the site intruders

Group-IB specialists discovered and analyzed the site used by this criminal group for storing tools and collecting stolen information.

Among the tools found on the attackers’ server were found scripts and exploits to enhance privileges in Linux: for example, Linux Privilege Escalation Check Script, developed by Mike Chumak (Mike Czumak), as well as an exploit for CVE-2009-1185.

The attackers used two exploits directly to attack online stores: the first is able to inject malicious code into core_config_data using CVE-2016-4010, the second exploit an RCE vulnerability in CMS Magento plug-ins, allowing it to execute arbitrary code on a vulnerable web server.

Also during the analysis of the server, various samples of sniffers and fake payment forms used by hackers to collect payment information from hacked sites were discovered. As you can see from the list below, some scripts were created individually for each hacked site, while for certain CMS and payment gateways a universal solution was used. For example, the segapay_standart.js and segapay_onpage.js scripts are intended for deployment to sites that use the Sage Pay payment gateway.

List of scripts for various payment gateways
The paymentnow [.] Tk host, used as a gate in the payment_forminsite.js script, was detected as subjectAltName in several certificates related to the CloudFlare service. In addition, the host was a script evil.js. Judging by the name of the script, it could be used within the framework of operating CVE-2016-4010, thanks to which you can inject malicious code into the footer of the site running CMS Magento. As a gate, this script used the request.requestnet [.] Tk host, using the same certificate as the paymentnow [.] Tk host.

Fake Payment Forms

The figure below shows an example of a form for entering map data. This form was used to embed an online store site and steal card data.

The following figure is an example of a fake PayPal payment form that was used by attackers to deploy to sites with this payment method.

CoffeMokko Family

The family of sniffers CoffeMokko, designed to steal bank cards of users of online stores, has been in use since at least 2017. Presumably, the operators of this family of sniffers are the criminal group Group 1, described by RiskIQ experts in 2016. Sites running CMS such as Magento, OpenCart, WordPress, osCommerce, Shopify have been attacked.

How CoffeMokko is embedded in the code of the online store

Operators of this family create unique sniffers for each infection: the sniffer file is located in the src or js directory on the attacker’s server. The implementation of the site code is carried out by a direct link to the sniffer.

In the code of the sniffer, the names of the form fields from which the data should be stolen are hard-coded. Also, the sniffer checks if the user is on the payment page, checking the list of keywords with the current address of the user.

Some detected versions of the sniffer were obfuscated and contained an encrypted string in which the main array of resources was stored: it contained the names of the form fields for various payment systems, as well as the gateway address to which the stolen data should be sent.

The stolen billing information was sent to a script on the attacker’s server along the path /savePayment/index.php or /tr/index.php. Presumably, this script is used to send data from the gate to the main server, which consolidates data from all sniffers. To hide the transmitted data, all of the victim’s payment information is encoded with base64, and then several character replacements occur:

the symbol "e" is replaced by ":"
the symbol “w” is replaced by “+”
the symbol “o” is replaced by “%”
the symbol “d” is replaced by “#”
the symbol "a" is replaced by "-"
the symbol "7" is replaced by "^"
“h” is replaced by “_”
the symbol "T" is replaced by "@"
the character "0" is replaced by "/"
the symbol "Y" is replaced by "*"

As a result of the replacement of characters, base64-encoded data cannot be decoded without performing the inverse transform.

This is a sniffer code snippet that has not been obfuscated:

Infrastructure analysis

In the early campaigns, the attackers registered domain names similar to the domains of legitimate online shopping sites. Their domain could differ from the legitimate one symbol or another TLD. Registered domains were used to store the sniffer code, the link to which was embedded in the store code.

This group also used domain names resembling the name of popular plugins for jQuery (slickjs [.] Org for sites using the slick.js plugin), payment gateways (sagecdn [.] Org for sites using the Sage Pay payment system).

Later, the group began to create domains whose name had nothing to do with the store domain or the store theme.

Each domain has a corresponding website where the / js or / src directory was created. Sniffer scripts were stored in this directory: one sniffer for each new infection. Sniffer was injected into the site code for a direct link, but in rare cases, attackers modified one of the site files and added malicious code to it.

Code analysis

First obfuscation algorithm

In some detected samples of sniffers of this family, the code was obfuscated and contained encrypted data necessary for the sniffer to work: in particular, the gateway address of the sniffer, the list of fields of the payment form, and in some cases the code of the fake payment form. In the code inside the function, the resources were encrypted using XOR by the key, which was passed by the argument of the same function.

Having decrypted a string with a corresponding key, unique for each sample, it is possible to obtain a string containing all the lines from the sniffer code through a separator character.

Second obfuscation algorithm

In the later samples of sniffers of this family, another obfuscation mechanism was used: in this case, the data were encrypted using a self-written algorithm. The string containing the encrypted data necessary for the operation of the sniffer was passed as an argument to the decryption function.

Using the browser console, you can decrypt the encrypted data and get an array containing sniffer resources.

Link to early MageCart attacks

In the analysis of one of the domains used by the group as a gate for collecting stolen data, it was found that the infrastructure for theft of credit cards, identical to that used by Group 1, is one of the first groups discovered by RiskIQ specialists.

Two files were found on the host of the CoffeMokko sniffer family:

  • mage.js – file containing the sniffer code of Group 1 with the gate address js-cdn.link
  • mag.php – PHP script responsible for collecting stolen data sniffer

It was also found that the earliest domains used by the group behind the CoffeMokko family of sniffers were registered on May 17, 2017:

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

The format of these domain names coincides with the domain names of Group 1, which were used in the 2016 attacks.

On the basis of the facts discovered, it can be assumed that there is a connection between the operators of the CoffeMokko sniffers and the criminal group Group 1. Presumably, CoffeMokko operators could borrow tools and software for card theft from their predecessors. However, it is more likely that the criminal group behind the use of CoffeMokko family sniffers is the same people who carried out the attacks as part of Group 1. After the first report on the activities of the criminal group was published, all their domain names were blocked, are described. The group was forced to take a break, modify its internal tools and rewrite the code of the sniffers in order to continue their attacks and go unnoticed.