Mobile Device Theft-based Fraud Attack Vectors

1. Introduction

Smartphones have changed the way people access digital services and store personal information. This includes services and information related to their day-to-day banking, given the adoption of mobile banking applications and related services such as USSD banking. As such, the banking fraud threat landscape has changed to include new attack vectors against mobile devices and the applications/information stored within them, which includes vectors that start with physical access to the device.

According to the latest statistics from the South African Banking Risk Information Centre (SABRIC), there was a significant increase in the number of banking fraud incidents that followed theft of the fraud victim’s mobile device^[1]. Over ten thousand incidents of banking fraud that involved theft of the victim’s device and/or SIM swap were recorded in 2020, resulting in a loss of over R120m. This is also reflected in the sharp increase of the number of mobile device theft-based fraud incidents, that MWR has assisted various financial institutions in investigating over the last few years.

While all of the vectors used to commit these mobile fraud attacks are not definitively known, several have been theorised and are discussed in this article. Additionally, we will look at controls mobile application developers can incorporate to mitigate the risk of such attacks, and what mobile banking users can do in order to limit the risk of falling victim to such attacks.

2. Attack Vectors

We will take a generic view of the mobile application and device attack surface from the perspective of an attacker with physical access to a victim’s device. We are also making the assumption that the attacker has unlocked access to the device – this could be achieved in a number of ways:

The attacker stole the device while it was in an unlocked state. As cellphone snatching was one of the main ways devices were stolen^[2], this would be possible as the victim would likely be actively using the device at the time. Alternatively, the device may not have a lock screen set at all.
The attacker guesses the device lock screen PIN, password, pattern or other unlock credential. This is made more likely if the device had an easily guessable unlock credential.
The attacker gains knowledge of the device lock screen credential from the victim. For example, this could be achieved through shoulder surfing the victim while they unlock their device, prior to stealing it.
The attacker could phish the victim for the device lock screen credentials. Similar phishing campaigns by organised crime groups have been documented in the past.^[3]^[4]
Some device unlocking tools are available to law enforcement agencies, which are advertised as being able to unlock modern Android and iOS smartphones^[5]. Should an attacker gain access to these tools, they could be useful in compromising unlock credentials. However, these devices are generally not freely available.

The ideal scenario for an attacker would be to know the device unlock credential, as this would allow them to add fingerprints, change settings, enable developer options, etc. Additionally, an attacker aiming to exploit technical vulnerabilities would likely want to jailbreak or root the device to gain privileged access to its operating system (OS), which allows them to bypass platform sandbox controls. Rooting and jailbreaking would generally result in a device restart, which would lock the device again, further justifying the need for them to obtain device unlock credentials.

2.1. Authentication Credentials

Naturally, stored banking and other sensitive credentials would be the first port of call for an attacker attempting to gain access to an application on a stolen device.

Credentials could be exposed on a device in a number of ways, some not immediately apparent to the developer or the user. In most cases where an attacker has access to the device, they also have access to the user’s email, messaging applications, stored notes, and social media. If a user shares or exposes their credentials through any of these channels, compromising the credentials becomes as simple as finding them. If the attacker managed to compromise the device PIN or password and it was reused for the targeted application, it would also lead to a straightforward compromise of that application.

A less obvious way in which a credential could be stored is through the browser credential storage. Mobile browsers typically allow users to store credentials used to authenticate to web applications. An attacker can use the mobile browser on the stolen device to authenticate to a web application related to the targeted mobile application. In the case of banking applications, this could be the bank’s web application.

This removes the need to access the mobile application altogether; alternatively, using publicly available tools, the attacker could extract these credentials and use them on the mobile application.

How the targeted application stores credentials and handles authentication might similarly expose the credentials; sometimes through easily exploitable vulnerabilities, or overlooked platform-level nuances. We will discuss some of these areas below.

2.1.1. Device Storage Mechanisms

Android and iOS have local storage mechanisms tailored for different uses. Developers can use these mechanisms to conveniently store data and user preferences. Standard local storage mechanisms are not protected against exfiltration of data on rooted and jailbroken devices. As such, an attacker with knowledge of the device lock screen credentials could root/jailbreak the device and access the local storage in search of any credentials stored by the application on the device.

