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.
CTO, Trusteer, an IBM company