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.
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.
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.