JavaScript sniffers' new tricks: Analysis of the E1RB JS sniffer family

Victor Okorokov
Lead Threat Intelligence analyst at Group-IB
In January 2021, Group-IB analysts came across a new JS sniffer family. While analyzing two infected websites, they found two similar samples that used unusual anti-detection techniques. Both samples had a unique hash for each request: when a victim visited an infected online store, the JS sniffer injector uploaded the JS sniffer main script, which represented a unique sample with unique obfuscated data and the names of all variables and functions. In one of the samples, the threat actor used time-based obfuscation: part of the key in the obfuscation mechanism was the value of the minutes when the attacker's website, which hosted the JS sniffer payload, received the request. After analyzing the code and studying the deobfuscation logic, Group-IB analysts found that both samples were similar and only differed by the gates for collecting stolen credentials. Both samples analyzed belonged to the JS sniffer family that Group-IB named E1RB. Judging from the code specificities, this JS sniffer family is based on Grelos JS sniffer family, used by many cybercriminal groups.
First E1RB sample
In the first case, the infection starts after a small piece of code is injected into the HTML code of a compromised website (Picture 1).
Picture 1: Malicious injector for downloading another payload
This small piece of code is a modified sample of a legitimate snippet designed to load a Google Analytics script (Picture 2).
Picture 2: Legitimate Google Analytics injector
Due to this modification, instead of loading the legitimate library the malicious injector checks whether there is a "onepage" keyword in the user's location address, which would indicate that the user visited the checkout page. If so, the injector loads the malicious script for stealing bank card information from URL google-analitics[.]org/diem/stat.

The first part of the injected script is designed to replace a payment form: a fake one is stored as Base64-encoded data in the script in the "val" variable (Picture 3).
Picture 3: Code for replacing the original payment form with the fake one
After decoding Base64 data, Group-IB analysts obtained the HTML code of the fake form that was used to collect bank card information and that replaced the original payment form (Picture 4).
Picture 4: Fake payment form used in the JS sniffer
The second part of the injected script collects bank card information. It is obfuscated and contains a deobfuscation function. The obfuscation/deobfuscation mechanism uses current time: when the attacker's server receives a request of the JavaScript sniffer script, it obfuscates the script source code using the minute value of the request time. When the script is ready to be executed, it is deobfuscated using the getUTCMinutes() function, which returns value in minutes of the current time (Picture 5).

An interesting fact about this script is that, for each request, the names of functions and variables are unique: the server-side script renames the names with random strings. As such, for each request the malicious script has a unique fingerprint.
Picture 5: Code to deobfuscate the main part of the JS sniffer source code
After the deobfuscation, we get a clean script designed to collect the customer's bank card information on the infected website of the online store during checkout.