Alternative methods for exfiltration of local storage is via backup mechanisms on Android and iOS. If the device is already in an unlocked state and developers stored sensitive information insecurely, it becomes trivial to enable developer features and use device backup functionality.

2.1.2. Biometric Authentication

Biometric authentication is an attractive target to attackers looking to gain access to an application that uses this mechanism. The complexity of implementing biometric authentication securely is often overlooked as public guides often provide working, but insecure implementations.

A common vulnerability in biometric authentication is when the application does not invalidate the biometric credential upon addition of new biometric material to a device. This would allow attackers with knowledge of the device lock screen credentials to access the target application by simply adding their biometric material e.g. fingerprint or face ID to the device.

Insecure biometric authentication can also be subverted through dynamic instrumentation^[6], though this requires a more technically sophisticated attacker and for the device to be rooted/jailbroken.

2.1.3. Device logging and Request Caching

Developers often log application data to allow for debugging. Depending how content is logged and what it contains, it might expose user credentials. The most likely avenue for this to occur is in logging request and response data that contains the user’s credentials or authentication tokens. An attacker could access these logs on the device and retrieve the credentials.

Certain communication libraries cache response data automatically. This could also serve as a vector to compromise session or authentication tokens that can then be used to interact with the back-end API.

2.2. Password Reset and 2FA Mechanisms

Password reset requests or requests to perform sensitive actions, such as payments, are often verified using a second factor authentication mechanism (2FA). This is typically in the form of a link, one time PIN, push notification or other token sent to the user’s email address or cellphone number. Attackers with access to a user’s device will also likely have access to their email accounts and messaging application; thereby making any authentication mechanisms relying on these second factors ineffective. As such, if an application solely relies on these mechanisms to allow users to reset their account password, the attacker would likely be able to exploit them and gain access to the account.

3. Developer Recommendations

Developers should consider what their application’s attack surface is and who the likely threat actors are that would target it. In the context of fraud after the theft of a mobile device, the threat actor is someone with physical, and assumed unlocked, access to the victim’s smartphone. From a technical perspective, the following areas should then be considered likely targets for the threat actor and reviewed with the assumption that the attacker has authenticated access to the device:

Biometric authentication
Password reset and 2FA mechanisms
Local storage
Device linking and unlinking mechanisms
User education
Logging, detection and response

3.1. Biometric Authentication

A secure biometric authentication implementation relies on secure storage mechanisms to store a biometric authentication credential such that only the currently enrolled biometric material can unlock it. This is somewhat simpler on iOS than on Android, as the iOS environment and device specifications are more strictly controlled. Developers can store the credential in the Keychain^[7] directly and configure it to only be unlocked by the currently enrolled set of biometric credentials. The system then does the hard work of ensuring that a real fingerprint or faceID has been presented.

Android’s equivalent to the Keychain, the KeyStore^[8], cannot be used to store arbitrary data; it only supports cryptographic keys and certificates. A secure biometric authentication mechanism on Android must use the KeyStore to store an encryption key that is protected by the current set of biometric enrollments. This key is then unlocked by a biometric scan which can then be used decrypt an encrypted credential stored elsewhere on the device. This is facilitated through a so-called CryptoObject that is linked to a set of biometric enrollments.

Given that third-party device manufacturers design and create Android devices, the security and specifications of biometric sensors differ. Luckily, Android imposes restrictions on biometric sensors based on a compatibility performance classification^[9]^[10]. While these restrictions can serve as a baseline measure of trust, the developer should also ensure that encryption keys protected by biometric enrollments are stored in hardware/strongbox backed KeyStores. If this is not the case, the keys can be exfiltrated on rooted devices.

3.2. Password Reset and 2FA Mechanisms

When performing a password reset, applications should use traditional out of band channels but additionally rely on a third factor such as something that the user knows and/or has; for example, a bank account number, card number and/or card PIN.

This protects users who have had their devices stolen, since while an attacker could get access to 2FA tokens via SMS or email, they would have no way of knowing the third factor.

3.3. Local Storage

Ideally, sensitive information such as user credentials should not be stored on the device. If such information needs to be stored, secure storage mechanisms are available to facilitate just this. They are specifically tailored for storing relatively small portions of data, such as encryption keys or user secrets. The secure storage mechanisms are normally backed by secure hardware components that limit the risk of the key material entering the operating system layer, and become accessible with root access.

