Recently, we were approached by a bank that experienced an attack on the SMS channel used to authenticate online banking transactions. Customers infected with PC-based financial malware were asked to install a malicious Android mobile application. The malicious application was permitted to access the device’s SMS channel and redirected SMS one-time passwords (OTP) to the fraudsters. The malware used the bank’s brand and the mobile brand of Trusteer* to encourage users to install the mobile malware component of the attack. It’s time for this bank to update its risk engine.

This type of attack isn’t new. As explained in a blog post two years ago, SMS-stealing malware is embedded in many fake mobile applications and abuses the brands of multiple banks. The attack flow is shown below.

Going Mobile

First, we are seeing increased usage of mobile devices as part of advanced fraud schemes. A “siloed” view of the threat landscape drastically limits the financial institution’s ability to combat this fraud.

In the above example, the attack starts on the PC with a Man in the Browser (MitB) malware infection. Detecting this infection and associating it with the device and account being accessed is a key risk indicator. It colors the account as high risk, which enables the prevention of fraudulent access and transactions from the customer’s infected device or a separate fraudster device.

Mobile Malware

Second, the attack involves the installation of mobile malware. The Android security system asks users to give permission to new applications that want to access sensitive data on their phones, like SMS content. Most users will, of course, approve all required access just to “get it over with.”

Mobile malware is evolving. Banks should incorporate mobile device risk into their risk engine analysis. Mobile risk factors include a lack of malware infection detection processes, risky OS settings (for example, allowing the installation of apps from any source), the installation of rogue applications and jailbroken/rooted devices.

A New Device

Third, the final step of the attack occurs when the fraudster accesses the account from a new device using the stolen credentials and ultimately commit fraud. The new device is often a PC but can also be a mobile device. Banks react to new devices by stepping up authentication with methods like security challenge questions. Remember the malware on the PC? The answers to these challenge questions are all in the hands of the fraudsters. If you challenge users with SMS OTP, as many banks do, we’re back to square one with the compromised SMS channel. Other approaches use anomaly-detection to analyze factors such as geo-location and access time, but fraudsters understand these controls and use proxies and other techniques to evade detection.

Covering the Blind Spot in a Risk Engine

Risk engines must evolve. When the fraudster accesses the account, the risk engine can prevent fraud if it has visibility into the full attack life cycle. Seeing a new device logging in and accessing the account after a malware infection is detected on a PC or mobile device should be treated as high-risk and all transactional activity should be reviewed. For example, IBM Security Trusteer Pinpoint Criminal Detection incorporates these risk indicators, discovered by different components of the IBM Security Trusteer fraud prevention platform to achieve conclusive fraud-risk detection.

Finally, the attack isn’t over until it is over. One of the biggest challenges banks face is helping customers remove malware components from their devices so they can safely resume online banking. This is a constant operational struggle as anti-malware solutions can’t detect financial malware strains due to their evasive nature. Solutions like IBM Security Trusteer Rapport and IBM Security Trusteer Mobile Risk Engine solve the remediation challenge by automatically removing the financial malware variants on the end user’s PC and providing the user with clear instructions for removing the malicious application from the mobile device.

* Trusteer was acquired by IBM in August 2013.

More from Fraud Protection

What’s up India? PixPirate is back and spreading via WhatsApp

8 min read - This blog post is the continuation of a previous blog regarding PixPirate malware. If you haven’t read the initial post, please take a couple of minutes to get caught up before diving into this content. PixPirate malware consists of two components: a downloader application and a droppee application, and both are custom-made and operated by the same fraudster group. Although the traditional role of a downloader is to install the droppee on the victim device, with PixPirate, the downloader also…

Unveiling the latest banking trojan threats in LATAM

9 min read - This post was made possible through the research contributions of Amir Gendler.In our most recent research in the Latin American (LATAM) region, we at IBM Security Lab have observed a surge in campaigns linked with malicious Chrome extensions. These campaigns primarily target Latin America, with a particular emphasis on its financial institutions.In this blog post, we’ll shed light on the group responsible for disseminating this campaign. We’ll delve into the method of web injects and Man in the Browser, and…

PixPirate: The Brazilian financial malware you can’t see

10 min read - Malicious software always aims to stay hidden, making itself invisible so the victims can’t detect it. The constantly mutating PixPirate malware has taken that strategy to a new extreme. PixPirate is a sophisticated financial remote access trojan (RAT) malware that heavily utilizes anti-research techniques. This malware’s infection vector is based on two malicious apps: a downloader and a droppee. Operating together, these two apps communicate with each other to execute the fraud. So far, IBM Trusteer researchers have observed this…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today