The document discusses man-in-the-browser attacks, which occur when malicious code infects a user's internet browser. The code can then modify or initiate actions in the browser without the user's knowledge. This allows the code to hijack online banking sessions and redirect funds to criminal accounts. The attacks are difficult to detect as they manipulate browser traffic after authentication. Common techniques used include injecting code through browser extensions, modifying webpage content, and hooking key browser and operating system APIs to control internet traffic. These attacks pose a global threat as many banks now use two-factor authentication, which has attracted more MITB targeting.

1. Man-in-the-Browser Attacks
Mário Almeida Umit Buyuksahin
Emmanouil Dimogerontakis Aras Tarhan
December 20, 2011

2. Contents
1 Background 2
2 Introduction 3
2.1 The Risk in Man-in-the-Browser Attack . . . . . . . . . . . . 4
2.2 Global Threat of Man-in-the-Browser . . . . . . . . . . . . . . 4
2.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Point of Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Background & Overview of the Method of Attack 8
3.1 The Method of Attack . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Phase 1: Infection . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Phase 2: Transaction Takeover . . . . . . . . . . . . . 11
3.2 Banking Malware Example . . . . . . . . . . . . . . . . . . . 13
4 Banking Trojans 14
4.1 Banking trojans capabilities . . . . . . . . . . . . . . . . . . . 15
4.2 Anatomy of an e-fraud incident . . . . . . . . . . . . . . . . . 16
4.3 Zeus configuration files . . . . . . . . . . . . . . . . . . . . . . 16
4.4 Domain Generation Algorithms . . . . . . . . . . . . . . . . . 17
4.5 P2P botnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6 Social Engineering . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7 Man-In-The-Mobile . . . . . . . . . . . . . . . . . . . . . . . . 19
4.8 Tatanga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.9 Banking trojans statistics . . . . . . . . . . . . . . . . . . . . 21
5 Counter Measures 23
5.1 Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Passive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3 Combination of Active and Passive counter Measures . . . . . 25
1

3. Chapter 1
Background
Initially, online Fraudsters (phishers) used social engineering techniques to
try to get personal information of customer by sending emails in order to
steal money from their Internet banking account. These information can be
passwords or bank account details, could be further used for other criminal
activities. For example, the fraudsters may intend to leave the victims information
behind after they have successfully committed the crime. Therefore polices
can suspect the visible evidence which belongs to victims as a suspicious
criminal. Fraudsters are using newer and more advanced methods to target
online customers. One of the latest and most dangerous methods being
developed and deployed is the use of Trojans to launch man-in-the-Browser
(MITB) attacks. Shortly, a Man-in-the- Browser attack occurs when malicious
code infects an Internet browser. The code modifies actions performed by the
computer user and, in some cases, is able to initiate actions independently
of the customer. When a customer logs onto their bank account, using an
infected Internet browser is enough to trigger illicit transactions that result
in online theft.
2

4. Chapter 2
Introduction
Firstly, online fraudulences have been introduced as a use of social engineering
technique in which potential victims are persuaded to obtain their confidential
information, such as usernames, passwords, and bank account details, to a
return email. General type of this attack is extended by creating fraudulent
web pages to convince the customers to believe that they are on the legitimate
websites of banking. When information of customer has been submitted
through the form provided fraudulent web pages, these information is been
sent to the online fraudsters. There are some kind of spying techniques that
are used to monitor the customers banking information claimed such as :
• screenshot and video capture
• code injection of fraudulent pages or form fields
• redirecting website
• keystroke logging
Sometimes, in order to obtain customers information can be combined with
multiple penetrating techniques; for instance, by using the screenshot and
video capture to monitor the users activity and using the keystroke logging
to record passwords or information.
Subsequently, on of the latest and more dangerous approach of online
fraudulences technology such as a Trojan horse has been released. It operates
by becoming embedded in a users Internet browser and later steals confidential
information and sends it back to the online fraudsters.
A number of Trojan families are used to conduct Man-in-the-Browser
attacks including Zeus, Adrenaline, Sinowal, and Silent Banker. Some MITB
Trojans are so advanced that they have streamlined the process for committing
fraud, programmed with functionality to fully automate the process from
infection to cash out.
Man-in-the-Browser and Man-in-the-Middle Attacks: Although Man-in-
the-Middle attacks (MitM) and man-in-the-Browser (MitB) attacks have
3

