Recently, a large U.S. bank client of IBM received a notification that malware was identified on one of its client’s devices. The malware was identified using a server-based malware-detection tool that identifies the presence of malware on all devices that can initiate an online banking session. The bank discovered that the user in question had not logged in to his or her bank account around the time the malware was identified, and therefore, it did not understand how malware could have been detected on the user’s device or how credential theft could have taken place.

In this case, the malware on the user’s device captured the user’s credentials at login and immediately communicated them to the fraudster’s command-and-control (C&C) center. Interestingly, the malware requested the user’s one-time password (OTP) at login, even though the user logged in from his or her regular device.

At the same time, the malware blocked the user’s credentials from being submitted to the bank. Instead, it injected a page notifying the user that the bank’s website was temporarily down (see below). Because the login request never reached the online banking server, the bank had no record of the legitimate user attempting to log in. Why would a fraudster go to such lengths rather than simply using the compromised credentials to initiate a new user session?

Injected malware message to the online banking website

Bank Risk Engines and Credentials Theft

The short answer is to evade detection by bank risk engines. Banks use these risk-based analytic tools to detect a variety of anomalous conditions that could be indicative of fraud. These risk engines are often used to identify credentials theft by looking for multiple devices simultaneously logged in to a single account, as well as successive user logins from locations that are geographically too far apart for an account owner to possibly travel within the given time frame.

When either of these conditions is met, the bank can quickly identify that fraud is being attempted and take appropriate actions. However, because fraudsters tend to be persistent and innovative, they have developed new approaches to circumvent these detection techniques.

The Risk Engine View

he following is an abbreviated representation of the bank’s log file in the example provided above:

Based on the log file, six days after accessing the account, the user logged in on an unrecognized device from a new location. Users commonly change devices and frequently travel, so this situation was flagged by the bank’s real-time risk engine for secondary authentication. The user successfully entered an OTP and was allowed to log in. However, things are not always as they appear.

The Trusteer Pinpoint View

Another view of the sequence of events can be found using an abbreviated representation of the log file generated by IBM Security Pinpoint Criminal Detection:

In this sequence, we are able to see a new, previously hidden event on line two. Because the user’s login credentials were blocked from being submitted, the bank’s online application and risk engine did not see the action indicated on line three. However, Trusteer Pinpoint Criminal Detection identified this action, which occurred four minutes before the action on line three.

Line two shows that the user attempted to log in, but the credentials never reached the bank’s server. Blocked credentials followed by a login attempt from a different machine in a distant location are clear indicators of real-time credential theft. Because the credential transmission was blocked, the bank’s risk engine only saw one new login attempt: the fraudulent one (line three).

By doing this, the criminals greatly increase the likelihood of avoiding detection and successfully committing fraud. Criminals often use a session-blocking Man in the Browser (MitB) technique to access commercial accounts that require an OTP for login. Using available malware, such as Zeus or SpyEye, cyber criminals can capture the complete set of login credentials, including OTPs, immediately log in to a compromised account before the OTP expires and block the legitimate user login attempt from reaching the bank.

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