Webinjects have now taken the place of keyloggers and form grabbers in the financial malware arena as the primary means of stealing login credentials and other personal information through a web browser. Some webinjects are even capable of performing tasks that traditional malware modules can’t do, like carrying out automated fraudulent transactions.
In this post, we help you understand what webinjects are, explain their underlying mechanisms, and look into the different ways cybercriminals use them.
How Webinjects Work
Webinjects are modules or packages used in financial malware that typically inject HTML or JavaScript code into content before it’s rendered on a web browser. As a result, webinjects can alter what the user sees on his/her browser, as opposed to what’s actually sent by the server. For example, it can add or remove text, labels, text fields, and other GUI elements.
Figure 1 below shows a simplified illustration of a webinject inserting an additional field to a form sent by an online bank’s server. The purpose of those extra fields (presumably accompanied by supporting labels and instructions) is to dupe the user into entering certain confidential information (e.g. login credentials, credit card numbers, CVVs, PINs, tokens, etc.) even if that information was not being requested by the online bank in the original form.
Figure 1 – A webinject inserting an additional field
Webinjects can remove web page elements as well. One purpose of doing so is to prevent the user from seeing security alerts/warnings that might hamper the malware’s fraudulent activities.
Figure 2 – A webinject removing a warning
Because the extra fields appear in the course of a legitimate transaction after presumably a secure login, the unwitting victim wouldn’t suspect anything amiss and would promptly enter the requested information. Once the attackers get a hold of that information, they can then use the information to perform unauthorized logins and carry out fraudulent transactions.
Can’t we prevent these malicious content alterations by using HTTPS, i.e. so that data can be encrypted by SSL or TLS? Unfortunately not. While HTTPS does encrypt data from the online bank’s web server to the user’s computer, many of these webinjects (like those used by SpyEye and its derivatives, for example) operate between the HTTPS API functions and the browser’s rendering engine. At that point, the data would have already been decrypted and thus be vulnerable to tampering.
When HTTPS is used, the unaltered HTML and CSS source code (which dictate the appearance of the webpage) is transmitted from the web server to the user’s computer in encrypted form. Of course, that code has to be decrypted eventually. Otherwise, the browser rendering engine wouldn’t be able to parse the code, process the layout, paint the tree, and then ultimately display the text, buttons, fields, etc. for the user to see and interact with.
The decryption process takes place when the code reaches the network APIs (in the case of Windows, that would be in the Wininet.dll library). In other words, the code is decrypted before it’s forwarded to the browser’s rendering engine. This is where the attack is carried out and the webinject is called into play. Because the attack essentially happens in the browser, it’s usually considered as a Man-In-The-Browser (MITB) attack.
A man-in-the-browser attack is usually carried out by hooking the API functions responsible for sending and receiving the HTTP or HTTPS data. API hooking is basically a technique that enables a piece of software (in this case, the malware) to intercept function calls or messages exchanged between two other pieces of software and make unauthorized changes. In this case, the changes are able to alter the web content.
There are a number of ways to hook an API but the popular methods include inline hooking, IAT (Import Address Table) hooking, and export address table (EAT) hooking, to mention a few.
Configuration files
Most banking trojans target multiple financial institutions. Because the web pages and the corresponding content of these different institutions naturally vary from one another, the webinjects are designed so that they can easily adapt to whichever URL the user has visited (provided of course that URL is included in the target list). This is done with the help of a configuration file.
A webinject configuration file contains instructions that support the injection process, e.g. the target URL, what to inject, where (on the webpage) to inject, etc. In most cases, the malware polls it’s C&C (command and control) server and obtains its configuration file from there.
Having the malware retrieve its configuration file from a remote C&C provides a convenient way for the malware operators to update the details in the file if needed. This can come in handy if any of the target institutions decide to change the URLs or the web page content associated with those URLs.
A configuration file consists of configuration blocks, with each block consisting of a set of parameters specifying a target URL, the corresponding modifications to be made for that URL, and a couple of other instructions.
For example, if you happen to view the configuration files of Zeus and SpyEye, you’ll find that each block consists of the following parameters:
set_url – This is where the target URL is specified. In most cases, the ‘URL’ is written in the form of a regular expression in order to target a set of URLs that match a certain pattern. These URLs are accompanied by letters like G, P, and L that tell the malware what to do when the browser lands on that particular URL.
For example, G instructs the malware to act on all GET requests, P tells it to act on POST requests, and L instructs it to log certain data.
data_before – Defines existing content on that URL that, after injection, should be displayed right before the injected content.
data_after – Defines existing content on that URL that, after injection, should be displayed right after the injected content.
data_inject – This is where the content to be injected is specified, typically in the form of HTML or JavaScript code, and is basically the web inject itself. The main code can be either written inline or referenced as an external script.
Other Criminal Applications of Webinjects
Their ability to hijack a legitimate transaction on a trusted site (e.g. the user’s online bank) and then display content to dupe users into submitting confidential information or responding to some kind of call-to-action makes webinjects suitable for other criminal activities.
Attacking Facebook users
A couple of years ago, the Qadars banking trojan used webinjects to force an infected system’s browser to display deceptive content when the user was on Facebook. The content was designed to trick the victim into entering his/her phone number, performing a series of actions, and then ultimately downloading Android malware known as iBanking.
Corporate espionage
There have also been reports in the past of browsers getting infected with Zeus (a popular banking trojan) and then displaying pop-ups that asked for the user’s employer and phone number.
It was suspected that the Zeus operators may have combined this information with the user’s passwords (which the operators may have acquired through a separate form also displayed via webinjects) to gain access to that user’s corporate network.
Once attackers are able to gain initial access to a corporate network, they could apply privilege escalation techniques to gain a better foothold into the infrastructure and conduct corporate espionage. But how could attackers infiltrate a corporate network using information gained from a user’s banking transactions? Easy. By taking advantage of poor security practices.
Unless they belong to an organization that implements a strict password policy, a lot of end users tend to recycle passwords. Not only do they use the same passwords for all their corporate business applications, they also use those same passwords in their personal activities – including banking transactions. As you can see, malware operators can use webinjects to steal not only money but also intellectual property.
Webinject kits on the market
You’ve heard of exploit kits, right? Those bundles of exploits sold to malware operators in the dark corners of the Internet. Well, there are also webinject kits. Mainly consisting of webinject configuration files, webinject kits are specifically marketed to banking trojan operators. Some kits are simply designed to steal confidential data, while the more advanced kits are equipped with ATS (automatic transfer system), mechanisms for bypassing 2-factor authentication, and even mobile device components.
The presence of these webinject kits is now making it much easier for cybercriminals to launch their own banking trojan campaigns.
Do you have the capability to detect these types of malware before their operators defraud your employees or, worse, penetrate your network?