Red Alert v2.0: Misadventures in Reversing Android Bot Malware

(Analysis by Rodel Mendrez and Lloyd Macrohon)

Spam Campaign

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.

Initial Analysis

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, hereand 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:

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 filescontains 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 vDexExtractortool.

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 Studioor anyJava 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:
  • GetTemplateHandler
  • PostCallListHandler
  • PostContactListHandler
  • ServerCommandHandler - controls the malware by mostly writing to the database
  • RegisterDeviceHandler
  • SendSmsListResponseHandler
  • GetSmsListResponseHandler

• 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.

Key Characteristics

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:
  • startSmsInterception
  • stopSmsInterception
  • sendSms
  • setDefaultSms
  • resetDefaultSms
  • getSmsList
  • getCallList
  • getContactList
  • setAdmin
  • launchApp
  • block
  • sendUssd
  • notify

• 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 herefor anyone interested:

Figure 13

Figure 14

Here's a video of the control panel in action controlling our bot running in an emulator.

The protocol effectively goes as follows:

1. 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..

    

2. 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

    

3. Loop and wait for commands from the server and dispatch this.

   

   Figure 17. The bot beacons every 10 seconds to obtain new commands.

    

4. Dispatch is done through the database by setting a bunch of flags and parameters according to the command to be executed.

5. Another service then polls the database and executes the appropriate command.

6. 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

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.

Underground Market

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:

Hello!
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

Functionality:
-  SMS sending
-  SMS interception
-  APK launching
-  HTML Injects
Features:
-  APK size 95kb
-  SMS interception on all version higher 4.4+ and 6+
-  Admin rights gives 85% bots
-  Clean APK
-  Durability

Unique features:
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:

AUSTRALIA

-ANZ Bank

-Bankwest

-CUA

-ME Bank

-Newcastle Permanent

-Suncorp Bank

-Commonwealth

-CitiBank

-ING Bank

-NAB

-St.George

-WestPac

AUSTRIA

-Raiffeisen

-Volksbank

CANADA

-Bank of Montreal

-CIBC

-Desjardins

-TD Bank

-Royal Bank of Canada

-Tangerine

CZECH

-Air Bank

-Equa Bank

-mBank CZ

POLAND

-AliorBank

-Alior Business Pro

-Alior Mobile

-BZWK24

-BZWK24 Biznes

-BZWK24 Mobile

-Citi handlowy (Citibank)

-EuroBank

-Getin Bank

-ING

-iPKO

-BGZ BNP Paribas

-PekaoBank

-PekaoBiznes24

-Raiffeisen Poland

-mBank

DENMARK

-Danske Bank

-Nordea

-Jyske bank

-MobilePay

-Sydbank

-Nykredit

GERMANY

-Post Bank

-Commerzbank

-ComDirect

-Sparkasse

-DKB Bank

-Sparda-Bank

FRANCE

-Crédit Mutuel

-Bankque palatine

-Banque Populaire

-Ma banque

-Lapost bank

-Mes Comptes

-Banque

-Mes Comptes BNP Paribas

LITHUANIA

-Swedbank lt

INDIA

-Axis Mobile

-Bank of Baroda

-iMobile by ICICI Bank

-India Bank

-SBI Anywhere Personal

-HDFC Bank MobileBanking

-Union Bank Mobile Banking

-IDBI Bank GO Mobile

-Kotak Bank

-YesBank

ITALY

-Intesa Sanpaolo

-UBI

IRELAND

-Bank of Ireland

-Ulster Bank

-Permanent tsb

JAPAN

-Aeon Bank

-MUFG Bank

-Orico Bank

-Rakuten Card

SPAIN

-CaixaBank

-BBVA

-Bankia

-Cajamar

-Caixer automatic Ibercaja

-Banco Sabadell

-Satander Bank

- Unicaja Banco

ROMANIA

-Central Transilvania

-BCR Bank

-Raiffeisen Bank Romania

SWEDEN

-Swedbank

TURKEY

-AkBank

-DenizBank

-Finansbank

-Banking banks

-Turkiye Bankasi

-HalkBank

-VakifBank

-YapiKredi

-Ziraat bank

UNITED KINGDOM

-Metro Bank

-Natwest

-Barclays

-Lloyds

-HALIFAX

UNITED STATES

-Bank Of America

-ChaseBank

-Suntrust

-Capital One

-WellsFargo

NEW ZEALAND

-Kiwi Bank

 

It also targets several payment services, retail applications and social media. Here's the list we obtained from the underground forum.

Payment Systems

-PayPal

-Airbnb

-Coinbase

-Poker Stars

-Neteller

-Skrill

-Unocoin Bitcoin Wallet India

 

CC+VBV Grabbers

-Amazon

-eBay

-LINE

-GetTaxi

-Snapchat

-Viber

-Instagram

-Facebook

-Skype

-UBER

-WeChat

-WhatsApp

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!