Excuse me. Are you an Adware or a Rootkit?

Like I've said in a previous post, Adware nowadays can be so complex that they aren't just adware anymore. Some adwares are now packed with other traits as if they're on steroids! 



Today, I'll be covering two recently discovered Adwares by FireEye, Xinyinhe and Kemoge. These two innocently dubbed adwares aren't so innocent when they infect your devices. So be careful!


Xinyinhe, are you just an adware?
Xinyinhe was supposedly developed by a Mobile App Promotion company named NGE Mobi/Zinyinhe and claims to have a value of more than $100M with offices in China and Singapore.

This malware's dev repackages popular apps by injecting malicious logic and components to them.

When an infected app has been downloaded and installed to a device, the malware will unpack and releases the malicious payload along with the normal components of the repackaged app.

Let's get technical!
First, the adware collects and uploads the infected device's device model details, MAC address, IMEI/IMSI, system and software info to a remote server. All uploaded data will be encoded using AES/CBC/NoPadding followed by Base64.
It then downloads an APK and dynamically loads logic to execute.

The downloaded APK will be under the name "com.dashi.rootmaster.demo" and it will be loaded into the original app and then drives the process of rooting the user's device.

After loading the root master to the device, the app will extract a few native executables and a shell script. Each binary corresponds to a root exploit, namely Framaroot, Root exploit targeting Mediatek mt65xx chips, put_user exploit, Mempodroid, etc.

When the infected device has been successfully rooted, the app will execute a "rsh" script. This script may perform actions such as remount /system as writable, implant SU daemon as the root backdoor into /system, and append a line into install-recovery.sh that executes on boot, set the install-recover.sh as immutable to avoid removal, and install APKs into /system partition to consistently and persistently control the user's device.

Xinyinhe's workflow

And you thought Xinyinhe's malicious acts stop there? HA!
Now that the malware has total control over the user's device, it will use the infected device however it wants. The malware never mounts the /system back to read-only, and allows anyone(and i mean, anyone who wants to prey on a very vulnerable device) to invoke its root backdoor to obtain root privilege. Any other malware that wants to perform malicious acts on this infected device can freely have a go at it. All communications use HTTP so that anyone can hijack the connection and take over the control of this large botnet. (poor device. :( )

This malware also downloads and installs a browser app with the name, "Cool Browser". This app serves adult content in its own home screen and promotes other malicious apps on the infected device. It also puts pornographic videos and app ads as shortcuts on the device's home screen.

This is what "Cool Browser" does to your infected device

"Is Xinyinhe finished with my device already? I mean. Come on!". Of course not!
Regardless whether the rooting process of the user's device was successful or not, this adware utilizes the Android Accessibility Service to check if the current window is the Android installation prompt. If so, it will force click the install button. How you ask? This malware will have added accessibility entries. The description of the accessibility will be misleading and does not mention that it will force click the install button. The samples themselves lures victims to enable the accessibility entry.

additional accessibility entries

Xinyinhe tricks users to enable the auto start service

If the user follows the instructions given in order to enable the corresponding accessibility service, the installation of any app promoted by the samples will be automated as:

• If the user clicks the ad to download an APK and trigger the installation prompt, the malicious accessibility service automatically clicks "install" and "yes" on behalf of the user.
• If the user clicks an ad but the ad points to a Google Play link, the malicious accessibility service automatically clicks "install" and "accept" when Android prompts the permission list to the user to confirm.

In conclusion, even if the malware fails to root the infected device it could still automatically install any app without the user's consent.

Additionally, the normal Java code and native code obfuscation of the malicious adware obfuscates itself using methods that increase the difficulty of detection and reverse engineering. It uses packers to pack executables as well as Java and native components that are encrypted and extracted at runtime.

Now, on to the next Featured Adware. Kemoge.


Kemoge, an adware with multiple faces. Literally.
Kemoge has a lot of repackaged versions of popular apps roaming around third-party play stores, download links from websites and in-app ads. It could even be installed via an aggressive ad network that had gained root privilege on an infected device.

Let's get technical!
Once launched, the malware will collect the infected device's information and uploads them to an ad server. It will then bombard the infected device with ads. It even displays an ad if the device is just on the home screen. But wait! There's more!(corny ad joke. haha~ get it?---nevermind.)

Kemoge's cycle

Kemoge's adware trait will then change to something more sinister. It will register a MyReceiver in the AndroidManifest so that it will launch automatically whenever the user unlocks the device or the network connectivity changes. MyReceiver prompts MyService. Both are disguised as Google's code.(ex. com.google.rp.confirm, com.google.system.provider.comfirm) MyService then looks for an asset called '<name>.mp4'. <name> could be bg, info or hello. The mp4 extension actually hides the fact that the asset is a ZIP file with multiple levels of encryption. It uses ZIP inherent password-based encryption to protect its content. The protected ZIP file is then encrypted with DES(Data Encryption Standard). It encrypts the DES Key(Key1) with another DES Key(Key2) and disassembles Key2 as bytes in the code. At runtime, Kemoge decrypts the ZIP file in a reversed order.

Kemoge's real-time decryption process

After the decryption process, Kemoge opens the ZIP file which includes 8 root exploit executables(Yes, my dears. 8!). and other files that targets a wide range of device models. The root methods may include mempodroid, motochopper, perf_swevent exploit, sock_diag exploit and put_user exploit. Some of the exploits may come from open source projects while others from a commercial tool called "Root Dashi".

After gaining root access to the user's device, Kemoge will now execute root.sh to obtain persistency and then implants a AndroidRTService.apk into the /system partition as Launcher0928.apk, which copies a legit launcher system service's filename. 

The now malicious system service will then contact aps.kemoge.net for commands. The system service only asks for commands on the first launch or after 24 hours from its last command to avoid user detection. In each interaction, the malware first posts the IMEI, IMSI, storage info and installed app info of the infected device back to the remote server. The malware will then ask the remote server for more commands. The remote server may command the malware to upload more information or ask the malware to uninstall and install certain apps on the infected device. It may even tell the malware to download and install apps from a list of URLs given.
















Article Refs: https://www.fireeye.com/blog/threat-research/2015/09/guaranteed_clicksm.html and https://www.fireeye.com/blog/threat-research/2015/10/kemoge_another_mobi.html