Following the recent source code leak of the Android banking Trojan ExoBot, IBM X-Force research delved into the malware’s inner workings to help uncover insights into its dynamic mechanisms and the features that help criminals use it in cross-channel bank fraud.

ExoBot Genesis

ExoBot is Android malware that was based originally on a previous code known as Marcher. This code represents a banking Trojan that uses the overlay technique — that is, popping up fake windows that hide the original app users open — to trick victims into tapping their banking credentials into a fake interface. After stealing account access details, the malware can also intercept SMS messages and phone calls, thereby enabling criminals to take over the victim’s bank account and other financial accounts at their discretion.

Some of the capabilities that enable ExoBot to facilitate fraudulent activity on infected devices include gaining admin privileges, launching overlay screens, and exfiltrating SMS, data and other information from the infected device.

In 2016, ExoBot’s developer was selling the malware on the clear web for a while, even advertising an upgrade in May 2017. In January 2018, the actor decided to sell it off in the underground, but by May 2018, the source code was leaked online by an unknown actor.

Source code leaks, especially those of Android malware codes, have happened in the recent past. When they do, they give rise to variants and variations of the same malware, lowering the bar for more criminals to enter the mobile malware scene and try their hand at mobile banking fraud.

Delving Into ExoBot’s Inner Workings

The following sections describe technical details about ExoBot as analyzed by X-Force mobile threat researcher Shahar Tavor.

Architecture Basics

Having analyzed ExoBot’s leaked source code, X-Force researchers found the malware to possess some notable features, such as dynamic modules loaded at runtime and some anti-emulation tricks to evade popular sandboxes.

The image below illustrates the malware’s architecture. The overall routine occurs as follows:

1. An Android mobile device user unknowingly downloads a loader app via SMS spam or directly from the official store.
2. The loader app calls back to the attacker’s command-and-control (C&C) server and is replied with the most recent version of the malware binary.
3. ExoBot is fetched and executed on the device.
4. ExoBot downloads a .dex file from the C&C server. This file is the malware’s main module. This component is central to ExoBot’s functionality, and without it, most malware features would not work.
5. The attacker can now send commands to the malware; those are handled by the main module.

Figure 1: ExoBot’s architecture

ExoBot’s Infection Routine

ExoBot mostly spreads to new devices via SMS spam and sometimes via downloader apps that make it into the official stores.

First Run

At its first run on a device, ExoBot removes the application icon from the home screen, minimizes all running apps, and then shows the home screen so that the infected user wouldn’t notice anything new on his or her device.

OpSec Checks

To evade sandboxes and automated analysis, ExoBot performs several checks before running:

• Anti-emulation checks — Like other malware, Android malware is often analyzed by mobile threat researchers’ emulators and sandboxes. To dodge the analysis, ExoBot checks the environment’s build model, International Mobile Equipment Identity (IMEI) and registered operator.
• Antidebugging — To evade debugging by automated tools, ExoBot uses the isDebuggerConnected() function to determine if a debugger is attached to the device.
• Country filter — To limit the reach of local law enforcement, some malware codes avoid running in Eastern European countries. ExoBot’s developer included a special list of countries where the malware should not run:
  • Armenia
  • Azerbaijan
  • Belarus
  • Canada
  • Kazakhstan
  • Kyrgyzstan
  • Moldova
  • Russia
  • Serbia and Montenegro
  • Slovakia
  • Tajikistan
  • Turkmenistan
  • Ukraine
  • United States
  • Uzbekistan

Interestingly, Canada and the U.S. are on the list of countries that would not be targeted.

A second filter is applied by the language set on the device. The following language specifications will make ExoBot stop running on the device:

• Armenian
• Azeri (Latin)
• Belarusian
• Chinese
• Czech
• Indo-European
• Kyrgyz
• Romanian
• Russian
• Slovak
• Turkish
• Ukrainian
• Uzbek (Latin)

Device Admin Request

To be able to use all of its features, especially locking the user’s screen and changing the lock screen’s password, ExoBot needs to run with admin permissions. Requiring this permission level involves the infected user, and to solicit his or her help, ExoBot displays a fake screen that purports to be the GNU General Public License.

Figure 2: ExoBot asking for admin permissions via a fake GNU page

By gaining the admin permission level, ExoBot can also establish its persistence mechanism and ensure that the user would not be able to remove the app without disabling the malware with equal permissions. Getting rid of ExoBot involves manually removing it from the device admin apps list. Unfortunately, even after removals, ExoBot will pop up a screen asking the user to activate it.

Obfuscation

To keep its resources protected, ExoBot’s developer uses two obfuscation techniques:

1. String protection — The malware’s operator can elect to replace all string characters with a key of his or her choosing.

Figure 3: String protection

This can be reversed by a decrypt function, which replaces the new key with the default key and reverts to the previous string.

Figure 4: Reversing the string obfuscation

2. Advanced Encryption Standard (AES) encryption of requests and responses from the C&C server, as well as encrypting the malware’s configuration. The encryption was implemented using a hardcoded key and then Base64 encoding.

ExoBot’s Continuous C&C Communication

With new infections, ExoBot retrieves modules from the C&C server and then continually keeps in touch with it to check for new tasks assigned by the attacker. If new tasks are found, ExoBot queues them for execution in a designated file located in in a private folder on disk. All the information in the queue is saved in encrypted form. The queue file is used throughout the malware’s activity and life cycle.

