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).

This small piece of code is a modified sample of a legitimate snippet designed to load a Google Analytics script (Picture 2).

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).

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).

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.

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).

The script collects information from the following elements: input, select, text area, checkbox, and button (Picture 7).

All the collected information is encoded and then sent to the gate address using a HTTP POST request (Picture 8).

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.

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.

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.

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.

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.

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.

Lear more about Group-IB's Security Assessment, Threat Intelligence & Attribution, and Fraud Hunting Platform on our website.

● jquery-live[.]com

● jquery-on[.]com

● cdn-gstat[.]com

● cdn-host[.]org

● google-analitics[.]org

● telrshop[.]com