Debug logging and request caching should also be disabled during the build process for mobile application release candidates, in order to prevent exposure of sensitive user credentials.

3.4. Device Linking and Unlinking Mechanisms

Device linking is an important component of mobile application security, especially for banking applications. The bank should have the ability to unlink devices such that they can no longer be used to access the user’s bank account in the event that the device was stolen. This can be highly effective at reducing fraud, although it is reliant on the user promptly notifying the bank when their device is stolen.

3.5. User Education

User behaviour plays an important role in whether or not fraud attempts would be successful. Therefore, users’ demographics and levels of technical understanding should also be considered. An understanding of the userbase would allow developers to have targeted user education campaigns to guide them in protecting themselves. Key points to include in such campaigns are described in the User Recommendations section that follows.

3.6. Logging, Detection and Response

The detection and response capability of the application is another important factor to consider. Detailed event logs are highly useful in fraud investigations and in determining whether technical vulnerabilities were exploited. We recommend logging at least the following information:

Device identifier (UUID or IMEI)
Detailed authentication events, including the authentication type i.e. whether the user authenticated via biometrics, passcode, password etc. Care should be taken to ensure sensitive information such as the user’s password is not included in these event logs.
Password reset events
Device IP address
Application functions used (transfers, beneficiary changes, payments, device linking, etc.)
Device make, model, and OS version information

Based on MWR’s experience on various fraud investigations, it was often the case that fraudulent transactions were very consistent and identifiable. With detailed logs, automated fraud detection mechanisms could be implemented based on relatively simple detection rules. These rules could be based on location, time, sizeable transfers to accounts not transacted with yet, etc. Some creativity will have to be applied here, but this can be an efficient way to reduce the number of successful fraudulent transactions. Automated rule-based detection mechanisms will be bypassable if the rules can be determined or inferred, so they should not be set in stone, but should rather evolve with the actions that the attackers normally take and continuously be updated to cater to the evolving threat landscape.

4. User Recommendations

If a device is stolen, users should notify their bank as soon as possible. In most cases, this would allow the bank to then unlink the device from the user’s account and prevent access.

iPhone users also have the ability to use the Find My iPhone feature to remotely lock or erase the device if it is lost or stolen. This feature is useful in removing any sensitive information and applications from the device. Android devices might have similar alternatives, but this depends on the device manufacturer, model and OS version.

Users should be wary of phishing attempts following the theft of a device. Given the amount of personal information that the attacker could potentially gain from the stolen device, targeted phishing campaigns could prove very effective. Phishing has been used to target iPhone users in an attempt to steal iCloud credentials^[11] to disable the Find My iPhone feature so that the phone is usable after lost mode has been enabled.

Password security is a specific area that is frequently targeted and that has been a problem area in all fields of information security. Users can limit their own exposure and make it infeasible that their passwords could be guessed or brute-forced by following the below guidelines:

Never reuse passwords across applications
Never reuse the device lock PIN or password in other applications
Never store passwords in note taking applications as they would generally be stored insecurely
Never share passwords, especially through messaging and email applications
Use passwords generated by a reputable password manager and enable biometrics on all applications that could potentially contain sensitive information, such as email clients and messaging applications. Generated passwords should have a good length and complexity, to make it harder for attackers to perform password guessing attacks.

Password length has the biggest impact on password strength^[12]. To ease the burden on users’ memories, passwords should instead be thought of as passphrases, which are combinations of words rather than letters. This increases the length while still being easy to remember. Password managers can be used to make it easier to follow the guidelines described above.

Biometric authentication also makes it easier for users to have a complex password, as it reduces the number of times that it would have to be manually entered. Users can normally still use a password or PIN if they cannot authenticate via the biometric sensor for any reason. The biometric authentication mechanism is therefore only as strong as the underlying password or PIN. Biometric authentication should only be used in conjunction with a strong password, which then offers the best of both worlds in terms of security and convenience.

5. Concluding Remarks

Mobile banking in South Africa has made a wide range of services more accessible and convenient. With this comes a certain level of risk that users need to be aware of. Attackers and crime groups will generally follow the path of least resistance when it comes to targeting users. The goal then should be to raise the bar such that targeting banking applications becomes a less lucrative endeavour. This can only be achieved if developers and users are aware of the risks and take active steps to address the growing concern.