Web skimming with Google Analytics

Web skimming is a common class of attacks generally aimed at online shoppers. The principle is quite simple: malicious code is injected into the compromised site, which collects and sends user-entered data to a cybercriminal resource. If the attack is successful, the cybercriminals gain access to shoppers’ payment information.

To make the data flow to a third-party resource less visible, fraudsters often register domains resembling the names of popular web services, and in particular, Google Analytics (google-anatytics[.]com, google-analytcsapi[.]com, google-analytc[.]com, google-anaiytlcs[.]com, google-analytics[.]top, google-analytics[.]cm, google-analytics[.]to, google-analytics-js[.]com, googlc-analytics[.]com, etc.). But attack of this kind were also found to sometimes use the authentic service.

To harvest data about visitors using Google Analytics, the site owner must configure the tracking parameters in their account on analytics.google.com, get the tracking ID (trackingId, a string like this: UA-XXXX-Y), and insert it into the web pages together with the tracking code (a special snippet of code). Several tracking codes can rub shoulders on one site, sending data about visitors to different Analytics accounts.

Recently, we identified several cases where this service was misused: attackers injected malicious code into sites, which collected all the data entered by users, and then sent it via Analytics. As a result, the attackers could access the stolen data in their Google Analytics account. We found about two dozen infected sites worldwide. The victims included stores in Europe and North and South America selling digital equipment, cosmetics, food products, spare parts etc.

The screenshot below shows how the infection looks — malicious code with the attacker’s tracking code and tracking ID:

Screenshot 1

The attacker tries to hide their malicious activity using a classic anti-debugging technique. Screenshot 2 shows code for checking whether Developer mode is enabled in the visitor’s browser. The code in the screenshot above is executed only if the result is negative.

Screenshot 2

Curiously, the attackers left themselves a loophole — the option to monitor the script in Debug mode. If the browser’s local storage (localStorage) contains the value ‘debug_mode’==’11’, the malicious code will spring into life even with the developer tools open, and will go as far as to write comments to the console in clumsy English with errors. In screenshot 3, the line with the ‘debug_mode’ check follows the implementation of the RC4 encryption algorithm (used to encrypt the harvested data before sending it).

Screenshot 3

If the anti-debugging is passed, the script collects everything anyone inputs on the site (as well as information about the user who entered the data: IP address, UserAgent, time zone). The collected data is encrypted and sent using the Google Analytics Measurement Protocol. The collection and sending process is shown in screenshot 4.

Screenshot 4

The stolen data is sent by invoking the send event method in the ‘eventAction’ field.

The function signature in this case is:

This leads to an HTTP request being sent to the URL
https[:]//www.google-analytics.com/collect?<parameters>&ea=packed_stolen_data&<parameters>

In the above-described case, malicious code is inserted into a script on the infected site in “readable” form. In other cases, however, the injection can be obfuscated. Malicious code also can be downloaded from a third-party resource. Screenshot 5 shows an example obfuscation option. In this variant, a call to a malicious script from firebasestorage.googleapis[.]com is inserted into the infected site.

Screenshot 5

After deobfuscation, we obtain a similar script with the same distinctive comments. Part of its code is presented in screenshot 6 (a different tracking ID is used).

Screenshot 6

What’s the danger

Google Analytics is an extremely popular service (used on more than 29 million sites, according to BuiltWith) and is blindly trusted by users: administrators write *.google-analytics.com into the Content-Security-Policy header (used for listing resources from which third-party code can be downloaded), allowing the service to collect data. What’s more, the attack can be implemented without downloading code from external sources.

How to avoid the issues

Users:

• Install security software. Kaspersky solutions detect malicious scripts used in such attacks as HEUR:Trojan-PSW.Script.Generic.

Webmasters:

• Do not install web applications and CMS components from untrusted sources. Keep all software up to date. Follow news about vulnerabilities and take recommended actions to patch them.
• Create strong passwords for all administration accounts.
• Limit user rights to the minimum necessary. Keep track of the number of users who have access to service interfaces.
• Filter user-entered data and query parameters to prevent third-party code injection.
• For e-commerce sites, it is recommended to use PCI DSS-compliant payment gateways.

IOCs

firebasestorage.googleapis[.]com/v0/b/bragvintage-f929b.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/canature-5fab3.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/ericeirasurfskate-559bf.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/gluten-8e34e.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/laser-43e6f.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/movile-720cd.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/plumb-99e97.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/redfox-64c35.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/tictoc-9677e.appspot.com/o/*