Mobile Fraud Detection

What is mobile fraud detection?

Mobile fraud attacks continue to increase as mobile devices and mobile applications become more popular. With the recent surge in mobile banking, the growth in the use of mobiles is set to continue. Fraudsters also see the opportunity with mobile fraud. Over 60% of digital fraud now occurs through mobile devices, and in 2022, more than 50% of personal devices were exposed to a mobile phishing attack every quarter. To combat this, mobile fraud detection uses different technologies, such as mobile app shielding and multi-factor authentication, to help prevent account takeover and other types of fraud. Different technologies are used behind the scenes to detect fraudulent activity and provide fraud protection to consumers without impacting their user experience.

How mobile devices and apps are driving mobile fraud

Metrics indicate that mobile users increasingly rely on their devices for their banking needs. Juniper Research reports that more than two billion mobile users globally will have used their devices for banking purposes by the end of 2021, compared to 1.2 billion in 2020. While the online channel still faces threats, fraudsters are investing more time and money in attacking the mobile channel as consumers worldwide continue ecommerce spending on things such as apps for games, other diversions and more. According to Statistica, “In 2024, consumers are projected to spend 55.5 billion U.S. dollars on mobile apps from the Google Play Store. Combined user spending in the App Store and Google Play is set to reach almost 171 billion U.S. dollars by 2024.”

Mobile fraud detection, understanding common mobile fraud techniques

Attackers use a variety of techniques to carry out mobile fraud. Here are some examples:

• Reverse Engineering: A bad actor can reverse engineer an app to analyze its source code and component parts. The goal here would be to gather information that can be used to develop malware that exploits the app’s operation, or to tamper with the app. For example, an attacker might deploy their own malicious app designed to exploit vulnerabilities discovered by reverse engineering the banking app.
• Repackaging: A repackaging attack starts with an attacker reverse engineering an app, inserting malicious code into the app and then republishing the tampered app on unofficial marketplaces. To a consumer, it will appear as though they downloaded the correct application and the app will appear to them as the legitimate application. However, behind the scenes, the counterfeit app is code stealing personal information, redirecting funds, or performing other malicious activity.
• Overlay Attacks: An overlay attack consists of an attacker-generated screen that appears on top of the legitimate application’s user interface. To the unsuspecting victim, it will appear as a normal experience within the app, but they will be entering their sensitive information, such as usernames, passwords, credit card numbers, or other personally identifiable information, into a form controlled by the attacker. The information entered into the malicious window is then sent directly to the attacker. The victim of this fraud doesn’t know that they have just handed over their information. In addition to hijacking data, overlay attacks are used for social engineering. They can be used to trick people into installing other malware or performing insecure tasks on their mobile devices, such as granting a malware app full control of the user’s phone.
• Rogue Keyboards: The app marketplace has numerous legitimate alternative keyboard applications to replace the native keyboards installed on mobile devices. Some of these keyboard apps will have vulnerabilities that attackers can exploit or some of the keyboard apps may be rogue and specifically designed to record keystrokes and send them to an attacker.
• Mobile Banking Trojans: A mobile banking Trojan appears to be legitimate, but is it hiding malware that specifically targets a mobile banking app on the device that it has infected. A common technique used by mobile banking Trojans is an overlay attack in which a fake screen is put on top of a legitimate banking application (see “Overlay Attack” above). The malware captures the victim’s authentication credentials and can remain active while other banking transactions are performed. For example, the malware can modify transaction data by intercepting a funds transfer and redirecting the money to a fraudulent account. These attacks are destined to grow as smartphone use continues to increase globally. The FBI notes that it’s best to be cautious when downloading apps on smartphones and tablets, as some could be banking Trojans.
• Man-in-the-Middle Attacks: In a Man in the Middle attack, the fraudster positions themselves between the financial institution and the customer to be able to intercept, edit, send and receive communications between the two parties without raising any suspicion. The fraudster takes over the communication channel between the customer’s device and the server by setting up a malicious or rogue Wi-Fi network as a public hotspot (known as a rogue access point) for the attack to occur. The customer can use the public hotspot without realizing they may be transferring their payment data through a network controlled by a fraudster. A mobile app's communications should be securely implemented through things such as certificate pinning where the app will only communicate with a specific server because it uses a specific certificate that the mobile app is looking for. Not doing so makes the app vulnerable to a Man-in-the-Middle attack. Fraudsters also use a Man-in-the-Middle attack to insert themselves between an SDK and the endpoint it intends to reach out to. Then, they continuously hit that endpoint with a series of test calls to reverse engineer what calls represent a successful action. Over time, they identify what parameters are being passed to indicate a successful install. Once they successfully “install” an app, they continue with SDK spoofing.
• SIM Swapping: Swapping a SIM card is a legitimate service offered by mobile phone carriers when a customer buys a new device, and the old SIM card is no longer compatible with it. A bad actor can abuse this service. In a SIM swap, a fraudster uses social engineering techniques to transfer the victim’s mobile phone number to a new SIM card. The fraudster contacts a customer’s mobile phone carrier and impersonates the customer, convincing a call center agent to port the mobile phone number to the SIM card under the control of the fraudster. As a result, the user’s banking app can be activated on the fraudster’s phone. If the bank’s authentication mechanism includes text messages as a means of delivering one-time passwords, then taking over the victim’s number becomes an attractive way for a criminal to perform fraudulent transactions, add payees, or perform other operations during a banking session.
• Mobile phishing: A form of phishing, smishing is when a bad actor texts you a link to try to trick you into clicking on it. Clicking on the link can result in loading a phishing page where the user is tricked into inputting their login credentials, or unknowingly initiates a silent download of surveillance spyware on the device. The goal is to gain unauthorized access to personal, sensitive and corporate data stored and accessed by the device. Tiny URLs, which are shortened URLs, are also used in SMS phishing attacks to direct you to malicious content and are often used in large scale smishing attacks.

