Avast Threat Labs analyzed malware that has affected thousands of users around the world
Blog post and analysis by Vojtech Bocek and Nikolaos Chrysaidos
When you get a brand new phone, you expect it to be clean from any malware and adware. Unfortunately, this is not always the case. The Avast Threat Labs has found adware pre-installed on several hundred different Android device models and versions, including devices from manufacturers like ZTE and Archos. The majority of these devices are not certified by Google.
The adware we analyzed has previously been described by Dr. Web and goes by the name “Cosiloon.” As can be seen in the screenshots below, the adware creates an overlay to display an ad over a webpage within the users’ browser. The adware has been active for at least three years, and is difficult to remove as it is installed on the firmware level and uses strong obfuscation. Thousands of users are affected, and in the past month alone we have seen the latest version of the adware on around 18,000 devices belonging to Avast users located in more than 100 countries including Russia, Italy, Germany, the UK, as well as some users in the U.S.
We are in touch with Google and they are aware of the issue. Google has taken steps to mitigate the malicious capabilities of many app variants on several device models, using internally developed techniques. Google Play Protect has been updated to ensure there is coverage for these apps in the future. However, as the apps come pre-installed with the firmware, the problem is difficult to address. Google has reached out to the firmware developers to bring awareness to these concerns and encouraged them to take steps to address the issue.
We’ve observed strange Android samples coming into our database from time to time for a few years now. The samples appeared to be like any other adware sample, with the exception that the adware appeared to have no point of infection and several similar package names, the most common being:
Recently, one of the samples topped our detection statistics after our apk.io threat intelligence platform marked it as malware, so we started digging. It turns out these adware packages are just payloads dropped from a system application pre-installed by the manufacturer on a surprising amount of various devices. Even more surprising is that the earliest sample of the dropper, which is an app that downloads further malicious apps, we have is from January 2015 and was preinstalled on a budget tablet sold in Poland. Moreover, the dates on the files inside the oldest APK we have are old, some dating as far back as January 1, 2016 and March 7, 2013. This adware family also has many variants of both payloads and droppers, indicating continuous development.
The C&C server used to control the malware is still active and being updated with new payloads. We contacted CNCERT, as well as the companies that host the C&C server, and the server was taken down on April 10, 2018. The domains, however, are still live.
The malware family is old, not particularly stealthy, and at least parts of it are usually detected by common antivirus apps, but despite this, we are not aware of any detailed analysis that would link all the pieces together. So, let's get into it.
The whole assembly consists of two separate APKs; the dropper and the payload. Older versions of the malware had a separate adware app pre-installed in the /system partition, but this approach appears to have been changed in favor of the new, dropped payload.
The dropper is a small application with no obfuscation, located on the /system partition of affected devices. The app is completely passive, only visible to the user in the list of system applications under “settings”. We have seen the dropper with two different names, “CrashService” and “ImeMess”. There are several versions in the wild, all sharing the same basic behavior:
1. They download a manifest from http://www.cosiloon.com/version.xml when the device is connected to Wi-Fi. Different subdomains (abc, abd) and different file names (version_2.xml, version_3.xml, information.xml) are also used, presumably for debugging. Right now, they all point to the same file or are broken.
The XML manifest contains information about what to download, which services to start and contains a whitelist programmed to potentially exclude specific countries and devices from infection. However, we’ve never seen the country whitelist used, and just a few devices were whitelisted in early versions. Currently, no countries or devices are whitelisted. The entire Cosiloon URL is hardcoded in the APK. The manifest changed throughout time and we have several versions recorded. We are keeping a history of the manifest’s contents here and this is its content as of 2018-03-19:
2. Then, the dropper installs a payload from a URL. The dropper downloads an APK from a <url> found in the manifest (it changes from version to version) to /sdcard/Download/<name> and then installs the APK via the pm install command, the standard command to install apps on Android devices.
3. Finally, the dropper starts the payload service. The <startupX> entries from the manifest are used to start the payload’s services. This step is repeated each time the phone boots.
We have found at least eight different code variations of the dropper with numerous different signatures (since it’s a system application, it is always signed by the same key the vendor used to sign the system image). The base functions of all variations are the same, with some subtle differences in the hardcoded URLs and support for additional pre-installed malware packages. All in all, this is a simple and flexible dropper that works well, as long as the authors have control of the hardcoded domain, and can keep the URL up and running.
To summarize:
Detecting the dropper is further complicated by the fact that it is a system app, part of the devices’ read-only firmware, which is integrated in the device shipped from the factory. Also, it is likely odexed in most firmwares, meaning the app’s code was removed from the original APK file, optimized and stored separately during the firmware’s build process. As a result, cybersecurity firms are likely missing many of the dropper samples and have to rely on the payload for detection and statistics.
A second variant of the dropper is a bit more interesting. The code is pretty much the same as the first variant, but it is not a separate system application. The code is embedded in SystemUI.apk, an integral part of the Android OS. This makes the dropper pretty much impossible to remove by the user.
SystemUI.apk usually contains the implementation of the user interface, like status and notification bar, lockscreen and more. The samples we examined had the dropper code hidden in the com.android.keyguard package:
This variant uses manifests on http://www.cosiloon.com/version_4.xml and http://www.cosiloon.com/version_5.xml which serve a slightly different version of the payload (with different intent & receiver names), so we can tell that this variant is significantly less popular than the other, with variant A having thousands of affected users, and variant B only about 200.
The SystemUI.apk samples we examined were also infected with two more malware packages, all capable of showing apps, installing additional APKs from the internet and submitting private data such as IMEI, Mac address and phone number to remote servers, but their code seems unrelated to the Cosiloon family, so we won’t go into them any further.
Another implication of the dropper being part of SystemUI.apk instead of a separate APK is that the firmware’s source code was somehow hijacked and modified, which is difficult to do.
We have found over a hundred different payload versions. We’re going to mainly focus on the latest one[1], but most of the analysis applies to other samples as well.
The payload, in contrast to the dropper, is heavily obfuscated and very complex. In addition to the usual class renaming and reflection use, it also includes randomly inserted method calls that don’t affect the application state, and even includes methods that are completely useless. These are likely added in an effort to make manual analysis harder, but may actually trigger some static analysis heuristics due to their contents (CALL or SEND intents may look like malicious behavior). The obfuscation mechanism certainly required a lot of effort.
Example of a method that doesn’t actually do anything.
Example of randomly added statements with no effect.
The payload APK includes an XOR-encoded JAR file[2] which currently contains Google, Facebook, and Baidu ad frameworks. It also includes emulator detection based on files in /dev, which means it is able to detect if the file is run in an antivirus emulator, and, if so, will hold back any suspicious actions so that it goes unnoticed. An update mechanism is also built-in, and is capable of downloading additional dex files from the internet.
The payload seems to only be active if the system dropper is present, but we have managed to trigger its behavior several times. For us, it offered downloads of questionable games from the Baidu network:
The intrusive pop-ups have rate limiting (so they don’t show up too often). The full screen ad variant also seems to include a check that prevents it from showing up on top of everything but the current default web browser.
Most versions of the payload do not have any user-facing entry point, except for the short-lived H5GameCenter version and the new version #29[3], which shows entry in the app launcher, masking as “Goolge Contacts”. Tapping on the icon starts the ad service and opens the default web browser. The payload versions that are not visible on the tablet’s or phone’s screen again are visible to the user only as system applications under “settings” and come with about 15 different names, including “MediaService”, “eVideo2Service”, and “VPlayer”.
The payload icon in the app drawer.
The corresponding code in the payload.
On April 8, 2018, the payload was updated again. The name in app launcher changed to “Google Download” and some class names in the code changed (notably “.backservice” to “.startService”), likely in an attempt to avoid detection.
The next update happened on April 17, 2018. The payload’s code was significantly simplified, and it was renamed to “Google++”. It no longer contains an encrypted code package inside, but still shows ads like the previous versions. This appears to be a temporary version they were forced to develop as we took down the old C&C server, since the next day’s update brought almost all of the code back and the payload looks very similar to the state before it was taken down.
The system dropper contains whitelisting methods which disable the whole package under certain conditions. They are rather interesting and enable the creator to modify the adware behavior based on current requirements.
The dropper checks how many apps the user has installed, and stops if it is less than three. This prevents the ads from showing up, for example, on demo devices in stores and perhaps during the Google CTS certification process.
Furthermore, nothing is dropped if the device language is set to Chinese.
The XML manifest also specifies a <country> tag that could be used to whitelist devices in specific countries, but as previously mentioned, this whitelist hasn’t been used as far as we know.
The tag <reject> from the version.xml manifest is used for this whitelist.
The location whitelist is implemented in a rather interesting way. First, the URL specified in the <ipurl> tag inside the version.xml is queried, which is currently http://pull-3045.kxcdn.com/getip.php. It returns the IP address of the server, but since it is using a content delivery network (CDN), the <ipurl> is resolved to different servers based on the user’s location.
The returned IP is then checked against an SQLite database of IP ranges packed into the dropper application, in assets/data. It contains over 320k different IP ranges, almost all of which are in China.
According to our statistics, users in over 90 countries are affected. The top ten over the last month are Russia, Italy, Germany, the United Kingdom, Ukraine, Portugal, Venezuela, Greece, France, and Romania.
Several hundred different devices are affected. The affected devices usually sport a Mediatek chipset and are mostly low cost tablets. The list, including the most affected devices, can be found here and includes devices from brands like Archos, ZTE, and Prestigio. The list is likely so extensive because the malware was part of a chipset platform package which is reused for many similar devices with different brand names. We cross-checked many, but not all of the devices, and noticed that the chipset on the devices we inspected was from MediaTek. The devices run different Android versions ranging from 4.2 to 6.0.
Not all device models listed are affected, as each model has countless firmware variants (e.g. for different countries, and carriers) and only a few or one variation of a device might be affected, or perhaps a custom ROM version had the dropper. This list simply contains device models on which we spotted the dropped payload at least once in its <downloads>/Temp path, which is the path the system dropper downloads the payload to before installing it, and the payload was also installed on the same device.
It is impossible to check all of these devices, but we have downloaded some of their firmware images and confirmed that the dropper is indeed preinstalled on some of them, in paths like /system/priv-app/CSTR.apk (ZTE E10Q, 4.4.2) or /system/priv-app/ANLRadio/ANLRadio.apk (Alcor Access Q784M, 5.1).
As the dropper APK comes with the firmware, it is hard for antivirus apps to detect, and it cannot be removed. Antivirus apps will detect the payload, however, once antivirus removes it, the dropper will again do its job and re-download the payload.
The reach of this malware strain seems to be very wide. By searching for the app names, you can find user reviews of different devices in many countries, complaining about ads showing up. Here’s a few examples:
This sample appears to be an early version of the dropper. It does not download anything, but instead stores the payloads in the assets folder inside the APK and installs them periodically. The earliest sample we have is from November 2014. The same class names (.BackService) and similar code structure link it to the rest of this family.
Com.android.keysetting seems to be the earliest version of the adware payload. It is meant to be installed as a system app, too. The app does not really do anything anymore since the servers (*.7176.com) are dead, but it was prepared to show ad overlays. It contains the same classes and “if locale set to Chinese then do nothing” check as the newer payloads, and it contains an encrypted .jar file with the ad framework shared among several other intrusive apps. The jar contains strings with dates from July 2014.
com.get.googleApps is another early version of the adware application. It was installed as a system application, and mostly used Google AdSense, but this approach was discontinued and most of the code from this app moved to the payload.
This version of the payload is from around December 2016. It is notable because unlike all the other payloads, it actually has user-facing activity besides the ad pop-ups. It is supposed to be a “game app store”. It made the news around December 2016 when Dr. Web found it.
By far the most jarring fact is that Dr. Web reported on this in 2016… and yet nothing happened. The control server was live until April 2018, and the authors kept updating it with new payloads. Manufacturers also continued to ship new devices with the pre-installed dropper. Some antivirus apps report the payloads, sure, but the dropper will install them right back again and the dropper itself can’t be removed, so the device will forever have a method allowing an unknown party to install any application they want on it. We have seen the dropper install adware on the devices, however, it could easily also download spyware, ransomware or any other type of threat.
We have attempted to disable Cosiloon’s C&C server by sending takedown requests to the domain registrar and server providers. The first provider, ZenLayer, quickly responded and disabled the server, but it was restored after a while using a different provider. The domain registrar has not responded to our request, so the C&C server still works.
Avast Mobile Security can detect and uninstall the payload, but it cannot acquire the permissions required to disable the dropper, so Google Play Protect has to do the heavy lifting. If your device is infected, it should automatically disable both the dropper and the payload. We know this works because we have observed a drop in the number of devices infected by new payload versions after Play Protect started detecting Cosiloon.
Users can find the dropper in their settings (named “CrashService”, “ImeMess” or “Terminal” with generic Android icon), and can click the "disable" button on the app's page, if available (depending on the Android version). This will deactivate the dropper and once Avast removes the payload, it will not return again.
https://docs.google.com/spreadsheets/d/10GREhHGREaQvx45kb7AI4FkXDFX1VDjNWyRpU9qGJ5k/edit?usp=sharing
[1] 838d70c21ab98bfbf9c69ce516ddebbd988cade05d25558b086e1c103dadcb06
[2] b81a7e72197fa8dff5970e6c326d18f678799f316985daf6aef7b3e562bfb2ad
[3] 12a6a5e9c58f8a04f54ef812f2159a0fa760ae9272141749f8ed6fc919622da1
Avast is a global leader in cybersecurity, protecting hundreds of millions of users around the world. Protect all of your devices with award-winning virus protection. Safeguard your privacy and encrypt your online connection with SecureLine VPN.
1988 - 2024 Copyright © Avast Software s.r.o. | Sitemap Privacy policy