The threat landscape is changing. With the rise in mobile traffic and the increased use of mobile banking applications, the threats posed by mobile channels are growing as well. The ability to distinguish between real human activity and automated software on mobile devices with a high level of accuracy is a must for any fraud prevention technology. Behavioral biometrics is a promising avenue to address the problem of automated fraud attempts. By combining hundreds of unique behavioral parameters into accurate user profiles, behavioral biometrics makes simulating user activity an extremely difficult task for an attacker.

Emulators and Fraud

Emulators are software simulations of physical devices that have many legitimate uses, but like all technology they can be used by cybercriminals to commit fraud. An Android OS emulator, Bluestacks for instance, is a legitimate simulator that is often used by software developers to test their programs. However, emulators can be easily abused by fraudsters and threat actors.

So how do fraudsters utilize emulators to commit fraud? For example, a fraudster can run multiple emulators on the same application and then use stolen credentials for account takeovers. Since emulators act in exactly the same way as physical devices, fraudsters can simulate touch and user behaviors – in fact, they can imitate anything.

Emulators are attractive to fraudsters since it is much easier to work on large scale attacks from a desktop rather than a mobile screen. Emulators allow fraudsters to easily run multiple instances of applications, helping them to rapidly scale fraud attacks. Another key advantage of using a mobile device emulator is that emulators can easily bypass device ID blacklists: once a simulation instance is blacklisted, it is simply binned and a new, whitelisted copy is generated. Therefore, threat analysts can no longer rely solely on unique device IDs to differentiate between real users and automated fraud attacks.

For banks and financial institutions it is extremely important to identify when a traffic is coming from an emulator or a real user since the use of an emulator to access a mobile application suggests high risk for fraud.

Mobile Fraud by the Numbers

As the number of mobile transactions increases, so does the amount of mobile fraud.

• ~52% of total transactions come from mobile devices
• Online fraudulent transactions are expected to reach $25.6 billion by 2020
• 65% of fraudulent transactions in Q1 2018 were made by mobile devices, compared to 39% in 2015

To effectively combat mobile fraud, we need to understand where it originates from and how it’s being performed.

Emulators vs. Man-to-Machine

Unfortunately, emulators are a commonplace occurrence. Traditional fraud detection tools struggle to detect emulated devices, which means you likely have emulated traffic interspersed with genuine traffic from real devices. However, emulators are vulnerable for the same reasons they are powerful: since they are not physical devices, they are not easily capable of providing all of the unique attributes that a physical device can provide.

Behavioral biometrics leverages this vulnerability. By relying on hard-to-spoof data points and parameters, behavioral biometrics makes it exceptionally difficult for emulated devices to pass for physical devices. It does this without relying on specific footprints or classical detection methods, allowing it to work against even the most advanced emulation software.

This article mainly looks at a number of techniques for detecting Android emulators.

As we shall see, there are many ways to detect emulators, but there are also a great number of such emulators on the market; and counting!

Android and iOS Emulators

Often-used Android emulators include:

• Android Studio’s emulator
• Andy
• ARChon
• Bluestacks
• Droid4X
• Genymotion
• KoPlayer
• MEmu
• Nox
• PrimeOS
• Remix OS Player
• Xamarin
• YouWave
• ArcWelder
• DroidDolphin
• Bouncer
• BareDroid

Commonly used iOS emulators include:

• Smartface
• iPadian
• Appetize.io
• App.io
• MobiOne Studios
• Air iPhone
• XCode
• Remoted iOS simulator

Build Values

Reading the build values may be a quick test to check for an emulator.

All the following values can be accessed programmatically on Android, and they often contain proof of the presence of an emulator.

Build.FINGERPRINT

Build.MANUFACTURER

Build.MODEL

Build.BRAND

Build.DEVICE

Build.PRODUCT

Etc.

Here we list the different default values for several popular emulators: BlueStacks, GenyMotion, Andy, YouWave, and ARCWelder.

By themselves, these values can create a simulator fingerprint.

Hardware-Based Detection

It is possible to detect the presence of an emulator by looking at inconsistencies with the hardware. The following table gives an overview of such possibilities. For each emulator, we list the default values. So by using that table with known values of a real device, we can eventually decide if we are dealing with an emulator or not

Additionally, an IMEI check will return a value of ‘000000000000000’ for an emulator. The same can be done with the IMSI check, etc.

Networking Environment Checks

A network can give a lot of hints that an emulator is present. The MAC addresses of the network cards may have specific values.

Additionally, an analysis of TTL (Time to Live/Hop limits) values can also give some clues, as shown in the following table:

Conclusion

There are many more detection techniques available than have been described here. Detecting an emulator in an Android or iOS context is not per se the most difficult challenge for a RASP system. However, it may prove to be difficult because of the great number of different emulators and hence, an important margin of error, that create important False Acceptance Rate or important False Reject Rates. Using Machine Learning on the top of the checks might also aid in getting more accurate results from a mobile emulator detector.

The post The big challenge of the Iran payment applications with emulator detection appeared first on Mohammad Rasoul Kazemi.