Trusteer

Once malware has access to the browser (for simplicity. let’s assume it is Microsoft Internet Explorer), it can act as a “man in the browser”, potentially modifying incoming HTML from the web server. This capability enables malware to conduct various interesting attacks:

• Advanced phishing: in regular phishing attacks, the URL in the address bar is different than the bank’s genuine URL. In pharming attacks, the attacker cannot forge the genuine SSL certificate of the bank. Yet when malware replaces the bank’s post login page with a page that requires more information (such as credit card, PIN, SSN, CVV2, memorable word and security question and answer), the user is likely to fall prey: the URL appears genuine, the SSL certificate is valid, and any 2-way authentication methods (such as a customized, per-user image and/or phrase) match. This is because the malware modifies the incoming HTML at the browser, after the browser itself decrypts the SSL, and after the security image has been shown to the user. This is the advantage of attacking the user from within the browser.

• Transaction takeover: the malware can wait for the user to conduct a transaction (such as wiring money to another account). At this time, the malware can change the transaction submission so that the money is wired to another account. In some cases, this suffices for the fraudulent transaction to succeed. However, some banks employ stronger security measures, such as requiring the user to provide a one-time password (typically generated by a hardware or software token). This may be implemented as a two phase process – the first page for the user to fill the transaction details and submit, the second page for the user to verify the transaction details by filling the one time password. Now, a naïve malware would fail in such case, since the user will see the details of the fraudulent transaction in this verification page, rather than the details of the user’s intended transaction. However, malware that is capable of modifying HTML can simply replace the details of the transaction displayed to the user by the details of the transaction expected by the user, at the HTML level. The user will think he/she signs the intended transaction, but the actual transaction that will be conducted by the server is the fraudulent transaction.

Accessing the HTML and modifying it, once in the browser, can be accomplished in several ways:

• Malware can load itself into the browser as a plug-in, in which case it can exploit the standard (and rich) API the browser offers to plug-ins, particularly around DOM (which is essentially the data structure in which the browser stores the parsed HTML).

• Malware can access the browser externally, via API that the browser provides for the system. In such case, the malware typically enumerates all instances of open browsers, chooses the ones that are of interest to it, and accesses the DOM via the API, much like it were a BHO loaded by the browser into its own process space.

• Malware can hook/patch the communication layers that the browser uses in order to read data from the web server. For instance, by hooking/patching the WinInet InternetReadFile family of functions, the malware can read and manipulate the HTML response from the web server, just before Microsoft Internet Explorer receives it. It seems that this method is preferred by the newer breed of malwares, probably because its stealthier than BHOs (which are visible in Internet Explorer under Tools -> Manage Add-Ons)

High profile malware such as Torpig and SilentBanker are notorious for employing HTML modification techniques in order to “phish” victims of credentials and sensitive information. For example, full card information (card number, PIN, CVV2, name, etc.) is requested from the victim, which is probably used later for fraud against non online-banking channels.