5. same idea based on controlling the Internet traffic between client and server,
these attacks use different ways to carry out the attack. Unlike Man-in-the-
Middle attack, man-in-the-Browser attacks placed customers browser and
manipulate the outgoing and ingoing traffic after the authentication process
of customers processes.
2.1 The Risk in Man-in-the-Browser Attack
The most obvious and most dangerous properties of Man-in-the-Browser is
that hard to detect and, in many cases, succeed in causing damage completely
surreptitiously.
Following are some of reasons why MITB attacks pose high risk:
• Computers can be infected easily: Especially, while customers are browsing
or downloading media and other files, they are encouraged to install
updated versions of software. These requests are so common, that
many clients automatically accept and customers do not notice fine
differences between malware program and normal program. Thus, they
may download malware and their computers unknowingly are infected.
• Detection is hard : Since malwares are produced by using some kind
of toolkit that support variation of malicious code , they are hard to
detect .
• Traditional Strong Authentication is inadequate: Traditional Strong
authentication validates that a person logging on to an online resource
is indeed who he or she claims to be. When the customer wants to
make an online transaction, the infected browser carries out illicit
transactions covertly - neither the customer, nor the bank, are aware
that anything irregular is happening.
• Traditional Anti-Fraud Mechanisms are Not Effective: Since risk-based
anti-fraud tools just focus on user authentication and transaction validation,
they do not detect whether a transaction was initiated by malware or
not, there is a high risk.
2.2 Global Threat of Man-in-the-Browser
MitB attacks are not contained to one region or geography; They are a
global threat, affecting all regions of the world. However, they are especially
prevalent in areas where two-factor authentication is densely deployed. Today,
MitB attacks are increasing in their deployment and scale:
• In the United Kingdom, banks are suffering an increasing number
of MITB attacks. One financial institution alone reported a loss of
4

6. 600,000 pounds as a result of a single attack by the PSP2-BBB Trojan.3
European countries such as Germany, the Netherlands, Spain, France,
and Poland have deployed two-factor authentication in the last few
years, which have attracted a rise in the numbers of MITB attacks in
these regions. Germany has been particularly hard hit by an abundance
of MITB attacks as it is one of the few successful paths to commit online
banking fraud in the country. Banking innovations such as the Single
Euro Payments Area (SEPA) and pressure to deliver faster payments
have also increased exposure to transaction fraud. The increased ease
and speed of moving money is advantageous for legitimate transactions,
but reduces the flexibility to investigate and prevent suspicious transactions.
• In U.S. financial institutions are attacked by MITB; however, the
threat has been mainly confined to commercial banking or high net
worth customers. Because one-time password authentication is not
very common amongst consumers in the U.S., MITB attacks against
the general consumer public are less common compared to the volume
experienced by consumers in Europe. However, as security defenses
increase and the ability to infect more machines with MITB Trojans
increases the expected number of attacks on US retail banking institutions
is also expected to rise.
• Financial institutions in Australia, Asia and Latin America are increasingly
deploying two-factor authentication for their online banking users, and
as a result, have experienced an increasing number of MITB attacks.
2.3 Evaluation
Man in the browser is also called a proxy Trojan or a password pinching
Trojan. It combines the use of online fraudulences approaches with a Trojan
horse technology, put in a customers browser, to modify, capture, and/or
add an additional information on web pages without the customers and the
hosts knowledge.
Man-in-the-Browser Trojans commonly perform what is known as session
hijacking abusing a legitimate users session with the site being accessed
while the user is logged into their account. By hijacking a session in this
way, all actions performed by the Trojan actually become part of the users
legitimate session such as conducting a malicious activity (i.e., a fraudulent
money transfer, changing a postal address) or even injecting JavaScript code
that can then perform this automatically. The basic flow of a MITB attack
is as follows:
1. A consumer gets infected with a Trojan capable of launching an MITB
attack.
5

