Blue Coat Labs

Labs Blog

Dendroid under the hood – A look inside an Android RAT kit

Dendroid under the hood – A look inside an Android RAT kit

Felix Leder

Recently , Symantec and Lookout blogged about an Android malware creation kit that was advertised in malware forums: Dendroid. Dendroid consists of a web-based administration panel and a builder that can add “Remote Administration Toolkit” (RAT) functionality by repackaging it with existing applications.

Researchers have discussed how easy it is to patch Dendroid into existing apps, which is scary enough given how quick users are to download new apps. What caught our interest, though, is the variety of malicious functionality. One of the scariest examples is that it can secretly record all of your phone calls or silently listen in on the built-in microphone whenever it wants. And who doesn’t take their phone to meetings?

The malware can also surreptitiously upload all pictures on the phone – a big privacy violation that, on the harmless side, could result in unflattering pictures of you on vacation. More costly, though, is the uploading of pictures of notes from brainstorming sessions or pictures of your family and loved ones. Like earlier versions of Android malware, Dendroid can also send SMS messages to premium-rate numbers. Because the phone owner doesn’t know this is happening, it can become incredibly costly.

Dendroid under the hood – A look inside an Android RAT kit-

In addition to all its evil functionality—secret recording, ability to upload photos and send SMS messages to premium-rate numbers, the Dendroid authors claim to have “Google Play Bypass” functionality.

Google Play Bypass functionality

A hardcoded flag determines if Dendroid should check if it is running in Google’s Bouncer. Previous research by Jon Oberheide and Charlie Miller highlights several ways to identify if an app is running in Google’s sandboxes.

The technique used by Dendroid does not only identify Bouncer but any type of Android emulator. The actual check is not very sophisticated, checking only the DEVICE, BRAND, PRODUCT, MODEL, and CPU (HARDWARE) of the system. If any of these match to that of an emulator, the service sleeps for one hour.

Check for running inside Android emulator

A typical emulator reports the following values compared to a real phone (example):


  • google_sdk_x86
  • Android SDK built for x86
  • generic_x86
  • generic_x86
  • goldfish

HTC phone

  • htc_vision
  • HTC Vision
  • htc_wwe
  • vision
  • vision

In case there is no indication of the emulator, the “Start” flag is set and a background thread is started that communicates with the C&C server.

Network fingerprint

Upon start, Dendroid first checks general Internet connectivity and then the availability of its primary and backup URLs. As a first steps, it sends a heartbeat with information about its environment.











The information is gathered with a best effort approach. That means that unavailable information, like when GPS is turned off, is not filled in. Since all parameters are passed as GET parameters, it can be used to fingerprint infections in the network. A proxy server or IDS can be used for that.

A very convenient feature is that Dendroid includes the Android device ID in the requests. This can be used by administrators to identify infected devices right from the network stream.

After the device has identified itself to the server, it retrieves the functions that are to be executed. The URL for this is




The server returns a list of commands (called functions) that are to be executed on the device. There is a hard-coded 2 second delay between the execution of each command. Once all commands have been executed, the service sleeps for the amount of milliseconds initially defined in the “timeout” configuration parameter. In this case, 10 seconds. This parameter can be changed by one of the functions available for the C&C server.

More Nasty Tricks—Parental Control

I came across a sample that was created in November 2013, but not found in the wild until late December 2013. This sample included an activity that even identified itself as “com.connect.Dendroid.” It is packaged inside an application called “com.parental.control.v4.”


MD5: db01f96d5e66d82f7eb61b85eb96ef6e

       349252  2013-11-30 12:13   assets/android-support-v4.jar

      708  2013-11-30 12:13   res/layout/cameraview.xml

      404  2013-11-30 12:13   res/layout/main.xml

      568  2013-11-30 12:13   res/layout/videoview.xml

      228  2013-11-30 12:13   res/menu/connect_layout.xml

     7968  2013-11-30 12:13   AndroidManifest.xml

     2404  2013-11-30 12:13   resources.arsc

   114450  2013-10-26 01:31   res/drawable-hdpi/launcher.png

   114450  2013-10-26 01:31   res/drawable-ldpi/launcher.png

   114450  2013-10-26 01:31   res/drawable-mdpi/launcher.png

   114450  2013-10-26 01:31   res/drawable-xhdpi/launcher.png

   694556  2013-11-30 12:13   classes.dex

      977  2013-11-30 12:13   META-INF/MANIFEST.MF

     1030  2013-11-30 12:13   META-INF/CERT.SF

      649  2013-11-30 12:13   META-INF/CERT.RSA

Hiding it as a parental control tool is a smart move. Parental control apps need several of the same privileges as the RAT like accessing GPS coordinates or checking installed apps. This way the app is less likely to raise suspicion, even with manual inspection.

This social engineering move is important as the app requests plenty of suspicious permissions when installed on a device, including:


The RAT client needs these permissions in order to get access to the various data sources. Android only allows access to these if the user approves it.

Obfuscated configuration

A first look into the internal code structure reveals that relevant parts of the configuration data are obfuscated. The URL to the command and control (C&C) server is base64 encoded in order to bypass heuristics in static analysis environments. Several analysis tools automatically extract strings that look like URLs, but base64-encoded URLs are often missed.