Technologies that strengthen mobile fraud detection

Mobile fraud impacts customers and enterprises alike. Existing customers who fall victim to fraud are more likely to leave, and potential customers may be wary to do business with an organization that’s considered to be lax with fraud prevention and fraud solutions as the fraud ecosystem continues to evolve.

Mobile fraud detection technologies, capabilities, and solutions

Mobile In-App Protection: Mobile in-app protection is an umbrella term for mobile app security and authentication technologies that developers can integrate into mobile apps to make them more resilient against mobile threats such as repackaging, malware, script injection, reverse engineering, SMS grabbing, and others. Gartner says that self-defending apps are “crucial” because mobile apps run on a wide variety of untrusted mobile devices with varying levels of security. Gartner recommends that organizations, "choose in-app protection for critical and high-value applications that run within untrusted environments and move software logic on the front end. The most common use cases will be mobile apps, single-page web apps (especially consumer-facing ones), and software on connected devices.” Gartner also recommends that organizations avoid using in-app protection as a replacement for application security testing and vulnerability patching – and to adopt secure coding best practices before looking at in-app protection solutions.

Mobile in-app protection solutions consist of security and authentication features such as the following:

• Mobile App Shielding with Run-time Application Self Protection (RASP): App shielding with run-time protection can detect and prevent real-time attacks. The combination of mobile app shielding with run-time protection allows mobile financial apps to run securely, block foreign code from interfering with the app’s functionality, or shut down the application if a threat to data exists. Integrating app shielding with runtime protection also protects sensitive information from cybercriminals, even on untrusted mobile devices.
  
  Run-time application self-protection (RASP), a term coined by Gartner, protects mobile apps against intrusions from multiple types of malware. RASP is natively integrated into the mobile app and mitigates malicious attacks that target the app by detecting them and shutting down the app before sensitive data can be compromised and used for fraud. It strengthens mobile app security by neutralizing potential threats and protects sensitive data and high-value transactions from hackers.
  
  App shielding with runtime protection is a prevention tool that protects the mobile app by preventing the app from operating on an emulator or when being interfered with by a debugger. These are tools that reverse-engineers use to interrogate an app and find vulnerabilities. It detects malicious keylogging, repackaged applications, and jailbroken or rooted devices, among others.
  
  Financial institutions can pair risk engine technology with mobile app shielding and mobile security technologies to gather additional information about the app in its runtime environment to optimize fraud management and allow the banking app to function securely in a risky environment.
  
  Application Hardening, also referred to as prevention capabilities, increases the level of effort required for the attacker to carry out an attack.

