Unkillable xHelper and a Trojan matryoshka

[harlan4096]

It was the middle of last year that we detected the start of mass attacks by the xHelper Trojan on Android smartphones, but even now the malware remains as active as ever. The main feature of xHelper is entrenchment — once it gets into the phone, it somehow remains there even after the user deletes it and restores the factory settings. We conducted a thorough study to determine how xHelper’s creators furnished it with such survivability.

How does xHelper work?

Let’s analyze the family’s logic based on the currently active sample Trojan-Dropper.AndroidOS.Helper.h. The malware disguises itself as a popular cleaner and speed-up app for smartphones, but in reality there is nothing useful about it: after installation, the “cleaner” simply disappears and is nowhere to be seen either on the main screen or in the program menu. You can see it only by inspecting the list of installed apps in the system settings.

The Trojan’s payload is encrypted in the file /assets/firehelper.jar (since its encryption is practically unchanged from earlier versions, it was not difficult to decrypt). Its main task is to send information about the victim’s phone (android_id, manufacturer, model, firmware version, etc.) to https://lp.cooktracking[.]com/v1/ls/get…

…and downloading the next malicious module — Trojan-Dropper.AndroidOS.Agent.of.

This malware in turn decrypts and launches its payload using a bundled native library; this approach makes it difficult to analyze the module. At this stage, the next dropper, Trojan-Dropper.AndroidOS.Helper.b, is decrypted and launched. This in turn runs the malware Trojan-Downloader.AndroidOS.Leech.p, which further infects the device.

Leech.p is tasked with downloading our old friend HEUR:Trojan.AndroidOS.Triada.dd with a set of exploits for obtaining root privileges on the victim’s device.

Malicious files are stored sequentially in the app’s data folder, which other programs do not have access to. This matryoshka-style scheme allows the malware authors to obscure the trail and use malicious modules that are known to security solutions. The malware can gain root access mainly on devices running Android versions 6 and 7 from Chinese manufacturers (including ODMs). After obtaining privileges, xHelper can install malicious files directly in the system partition.

Note here that the system partition is mounted at system startup in read-only mode. Armed with root rights, the Trojan remounts it in write mode and proceeds to the main job of starting the tellingly named script forever.sh. Triada employs its best-known tricks, including remounting the system partition to install its programs there. In our case, the package com.diag.patches.vm8u is installed, which we detect as Trojan-Dropper.AndroidOS.Tiny.d.

And several executable files get copied to the /system/bin folder:

* patches_mu8v_oemlogo — Trojan.AndroidOS.Triada.dd
* debuggerd_hulu —AndroidOS.Triada.dy
* kcol_ysy — HEUR:Trojan.AndroidOS.Triada.dx
* /.luser/bkdiag_vm8u_date — HEUR:Trojan.AndroidOS.Agent.rt

A few more files are copied to the /system/xbin folder:

* diag_vm8u_date
* patches_mu8v_oemlogo

A call to files from the xbin folder is added to the file install-recovery.sh, which allows Triada to run at system startup. All files in the target folders are assigned the immutable attribute, which makes it difficult to delete the malware, because the system does not allow even superusers to delete files with this attribute. However, this self-defense mechanism employed by the Trojan can be countered by deleting this attribute using the chattr command.

The question arises: if the malware is able to remount the system partition in write mode in order to copy itself there, can the user adopt the same strategy to delete it? Triada’s creators also contemplated this question, and duly applied another protection technique that involved modifying the system library /system/lib/libc.so. This library contains common code used by almost all executable files on the device. Triada substitutes its own code for the mount function (used to mount file systems) in libc, thereby preventing the user from mounting the /system partition in write mode.

On top of that, the Trojan downloads and installs several more malicious programs (for example, HEUR:Trojan-Dropper.AndroidOS.Necro.z), and deletes root access control applications, such as Superuser.

How to get rid of xHelper?

As follows from the above, simply removing xHelper does not entirely disinfect the system. The program com.diag.patches.vm8u, installed in the system partition, reinstalls xHelper and other malware at the first opportunity.

But if you have Recovery mode set up on your Android smartphone, you can try to extract the libc.so file from the original firmware and replace the infected one with it, before removing all malware from the system partition. However, it’s simpler and more reliable to completely reflash the phone.

Bear in mind too that the firmware of smartphones attacked by xHelper sometimes contains preinstalled malware that independently downloads and installs programs (including xHelper). In this case, reflashing is pointless, so it would be worth considering alternative firmwares for your device. If you do use a different firmware, remember that some of the device’s components might not operate properly.

In any event, using a smartphone infected with xHelper is extremely dangerous. The malware installs a backdoor with the ability to execute commands as a superuser. It provides the attackers with full access to all app data and can be used by other malware too, for example, CookieThief.
...

Continue Reading