This article was published by our partner OneSpan, written by Samuel Bakken – Senior Product Marketing Manager, Greg Hancell – Senior Manager of OneSpan’s Fraud Consultancy and with input from Frederik Mennes – OneSpan Director of Product –and Will LaSala – Senior Director of Global Solutions.
This past summer, the FBI warned of an increase in malicious activity targeting mobile financial services as mobile banking activity surged in response to COVID-19 and associated lock-downs. That warning came to fruition at the end of December with the discovery of an “evil emulator farm” that mimicked victims’ mobile devices to defraud bank account holders in the U.S. and Europe of millions of dollars.
The purpose of this article is to make financial institutions aware of this newly discovered threat as well as explain the layered approach to mitigating such increasingly sophisticated fraud.
Never-Before-Seen Mobile Fraud Scale and Speed
Researchers say the scale and speed of this scheme sets it apart from past incidences of mobile fraud. The attackers built a network of approximately 20 emulators mimicking 16,000 mobile devices and leveraged automation which enabled the draining of millions of dollars from bank accounts in just days. A mobile emulator is a virtual mobile device that imitates the functionality of real mobile devices and impersonates a user’s interaction with it. Emulators were originally developed to enable automated testing of software on a wide variety of devices.
Actions automated by the attackers included at least the following:
- Harvesting the device attributes
- Inputting usernames and passwords
- Initiating transactions
- Receiving and stealing one-time authorization codes sent via SMS
- Inputting those stolen SMS codes to complete transactions
Harvesting Mobile Device Identifiers
In some cases, the fraudsters mimicked the victim’s existing devices. In other cases, the fraudsters simulated the victim using a new device to access their bank account. The researchers aren’t certain how banking credentials were compromised in the first place, though it’s plausible credentials were stolen by malware, harvested via phishing attacks or found on the dark web. Exactly how device identifiers were gathered is unclear, but it seems logical that such data was collected by mobile malware present on victims’ devices.
What Financial Institutions Can Do to Mitigate Similar Mobile Threats
There’s no single silver-bullet that will slay this mobile threat. The best protection is a layered, defense-in-depth approach consisting of (but not limited to) the following:
- Mobile app shielding with runtime protection
- Strong customer authentication
- Client- and server-side risk analysis for fraud prevention
Combat Emulators and Other Mobile Threats with App Shielding including Runtime Protection
While details of how the attackers identified the weaknesses in the victim banks’ mobile apps and fraud detection systems, it stands to reason that they were able to reverse-engineer certain aspects of the mobile app. It’s likely that the attackers simply downloaded the legitimate apps from the official app stores and began poking and prodding the apps on an emulator to examine the app as it executed.
Mobile app shielding with runtime protection would have detected such activity and promptly shut the app down to prevent this malicious activity. Not only does advanced mobile app shielding stop an app from running on an emulator, it also detects and blocks several tools used by adversaries to reverse-engineer the app and understand how the app operates.
With the sophistication of this threat, it not unreasonable to assume that the attackers were able to reverse-engineer the app to understand how it was bound to a user’s device (if at all) and how it communicated with the bank’s server-side APIs. Mobile app shielding with runtime protection would have added yet another layer of security control that would have made the fraudster’s job that much more time consuming and expensive.
In addition to reverse-engineering mitigation, app shielding with runtime-protection offers several capabilities that make it more difficult for attackers to carry-out an attack on mobile banking apps and users:
- Preventing app impersonation by detecting app repackaging (i.e., maliciously modifying and re-publishing an app)
- Identifying code modification and/or injection of malicious runtime libraries into an app
- Reducing the risk of data leakage by stopping screenshots and malicious keyboards
- Detecting privilege escalation by recognizing jailbroken or rooted devices
- Mitigating UI overlay attacks by preventing foreground override on Android devices
Combat Account Takeover by Modernizing Authentication
Financial services analyst firm recently Aite Group recently suggested in its ”Revisiting Your Authentication Control Framework” report that “Financial institutions, fintech firms, and merchants need to take a step back and review their authentication control framework. If it has been a few years since that framework was last reviewed, with the technological advances over that time frame, it will likely need updating.”
The theft of usernames and passwords used to authenticate users and payments set the stage for this mobile fraud. These static, “single-factor” credentials are vulnerable to phishing if they haven’t already been compromised as part of other data security breaches. Implementing multi-factor authentication (MFA) that uses dynamic, one-time authentication codes significantly mitigates the risk of account takeover. Along with impersonating users’ existing devices, in some cases the attackers were able to activate new devices with victims’ accounts.
A bank should also not take the decision of what channels to use to transmit dynamic authentication/authorization codes lightly. SMS codes are known to be vulnerable to phishing and even interception. In this case, the masterminds behind the scheme were able to receive SMS codes with the impersonated devices, rendering the codes useless in terms of protecting banking accounts. A typical attack on SMS one-time-passwords/passcodes (OTP) will start by directing the victim to a phishing webpage that looks like the bank’s. There, the user will enter their details that triggers the transmission of an OTP over SMS. Malware present on a victim’s device will then obtain SMS codes and forward them to the attacker, meaning the victim never connects with the bank as they are interacting with a phishing page.
Push notifications sent via an encrypted channel to a mobile app that is strongly bound to the user’s device during activation would have likely stopped attackers from gathering and using SMS one-time passcodes to access accounts or authorize payments. In addition, leveraging mobile devices’ hardware features (e.g., Secure Enclave on iOS devices or Trusted Execution Environment / Secure Element on Android devices) make it much more difficult to steal device identifiers. Requiring biometric authentication along with the confirmation of a push notification would have provided another layer of defense that may have impeded these attackers.
It’s also important that financial institutions apply advanced anti-tampering technology (see mobile app shielding with runtime protection below) to any mobile banking app. This reduces the risk that adversaries could tamper with or reverse-engineer the device-binding process in order to replicate a legitimate user’s iteration of a mobile banking app on an emulated device.
Combat Sophisticated Digital Fraud with Client- and Server-side Risk Analysis
Gartner has suggested an online fraud detection framework consisting of five prevention layers – endpoint-centric, navigation- and network-centric, user- and entity-centric, cross-channel user- and entity-centric, and big data user and entity analytics – to detect online fraud. Because the fraudsters used an emulator, they were able to overcome certain aspects of the first layer of prevention. We see more and more examples of sophisticated fraudsters being able to simulate client-side data such as device, location, and time-of-day.
This mobile fraud incident, and the increasing maturity of online fraud rings in general, speak to the need for a more complete fraud prevention solution with properly configured, additional layers. At this time, it’s much more difficult for attackers to overcome subsequent prevention layers:
- Layer 1: Endpoint-centric – Analysis of endpoint behavior and location correlations; this layer also includes malware detection and device fingerprinting
- Layer 2: Navigation- and Network-centric – Analysis of session, network, and navigation behavior and suspect patterns
- Layer 3: User- and Entity-centric (single channel) – Analysis of user/entity behavior by channel (e.g., online banking, mobile banking, etc.)
- Layer 4: User- and Entity-Centric across channels and products – Analysis of anomaly behavior correlated across channels
- Layer 5: Big Data User and Entity linking – Analysis of relationships to detect organized crime and collusion
As you may have guessed, gathering and correlating risk signals across these areas becomes nearly impossible “at the speed of human.” Any complete online fraud detection system needs to leverage server-side machine-learning and contextual automated rules in order to make any impact here.
Detecting Automated, Non-Human Interaction
The evil emulation farm simulated victims’ devices, which puts any bank that relies solely on identifying / trusting mobile devices by an ID or with a one-time code sent via SMS at risk. Had the targeted banking apps enabled session analytics along with endpoint behavior and location correlations, the device could be identified as being emulated due to the lack of “human-like” interaction behavior (i.e. the way a human interacts with a device such as typing cadence, angle, height and may other behavioral traits).
How and when a user interacts with a session can provide insight into their usual session behavior. This is an additional prevention layer that can make an attacker’s job harder as the automated emulator would need to consistently mimic the human victim’s speed of interaction and more.
Monitoring More than the Log-in Event: Continuous Session Monitoring
As we move up to layers 3 and 4 – it’s important to account for banking session activity beyond the initial log-in. Ultimately an attacker is not going to pay a user’s bills for them, their aim is extracting funds. It is therefore crucial that banks apply continuous monitoring to review new devices, beneficiaries and transactions. The purpose of this review is to identify whether devices, beneficiaries, or transactions are new and/or known to (i.e., used by) any other of a bank’s consumer or commercial customers.
Automating Fraud Detection/Prevention with the Power of Machine Learning
Understanding analytics around typical activity of all users and devices can help to identify mass device activation, mass beneficiary creation and mass transactions – all signals of a scaled attack. In this case hindsight suggests the bank could have been alerted to any one of many stages of the attack. These include attackers activating numerous new devices, emulating devices, creating new beneficiaries, transferring high amounts, draining the balance of accounts and sending money to previously unknown accounts.
Such indicators, as well as thousands more, can be provided to machine learning models, that are able to operate in a highly dimensional space far superseding that of a human, and are able to provide a prediction (anomaly / risk score) in real time. Thus, enabling a bank to stop the attack in its tracks preventing its propagating and enabling an automated reaction.
Summary
In the end, to protect their customers and institutions from adversaries’ continued evolution and innovations, financial institutions must take a layered approach to online banking fraud consisting of strong customer authentication, server-side risk analytics, and advanced mobile app security including mobile app shielding with runtime protection.
