Malicious Javascript vs. card reader

Today’s bank customers face the very real threat of losing their hard-earned cash if their online banking identities are stolen by cybercriminals. To help prevent online banking theft, many banks have begun issuing USB dongles and card readers to their clients as a means of proving their identities when online. When a client uses their online banking service, the bank’s website requires the user to identify themselves as the account holder. This is achieved by each user having a unique login which is checked in tandem with the information held on the dongle or entered via the card reader as and when required.

At first glance this system looks pretty watertight. Even if a cybercriminal steals a user’s online banking identity, they will not be able to use it if they do not have the appropriate card reader or token as well. However, some cybercriminals have managed to get around this. Some malicious programs force the legal user to authorize money transfers from their account to that of the cybercriminals’. We will use ZeuS, a popular Trojan, as an example of how this scheme works.

After establishing itself on a victim computer, ZeuS intercepts all of the data passing through the web browser. It may change the data, e.g. by adding malicious code to that of the site. In this case, the user will see the version of the site only after it’s been tampered with.

First, let us see how the account management system works normally, without a Trojan present. The user enters their login and password. If the data is correct, the system provides the user with access to their bank account(s). Whenever the user wants to transfer money, the banking system will require them to authorize the transfer by registering their identity card using the card reader connected to the user’s computer. This is the way the system has been designed by the developers.

…But the cybercriminals have a trick up their sleeve.This is how the bank’s website normally looks.

The original home page of the online banking system contains a reminder

This page states that a card reader is not needed to log in. Now let us see the same page once the user’s computer has been infected with ZeuS:

The home page altered by ZeuS, without the reminder

The ZeuS configuration file contains the address of the bank’s homepage. The Trojan modifies the code in the downloaded page, as instructed, so the user does not see the original reminder about the card reader. In addition to this, links are added to the code which supposedly point to a script hosted on the bank’s legitimate website.

The code of the bank’s page has been modified by ZeuS

The bank’s website doesn’t actually contain this script. When the browser follows this link, it is intercepted by another function contained within the Trojan.

ZeuS’ configuration file contains instructions from the cybercriminal about the URL addresses or data to be substituted.

URL substitution instruction to the Trojan

In the above example, the line in the configuration file contains an instruction to take all requests to the first URL and redirect them to a different URL. As a result, whenever the user attempts to review the original banking page, they will be redirected to the page modified by ZeuS that contains malicious script.

Here’s a step-by-step account of what this script does.

If user authorization is successful, the intercepted data – i.e. login, password and PIN code, are sent to the cybercriminal (ZeuS inserts its own online form into the code of the page asking the user to enter their password and PIN code).

The user enters their data into the system and waits for the relevant page to be displayed so that they can manage their account. However, the script delays the appearance of the page in the browser. To avoid arousing suspicion when the page doesn’t open immediately, the malicious script displays the following message:

With the system open and the client waiting for the results of the supposed configuration check, a malicious script takes over and performs transactions as though it was the account owner.

A user may well have access to multiple accounts. In that case, the script looks for the account with the most money. The script checks all the links until it finds the transactions page.

In order to add a new payee, the script emulates a mouse click on the relevant link on the page:

Preparing a payment

Imitating the addition of a new recipient

The Trojan’s command center passes on detailed information about the transaction: name of the payee, the account details, Sort Code, the transaction destination, comments, and of course the amount of money to be transferred. These details are used to fill in the online form.

Once the recipient has been specified, the transaction can be carried out. There remains just one last important step – the user has to confirm the transfer using the card reader.

All these actions are performed very quickly by the script. The user, meanwhile, is still awaiting the results of the supposed configuration check. During that time the user receives the following message:

At the very beginning of the authorization process the Trojan hid the reminder that the card reader is not required to log in to the system, and because the user is perfectly sure that the bank sent the message, the card will most likely be inserted into the reader. If everything goes to plan, all the script has to do is make the final confirmation by clicking the “Make Payment” button.

Wave bye-bye to the money…

After the transaction has been made, the script hides all traces of the transfer: changes the account balance back to what the user expects it to be, hides the recipient added by the script, hides any related information in the payments made column, etc. As a result, it may be some time before the user even realizes that any money has disappeared from their account.

Despite the fact that antivirus protection is constantly improving and banks are modernizing their online systems to prevent access by cybercriminals, malware writers are really pulling out all the stops to get their hands on people’s money. This means that online banking users need to be extra vigilant.

If your bank tells you that a device such as a USB token or a card reader should only be used to confirm transactions, then you must only use it for that purpose, regardless of whatever confirmation requests you receive, no matter how genuine they might appear to be.