Four javascript sniffers that trap you in online stores

Almost every one of us uses the services of online stores, which means that sooner or later he risks becoming a victim of JavaScript sniffers - a special code that cybercriminals inject on the site to steal bank card information, addresses, logins and user passwords.

Almost 400,000 users of the website and mobile application of British Airways airline, as well as visitors to the British website of the sports giant FILA and the American ticket distributor Ticketmaster, have already been affected by sniffers.

Threat Intelligence Group-IB analyst Viktor Okorokov talks about how sniffers are embedded in site code and steal billing information, as well as which CRMs they attack.

"Hidden threat"

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 a serious threat in them. And completely in vain. Group-IB experts analyzed 2,440 infected online stores whose visitors — about 1.5 million people a day — were at risk of compromise. Among the victims are not only users, but also online stores, payment systems and banks that issued compromised cards.

The Group-IB report was the first study of the darknet market for sniffers, their infrastructure and ways to monetize, bringing their creators millions of dollars. 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 during the study.

ReactGet Family

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

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

How ReactGet is embedded in online store code

In addition to the “classic” implementation of a script by reference, the ReactGet family of sniffers use a special technique: using JavaScript code, it checks to see if the current address where the user is located meets certain criteria. Malicious code will only be launched 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 proceeds to pay for purchases and enters the payment information into the form on the site.


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

Version Analysis

An analysis of the active domains used by the ReactGet sniffer operators revealed many different versions of the sniffer family. Versions differ in the presence or absence of obfuscation, and in addition, each sniffer is designed for a specific payment system that processes bank card payments for online stores. Having sorted the value of the parameter corresponding to the version number, Group-IB specialists obtained a complete list of available sniffer variations, and by the names of the form fields that each sniffer looks for in the page code, they determined the payment systems that the sniffer is aimed at.

Password sniffer

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

Intersection with ImageID Sniffer

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

Universal sniffer

An analysis of one of the domain names related to the ReactGet sniffer infrastructure revealed that the same user had registered three other domain names. These three domains simulated 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 a single 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 modules of ecommerce sites for online payments.

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


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


Further, 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 ReactGet universal sniffer were found, located on two different hacked sites. However, both versions sent the stolen data to the same hacked site zoobashop.com .


An analysis of the prefixes used by the sniffer to search for the fields containing the victim’s payment information allowed us to determine that this sniffer pattern 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 discovered during the analysis of the attacker's infrastructure is used to obfuscate malicious scripts responsible for stealing bank cards. A bash script was discovered on one of the attacking hosts using the javascript-obfuscator CLI to automate obfuscation of sniffer code.


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

Phishing attacks

When analyzing the network infrastructure of the attackers, it was found that often a criminal group uses phishing to gain access to the administrative panel of the target online store. Attackers register a domain that looks visually similar to a store’s domain, and then deploy a fake Magento admin panel login form on it. If successful, attackers will gain access to the CMS Magento admin panel, which enables them to edit site components and implement a sniffer to steal credit card information.

Семейство G-Analytics

This family of sniffers is used to steal cards from customers of online stores. The very first domain name used by the group was registered in April 2016, which may indicate the beginning of the group's 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 to legitimate domain names. The attack was run on sites running CMS Magento.

How G-Analytics is embedded in online store code

A distinctive feature of this family is the use of various methods of theft of user 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 embedding code in the server part of the site, namely PHP scripts that process the data entered by the user. 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 the dittm.org domain as a gate .


An earlier version of the sniffer was also discovered, which uses 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 concealment of malicious activity and disguise.

At the beginning of 2017, the group began to use the jquery-js.com domain , which masquerades as a CDN for jQuery: when it goes to the site of intruders, the user is redirected to the legitimate site jquery.com .

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

Version Analysis

During the analysis of the domains used to store sniffer code, it was found that the site has a large number of versions that differ by the presence of obfuscation, as well as the presence or absence of unreachable code added to the file to distract attention and hide the malicious code.

