(Analysis by Rodel Mendrez and Lloyd Macrohon)
It all started with a spam message, which curiously had an Android App attachment. The spam email vaguely claims that the attachment was a dating app for finding anonymous sex-acquaintances called SilverBox.
Figure 1. Spam sample
Seeing an .APK (Android Package Kit) file attached to a spam email is unusual and quite a shift from the usual stuff we see, which centers largely on malicious executable that run on desktops. Here we have an Android application that runs on a mobile device. Our curiosity suitably aroused, we decided to dive in and analyze it.
First things first, we checked if the file has already been detected by anti-virus engines and sure enough it already was, mostly generic detections but nonetheless detected by 25 out 59 products.
Having little experience in reverse engineering Android applications, we thought it would be fun dissecting this app and hopefully learn new things along the way. To kickstart, we did a little bit of research on how to reverse engineer an Android app, and found a few useful articles that can be found here, here, here and here.
We started by decompressing and decoding the APK file using Apktool. We noticed right away how heavily obfuscated the code is.
Figure 2. DEX file is heavily obfuscated
Then we checked the file AndroidManifest.xml in the root directory. Every Android application must contain this manifest file that presents essential information about the app and permissions that the application needs to use. The manifest file shows the original package name of the application that is seemingly randomly named.
Figure 3. Package name of the application
Figure 4. Android permission of the application
The target SDK version code of the app is Android Marshmallow and later, shown in Figure 3. This is indicated in field platformBuildVersionCode. We can see in Figure 4, a huge list of Android permissions that this application requires. Most of these scream suspiciousness, including permissions like: WRITE_SMS, READ_SMS, RECEIVE_SMS. CALL_PHONE, CHANGE_NETWORK_STATE.
We have compiled all the Android permission this app needs in this table:
Allow access user's usage data
Allow read user's contact provider
allow application to receive ACTION_BOOT_COMPLETED
that is broadcast after the system finishes booting
Allow access information about WiFi Networks
allow an application to change WiFi connectivity state
allow application to access information about networks
allow application to change network connectivity state
Allows read only access to phone state, including the phone number of the device, current cellular network information, the status of any ongoing calls
Allows applications to open network sockets
Allows an application to broadcast a notification that an application package has been removed.
Allows access to the vibrator.
Allows an application to initiate a phone call without going through the Dialer user interface for the user to confirm the call.
Allows an application to read the user's call log.
Allows an application to write SMS messages.
Allows an application to monitor incoming MMS messages.
Allows an application to read SMS messages.
Allows an application to receive SMS messages.
Allows an application to send SMS messages.
Allows an app to create windows shown on top of other apps
Allows using PowerManager WakeLocks to keep processor from sleeping or screen from dimming.
Allows applications to disable the keyguard if it is not secure.
Allows an application to get information about the currently or recently running tasks.
We proceeded to install the app on an emulator using Android Studio's AVD (Android Virtual Device). As you can see, the app needs to be activated by the user in order to use it.
Figure 5. This malicious app needs to be activate by the user. So social engineering comes in place (in form of a spam) to fool the user to activate it
At this stage, we wanted to better understand the code, but we found it hard to bypass the obfuscation. We tried remote debugging the app using IDAPro which was painful and tedious. Another thing we did is to let the malware run then dump the device's memory. We ended up scraping the strings, but that's really it. This helped us find the malware configuration and strings from the application. While this is helpful, it still wasn't enough, we needed the decompiled source code to fully understand how this malware works.
In the device, we scrounged around for more interesting artefacts using the Android Debug Bridge (ADB) tool and we found the VDEX and the ODEX files of the application.
Figure 6. The .vdex file is located in the application's OAT (Ahead of Time) compilation folder in the device
.VDEX files contains the uncompressed DEX (Dalvic executable) code of the APK while the ODEX contains the Ahead Of Time compiled code for methods in the APK. So, our next step was to decompile the VDEX file using the vDexExtractor tool.
Figure 7. vDexExtractor tool command line to convert .vdex file to .dex file
There may be simpler ways to do this, but after decompiling and converting the .VDEX to .DEX file, we then converted the .DEX file to a.JAR file using the JADX tool. Then we can decompile the .JAR file using tools like IntelliJ/Android Studio or any Java decompiler available.
Figure 8. Android malware is decompiled. Shown in this screenshot are the Bot's command
After having got some Java code, the next step is detailed static analysis.
Malware's Main Architecture
The main architecture of the malware is organised into the following main categories:
- Database Access - data stored in SQLite. Commands are also stored in this database and mostly handled through this layer.
Figure 9. A SQLlite database is created by the malware to store commands, sms list and templates
- Telephony Related - set the default telephony package, utility functions (get device id, sim serial number, line number, etc…)
Figure 10. Setting the default telephony package
- Service Response Handlers - responding to replies and may initiate new requests to the command and control (C&C) server. Some response handlers are:
- ServerCommandHandler - controls the malware by mostly writing to the database
- Network Connection Related – this layer registers the device as a bot, ensure connection is online, post call list, sms list, etc… whose replies will be handled by the Service ResponseHandlers.
- Services - to handle intents that are intercepted. A few of these services handles the malware's life cycle and ensures that the malware is running at all times. Some examples of these services are:
- WatchDogService: sets timers to ensure that malware is running periodically.
- ControlService: registers the device bot, as well as starting up the ReadCommandThread: waits for instructions from the C&C server
- Ensures that device is connected to the C&C server
- BootReceiver: ensures all functionality is up and running when machine is rebooted. This boot receiver ensures that the watchdog service is run every 10 secs or 30 secs depending on the version of the OS.
- SmsReceiver: intercepts SMS messages.
- UI - to request for permissions from user and also to overlay some templates received from the C&C server on top of other apps to further fool the user, including enabling device admin access.
The malware sets itself up as a default telephony provider, mostly for intercepting SMS messages. A list of phone numbers to be intercepted can be controlled by the C&C server. Messages from these numbers may be hidden from the user. Intercepted messages are also sent to the C&C server. This could be used for intercepting 2 factor authentication codes used by most services these days including online banking.
Device Admin Access
The malware has full access to the device, including completely wiping out all data from the device. The malware has a UI to enable the device admin access, but does not allow you to disable it once enabled.
Bot and C&C Communication
The bot communicates mostly using a HTTP POST request to a specific url. If not available, it will try and get another service through a Twitter message. The HTTP POST body uses no fancy encryption, just encoded in Base64.
The format of this uri is: http://controlserver/<messagetype>/
The following message types are supported:
- stbi - register device along with its number, iccid, model, imei, os and lang.
- sy - read commands from server passing it its bot_id, imei, type, and whether device admin is enabled or not. Below are the list of commands that the attacker may perform:
- sban - get templates from server passing a list of applications installed in the system. This way the bot can tailor which template to overlay over a specific application.
- gt - get template from server
- ssl – return exfiltrated sms list
- scol – return exfiltrated contact list
- scal – return exfiltrated call list
- ping - ping bot
- ucs – return executed command
- std - ?
- ss - ?
At the time of our analysis, there were no longer any live C&C servers running and so we were unable to observe any traffic between the malware and the C&C server. We couldn't complete the reverse-engineering of some of the commands due to some issues, including no traffic observed, heavily obfuscated code, but also extremely buggy malware that crashed several times when we sent it a command. However, we felt like we have covered most of the important parts of the malware.
Figure 11. Malware's configuration is stored in the resources. This is were the C&C domain is stored.
Question: So what do you do if you have no live C&C server to test with?
Answer: Why build one of course!!
Once we had reverse engineered the C&C protocol, we implemented a quick and dirty C&C server for the bot to talk to. The C&C server is hardcoded in the malware, but that was easily redirected using iptables so all bot communication was sent to our C&C server.
iptables -t nat -A OUTPUT -p tcp --dport <BOT's port> -j DNAT --to-destination <your IP Address>:<port>
Figure 12. Using adb tool, we can shell to a device and redirect all bot's traffic to our control server using iptables
Figure 13 and 14 is a screenshot of the control panel we wrote. It enables us to control the bot while we reversed engineered it to fully understand how the bot works. This was written with Django web framework and source can be found here for anyone interested:
Here's a video of the control panel in action controlling our bot running in an emulator.
The protocol effectively goes as follows:
- If the bot has not registered yet with the C2 server, register with stbi command and get a new bot-id.
Figure 15. Initial POST data from the bot contains Device information, IMEI, phone model, etc..
Get a list of templates using the sban command to display to the user eventually.
Figure 16. Decoded HTTP POST body, captured shile the bot sends a list of applications from the phone
Loop and wait for commands from the server and dispatch this.
Figure 17. The bot beacons every 10 seconds to obtain new commands.
Dispatch is done through the database by setting a bunch of flags and parameters according to the command to be executed.
Another service then polls the database and executes the appropriate command.
Exfiltration such as sending a list of contacts, sms, and a call list are done using scol, ssl, scal commands respectively.
Figure 18. Decoded data captured when the bot returns a SMS list to the control server
Figure 19. Decode data of exfiltrated contact list
7. Notify the server that the command has been executed using ucs
Figure 20. Crude illustration of the bot and C&C server protocol
We were able to successfully exfiltrate all the data using our C2 server, however, while we had reverse engineered some of the other commands, it was proving difficult to run it on the malware due to it being extremely buggy and would crash when sent the wrong data.
We Googled some of the strings from the decompiled source code and found this bot was known as RED ALERT v2.0 BOT and is being rented out for at least $200 for 7 days test usage, $500 for a month and up to $999 for 2 months.
Figure 21. The bot seller advertising Red Alert V2.0 in the underground forum
This advertisement, in Russian is translated to English as follows:
We introduce absolutely a new product to the market
Red alert 2.0
There is no similar product
All small details are considered
Also, we develop new functionalities
- SMS sending
- SMS interception
- APK launching
- HTML Injects
- APK size 95kb
- SMS interception on all version higher 4.4+ and 6+
- Admin rights gives 85% bots
- Clean APK
If you rent, we develop injects for your any needs and any number.
There is no payment required for the inject development .
- Additionally, we one time per 2 weeks update software with new functionalities. Updates are free of charge for our clients
Rent price 500$ per month
We welcome grants of any form
This bot can target banks from several different countries as listed below:
-Bank of Montreal
-Royal Bank of Canada
-Alior Business Pro
-Citi handlowy (Citibank)
-BGZ BNP Paribas
-Mes Comptes BNP Paribas
-Bank of Baroda
-iMobile by ICICI Bank
-SBI Anywhere Personal
-HDFC Bank MobileBanking
-Union Bank Mobile Banking
-IDBI Bank GO Mobile
-Bank of Ireland
-Caixer automatic Ibercaja
- Unicaja Banco
-Raiffeisen Bank Romania
-Bank Of America
It also targets several payment services, retail applications and social media. Here's the list we obtained from the underground forum.
-Unocoin Bitcoin Wallet India
To wrap-up, we had fun reverse engineering this Android malware and learned a lot. It was interesting to see APK malware being spammed via email, but we wonder how effective the strategy really is for the bad guys. The malware required the user to OK to install, and Android pops up plenty of warnings about permissions. Also, Google Play Protect was detecting this threat, so in order to get the malware installed on Android we also had to disable Play Protect. We haven't seen any more samples being spammed, so perhaps the email campaign was not so successful after all.
Thanks Lloyd Macrohon, Nikita Kazymirskyi, Yermek Garifullanov and Phil Hay for their contributions!