mitb-120604175922-phpapp02

Man-in-the-Browser AttacksMario AlmeidaUmit BuyuksahinEmmanouil Dimogerontakis Aras TarhanDecember 20, 2011Contents1 Background22 Introduction32.1 The Risk in Man-in-the-BrowserAttack 42.2 Global Threat of Man-in-the-Browser 42.3 Evaluation 52.4 Point of Attacks 63 Background & Overview of the Method of Attack83.1 The Method of Attack 103.1.1 Phase 1: Infection 103.1.2 Phase 2: Transaction Takeover 113.2 Banking Malware Example 134 Banking Trojans144.1 Banking trojans capabilities 154.2 Anatomy of an e-fraud incident 164.3 Zeus configuration files 164.4 Domain Generation Algorithms 174.5 P2P botnets 184.6 Social Engineering 184.7 Man-In-The-Mobile 194.8 Tatanga 194.9 Banking trojans statistics 215 Counter Measures235.1 Active 235.2 Passive 245.3 Combination of Active and Passivecounter Measures 25

#Chapter 1BackgroundInitially, 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 crim,inal 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.

Chapter 2IntroductionFirstly, 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 loggingSometimes, 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 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 AttackThe 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-BrowserMitB 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 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, andas a result, have experienced an increasing number of MITB attacks.2.3 EvaluationMan 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.2. Upon the initiation of a legitimate online transaction, the Trojan is triggered into action and launches its MITB functionalities3. 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 AttacksIt 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.

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 andall visitors were silently infected with a variant of a MITB Trojan.

Chapter 3Background & Overview of the Method of AttackThe 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 itsInternet 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 extensionscode 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 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 whichwill 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 Attack3.1.1 Phase 1: InfectionThe first phase of an MITB attack is the infection of a target computer3'[footnoteRef:2]. [2: 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.]

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.

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.

Figure 3.2:Customer's web browser3.1.2 Phase 2: Transaction Takeover

1. Monitors all of the users 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 crossplatform 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.Figure 3.4:

3.2 Banking Malware ExampleThe 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.Chapter 4Banking TrojansBanking 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 ...4.1 Banking trojans capabilitiesThe 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.4.2 Anatomy of an e-fraud incidentAlthough 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. Infection2. Configuration file update/download3. Interaction with the user (Social engineering) with: HTML injection, Mit(B|M|Mo), Pharming, Phishing...4. Banking credentials theft5. Account spying6. 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 filesAn 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, its 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.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 AlgorithmsSince 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.4.5 P2P botnetsThis 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 EngineeringNow 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

Figure 4.3:|SCREEN-CAPTURING

Virtual keyboard

PHARMINKEYLOGGINGG ACode card f1

ID + PasswordFORM GRABBINGOTP(ft}

CODE INJECTION^^ SMS : mTAN

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-Mobile1. The attacker steals both the online username and password using a malware (ZeuS 2.x).2. The attacker infects the users 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 users pc as a socks/proxy and performs an operation_4.5.4. An SMS is sent to the users 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 TatangaTo provide new evidence of the banking trojan evolution, we will describe another trojan called Tatanga that was discovered by S21sec in February

Figure 4.4:

Figure 4.5:ID + PASSWORDZeuS infectedOTP:0023424 COMMANDSMitmo Infected2011. 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:

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) SmartHTTPDose4.9 Banking trojans statistics

Figure 4.6: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.Old statistics report over 160 million attempted losses and an actual loss of 50 million euros!

Figure 4.7:

Chapter 5Counter MeasuresAs 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 ActiveActive 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,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 PassivePassive 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.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 MeasuresAs 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 onetime-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 constantlyevolving 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.Bibliography[1] Nattakant Utakrit, "A Review of Browser Extensions, a Man-in-the- Browser Phishing Techniques Targeting Bank Customers"[2] Philipp Guhring, "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