Dendroid also includes a backup URL in case the main server is not reachable anymore. In addition to that, a password is encoded. This password is sent in plain text to the server and is used as a campaign identifier.

Hardcoded Configuration

Other configuration parameters are not obfuscated. Interesting in this case are the URL extensions. They are used for uploading files, sending latest status updates, or receiving new commands. Very interesting is the flag called “GPlayBypass”, which stands for “Google Play Bypass.” This functionality is used to evade detection by Google’s sandbox “Bouncer,” through which almost every app has to run before it is allowed into the Google Play store.


The overall functionality is implemented as a background service by the name “com.connect.MyService.” This allows for the compiled code to be added to existing apps without having to significantly patch their code.

Available commands/functions

The wide variety of available commands is probably the most impressive part of Dendroid. After every successful command execution, the server is notified with a message





The “Data” field contains more information about each executed command and helps the bot master to identify problems and to get telemetry about the execution. It is also used to receive specific data collected by the individual commands.

The following commands are available and can be triggered by the C&C server in arbitrary order:

  • mediavolumedown – Decrease the media volume
  • ringervolumeup – Increase the ringer volume
  • ringervolumedown – Decrease the ringer volume
  • screenon – Activate the screen
  • recordcalls – Record calls to file
  • intercept – Intercept incoming SMS and forward them to C&C server
  • blocksms – Block incoming SMS
  • recordaudio – Record audio from microphone and save to file
  • takevideo – Record a video and save it to a file
  • takephoto – Take a photo with the local camera and save it to a file
  • settimeout – Change the delay for retrieving the next set of commands/functions
  • sendtext – Send an SMS
  • sendcontacts – Send all contacts to the C&C server. Each individual entry is sent as a separate query and therefore very noisy.
  • callnumber – Call a given number using the phone
  • deletecalllognumber – Delete all calls to a given number from the call log
  • openwebpage – Open a web-page with the default browser
  • updateapp – Checks if available versions are newer than the current one and downloads a new APK file to “/mnt/sdcard/Download/update.apk”. The installation is triggered by using default mechanisms on the phone and likely requires user interaction.
  • promptupdate – Repeats the installation of the update. This behavior can be used to nag the user in case he cancels the update prompt the first (few) times.
  • promptuninstall – Uninstalls itself. This, again, requires user interaction
  • uploadfiles – Uploads all files in a given file path. Each file is uploaded as a separate HTTP form-data post. This is very likely to create a lot of traffic and connections.
  • changedirectory – Randomly changes the external storage of collected data between «System», «System Media», «Saved Files», «Recent Media», and «Temporary»
  • deletefiles – Delete all files in a given folder
  • getbrowserhistory – Retrieve the history of the default browser (noisy because every bookmark is a separate request)
  • getbrowserbookmarks – Retrieve the bookmarks of the default browser (noisy because every bookmark is a separate request)
  • getcallhistory – Upload the full call history (very noisy)
  • getcontacts – Redundant implementation of the same functionality as “sendcontacts” using different URL parameters :)
  • getinboxsms – Uploads all SMS found inside the SMS inbox
  • getsentsms – Uploads all SMS that are inside the SMS “sent” folder
  • deletesms – Delete an SMS with a given ID
  • getuseraccounts – Get all user accounts registered on the device
  • getinstalledapps – Get information about all installed applications. This can be used to identify e.g. installed security products
  • httpflood – Poorly implemented HTTP flooder. Basically simple (D)DoS functionality to attack remote servers. The implementation is single threaded and closes the connection.
  • openapp – Start an installed application
  • opendialog – Open a popup for the user
  • uploadpictures – Upload information about all pictures from the device’s media store to the C&C server
  • setbackupurl – change the backup URL of the C&C server
  • transferbot – change the main URL of the C&C server

Each command can come with a number of parameters that are separated by “~~”. E.g. the “takevideo” command has 2 parameters: One that specifies the camera (in case the device has multiple), and one that specifies the time of the recording.

Each command is executed in a separate thread. All of the commands that submit multiple pieces of information are very noisy as most functions result in an HTTP request for every single piece of information. Thus, activity profiles of specific devices can be used to identify infected devices on the network.

Source code for Sale

The author also advertised selling the source code for both the panel and the builder in a forum in October 2013. According to that post, it took him/her “1.3” years to finalize Dendroid.

In another forum post, the author asks for advice on pricing and making his creation available. This is a small, yet interesting, discussion around building up a business model for this RAT kit.


All in all, this is a very interesting piece of malware. The large variety of available commands shows the full threat potential that an infected phone can have. The emulator detection is simple but is likely to work in various analysis environments. Since the kit includes components to repackage existing apps, we can expect to see more of Dendroid in the future.

The variety of functionality is also the weak point of Dendroid and can be used to detect it. The HTTP requests are very verbose and have unique characteristics. Users of Android devices should be extremely careful when an app requests such a wide variety of suspicious permissions.

Users of networks forensics appliances, like Blue Coat’s Security Analytics Platform, should look for indications of the traffic patterns given above. Specifically when all of the Android device IDs are known it is a good idea to look for these in URLs.