Breaking news? App promises news feeds, brings DDoS attacks instead

ESET researchers discovered a malicious Android app used for launching DDoS attacks. Thanks to the fact it was ESET’s website that was targeted, ESET researchers were able to identify the app, analyze it and report it to Google – who swiftly removed it from the Play store.

The attack targeting ESET’s global website, www.eset.com, occurred in January 2020. It lasted seven hours and was conducted using more than 4,000 unique IP addresses. Those were identified as malicious and blocked for the time of attack.

Our analysis showed the attack was carried out using thousands of instances of the “Updates for Android” app that was – at the time – available on the official Android app store. The app’s only malicious functionality relied on its ability to load JavaScript from an attacker-controlled server and execute it on the user device. This explains why the app made it onto the Play store.

The “Updates for Android” app was first uploaded to the Play store on September 9, 2019. The app’s original version lacked the functionality of loading JavaScript that was, ultimately, abused for carrying out the DDoS attack – it was added in the app’s most recent update two weeks prior to the attack. The app reached over 50,000 installs; we don’t know how many instances of the app were installed after the update or were updated to the malicious version. Based on our notice, Google swiftly removed the app from the Play store.

To garner its victims, and to pose legitimately, the app has a corresponding website, i-updater[.]com, that promotes itself as “daily news updates”. (The website is still live; there are no grounds for any takedown effort as the website itself is not malicious.)

Figure 1. The website promoting the malicious “Updates for Android” app

Functionality

The advertised functionality of the “Updates for Android” app, which is still available in unofficial app sources, is displaying a feed of daily news to the user.

Figure 2. The malicious app’s appearance on Google Play before its removal

Even if the app’s maliciousness is discounted, its name and also the name of its developer, “System apps”, are misleading. The app has nothing to do with any system or system updates.

To avoid suspicion, the app displays some news; however, its main functionality is to receive commands from a pre-defined website that serves as the Command and Control server (C&C). The malware pings the C&C every 150 minutes and provides its device ID – a measure that allows for each device being controlled individually.

Figure 3. List of commands that could be executed by the Updates for Android app

Figure 4. List of commands received from C&C

Malicious functionality

Based on the commands the app receives from the C&C, it can display ads in the user’s default browser (note: this functionality spans outside of the app), hide the presence of the app from the user by hiding the app’s icon, and execute arbitrary, remotely supplied JavaScript.

This last functionality was used for carrying out the DDoS attack on the ESET website.

The following information stems from the analysis of the samples used in the attack.

The malware would open a local file named new_method.html that the app carries in its assets. Its goal is to load remote JavaScript served by the C&C server.

Figure 5. The content of the new_method.html file

Based on the JavaScript code received by the app from its C&C, the device connects every second to the target website to flood it with traffic.

Figure 6. Code returned from the attacker’s server and executed by an infected device

The DDoS attack starts with the compromised device receiving a command to load the attacker's script that specifies the targeted domain. Once the script is loaded, the device starts making requests to the targeted domain until it is served with another script by the C&C server, which may contain a different target domain.

Since we started to monitor the website providing C&C functionality to the botnet, we witnessed another six scripts being served, each containing a different domain for the captive devices to attack. Those were notable news and ecommerce sites, most of them in Turkey. Since February 2, the script is empty, meaning the attackers tried to serve their botnet until two days after Google put the end to (most of) it.

Conclusion

The described method of DDoS attack depends on the number of infected devices available to the attackers. Out of the theoretical number of 50,000+, around 10% were actually involved in the attack.

The described attack shows that attackers may be patient and wait for an app’s user base to grow to the required size before they implement the malicious functionality into the app.

Detecting this kind of malicious functionality is not easy, as the very same technique (of course, without any malicious JavaScript being loaded) is used by dozens of legitimate Android software development kits and frameworks. This means that any plain detection based on such code would result in lots of false positives.

The fact that simple solutions are not viable, however, doesn’t mean the users of Android devices have no chance for protection. We have improved our detection mechanisms based on what we learned from this app’s features and behavior. Some of those improvements have been already implemented in the technologies we use for the protection of the Play store within the App Defense Alliance. Others are being implemented in other security layers in our endpoint security solution, including our machine learning-based detections.

Indicators of Compromise (IoCs)

MITRE ATT&CK techniques

Related reading:

Lukas Stefanko: How we fought off a DDoS attack from a mobile botnet