Research

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/*

 

Web skimming with Google Analytics

Your email address will not be published. Required fields are marked *

 

  1. mark skelding

    Hi, I stupidly answered a question from a friend on Facebook. I realised too late it was a scam. I find, in my history, a hyperlink to a site called: https://firebasestorage.googleapis.com/v0/b/[some-firebase-bucket-name]/o/[some-file-path]?alt=media&token=[some-token].
    I don’t have a firebase account. what to do?

Reports

APT trends report Q2 2021

This is our latest summary of advanced persistent threat (APT) activity, focusing on significant events that we observed during Q2 2021: attacks against Microsoft Exchange servers, APT29 and APT31 activities, targeting campaigns, etc.

LuminousMoth APT: Sweeping attacks for the chosen few

We recently came across unusual APT activity that was detected in high volumes, albeit most likely aimed at a few targets of interest. Further analysis revealed that the actor, which we dubbed LuminousMoth, shows an affinity to the HoneyMyte group, otherwise known as Mustang Panda.

WildPressure targets the macOS platform

We found new malware samples used in WildPressure campaigns: newer version of the C++ Milum Trojan, a corresponding VBScript variant with the same version number, and a Python script working on both Windows and macOS.

Ferocious Kitten: 6 years of covert surveillance in Iran

Ferocious Kitten is an APT group that has been targeting Persian-speaking individuals in Iran. Some of the TTPs used by this threat actor are reminiscent of other groups, such as Domestic Kitten and Rampant Kitten. In this report we aim to provide more details on these findings.

Subscribe to our weekly e-mails

The hottest research right in your inbox