After being targeted by an Android DDoS app, ESET seized the opportunity to analyze the attack and to help put an end to it
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.)
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.
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.
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.
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.
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)
Package Name | Hash | Detection |
---|---|---|
com.world.hello.myapplication | 34A6BD8B96729B6F87EC5E4110E02BEE1C76F5A9 | Trojan.Android/Hiddad.AJN |
MITRE ATT&CK techniques
Tactic | ID | Name | Description |
---|---|---|---|
Initial Access | T1475 | Deliver Malicious App via Authorized App Store | The malware impersonates legitimate services on Google Play. |
Persistence | T1402 | App Auto-Start at Device Boot | The malware listens for the BOOT_COMPLETED broadcast, ensuring that the app’s functionality will be activated every time the device starts. |
Defense Evasion | T1508 | Suppress Application Icon | The malware hides its icon from launcher. |
Impact | T1472 | Generate Fraudulent Advertising Revenue | The malware can display unwanted advertisement. |
Command and Control | T1436 | Commonly Used Port | The malware uses port 443 for its C&C communications. |
T1437 | Standard Application Layer Protocol | The malware uses HTTPS for its C&C communications. |
Related reading:
Lukas Stefanko: How we fought off a DDoS attack from a mobile botnet