Malicious script uses the URL address hXXps://google-analitics[.]org/diem/track as a gate. All collected bank cards are sent there (Picture 6).
Picture 6: Part of the final JS payload with the gate for collecting stolen data
The script collects information from the following elements: input, select, text area, checkbox, and button (Picture 7).
Picture 7: Part of the JS sniffer for collecting bank card information
All the collected information is encoded and then sent to the gate address using a HTTP POST request (Picture 8).
Picture 8: Part of the JS sniffer for sending collected payment information
An analysis of the final payload used to steal customer bank cards showed that, in this case, the attackers used a modified version of the Grelos JavaScript sniffer. Variations of Grelos-based sniffers are used by many groups, including UltraRank, which used it in its earliest attacks in 2015. Group-IB named this variation of the Grelos JS sniffer E1RB, after the name of the main object in the sniffer source code.
Second sample
The second infection starts with a similar snippet of a modified Google Analytics injector. The modified Google Analytics script searches for string "onestepcheckout" in the user's address and if the search returns "true", the script loads a JavaScript sniffer from the URL address cdn-gstat[.]com/thredzonline/script.
    Picture 9: Malicious injector for downloading the JS sniffer
    The downloaded script (Picture 10) uses another obfuscation mechanism, however. In this case, the attackers again used a server-side script for creating unique JS sniffer samples. With each request, the server re-obfuscates the script with new names of functions and variables.
      Picture 10: Script downloaded by the injector
      After cleaning up the script text, Group-IB analysts uncovered the deobfuscation algorithm (Picture 11). This variant uses a similar snippet for replacing the original payment form with a fake one, stored as Base64-encoded data.
        Picture 11: Function for the deobfuscation of the JS sniffer source code
        After decoding we get the final payload, which is designed to replace the original payment form with a fake form, collect bank card information from it, and send any data collected to the attacker's gate using the URL hXXps://cdn-gstat[.]com/thredzonline/data (Picture 12).

        The decoded payload is another sample of a Grelos-based JS sniffer of the E1RB family, which is similar to the JS sniffer detected in the first previous of this investigation. As in the previous case, it uses the "val" variable for storing Base64-encoded HTML code of the fake payment form.
          Picture 12: Part of the E1RB sniffer source code with the Base64-encoded fake form and the gate address
          Analysis of infrastructure
          According to an analysis using the Group-IB Graph Network, the domain name google-analitics[.]org was created using the email address alexey_rublev@protonmail.ru. The same address was used to create cdn-host[.]org.

          At the same time, a similar email address, alexey_rublev@protonmail.com, was used for four other domain names:

          ● telrshop[.]com

          ● jquery-live[.]com

          ● cdn-gstat[.]com

          ● jquery-on[.]com

          As such, during their attacks the cybercriminals behind the E1RB JavaScript sniffer created 6 unique domain names for storing malicious files and collecting stolen bank card information. While 4 of these domain names use well-known legitimate brands like jQuery and Google Analytics, the domain name telrshop[.]com caught our attention. We found that "Telr" is the legitimate brand belonging to a Dubai-based payment gateway that recently launched its own platform for building e-commerce websites (the original website is https://www.telrshops.com/). We can therefore assume that threat actors prepared this fake domain name for the attacks on websites created using the Telr platform.
          For issuing banks

          ● Notify users of possible risks in the online payment process when using bank cards.

          ● If payment cards related to your bank have been compromised, block these cards and notify the users that the eCommerce store has been infected with a payment card sniffer.

          ● Receive first-hand reports about compromised card sales on the Dark web. Check for the cards issued by the bank in the DBs for sale.
          To access unique closed sources, and improve your visibility into the underground card shops you may use Group-IB Threat Intelligence & Attribution

          ● Prevent fraud with stolen credit cards and protect your customers' digital identity. An example of such a solution is the Group-IB Fraud Hunting Platform

          For eCommerce websites administrators

          ● Use complex and unique passwords to access the website's admin panel and any services used for administration, for example phpMyAdmin, Adminer. If possible, set up two-factor authentication.

          ● Install all necessary updates for the software used, including CMS of websites. Do not use outdated or unsupported versions of the CMS. This will help to reduce the risk of servers being compromised and make it more difficult for an attacker to download the web shell and install malicious code.

          ● Regularly check the store for malware and conduct regular security audits of your website. For example, for websites based on CMS Magento, you can use Magento Security Scan Tool.

          ● Conduct complex security assessment of your website to discover all possible vulnerabilities, get information about existing exploits, and receive in-depth recommendations to eliminate them.

          ● Use the appropriate systems to log all changes that occur on the website, as well as to log access to the website's control panel and database and track file change dates. This will help you to detect website files infected with malicious code, as well as track unauthorized access to the website or web server.

          For payment systems/payment processing banks

          ● If you provide payment services for eCommerce websites, regularly inform your customers about basic security measures when accepting online payments on the websites, as well as the threat of JavaScript sniffers.

          ● Ensure that your services use a correctly configured Content Security Policy.
          Indicators of compromise
          ● jquery-live[.]com

          ● jquery-on[.]com

          ● cdn-gstat[.]com

          ● cdn-host[.]org

          ● google-analitics[.]org

          ● telrshop[.]com