Teardown of Android/Ztorg (Part 2)

UPDATE March 20, 2017 : the sample does not seem to embed root exploits themselves, but more precisely executables that run rooting tools. Also Agcr64 is curiously a 32-bit executable, not 64-bit.

In the part 1 of this blog, we saw that Android/Ztorg.AM!tr silently downloads a remote encrypted APK, then installs it and launches a method named c() in the n.a.c.q class. In this blog post, we’ll investigate what this does.

This is the method c() of n.a.c.q:

This prints "world," then waits for 200 seconds before starting a thread named n.a.c.a. I'll spare you a few hops, but among the first things we notice is that the sample uses the same string obfuscation routine, except this time it is not named a.b.c.a() but a.a.p.a(). We patch the JEB2 script to deobfuscate those strings:

Embedded Packages

The sample checks for various packages (om.android.provider.ring.a, com.ndroid.livct.d). If they are present, it starts them. If not, it retrieves them and starts them.

The way it retrieves the application is quite peculiar. By default, it does not download it from the web, but gets it from a hexadecimal string stored in the code itself. It only downloads from the web if the hexstring is not present.

It retrieves many files that way: Android applications, ELF executables and scripts. All of these are embedded in the sample itself. Sometimes, the sample is embedded in an encrypted form (making it even more difficult to detect for an anti-virus engine.) This is the case of the mainmtk.apk application, which is retrieved from a DES encrypted hex string. The DES key is built using a homemade algorithm, which consists of numerous Base64 encodings and decodings.

Resorting to Encrypted File Download

When the files are downloaded from the web, they are not sent in clear text, but are XOR encrypted (see class b.b.b.a.b). The XOR key is contained within the encrypted stream.

Based on the reverse engineering of the decryption class, we can implement a decryptor. Mine is available here.

For example, once decrypted, the bx file downloaded from hxxp://ks.freeplayweb.com/lulu/bx turns into an ELF executable (a root exploit):

Creating Scripts

The sample also uses some shell scripts. They are not included in the assets or resources, but embedded in the code. This is probably done so that anti-virus engines cannot directly match or search for those scripts.

For instance, the code below writes a shell script named boy.

The script will look as follows, and is used to run shell commands.

 

Files Summary

Now let's summarize the various files the sample uses. We have applications and ELF executables. If you want to follow along in the source code, those are retrieved in the b.b.d.a namespace.

The files are stored locally in the application's directory, in subdirectories named .zog or .zok. Note, the name starting with a point will conceal the file to basic file listings.

File name	File type	Description
Agcr32	ELF executable	Runs root exploit tools, 32 bit version
Agcr64	ELF executable	Runs root exploit tools, expected a 64 bit version, but actually it seems it's a 32 bit version too...
bbox.apk	Application	Installs busybox
bx	ELF executable	Runs root exploit tools
cx	ELF executable	Runs root exploit tools
exp	ELF executable	Runs root exploit tools
maink.apk	Zip	Contains boy and bx files
mainmtk.apk	ELF executable	Rusn root exploit tools
mainm.apk		Replacement for com.android.musitk.b
mainp.apk		Could not be retrieved (server down)
mains.apk	Application	Replacement for com.ndroid.livct.d
mains2.apk	Application	Replacement for com.android.provider.ring.a
nn.zip	ELF executable	Runs root exploit tools
np	ELF executable	Runs root exploit tools
supolicy	ELF executable	tool
ym32	ELF executable	Runs root exploit, 32 bit version
ym64	ELF executable	Runs root exploit, 64 bit version

We see we have:

• Tools such as busybox and supolicy. These are not malicious. Busybox is used to support various Unix commands on Android. Supolicy is used to modify the current SE Linux policies on Android, and for instance, switch the phone to permissive policies.
• Root exploit tools. For example, the executable Agcr32 tries to root the phone by running rooting tools. It considers it has succeeded if the output contains the keyword TOY. See below. This is the 32-bit variant.

• Scripts to run commands.

Running the exploits

Once the root exploits are on the file system, they need to be run. This is done in the code by creating a new process that runs sh, writing the shell commands to the process's output stream, and reading the responses on the input stream.

Payload

Let's put pieces together.

The sample:

• Gets numerous exploits, tools and scripts to root the device. The files are embedded in the code itself, or retrieved from external websites.
• Lowers the SE Linux policy and attempts to root the device.

Once the device is rooted, the sample gets to its real payload:

• Replaces some system files with its own versions. For example, it creates a backup of the original /system/bin/debuggerd, replaces it with its own .zog/.k file, assigns it to root, and changes its SE Linux security context.
• Installs various applications and runs them. In the case of this sample, those applications are com.android.provider.ring.a, com.ndroid.livct.d, and com.android.musitk.b. The .zog/.k ELF executable also downloads other applications from a remote server and installs them. The screenshot below shows the .zog/.k starting a key assistance application (am start -n) and downloading from http://api.agoall.com/ (no longer responds.)

So, we have a malware that roots victims' devices without their knowledge, and uses this privilege to install other malicious applications.

Conclusion

This concludes the analysis of the sample silently downloaded by the Android/Ztorg.AM!tr sample that we studied in Part 1 of this blog.

My guess is that you will agree with me that this malware is very advanced. There is string obfuscation, multiple levels of encryption (nested), root exploits, tools, and scripts hidden inside the code. The malware will be difficult to remove from the device, because it spans across many locations and replaces system binaries.

This malware is detected as Android/Ztorg.K!tr. Its sha256 sum is 5324460dfe1d4f774a024ecc375e3a858c96355f71afccf0cb67438037697b06.

The downloader (see Part 1) is detected as Android/Ztorg.AM!tr.

Its sha256 sum is 2c546ad7f102f2f345f30f556b8d8162bd365a7f1a52967fce906d46a2b0dac4.

-- the Crypto Girl