7. 2. Upon the initiation of a legitimate online transaction, the Trojan is
triggered into action and launches its MITB functionalities
3. The user passes all authentication stages, including any two-factor
authentication when needed. The Trojan wait silently for successful
login and/or transaction authorization.
4. The Trojan manipulates the transaction details payee, and sometimes
the amount. In most cases the legitimate payee account is replaced
with a mule account that the fraudsters can use.
5. By using social engineering techniques the user is unaware that they
are being impacted. The Trojan displays fake pages to the user, which
may show the transaction details as originally entered by the user.
If additional authentication is necessary to complete the transaction,
the Trojan will interact with the user and ask the user to enter their
authentication credentials in real-time to approve the transaction.
2.4 Point of Attacks
It is known that Online Fraudsters can successfully target to Firefox, Internet
Explorer and Opera , on the Windows, Linux and MacOS X Platform by
using Trojans.The trojans can do the following:
In the Man-in-the-Browser attacks, Trojans uses some kind of properties
of Internet web browsers for this purpose:
• Browser Helper Objects: These are dynamically-loaded libraries (dll)
loaded by Internet Explorer(IE) upon start-up. They run inside IE, and
have full access to IE and full access to the DOM tree, etc. Developing
BHOs is very easy.
• Extensions: It is similar to Browser Helper Objects for other Browsers
such as Firefox (hereafter, both will be referred to as extensions).
Developing Extensions is easy. UserScripts Scripts that are running in
the browser (Firefox/Greasemonkey+Opera). Developing UserScripts
is very easy.
• API-Hooking: This technique is a Man-in-the-Middle attack between
the application (.exe) and the dlls that are loaded up, both for application
specific dlls such as extensions and Operating System dlls. For example
if the SSL engine of the browser is a separate dll, then API-Hooking
can be used to modify all communication between the browser and the
SSL engine. Developing API Hooks is difficult.
6

8. Figure 2.1: A good example this type of attack is the breach of Paul
McCartneys fan page. In April 2009, the site was hacked for two days and
all visitors were silently infected with a variant of a MITB Trojan.
7

9. Chapter 3
Background & Overview of the
Method of Attack
The fraudulent transaction is done from victims computer. It is made during
the time the victim works with the related site. It is done silently without
asking the victim for anything. Man-in-the-browser also sometimes called a
proxy Trojan operates from within the Web browser by:
• hooking key Operating System and Web browser APIs,
– When the Internet Explorer opens a connection to the Internet, it
will call a function named InternetConnect which resides within
the wininet.dll module that every Windows installation has MITB
Trojans will now just hook into this first call between the Internet
Explorer Application and the Windows System, so that the Trojan
get full control over everything that is transmitted in this call.
– On Mac, If a web browser is using the system API to manage its
Internet connections, then malware simply needs to hook CFReadStreamOpen(),
CFReadStreamRead() or CFReadStreamWrite() in a similar way
to the one described above.
– Hooking method works as follows; it jumps to its own codebase so
that, the malicious code is executed. It needs to make sure that
the original code is called. Otherwise, no internet connection
would be established.
• inserting advanced HTML/JavaScript Injections and utilising common
facilities provided to enhance browser capabilities
– Firefox extensions provide functionality to capture and edit HTTP/S
forms data when submitted to and received from the web server.
An attacker can change the values of form elements without knowledge
of the user. Even when the HTTPS protocol is used, an extensions
8

