Behind the Scenes of a Fake Token Mobile App Operation

In the last few years, we have seen the mobile space explode with malware. According to a recent report by Trend Micro, the number of malware and high-risk apps available on the Android platform has crossed the one million mark, growing more than a thousand fold in under 3 years.

To the financial industry, the threat manifests itself in the form of rogue apps (apps that mimic the legitimate banking apps) and in the form of SMS-sniffers. The latter becoming standard functionality when it comes to banking Trojans, with the term “*iTMO” (<insert first letter of malware>-in-The-Mobile) gaining popularity—heard much about ZiTMO, SpiTMO, BiTMO, CiTMO, QiTMO?

The *iTMO component of a banking Trojan is designed to overcome a single obstacle: out-of-band authentication using mobile devices. By installing a malicious “*iTMO app” on the device the botmaster can intercept SMS messages and/or telephone calls thus defeating the OOB authentication. It is one such app that we recently analyzed.

The app, which has been around for a while and uses the moniker mToken, disguises itself as a fake token app (AV classification), and displays “standard” functionality as far as SMS message interception goes: During the installation process it would ask the user for the necessary SMS-, and communication-related permissions; and to appear legitimate it made use of the customers’ logos, not to mention displaying a “random” token code when launched (a detailed analysis of the app is available below).

But the most interesting finding was the analysis of the Web-based control panel. This offered a behind-the-scenes glimpse into a mobile botnet operation and demonstrated the ease of commanding it, but more importantly—its flexibility and resilience.

Building Malicious Apps On-the-Fly

The panel we analyzed was used in attacks targeting several financial institutions around the globe along with a well-known social media platform. At the time it was commanding over 2,000 mobile devices and had intercepted over 25,000 SMS messages:

AFCC_3
Main screen of the control panel.

The panel’s standard functionality provided the fraudster with the ability to review bot-related information, send HTTP-based commands (to the bot), and review the intercepted SMS messages:

AFCC_5
Intercepted messages for a specific device.

 

But the flexibility and resiliency of the operation was apparent when we hit this:

AFCC_7
Application (APK) builder screen.

Built into the control panel was functionality to create custom-looking malicious mobile apps on-the-fly. Asking the botmaster to provide basic app-related information (such as name) and default communication points, it would offer a selection of existing designs or the ability to create new designs using image files and a simple HTML file (seen below)

AFCC_8
The HTML file used to build the apps.

In order to build the app, the panel makes use of APKTool, a freeware, command-line tool used to decompile and recompile Android application packages. The tool wraps the HTML and images in a standard Android APK and makes it available to the fraudster for immediate use.

Resiliency Above All Else

The ability to create custom-looking apps, as well as to command the botnet over HTTP and SMS, make the operation increasingly resilient. Having two separate communication channels (to the bots) means that any take down effort must affect both points simultaneously. Not to mention the PC-based Trojan operation that can be used to re-infect the mobile devices if needed.

Summary

It is no secret that relying solely on SMS-based out-of-band authentication is not the best idea… Taking today’s mobile threat landscape into account will require organizations to consider stronger authentication measures to ensure the identities (and transactions) of their customers.

****

App Analysis

The delivery method of the app uses basic social engineering techniques to get the user to download and install the malicious app.

Once logged into the bank’s website (on the PC), the malware presents additional, custom screens (using HTML-injection) asking the victim to select the mobile device’s operating system (only Android is supported) and the device’s phone number to which the fraudster then sends an SMS message with a link to download the app.

During the installation process the app requests permissions to communicate via the internet and to gain access to the SMS messages (send and receive).

The app then waits for the botmaster to enable the SMS-sniffing function (via the control panel) at which point it begins to intercept all inbound and outbound SMS messages, forwarding them (via HTTP POST) to the drop server.

App Communication Analysis

Analysis of the bot’s communication revealed that it would regularly beacon its command and control server receiving updated communication parameters as well as commands to carry out on the device. Commands included enabling (or disabling) SMS-interception and sending SMS messages from the infected device to a 3rd party.

In each communication session with the server the app would relay device related information including IMEI, IMSI and phone number and receive a response in a simple, XOR hashed form.

 

Beacon communication to the server, posting device related data.

 

The un-hashed, json-formatted, response received from the server provides the following parameters:

{“timeNextConnection”:1365590046903,”startPeriod”:1,”period”:2,”enable“:
false,”phone“:”+**********12″,”servers“:[“http://*********i.com/**********/server.php”]}

  • enable: should the SMS intercepting capability be enabled or not;
  • phone: a phone number to which SMS messages should be forwarded to, and from which SMS-based commands will be sent to the bot;
  • servers: a list of servers to which the app must communicate to.

Sending commands to the bot can be done via SMS or using Web-based control panel (over HTTP) as seen below:

AFCC_6
Interface to send commands to a specific bot.

 

The panel can also command the bot to send SMS messages to a third party. This can be used to send SMiShing messages to other devices that will originate from the victim device. This could possibly allow the botmaster to grow his botnet. (from top to bottom:)

  • Command to be executed (“send SMS”)
  • Phone number to which the bot should send the SMS message
  • Message content
  • Command name: this allows the fraudster to save the command for future use
  • Save to history (checkbox)

 

No Comments