The scale of this operation is one that has never been seen before, in some cases, over 20 emulators were used in the spoofing of well over 16,000 compromised devices. The attackers use these emulators to repeatedly access thousands of customer accounts and end up stealing millions of dollars in a matter of just a few days in each case. After one spree, the attackers shut down the operation, wipe traces, and prepare for the next attack.

Given the size and scale of this attack, we are publishing this blog to urgently raise awareness to the sophistication of the campaign, and to help financial institutions prepare for potential similar attacks on their customer base.

This post goes into further detail about what we found and how to mitigate risk from such coordinated and customized attacks.

An Evil Network of Mobile Emulators

Mobile emulators are inherently legitimate software used for virtualization needs. An emulator can mimic the characteristics of a variety of mobile devices without the need to purchase them and is typically used by developers to test applications and features on a wide array of device types. In this case, they were leveraged in an attack and used maliciously to spoof compromised mobile devices.

It’s of note that the emulator attacks we analyzed have the potential to work on any application that offers online access to customers, especially financial institutions, anywhere in the world. This is applicable even where transactions are approved with a code sent via SMS, and potentially also voice calls, or an email message.

Looking at the overall infrastructure, or anatomy of the attacks, shows that the attackers based their schemes on a few major components:

• Access to account holders’ usernames and passwords
• Access to device identifiers and data likely gathered via compromised mobile devices.
• Some ability to obtain SMS message contents.
• A customized automation environment tailored to targeted applications and the logical flow of events to approve transactions.
• A set of virtual mobile emulators, dozens in each case, to amplify the ability to spoof a larger number of devices and cycle through new ones rapidly and at scale.
• Customized network interception scripts that communicated with the targeted application’s API. These interceptions both submitted transactions and also monitored communications to ensure that the fraud was not being detected.

Figure 1: Anatomy of mobile account takeover at scale 

Hiding a Mobile Emulator in Plain Sight

Within the network mounted to emulate devices, each emulator was set up carefully to either appear exactly like an actual device from the repository the attackers accessed, or as a randomized “new” device. To ensure that the emulation was successful, the attackers ran tests and viewed device parameters by using a variety of legitimate apps they downloaded from official stores.

For the next step, feeding the emulators with device specs, the attackers used an application they developed for this purpose. Via the custom application, during the actual operation, device characteristics and technical specs were picked up automatically and rapidly from a database of compromised device logs, providing speed and accuracy of all parameters to the emulator, such as brand, OS version, IMEI, bootloader, and more.

Additionally, the automation matched the device with the account holder’s username and password for access to their bank account.

Figure 2: Code excerpt from the attacker’s proprietary application that automates spoofing of emulator specs (Source: IBM Trusteer)

When a compromised device operated from a specific country, the emulator spoofed the GPS location. From there, it connected to the account through a matching virtual private network (VPN) service. The attackers used a mix of legitimate tools available publicly (used mostly in testing) and customized applications likely created for the operation.

Cycling Through Infected Devices

Each time the system used a device in a successful fraudulent transfer, it was ‘recycled’ and replaced by another, unused device. The same happened when a device was blocked by the financial institution. In most cases, the attackers used existing device identifiers. However, in some cases, they created a randomized device to appear as if a customer was using a new device to access their account.

In the image below are data slices created of just one emulator of the many we observed. The attackers used this emulator to spoof over 8,000 devices and gaining illegal access to thousands of accounts.

Figure 3: Data from one emulator that was used in the fraud operation to repeatedly access accounts (Source: IBM Trusteer)

A Mobile Emulator Testing Ground for Custom Attacks

To ensure the emulation and automation framework was working as expected, the attackers created yet another custom-tailored applications to mimic the targeted application they wished to defraud. By creating those as a training environment, they were able to test and fine-tune the scripts and the actions their tools took in different situations. Only after perfecting the flow did they target customer accounts through the actual mobile banking apps of the banks they attacked.

Real-Time Fraud

This mobile fraud operation managed to automate the process of accessing accounts, initiating a transaction, receiving and stealing a second factor (SMS in this case) and in many cases using those codes to complete illicit transactions. The data sources, scripts and customized applications the gang created flowed in one automated process which provided speed that allowed them to rob millions of dollars from each victimized bank within a matter of days.

The Dark Side of ‘Transaction Monitoring’

To monitor the flow of fraudulent access attempts to user accounts and receive real-time information about anything not going as planned, the attackers used hooking techniques that listened and intercepted the communication with targeted application servers during the fraud attempts. Logs from the fraudulent sessions were recorded and sent to the attackers’ remote server, alongside screen captures from the targeted application.

The attackers followed closely on how the targeted application reacted to connection attempts from the emulated devices, which helped them make sure things were working. In addition, it allowed them to modify tactics on the fly and gave them warning signs in case something went wrong. In the case of a warning sign, they could halt the operation and wipe traces.

Figure 4: Code excerpt from the attackers’ proprietary interception application (Source: IBM Trusteer)

Trending Now… And Later

After responding to this massive attack, Trusteer researchers found that the robustness and sophistication of the operation’s automation environment were not a common sight in the cybercrime area. It is likely that those behind it are an organized group with access to skilled technical developers of mobile malware and those versed in fraud and money laundering. These types of characteristics are typical for gangs from the desktop malware realms, such as those operating TrickBot or the gang known as Evil Corp.

In subsequent attacks using the same tactics, we were able to see evolution and lessons learned when the attackers evidently fixed errors from past attacks. This is indicative of an ongoing operation that is perfecting the process of mobile banking fraud.

Furthermore, our intelligence team has observed a trending fraud-as-a-service offering in underground venues that promises access to the same type of operation to anyone willing to pay for it, with or without the required skill. This lowers the entry bar for would-be criminals or those who plan to transition into the mobile fraud realm. It also means this at-scale automation scheme can be adapted to almost any financial institution in a variety of countries and territories and is likely to become a growing trend among cybercriminals.

Reducing Risks From Mobile Emulator Fraud Attacks

Organizations may find it challenging to mitigate fraud risk from sophisticated or organized crime operations on their own. This is especially true when the targets are customers who have widely varying awareness levels of online threats.

One way to strengthen financial services cybersecurity and protect account holders is by using designated technological solutions that can detect real-time device and session risks, detect fraud, authenticate legitimate users and establish identity trust across the omnichannel customer journey.

Communicate With Customers

In the case of mobile fraud, it is important to help customers understand how to better protect their mobile devices. In general, they should:

• Avoid jailbreaking or rooting any of your devices.
• Ensure all system updates and app updates take place on time.
• Delete apps no longer in use.
• Obtain apps directly from official app stores.
• Ensure apps being downloaded are from a legitimate developer/company.
• Check your bank statements and report suspicious account activity promptly.

Additionally, beware of unsolicited SMS messages. Your bank does not inform you of account issues via SMS. Call the bank directly from the number on the back of your card and ask to verify potential issues.

This fraud can affect online banking customers whether they bank on mobile apps or not. Keep in mind browsing hygiene, protect accounts with additional steps beyond username and password, and check account activity regularly.

Technology that’s designed to help protect against online and mobile fraud is an asset to those charged with mitigating fraud risk. Learn more about how IBM Security can help your organization better protect customers here