Triada Android Trojan
The Triada Android Trojan family is a malware family that first grabbed the attention of cybersecurity professionals back in 2016. Soon after it first emerged, the Triada Android Trojan was detected on devices produced by a long list of Chinese phone brands. Among the brands in question are iLife, Prestigio, Leagoo and Mito. So far, malware researchers have not been able to determine whether the mobile devices' manufacturers were aware of the presence of the Triada Android Trojan. However, the more likely explanation is third party software used by the manufacturers. This is an exceptionally threatening infection vector as the majority of users would never suspect that their brand-new device has a Trojan installed on it before they ever got to use it.
Despite the fact that it first appeared in 2016, Triada is still very much active. In August 2020, it turned out that thousands of customers had been sold Tecno W2 smartphones infected with Triada. The list of countries where customers were affected includes South Africa, Ethiopia, Cameroon and Ghana.
Generally, the Triada Android Trojan is not going to cause a lot of harm. It’s a modular trojan and the default modules of the Triada Android Trojan only allow it to collect information regarding the compromised device's hardware and software. Triada sends the gathered data to one of the C&C (Command & Control) servers of the Triada Android Trojan's operators. When this is completed, the Triada Android Trojan receives a unique victim ID for the affected machine. Additionally, the C&C sends a list of modules that will be planted on the compromised host. This clever feature allows the operators of the Triada Android Trojan to expand the capabilities of this threat greatly.
One of the more prominent features of the Triada Android Trojan is its capability of modifying the Zygote Android process. Since Zygote is the core process in the Android OS and it is a template for all applications, once the Trojan gets into Zygote, it essentially becomes a part of every app launched on the infected device. This also allows the Triada Android Trojan to manage how the device is handling newly installed applications.
Triada History and Evolution
Initially, Triada installed a type of superuser (su) binary file. This su binary enabled other apps on the device to use root permissions. The su binary that Triada used required a password, so it was different from regular su binary files often found on Linux systems.
Triada’s binary accepted two passwords, od2gf04pd9 and ac32dorbdq. The difference was what the binary did when provided with each one. The binary could either:
- Run the command given as an argument as root
- Combine all of the arguments, run that chain preceded by sh, then run them as root.
Either way, the application had to provide the correct password to run the command as root.
The rooting functionality of the Triada Android Trojan allowed for the installation of apps and the display of ads. This version of the trojan targeted older model devices because the rooting exploits don’t work on current generation devices. Therefore, Triada enforced a weight watching feature to determine if previously installed apps should be deleted to make space for new installs.
This process to assign a Weight to apps had several steps and the goal was to free up space on the infected machine’s user partition and system partition. Triada included a blacklist and whitelist of apps. The first priority was to remove all the apps on its blacklist. In case more free space was needed, Triada would remove all other apps that were not on the whitelist. In this way Triada freed up space while making sure the phone functioned properly.
All apps on the system partition were given numbers to represent their weight. The weight was calculated as a sum of the number of other applications installed on the same date and the number of apps signed with the same certificate. As a result apps that had been installed in isolation (meaning, not on a date when the device system image was created) and weren’t signed by the OEM or didn’t come as a part of a developer bundle were assigned the lowest weight number. These were the apps Triada deleted first in its weight watching process. This went on until there was enough space for the new app Triada aimed to install.
Triada install process - Source: security.googleblog.com
The apps Triada installed had one goal - to display ads and bring revenue to the cybercriminals. However, Triada also injected malicious code into at least four web browsers: AOSP (com.android.browser), 360 Secure (com.qihoo.browser), Cheetah (com.ijinshan.browser_fast), and Oupeng (com.oupeng.browser). The goal of the code injection was to redirect URLs and change ad banners on websites with ads making money for Triada’s authors.
Another thing that set Triada apart was that it used a strange and complex communication encryption routine. When it sent a request to the C&C server, it encrypted the data using two XOR loops with different passwords. Because of how XOR works, if the passwords had the same character in the same position, those characters weren’t encrypted. After encrypting the request, Triada saved it in a file, which had the same name as its size. The last step was to compress the file using zip and send it to the C&C server in the POST request body.
Over the years Triada has changed in response to Google’s security measures. In mid 2017 the trojan was transformed into a pre-installed Android framework backdoor. For that purpose, Triada included a call in the Android framework log function. This change resulted in the execution of an additional code every time the log method was called. Since such calls happen all the time the additional code was running constantly. What’s more, the code executed in the context of the app calling the log method. This allowed Triada to execute code in the context of any app.
The creators of Triada came up with a new file format, which Google security researchers called MMD, on account of the file header. The MMD format is an encrypted version of a DEX file executed in the app context. The cybercriminals used a double XOR loop deploying two different passwords as shown below.
Triada file format password deployment process - Source: security.googleblog.com
Each MMD file was named following the format 36.jmd. The criminals used MD5 of the process name aiming to obscure the injection target. However, the hash was easy to reverse because of the limited pool of all available process names. Google’s security researchers identified two targets: com.android.systemui (the System UI app) and com.android.vending (the Google Play app). Com.android.systemui was injected to get the GET_REAL_TASKS permission. As a signature-level permission, it’s one that ordinary Android apps can’t hold.
Since Android Lollipop, the getRecentTasks() method is deprecated to protect users' privacy. However, if an app holds the GET_REAL_TASKS permission it can still get the result of this method call. For an app to hold that permission, it has to be signed with a specific certificate, the device’s platform cert, which is held by the OEM. Since Triada couldn’t access this cert, it instead used the System UI app, which has the GET_REAL_TASKS permission to execute additional code.
The second app Triada targeted with the injection was Google Play. The code enabled five commands and responses to them. The supported commands were:
- Download request
- Download result
- Install request
- Installation result
- Activation request
- Activation result
- Pull request
- Pull the results
- Uninstall request
- Uninstall result
In the Triada app and injection codes these commands were in Chinese. The commands initiate the corresponding action in the context of the Google Play app. By doing so, Triada could make it appear that all app installs came from the Google Play app, that in turn meant that the malware didn’t have to turn on the option allowing the installation of applications from unknown sources.
Triada downloaded the applications from its C&C server and encrypted the communication with the same custom encryption method using double XOR and zip. The packages of the applications Triada downloaded and installed were named after unpopular apps found on Google Play. Those apps had nothing to do with Triada, the cybercriminals were just using their names.
The final important part of how Triada worked was the communication between the log function backdoor and the applications that were installed. The applications could communicate with the backdoor by logging a line with a specific predetermined tag and message. Communication in the other direction was more difficult. The backdoor communicated with the apps using Java properties to send messages. The properties in question were key-value pairs akin to Android system properties, except they were focused on a specific process. Modifying a property in the context of a certain app means that it won’t be detected by other apps. Certain versions of Triada created these properties in every app process.
Triada malware properties creation processes - Source: security.googleblog.com
OEM Infection Vector
The way Triada finds its way on new devices is through third-party software. This usually happens when OEMs decide to include a feature which isn’t available in the Android Open Source Project. In such cases OEMs often turn to third-parties to create the feature the OEMs are looking for and send back a whole system image to the vendor for development. Google’s security researchers suspected a vendor who went by Yehuo or Blazefire might have infected the image with Triada.
Triada OEM vendor infection processes - Source: security.googleblog.com
Google reported that they worked with affected OEMs to provide system updates and eradicate Triada. However, as of 2020 there are still cases of devices infected with Triada.
