After a new victim has been successfully infected, the TA will deliver a specific configuration through the core Gozi loader, to instruct the bot on where to retrieve additional modules (also referred to as “second stages”), which typically includes:

  • Web-inject kit(s) for the targeted applications
  • hVNC module
  • SOCKS module
Figure 5 - Fraud-related additional modules (hVNC, Web-injects) from Gozi configuration
Figure 5 – Fraud-related additional modules (hVNC, Web-injects) from Gozi configuration

Web-injects are typically part of a MitB attack with the goal of modifying the content of a legitimate web page in real-time by performing API hooking. They are considered as an extension of the formgrabbing technique since they can intercept and manage web responses, altering the content before it is displayed on the browser (bypassing TLS protocol).  

hVNC stands for Hidden VNC and means that the malware controls a machine without the victim’s knowledge. Instead of controlling a victim’s desktop, an attacker can open a hidden instance in the shape of a virtual desktop and control it invisibly behind the scenes, even as the unwitting victim continues using his or her computer.

SOCKS module enables TA to remotely connect to the infected bot, routing all the internet data through the same IP address as the victim, bypassing anti-fraud countermeasures such as network heuristics, etc.

We refer to those three modules as the “Gozi fraud core toolkit” since those are the modules used by high-skilled fraud operators for conducting banking fraud nowadays which typically happens only on the most valuable bots. This is an interesting pattern that we observed especially over the last year: from the initial malspam campaign to the actual banking fraud attempt, it can take weeks or even months, and during this period operators enrich their botnet automatically via RATBANK, exfiltrating in the background useful information, such as:

  • Valid credentials
  • Personal information and phone numbers(for further vishing attacks, if required)
  • Account balances
  • Recent bank transfers
  • 2FA mechanism in use (e.g., SMS based, token based, QR codes)

RATBANK appears to be the main Web-inject kit used by this TA, which works as aRitB (RAT in the Browser), injecting a malware code into the browser memory by using MitB (Man in the Browser) techniques. In this way the victim’s browser becomes a middle man component for all monitored web sessions. These specific attacks are very hard to detect since the compromised user continues to act undisturbed in a normal-looking web session on his own device and with his own IP address, known to (and therefore not suspected by) the targeted bank.

Figure 6 – RATBANK injected during the login process into a targeted website

During our analysis, we were also able to intercept “less-common” configurations where we noticed the usage of another Web-inject kit in addition to RATBANK, also known as tables, and well described in the following research published by FireEye in 2018.

Figure7 – Two different Web-inject kits found on recent Gozi campaigns

An example of a related sample that has been caught delivering this specific configuration has been provided in Appendix 1: IOCs.

Once extracted, we identified more than 50 different financial institutions targeted by this specific configuration, including both retail and corporate banking environments, as shown in the following table:


Number of targets

Webinjects kit (family)

Additional modules



RATBANK (delsrc)






Appendix1: IOCs

2ef16b02901c1bdd819ddf1aa96f3994 (Gozi maldoc)

0b26191e482cf7c321efeb8d2569caac (Gozi loader)

x-energy[.org/components/com_finder/img32.rar(hVNC 32 bit)

x-energy[.org/components/com_finder/img64.rar(hVNC 64 bit)

ecertificateboly[.us (RATBANK C2)