An analysis of this trojan reveals a few interesting techniques that are enlisted below.
TAN Grabber
Transaction authentication number (TAN) is used as a two-factor authentication. It's basically a single-use password required to authorize the online banking transaction.
The bank normally generates a list of unique TAN numbers and handles it to the client. Any TAN from the list can be used only once. This way, it serves an additional security layer on top of traditional username/password authentication.
TANs are commonly used by German banks where the lists normally contain 100 unique numbers.
The banking trojan specifically attacks the clients of several online banking services that are known to rely on TAN. These banking services are registered on the following domains:
- gad.de
- vr-networld-ebanking.de
- finanzportal.fiducia.de
- financepilot-trans.mlp.de
- citibank.de
- wuestenrot.de
- norisbank.de
When the client enters a valid TAN number, the trojan intercepts that number and substitutes it with a random (incorrect) number that will be rejected by the bank. The contents of HTML page rendered by browser to the client is then filtered by the trojan so that the incorrect number is replaced again with the intercepted number - the user is shown that number in order to convince her that the number was entered correctly.
The intercepted (correct) TAN along with the user's login details is then posted to the hacker's website.
HTML Injection
Some variants of this trojan inject fake fields into the online banking forms that the browser displays to the user.
The additional fields are designed to collect details to help an attacker to impersonate the victim and/or compromise victim's account, such as credit card number, date of birth, and answers to the questions that are commonly asked during two-factor authentication.
The image below demonstrates extra fields added to the known online banking services. All intercepted details are also delivered to the remote site.
Form Grabber
Another interesting feature of this trojan is that it specifically targets several Australian financial institutions by inspecting the visited URL and the contents of the traffic by parsing POST requests and the returned HTML pages.
If the trojan detects that the client interacts with a pre-determined Australian bank, it will engage several techniques in an attempt to compromise the user account, as indicated below.
Firstly, the trojan seems to be able to easily compromise the "Scramble Pad" authentication employed by the Adelaide Bank.
Here is the contents of memory that the trojan dynamically allocates on the heap of the browser process:
The contents of the memory dump above represents a filter that the trojan uses to recognise and target Adelaide Bank's online banking service - the image below shows the actual online banking login window and the source of HTML that contains the strings recognised by the trojan (highlighted in blue):
As soon as the user enters "Customer Number" and provides "Personal Access Code" by typing letters from the Scramble Pad, the trojan easily intercepts the entered details. Considering that the Scramble Pad itself is a plain ASCII text (highlighted in the picture above in red), the account details are compromised with no obstruction.
Below is the actual contents of the trojan's heap memory once it intercepts the access code 12345 typed by using the Scramble Pad above as "GNDXT":
As seen in the picture, the trojan tags the intercepted details with 2 keywords: KEYLOGGED and KEYSREAD (presumably to reflect 2 different methods of grabbing the login form contents).
Other Australian financial institutions exclusively targeted by this trojan are:
- Australian Central Credit Union
- Police & Nurses Credit Society
- Citibank Australia
- Commonwealth Bank of Australia
This is evidenced with the following filters employed by the trojan:
NOTE: The "three Personal Icons" filter above will recognise the ACCU's two-factor authentication that is based on personal icons.
The trojan seems to be capable of intercepting data that is entered with the virtual keyboards too.
For example, below is the login window of the Citibank Australia:
During trojan analysis, there were fake details entered into the login form. Once specified, the memory contents of Internet Explorer was found to contain in plain text 37 instances of the User ID and 8 instances of the User Password - exactly as they were provided.
An example below shows one such instance. Please note that while VICTIM_ID word was typed on the keyboard, VICTIM_PASSWORD word was entered by using the virtual keyboard window:
As see on the picture, the contents of memory is visible for the trojan in plain ASCII text - it does not need to install any hooks into the chain of the keystroke handlers, and thus, can't be prevented with the host intrusion prevention systems.
Considering the intercepted data is then delivered via HTTP from the code running in the address space of Internet Explorer, the leakage of confidential data is transparent for the firewalls.
Another example demonstrates how the trojan intercepts login details for Netbank - the online banking service of the Commonwealth Bank of Australia:
As seen in the memory dump above, the trojan successfully intercepts fake login details (11220033, Victim_Password), tags them with the keywords KEYLOGGED and KEYSREAD, and encrypts them with XOR 0x0E in order to prepare the package for posting.
Analysis of this trojan leaves mixed feelings about the banks and the way they implement some two-factor authentication schemes.
What this trojan definitely proves is that current schemes employed by the online banking services need to be critically reviewed and significantly reinforced.