In total , six versions of sniffers were identified on jquery-js.com . These sniffers send the 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 g-analytics.com domain , used by the group in attacks since mid-2018, serves as a repository for a larger number of sniffers. A total of 16 different sniffer versions were discovered. In this case, the gate to send the stolen data was disguised 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 = 2560x1440 & vp = 2145x371 & 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

Монетизация украденных данных

The criminal group monetizes the stolen data by selling cards through a specially created underground store that provides services to carders. An analysis of the domains used by the attackers revealed that google-analytics.cm was registered by the same user as the cardz.vc domain . The domain cardz.vc refers to the store selling stolen bank cards Cardsurfs (Flysurfs), which gained popularity even during the activity of the underground trading platform AlphaBay as a store selling bank cards stolen using sniffer.


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

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

Family illum

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

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 of malicious sniffers of competitors were noted. Based on the information about the domain names appearing dates used by the group, it can be assumed that the campaign began at the end of 2016.

How Illum Embeds Online Store Code

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


A packaged version of the sniffer was later discovered using another gate - records.nstatistics [.] Com / records.php .


According to a Willem de Groot report , the same host was used in a sniffer that was embedded on the website of a store owned by the German political party CSU.

Analysis of the site of intruders

Group-IB specialists discovered and analyzed the site used by this criminal group to store tools and collect stolen information.


Among the tools found on the attackers' server, scripts and exploits for escalating privileges on Linux were found: for example, Linux Privilege Escalation Check Script, developed by 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 by exploiting CVE-2016-4010, the second exploits an RCE vulnerability in plug-ins for CMS Magento, allowing arbitrary code to be executed on the vulnerable web server.


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


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 evil.js script was located on the host . Judging by the name of the script, it could be used as part of the operation of CVE-2016-4010, thanks to which it is possible to inject malicious code into the footer of a site running CMS Magento. As a gate, this script used the request.requestnet [.] Tk host, which uses 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 website and steal card data.


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

CoffeMokko Family

The CoffeMokko family of sniffers designed to steal bank cards from users of online stores has been used since at least May 2017. Presumably, the operators of this sniffer family are the criminal group Group 1, described by RiskIQ specialists in 2016. Attacks came under the control of sites running such CMS as Magento, OpenCart, WordPress, osCommerce, Shopify.

How CoffeMokko is implemented in the code of the online store

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


In the sniffer code, the names of the form fields from which data must be stolen are hardcoded. The sniffer also checks whether the user is on the payment page, checking the list of keywords with the current address of the user.


Some detected sniffer versions 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 gate address to which the stolen data should be sent.


The stolen payment information was sent to the script on the attacker 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, consolidating data from all sniffers. To hide the transmitted data, all the victim’s payment information is encoded using base64 , and then several symbol replacements occur:

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

As a result of character substitutions, base64 encoded data cannot be decoded without reverse conversion.

This is the sniffer code snippet that did not obfuscate:

Infrastructure analysis

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

Also, this group 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 either the store’s domain or the store’s theme.


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

Code analysis

The first obfuscation algorithm

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


Having decrypted the string with the corresponding key, unique for each sample, you can get a string containing all the lines from the sniffer code through the delimiter character.

Second obfuscation algorithm

In later sniffer samples of this family, a different obfuscation mechanism was used: in this case, the data was encrypted using a self-written algorithm. A string containing the encrypted data necessary for the sniffer to work 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.

Linkage to Early MageCart Attacks

An analysis of one of the domains used by the group as a gate to collect the stolen data revealed that the domain has a credit card theft infrastructure identical to that used by Group 1, 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 Group 1 sniffer code with gate address js-cdn.link
• mag.php - PHP script responsible for collecting sniffer-stolen data

It was also found that the earliest domains used by the group behind the CoffeMokko sniffer family 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 is the same as the Group 1 domain names used in the 2016 attacks.

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