• Risk-Based Authentication: Risk-based authentication (RBA) helps prevent mobile fraud by determining the risk level for each financial transaction and what level of customer authentication is required. RBA matches the level of customer authentication needed to the level of risk involved and helps reduce false positives meaning fewer customers will be falsely rejected for fraud concerns. In the past, many organizations relied on one type of authentication for all customers and transactions: static passwords and usernames, which is binary authentication. Passwords and usernames are considered weak security because they are so easy for fraudsters to steal and exploit. On the other hand, risk-based authentication is a form of strong authentication because it gives context to the user and their transaction to determine the risk level and the susceptibility of fraud. In cases of a high-risk transaction, the user is prompted for additional authentication to confirm their identity. There are three common factors used for authentication: Something you know, something you have, and something you are. The most common authentication is something you know and can be a password or a simple personal identification number (PIN). However, it is also the easiest for fraudsters to beat. The something you have factor refers to items such as a mobile device or hardware authenticator tokens, which generate single use, one-time passcode. Smartphone-based options, such as a push notification and a one-time password (OTP), also deliver a multi-factor verification (MFA). Biometrics are the “something you are” factor and can be fingerprints, facial scans or voice analysis and are part of a move to passwordless logins. The three factors of authentication are often combined to provide stronger security to thwart fraudsters. The combination of a fingerprint scan with a one-time passcode strengthens security and is an example of multi-factor authentication.

• Out of Band Authentication: Out of band authentication is a type of two-factor authentication (2FA) that requires a secondary verification method through a separate communication channel along with their credentials. For example, it might involve the customer’s desktop as one channel and their mobile phone as another channel. It’s more difficult for an attacker to compromise two different channels which reduces the likelihood of a successful account takeover because the attacker would need to compromise two separate channels to gain access. Out-of-band (OOB) authentication is used by financial institutions and other organizations with high security requirements. It makes hacking an account more difficult because two separate and unconnected authentication channels would need to be simultaneously compromised for an attacker to gain access.

• Multi-Factor Authentication: Multi-factor authentication (MFA) uses multiple technologies to authenticate the customer’s identity and they must combine verification technologies from at least two different groups or authentication factors. Authentication factors include:

  Something you know: A password, PIN, passphrase or questions and their corresponding answers.

  Something you have: Most people use their smartphone with an authenticator app as the device that generates these codes or allows them to respond back to a server with a one-time passcode behind the scenes.

  Something you are: This is anything from fingerprints, retina scans, facial recognition, voice recognition, or a user’s behavior (such as how hard or fast they type or swipe on a screen) that can be used to identify a unique user.
  
  To achieve multi-factor authentication, at least two different technologies from at least two different technology groups must be used for authentication process. As a result, using a PIN coupled with a password would not be considered multi-factor authentication, while using a PIN with facial recognition as a second factor would be. It is also acceptable to use more than two forms of authentication. However, most users increasingly want frictionless authentication (the ability to be verified without the need to perform verification). MFA can prevent account takeover fraud and phishing, for example.

• Cronto®: A Cronto®, or multicolored QR-like code, can authenticate or authorize a financial transaction and enhances protection for high-value transactions. The customer will see a graphical cryptogram that resembles a QR code, displayed on their computer’s browser. Only the bank can generate the code so that it can be trusted to set up a secure channel between customer and the bank. When you want to perform a transaction, you enter the payment data into the online banking application in the browser. You’ll then see the QR-like code and scan it using the camera on your mobile device. Your device will decode it, decrypt the payment data, and show it to you on your mobile in plain text. This approach meets the dynamic linking requirements outlined in the European Union’s Revised Payment Services Directive (PSD2) Regulatory Technical Standard.

Additional mobile security capabilities that help with mobile fraud detection:

