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:
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:
But the flexibility and resiliency of the operation was apparent when we hit this:
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)
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.
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.
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.
The un-hashed, json-formatted, response received from the server provides the following parameters:
- 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:
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)