10. code can change the secured fields of a form before encryption
and after decryption of data. This allows Man-in-the-Browser
attack possible through malicious Firefox extensions. When a user
submits a form, an extension can intercept the form submission
and change its values. When a response arrives from the server,
again extension can intercept the response and can change it as
required. It do not make any difference whether the secured
channel is used or not, whether form request is POST or GET.
Since, the changes are made by the extension in the browser both
during request and response, it is not observable by a user and
difficult to detect. Examples below are some operations that can
be done through HTML/JavaScript Injections
– Persistent Storage: Persistent storage can be used if you want to
save the current account balance for later use. Internet Explorer
actually provides a nice interface for localStorage and globalStorage
that can be used for exactly this purpose.If thats not possible
(e.g. if you run Firefox), then they simply create a new content
element (thats a <DIV> element called customStorage) where
they store the information.Access to the persistent store is done
via a JavaScript function where you can specify whether you want
to read, write or delete the name and the value of the information
to be stored together with an expiry.
– Getting the actual cash balance for the current account.
– Replacing the login button with a malicious login button.
– Change account balance display (to remove fraudulent transaction
amount. JavaScript will get the fraudulent amount from local
storage into a variable. The correct HTML of the fake amount
(obviously the current balance plus the fraudulent amount) will
be written to the HTML.
– Remember the last login date and replace the "real" last login date
with a fake one. When called, this will walk through the content
elements and find the paragraph that contains last login. It will
then convert the date and time into a JavaScript variable. The
first time, it just store this information in the persistent storage.
The second time, it will replace the real date with the saved one
from the persistent storage.
– Change recipient details on form submission. The original recipient
details will be saved and the wire transfer form will be located. All
these details will be stored in the local storage. The login number,
the account number, the amount and the bank identification number
will be sent to the server, who will in turn reply with the money
mule account details. Then the function will be called which
9

11. will change the recipient details on the transaction. With all the
relevant information at hand, malware will search for the wire
transfer form and put the money mule details received into the
local storage for later use. Malware makes sure that this wire
transfer is executed immediately. Now the recipient details are
changed to the money mule details and finally the form will be
submitted and the wire transfer executed
– One-Time-Password token stealing: For an authentication page
where the user has to provide a OTP, maware will hook into the
onSubmit of the Sign on button. It will save all values (including
the OTP) and then simulate the look and feel of a new page
loading. This new page says that the token password has expired
and the user should please enter another one. The page loading
will be stretched to get a new OTP! All content elements will
be made invisible (via CSS) and the page loading time will be a
simulated for a certain time. With a timeout function, the content
elements keep appearing one by one (exactly how it looks if a page
loads slowly).They check all input parameters (including e.g. that
the OTP is different than the old one)
Briefly, Man-in-the-Browser malware which is virtually undetecable to
virus scanning software allows the attacker:
• not to have to worry about encryption since SSL/TLS happens outside
the browser
• to inspect any content sent or received by the browser
• to inject and manipulate any content before rendering within the Web
browser
• and to create dynamically additional GET/POST/PUT/etc. to any
destination.
3.1 The Method of Attack
3.1.1 Phase 1: Infection
The first phase of an MITB attack is the infection of a target computer3.1 .
A number of techniques have proven to be effective, typically relying on
social engineering to trick a user into doing something unwise, but sometimes
exploiting other browser or network vulnerabilities.
1. User is manipulated by means of phishing e-mails necessary video
codec, pirated software package, interesting PDF document etc. to
download malware-infected software or a patch to exploit browser vulnerability.
10

12. Figure 3.1:
2. At some later time, the user restarts the browser.
3. The trojan installs an extension into the browser configuration.
4. The browser loads the extension.
5. The extension registers a handler for every page-load.
3.1.2 Phase 2: Transaction Takeover
Figure 3.2:
11

13. 1. Monitors all of the user’s activities.
2. Whenever a page is loaded, the URL of the page is searched by the
extension against a list of known sites targeted for attack.
3. When a targeted site is loaded, it registers a button event handler.
4. Extracts all data through the DOM (Document Object Model, a cross-
platform and language-independent convention for representing and
interacting with objects in HTML, XHTML and XML documents)
interface in the browser and modifies them, then continues to submit.
5. The browser sends the form including the modified values to the server.
Figure 3.3:
6. The server cannot differentiate between the original values and the
modified values, or detect the changes and receives the modified values
in the form as a normal request.
7. The server performs the transaction and generates a receipt. The
browser receives the receipt for the modified transaction.
8. Then the extension detects the targeted URL and replaces the modified
data int the receipt with the original. The browser displays the modified
receipt with the original details. Finally, the user thinks that the
original transaction was received by the server intact and authorized
correctly.
12

14. Figure 3.4:
3.2 Banking Malware Example
The user passes all authentication stages, including any two-factor authentication
when needed. The Trojan waits silently for successful login and/or transaction
authorization. The Trojan manipulates the transaction details payee, and
sometimes the amount. In most cases the legitimate payee account is replaced
with a mule account that the fraudster can use. By using social engineering
techniques the user is unaware that they are being impacted. The Trojan
displays fake pages to the user, which may show the transaction details as
originally entered by the user. If additional authentication is necessary to
complete the transaction, the Trojan will interact with the user and ask
the user to enter their authentication credentials in real-time to approve the
transaction.
What makes MITB attacks difficult to detect is that any activity performed
seems as if it is originating from the legitimate users browser. Characteristics
such as the HTTP headers and the IP address will appear the same as the
users real data. This creates a challenge in distinguishing between genuine
and malicious transactions.
13

15. Chapter 4
Banking Trojans
Banking trojans commonly perform what is known as session hijacking abusing
a legitimate users session with the site being accessed while the user is logged
into their account. They steal data from infected computers via web browsers
and protected storage. Once infected, the computer sends the stolen data to
a bot command and control (C& C) server, where the data is stored.
Some MITB Trojans are so advanced that they have streamlined the
process for committing fraud, programmed with functionality to fully automate
the process from infection to cash out.
The banking trojans are generally composed by a Command and Control
webserver(C& C) and a botnet. They generally come with a configuration
file in XML that specifies specific attack methodologies
(i.e.: texttt{^^url_monitored1~~url_monitored2||code_to_change_in_original_page
|| injected_code})
and web injections, as well as the specific builder.
A number of Trojan families are used to conduct MITB attacks:
• Zeus
• Sinowal (Torpig)
• SpyEye
• Carberp
• Feodo
• Tatanga
• ...
14

16. 4.1 Banking trojans capabilities
The banking trojan families have different capabilities. The most common
are the following:
• Bot - An infected computer can perform actions demanded by the C
& C. This bots can be organized in different ways to work as proxies,
to provide the spreading of new configurations, etc.
• Configuration update - It is possible to update the configuration files
after infection.
• Binary update - Some of this trojans have a modular design that
allows them to update the binary functionalities or even add new
functionalities (Ex: Tatanga).
• HTML injection (check previous sections)
• Redirection (check previous sections)
• Screenshots / record video
• Capture virtual keyboards
• Credentials / Certificates / Information theft
• System corruption (KillOS) - The C & C allows the sending of command
that will corrupt the target system in a way that it will be difficult to
traceback the origin of the attacks.
Before going into deeper detail with some techniques used by Zeus and
Tatanga, lets focus on this specific banking e-fraud, how it works and its
main aspects. In order to perform an e-fraud, the banking trojans have to
be work in a transparent way, updating themselves and sometimes trick the
clients so they will install new software. This introduces three important
concepts:
• Social engineering - is the art of manipulating people into performing
actions or divulging confidential information. Consists of applying
deception for the purpose of information gathering, fraud, or computer
system access.
• Real-time integration - the trojans are updated with mule account
databases to aid in the automated transfer of money.
• Circumvention of various 2FA systems - Some banking trojans
even provide techniques to circunvent two phase authentication systems.
15

17. 4.2 Anatomy of an e-fraud incident
Although similar methodologies have been described for generic MITB attacks
we will revisit some of its aspects and mention the typical anatomy of an
e-fraud incident to understand how the previous concepts relate with it:
1. Infection
2. Configuration file update/download
3. Interaction with the user (Social engineering) with: HTML injection,
Mit(B|M|Mo), Pharming, Phishing...
4. Banking credentials theft
5. Account spying
6. Fraudulent transaction
• Manual Mules
• Automatic Man in the Browser (MitB)
7. Money laundering
• P2P Digital Currency.
• The informal value transfer system called Hawala.
• Mules + Western Union (most usual).
The infection process was already described so lets start by how the
update of the configuration file is done. The following sections will be based
on one of the most popular banking trojans, Zeus.
4.3 Zeus configuration files
An important fact to mention is that typically, the bot itself is merely
a framework that hooks itself into the system and hides there effectively
through the use of rootkits. The logics that drives behavior of the bot is
contained in its configuration file.
The configuration file of Zeus is similar to a definitions database for
an antivirus product. Without it, it’s pretty much useless. The logics
contained in the configuration contains the list of banking institutions that
the bot targets, URLs of the additional components that the bots relies on
to download commands and updates, the lists of questions and the list of the
fields that the bot injects into Internet banking websites to steal personal
details/credentials, etc.
16

18. This configuration is never stored in open text. It is encrypted an
although previous generation of Zeus used a hard-coded encryption mechanism
for its configuration, the new generations already encrypt it with a key that is
unique for and is stored inside the bot executable for which this configuration
file exists. This way, configuration file of one bot sample will not work
for another bot sample, even if both samples are generated with the same
builder.
4.4 Domain Generation Algorithms
Since this configuration files need to be updated, the attackers had to come
up with a way to distribute them without compromising the Zeus botnet
controllers. One of the first alternatives they came up with was DGA, the
domain generation algorithm that used date and salt to generate the domains
the bots should contact.
Zeus bots can cycle through a new list of 1,020 domains every day to
call to see which one is hosting the live C & C server. It tries to connect to
the domains in random order and once a file is downloaded and executed, it
stops checking.
Figure 4.1:
After a while, security researchers started to be able to predict and
register domains that will be used by Zbots ahead of time to learn about
the bots activities. So new generations of Zeus are using new alternatives,
for example Peer-to-Peer botnets.
17

19. 4.5 P2P botnets
This paradigm of updating configuration files through P2P networks opens
new alternatives for dynamically changing the bot network and applying new
techniques to hide the origin of the configuration files.
Figure 4.2:
4.6 Social Engineering
Now that we have described how the configuration of Zeus and its botnets
work, lets finally talk of how the social engineering has an important role on
the stealing of confidential information.
Nowadays banks make use of multiple-factor authentication mechanisms
such as mobile sms tokens. The idea is to use evidences which have separate
range of attack vectors (e.g. logical, physical) leading to more complex attack
scenario and consequently, lower risk.
Although the initial idea of this mechanisms was to secure the authentication
process, we will see there are techniques that can workaround them. The
following image shows, for each type of authentication mechanism, the respective
technique that can be used to steal the information.
For the simplest login mechanism that consists of a form with username
and password, we can use keylogging or form grabbing to intercept their
content. This can even be done through pharming that consists of redirecting
the traffic to another website, this can be done by exploiting vunerabilities
18

20. Figure 4.3:
in DNS protocols. The virtual keyboard password can be captured using
screen or video capturing. The one time passwords (OTP) such has code
cards, sms tokens and mobile transaction authentication numbers (mTAN)
can also be attacked. If through some code injection all the code card digits
are asked, then the attacker will have all the code card data. This could be
done in a more transparent way though, either through pharming or phishing
until a big percentage of the code card digits has been stolen. The mTAN or
the sms tokens can also be stolen through code injection and in some cases,
through Man-In-The-Mobile attacks.
4.7 Man-In-The-Mobile
1. The attacker steals both the online username and password using a
malware (ZeuS 2.x).
2. The attacker infects the user’s mobile device by forcing him to install
a malicious application (he sends a SMS with a link to the malicious
mobile application)_4.4.
3. The attacker logs in with the stolen credentials using the user’s pc as
a socks/proxy and performs an operation_4.5.
4. An SMS is sent to the user’s mobile device with the authentication
code. The malicious software running in the device forwards the SMS
to other terminal controlled by the attacker.
5. The attacker fills in the authentication code and completes the operation.
4.8 Tatanga
To provide new evidence of the banking trojan evolution, we will describe
another trojan called Tatanga that was discovered by S21sec in February
19

21. Figure 4.4:
Figure 4.5:
2011. Tatanga has MITB functionalities and affected banks in Spain, United
Kingdom, Germany and Portugal. It is capable of realizing bank transfers
automatically, obtaining "mules" from a server and faking the real balance
and money movements of the victims.
Some characteristics of Tatanga include:
• Very low detection
• C++
• No packers
• Modular design
• Anti-VM, anti-debugging
• Proxys to distribute binaries
• Records video!
One of the major aspects of Tatanga is its modular design that allows
the addition of new binary functionalities. This modules are ciphered using
XOR and BZIP2 and are deciphered into memory when the injection is done
in the browsers to avoid AV detection.
Some of this modules are described bellow:
20

22. • HTTPTrafficLogger
• Comm (Handles ciphering between trojan and control panel)
• ModDynamicInjection (Performs code injecton)
• ModEmailGrabber (Collects email info)
• ModAVTrafficBlocker (Blocks AVs)
• ModMalwareRemove (Removes other malwares, ex: Zeus)
• FilePatcher (Propagation)
• Coredb (Manages the configuration files - 3DES ciphering)
• SmartHTTPDose
• ...
4.9 Banking trojans statistics
To conclude this banking trojan section we will provide some statistics of
Zeus infections to show that this a large scale problem with millions of
infected machines.
Figure 4.6:
Old statistics report over 160 million attempted losses and an actual loss
of 50 million euros!
21

23. Figure 4.7:
22

24. Chapter 5
Counter Measures
As MITB attacks are still in process of evolving there is not a global approach
to defend against them. There are, though, combinations of counter measures
which can effectively resist against certain kinds of attacks. In this section we
are going to review a big number of known counter measures and comment
on their efficiency against MITB attacks. Our final goal is to provide a set of
counter measures which can effectively provide a defense mechanism against
a generic MITMB attack.
We can differentiate the counter measures in two wide categories: active
and passive.
5.1 Active
Active counter measures involve the user in some additional authenticating
steps, at login time, transaction execution time, or both.
Username and password, biometrics: Techniques applied generally
for user authentication like and are not effective because the malware can
intercept or wait until user is past this challenge before taking over.
OTP based: Techniques mostly used by banks for user authentication based
on One Time Passcode tokens. Out-of-Band OTP is an OTP delivered from
an alternative channel of communication, like cellular networks (i.e. GSM).
EMV-CAP OTP is consisted of an electronic physical reader which provided
a users chip-enabled bank card can generate OTP’s. All the OTP based
measures are not effective because the malware can intercept or wait until
user is past this challenge before taking over.
OTP based with Signature: Some forms of OTP tokens can also be used
to electronically sign transaction details, if they are equipped with a small
numeric keypad; user is prompted to enter transaction details on the small
keypad, then a signature code is calculated by the token. This method can
also be used with EMV-CAP OTP. This techniques can be effective against
MitB attack. User enters the transaction details so is aware of the specifics,
23

25. and the banking site can detect if malware attempts to change them. This
solution, though, is inconvenient because usability on the token screen and
keyboard is weak, and the user could be confused and special hardware must
be deployed.
Out-of-Band OTP with Transaction Details: Enhanced Out-of-Band
OTP which contains also information about the transaction so the user can
be able to verify that the right transaction is being performed. This measure
can be trully effective is simple MitB attack but can be vulnerable when the
attack is combined with a Man-in-the-Mobile attack.
Smart Cards with Digital Certificate: PKI digital certificate stored
on a smart card or USB cryptographic token; credential used to perform
client authentication via SSL. This technique is not functional against MitB
attacks as well because he malware can intercept or wait until user is past
this challenge before taking over.
Anti-Virus or Anti-Malware: This solution could be effective, but taking
into account that malware is changing so rapidly that client software is
having trouble keeping up; signature-based detection models are increasingly
ineffective and other models are still improving.
Separate Computer Used Solely for Online-Banking, Live-CDs:
This solution can be effective at a good level but is not convenient to
implement. Malware is less likely to be installed if the computer is not
used for other things but it is not a user-friendly solution.
Hardened Browser on a USB Drive: A hardened browser is shipped
to end-users on a USB drive and hard-coded to only connect to the target
banks Web site; sometimes there is also a PKI credential stored on the
USB device, and used for authentication. This measure can be effective
but many organizations have disabled USB drives or, at least, have disabled
autorun capability for external media, making deployment of this solution
more challenging. Moreover browser updates can also become problematic.
5.2 Passive
Passive counter measures are invisible to the user, yet help identify the user
or flag suspicious activity. These techniques are attractive because they
do not impact the user experience in any way and, as a result, are easily
deployed to protect all customers, even those who do not wish to see visible
security measures..
IP-Geolocation: Based on the end-users computer IP address, this
technique determines the users geographic location and compares it to typical
locations used by this user. This solution could be effective when credentials
are stolen and used elsewhere, these techniques fail against MITB because
the malware is in the users regular browser, at the users typical location.
24

26. Although in cases where credentials are stolen and sold to third persons this
technique could be helpful.
Device-Profiling: A snapshot of the users browser configuration is taken
(via Javascript and HTTP headers) to determine if the user is visiting from
their usual Web browser; in a PC browser environment this technique is quite
effective at uniquely identifying a computer with no interaction from the user.
It can be effective under the same circumstances with IP-Geolocation.
Transactional Fraud Detection: The online-banking application is modified
to make calls to the fraud detection service at every point an organization
thinks may be relevant to fraud. This is typically only done at initial logon
and at specific monetary transaction points where the fraud engine looks
at transactions and compares them to what would be termed normal for
that user or group of users; patterns are detected and warnings raised if
appropriate. It is essential to perform the analysis in real-time, because
the transactions are nowadays processed automatically and are completed in
small amount of time.
Monitor User Behavior: Users Web traffic data is captured and analyzed
from the moment they log on to the moment they complete their session.
Analysis from a single user session, multiple sessions for the same user and
multiple sessions for multiple users, gives the system a complete view of how
the banking application is being used and, more importantly, abused.
5.3 Combination of Active and Passive counter Measures
As we saw before, most of the classical counter measure techniques are not
able to protect users from MitB attacks. The solutions who work seem to
need though a lot of recourses in order to provide accurate results. We
have to consider also the rapid evolution of the MitB browser techniques
used. Concluding we will suggest a solution that we think is best, which is
assembled by a combination of working active and passive solutions.
The following combination can provide a high level of security against a
generic MitB attack:
• Active: Out-of-band transaction detail confirmation, followed by one-
time-passcode generation: this technique leverages devices such as
mobile phones that are already being carried by the intended end-
users, and enables review of transaction details outside the influence
of malware on the user’s PC.
• Passive: Fraud detection that monitors user behavior: this server-
side monitoring of a user’s movement through a banking Web site,
inclusive of transaction execution steps as well as the steps leading
there, provides flexibility for financial institutions to adapt to constantly
25

27. evolving malware features, and detect suspicious patterns of activity
for immediate intervention.
The combination of flexible authentication technology enabling easy
step-up authentication when risk levels dictate along with ongoing user
behavior monitoring provides a layered defense against malware threats.
26

28. Bibliography
[1] Nattakant Utakrit, "A Review of Browser Extensions, a Man-in-the-
Browser Phishing Techniques Targeting Bank Customers"
[2] Philipp Gühring, "Concepts against Man-in-the-Browser Attacks"
[3] http://securityblog.s21sec.com/
[4] "Evolution of Zeus botnet", http://www.symantec.com/connect/
blogs/evolution-zeus-botnet
[5] "How trojan.Zbot.B!inf uses crypto api" http://www.symantec.com/
connect/blogs/how-trojanzbotbinf-uses-crypto-api
[6] RSA Labs, "MAKING SENSE OF MAN-IN-THE-BROWSER
ATTACKS", http://www.rsa.com/products/consumer/whitepapers/
10459_MITB_WP_0611.pdf
[7] Frank Kim and Ed Skoudis, "Protecting Your Web Apps",
http://www.sans.org/reading_room/application_security/
protecting_web_apps.pdf
[8] Prajwol Kumar Nakarmi & Sajjad Rizvi, "Man in the Browser Attack"
[9] Karel Miko, "Internet Banking Attacks"
[10] http://www.cacert.at/svn/sourcerer/CAcert/SecureClient.pdf
27