• Code obfuscation scrambles the code and makes it harder for an attacker to reverse engineer how the application works. As a result, an application that is more difficult to read should be more difficult to attack, and to steal its intellectual property.
• White boxing or white-box cryptography: What’s known as whitebox cryptography is used to prevent an attacker from uncovering the encryption keys used by an app, using a combination of encryption and obfuscation, or scrambling the code so that it’s difficult to understand. In other cases, the rationale for white boxing is to offer an operating-system-independent security mechanism that protects secret keys even if the attacker somehow compromises the mobile operating system or device..
• Certificate Pinning: Rather than accepting any certificate from a specific range of certification authorities, pinning allows the parties involved in the mutual authentication process to pin down particular certificates — meaning only these certificates will be accepted. If an attacker spoofs a certificate, even if this certificate is coming from a legitimate certification authority, the communicating party will reject it, avoiding a Man-in-the-Middle attack.

 

How mobile applications can be vulnerable

Mobile app developers ultimately don’t know how their apps will be used, whether it's mobile ad fraud, mobile fraud, or in what environment. As a result, there is always a risk that, for example, a bank app will be targeted by malware on the device and result in fraud losses for a financial institution. Though the Apple App Store and Google Play Store stores filter out a large percentage of malware, app fraud is a possibility. Malicious applications do exist on the app stores waiting to be downloaded in order to steal personal information or inject malicious code into the mobile device or another app. Even if users only download apps from official stores, something malicious might slip through and if a malicious app resides on a user's device, it puts the developer’s app potentially at risk.

Another misconception is that the iOS and Android operating systems provide adequate security for the mobile device and, by extension, adequate security for their mobile apps. This is true to some degree. Android and iOS do spend quite a lot of time patching their operating systems to remove vulnerabilities, but neither is 100% secure and they can’t account for user negligence. Mobile app developers cannot simply depend on the security of Android or iOS and need to take additional action to make their apps secure. It’s also to be noted that there is always a time gap between a vulnerability that’s identified, and a patch released by manufacturers and mobile carriers. If the patch isn’t downloaded, a user could end up running long outdated versions of the operating system full of opportunities for attackers and malicious code.

Security required for banking apps

The Open Web Application Security Project (OWASP), an international community of industry leaders in their field --technologists, data security experts, and developers have developed an independent baseline for mobile application security called the Mobile App Security Verification Standard (MASVS). The Open Web Security Project provides unbiased guidance on recommended security capabilities for iOS and Android mobile apps, depending on their function. Banking and financial services applications require the strictest security standard under OWASP due to their sensitive data. They must also be resilient against reverse engineering. Banking apps serve a large, varied audience using a variety of devices on different operating systems and as a result, extra caution needs to be taken. Banking apps fall under the MASVS L2+R of the Open Web Application Security Project (OWASP), the strictest security standard.

MASVS SECURITY LEVELS

Source: Mobile App Shielding: How to Reduce Fraud, Save Money, and Protect Revenue

MASVS-L1	The minimum threshold for all mobile applications, it includes security best practices that have a “reasonable” impact on development costs and user experience.	Typical Applications Include: Fitness or meditation apps Simple tool applications like a flashlight Any app that does not qualify for a higher level
MASVS-L2	For applications with access to information or capabilities that can be leveraged by attackers for fraud, such as personally identifiable information, credit card numbers, or the ability to move funds.	Typical Applications Include: Healthcare applications Apps with subscription services Apps that enable access to sensitive information or allow a user to move funds
MASVS L1+R	The “R” in the MASVS levels refers to protections against clientside attacks or reverse engineering. Therefore, this level applies to applications that do not have access to sensitive user information, but still must be resilient against tampering and reverse engineering.	Typical Applications Include: Competitive gaming apps (to prevent cheating) Apps where Intellectual Property (IP) protection is a business goal
MASVS L2+R	The strictest security standard is reserved for apps that require access to sensitive user data, but also must be resilient against reverse engineering and made available to a large consumer base using a wide range of operating systems and devices.	Typical Applications Include: Banking and financial services applications