To keep on top of tasks, ExoBot checks them periodically and by an alarm setup. Requests and responses are kept encrypted in JavaScript Object Notation (JSON) format.

Figure 5: Queue file with pending tasks

Until a new task is sent through, the malware will continue to update the C&C server with information about the device, the installed apps and a configuration status.

Figure 6: ExoBot sends a request with device information to the C&C server

ExoBot’s C&C communication is secured with an SSL.

To identify devices, each infected device receives a unique MD5 with its identifiers: IMEI, build model, central processing unit (CPU) and Android ID. The details are transmitted to the C&C server under the “I” field inside every JSON request.

Dynamic Module Loading

Unlike similar malware, ExoBot has a unique method to load its modules in a dynamic way. The image blow shows the code that enables this tactic to work:

Figure 7: Code snippet showing ExoBot’s dynamic module loading

The developer here used the payload to manage module loading. The main module is the component that downloads the modules from the C&C on its first run, and it’s also the component that handles them later when they are required to run.

Modules are loaded to memory in reflection, giving the malware the ability to inspect and dynamically call classes, methods and attributes at runtime instead of having to do that at compile time.

The reflection is implemented using the Android DexClassLoader application programming interface (API), which is a class loader that allows an application to load .jar and APK files. This method can be used to execute code that was not previously installed as part of an existing app and load it into that app during runtime.

Note that ExoBot’s .dex file is still present on disk, but the code is not packed within the APK. Using reflection in this case allows the malware to avoid static analysis of its modules and keep them out of antivirus engines’ sight. Moreover, loading in runtime gives ExoBot added agility. It can fetch new modules from the C&C server at any time and add/update its features easily and quickly on devices that are already infected.

Module Execution

To execute modules, ExoBot’s C&C server sends the malware a command with relevant parameters alongside the MD5 hash of a .dex file that contains the module to ensure the correct one is executed:

data/data/app_package_name/m/md5(module_name).dex

The malware then proceeds with the required action on the infected device.

In some cases, the module may not exist in the malware’s folder on the device, and it will launch a request to download it from the C&C server.

Figure 8: ExoBot requesting a module download from the C&C server to get the victim’s contacts

Next, ExoBot hashes the required module on disk and compares its MD5 to the one attributed to that module on the C&C server. This step is taken to prevent tampering and errors. Upon confirming a match, the malware loads the requested module and reports the result back to the C&C server.

Figure 9: ExoBot’s request to get contacts from the victim’s texting app

A result in JSON format contains data returned from the module alongside an API status field indicating whether the module is running properly or has failed.

ExoBot’s Module List

The following table shows the modules that enable ExoBot’s capabilities. The first table lists the existing modules, and the second one lists modules that were yet to be added by the developer.

The following modules are not active as yet:

ExoBot’s Overlay Screen Mechanism

Overlay malware has been around for a while, but the method became popular when GM Bot started commercializing it in the underground. Ever since GM Bot, various Android banking Trojans use the overlay tactic, implementing its use in different ways.

In ExoBot’s case, the overlay screen pop-up takes place by detecting the foreground app and then displaying a custom webpage activity to match that app. In the case of banks, cryptocurrency exchanges, payment and shopping apps, the fake screen will match their login screens.

To begin, ExoBot gets its target list from the C&C server. The malware scans all the files found under the /proc virtual filesystem to map all running processes the user initiated. It does not scan apps and processes users cannot launch themselves.

Figure 10: Listing all active processes from /proc

At startup, services of the Android operating system run in the bg_non_interactive state. This state means that the service is at low priority at the time and cannot use more than 5 percent of the CPU. To determine if an app of interest is running in the foreground, the malware checks if the app’s process ID (PID) is not in the noninteractive state list.

Figure 11: Looking for processes that run in the foreground

If a targeted app is running in the foreground, ExoBot will pop up a new activity on top of the original app, covering it and prioritizing the fake screen. In the overlay, a custom webpage impersonates the login interface of the original app to phish the victim’s credentials.

Persistent Credit Card Requests

On top of targeting banking and other financial applications, social and chat apps, ExoBot possesses a module designed to steal payment card information.

This module is tasked with frequent pop-ups of fake screens that require victims to tap their payment card details into the activity. The lure is set up as a notification from Google Play, or from other services for Android-based devices.

Mobile Malware Continues to Evolve

ExoBot’s code leak is just another leak among others that provide cybercriminals with a basis for malware that they can adapt to their own illicit operations and attacks. With this code leak, X-Force researchers expect to see ExoBot offspring in the coming months, as well as new actors who will use it in different geographies to target local banks through their mobile banking user base.

To mitigate the threat of mobile malware, organizations can help protect their apps with IBM Trusteer. Those managing employee mobile devices can learn more about IBM’s unified endpoint management (UEM) solution, MaaS360.

Although we worked directly with the source code, here are some recent ExoBot samples for those looking to analyze this version:

• 42751858e99b7add2f4ac9e00e348d40
• 285197e39072bda563ccebc0fba78648
• 80b5821c7f1649b176381efaadb90f68
• f1ad35e91b45b5375e08666b39ca791b
• 3ff9fadb87812571f799a35c13d8490c

Our team also manages and updates an ExoBot collection on X-Force Exchange.

Read the white paper: How Digital Banking Is Transforming Fraud Detection