Teardown of a Recent Variant of Android/Ztorg (Part 1)

Ztorg, also known as Qysly, is one of those big families of Android malware. It first appeared in April 2015, and now has over 25 variants, some of which are still active in 2017. Yet, there aren't many technical descriptions for it – except for the initial Ztorg.A sample – so I decided to have a look at one of the newer variants, Android/Ztorg.AM!tr, that we detected on January 20, 2017.

The sample poses a "Cool Video Player" and its malicious activity was so well hidden I initially thought I had run into a False Positive. Definitely not, however, as we'll see.

Locating the Malicious Code

The sample's manifest shows the main activity is located in com.mx.cool.videoplayer.activity.MainActivity.

This activity initializes multiple SDKs, from which I could not detect malicious intent:

• com.adjust: Adjust SDK, for app analytics
• com.batmobi: Batmobi for mobile advertising
• com.catchgift: code shows this is clearly for advertising
• com.marswin89: this is a MarsDaemon, a library to keep apps alive. Interesting, but not malicious as such.
• com.squareup: well-known mobile payment
• com.umeng: well-known mobile advertising & analytics

So, where is the malicious code? Or is it just some not-so-clean code in one of these SDKs that triggered a (false positive) alert?

I kept on looking in other namespaces of the app:

• u.aly contained code for Mobclick – advertising again (hey, for the sake of AV analysts at least, can you developers stop using so many advertising SDKs, huh?),
• android.support.v4 is standard for app development.
• Namespace e.i.o.q isn't doing anything apart calling functions from the a namespace.

So, that's when I started looking into namespace a…

String Obfuscation

I immediately noticed many obfuscated strings, and couldn't resist de-obfuscating them (after all, I'm the Crypto Girl, right?).

For instance, we have this:

and c.a() is implemented as follows:

This basically takes the first and last byte as XOR key for the rest of the byte array. From that, I wrote a quick standalone Python decoder, mimicking the decompiled code. It is handy, but as I use JEB2 a script is even better where I can have it replace the strings directly in the decompiled output.

JEB scripts are a little trickier to write. Mine parses the decompiled classes, and in each class locates statements with a c.a(new byte[] { … }). The call to the decoding function occurs in several situations though, e.g v0[6] = c.a(new byte[]{… but also a = new String(c.a(new byte[]{…. Consequently, the right hand side of the line needs to be analyzed quite closely. Then, when a call is detected, the script decodes the value, and replaces it with the result.

For example, the first figure (on the left) illustrates the initial decompiled code for a.a.a. The second figure shows the result after applying the script.  

My scripts are available on Github.

Emulator Detection

Among the decoded strings, we notice many references to VirtualBox, QEMU etc. This is emulator detection, and we'll see that it is particularly advanced.

Let's go back to the flow of execution. The onCreate() method of the main activity ( MainActivity) calls f(), which calls e.i.o.q.d(). Reversing e.i.o.q.d(), we understand the function tests whether it is running on an emulator or not. It only runs the malicious part if not on an emulator, which explains why sandboxes won't be able to record any malicious activity.

The emulator detection routine is particularly advanced and extensive. It detects standard Android emulators, Genymotion emulators, Bluestacks emulators, BuilDroid VMs, and also tainted environments that use TaintDroid.

The detection is based on:

1. Specific values in system properties. This is quite standard, except the tests are particularly extensive (see Table) in this case.
2. Typical values for IMEI, IMSI and phone number on emulators. On Genymotion, the IMEI can be customized, but not the IMSI. On standard Android SDK emulators, none of these are easily customizable. It is possible to patch and re-compile one's emulator.
3. Presence of specific files. For example, /dev/qemu_pipe. From an AV analyst's perspective, this is difficult to counter, because many of the emulating environments won't work properly without these files.
4. Checking values in given system files. In particular, it's the first time I have seen malware checking values inside /proc/net/tcp. This is interesting: the file records active TCP connections. The first column corresponds to the number of entries, second column is local address, third column local port, and fourth column remote address. On a real device, we have something like this:

0: 4604D20A:B512 A3D13AD8…

But on emulators, the addresses are zeroed and easily noticeable:

0: 00000000:0016 00000000:0000

5. Specific TaintDroid class (dalvik.system.Taint) and injected fields (name in FileDescriptor class and key in Cipher). The code was probably inspired from Tim Strazzere's Anti Emulator code.

Downloading Remote Content

We have seen that the sample implements advanced emulator detection. However, many clean apps do that for various reasons. So where is the malicious stuff? At this point, we aren't convinced yet that this is not a False Positive.

Actually, we're getting closer. After the sample has tested it is not running on an emulator, it sends an HTTP request to hXXp://bbs.tihalf.com/only/[$1]/2.html?. This is a URL we de-obfuscated at the previous step. The [$1] is replaced with gp1187 (another de-obfuscated string), and an information blob is appended to the url, where the blob is a DES-encrypted JSON object containing code version, SDK version, etc.

This is getting more suspicious.

The response is base64 encoded, and encrypted with DES-CBC (see class a.c.a):

The key is hard-coded (it's the de-obfuscated string sokhlwej) and the IV is DES_e.IV = new byte[]{1, 2, 3, 4, 5, 6, 7, 8};. We decrypt the server's response:

We notice that o and p contain a link to an Android package. Are they used? Yes! As soon as the JSON object is retrieved, the sample reads the URL in o and tries to download the file. If ever o does not work, it tries p.

So, basically, in this case, the sample downloads another Android package from hXXp://alla.tihalf.com/only/gp1187/gp1187.apk and stores it locally on the smartphone.

But we are not done yet. The downloaded APK is not in clear text:

It is XOR-ed with 0x99 (see code excerpt of class a.d.f) and copied to a file named dba.jar:

This indeed results in a valid Android package:

And then? It loads the downloaded application, of course! See code below – taken from a.d.n.

The installation of the application is done via DexClassLoader and is invisible to the end-user.

Finally, it invokes a method of that application. Specifically, it loads the class referenced by key q in the JSON object, and invokes method h from the JSON object:

In our case, q is n.a.c.q and h is c, so the sample invokes n.a.c.q.c().

Conclusion

This Ztorg sample does a very good job of concealing its maliciousness, but we can confirm that it is malicious and not a False Positive.

• It implements many emulator detection features. It detects the Android SDK emulator, but also emulators from Genymotion, Bluestacks and BuilDroid. It also detects tainted environments. Several of its checks will be difficult to bypass.
• It uses string obfuscation, based on XOR.
• It communicates with a remote server using DES-CBC encryption.
• It downloads, installs and launches an Android application from that remote server.

In part 2 of this analysis, we will examine the downloaded application.

— the Crypto Girl

Appendix:

Sample analyzed in this article:

sha256: 2c546ad7f102f2f345f30f556b8d8162bd365a7f1a52967fce906d46a2b0dac4

Table 1: Elements tested by Android/Ztorg.AM!tr to detect emulators