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 Q3 2021

The APT trends reports are based on our threat intelligence research and provide a representative snapshot of what we have discussed in greater detail in our private APT reports. This is our latest installment, focusing on activities that we observed during Q3 2021.

Lyceum group reborn

According to older public researches, Lyceum conducted operations against organizations in the energy and telecommunications sectors across the Middle East. In 2021, we have been able to identify a new cluster of the group’s activity, focused on two entities in Tunisia.

GhostEmperor: From ProxyLogon to kernel mode

While investigating a recent rise of attacks against Exchange servers, we noticed a recurring cluster of activity that appeared in several distinct compromised networks. With a long-standing operation, high profile victims, advanced toolset and no affinity to a known threat actor, we decided to dub the cluster GhostEmperor.

Subscribe to our weekly e-mails

The hottest research right in your inbox