by Jindrich Karasek
We observed a new cryptocurrency-mining botnet malware that arrives via open ADB (Android Debug Bridge) ports and can spread via SSH. This attack takes advantage of the way open ADB ports don’t have authentication by default, similar to the Satori botnet variant we previously reported. This bot’s design allows it to spread from the infected host to any system that has had a previous SSH connection with the host.
The use of ADB makes Android-based devices susceptible to the malware. We detected activity from this malware in 21 different countries, with the highest percentage found in South Korea.
We found that the IP address 45[.]67[.]14[.]179 connects to the ADB running device or system then conducts several activities. Figure 1 summarizes the attack’s infection chain.
The attack starts by using the ADB command shell to change the attacked system’s working directory to “/data/local/tmp”. This is because .tmp files typically have default permission to execute.
The bot then determines the kind of system it has entered and whether the system is a honeypot or not, as indicated by the command “uname –a”.
It then uses wget to download the payload, and curl if wget is not present in the infected system. The bot then issues the command “chmod 777 a.sh” to change the permission settings of the downloaded payload, allowing it to be executed.
Finally, when “a.sh” is executed, it is removed using the command “rm -rf a.sh*” to remove its traces. All these commands can be seen in the malware’s code as seen in Figure 2.
The script for a.sh reveals that this attack will choose from three different downloadable miners. This can be seen in the output of the “uname -m” command, shown in Figure 2 above.
The uname –m command, once executed, gets the infected system’s information, such as its manufacturer, hardware details, and processor architecture. The output from this command is used as a variable for determining the miner to use in the attack.
As mentioned earlier, if uname –m gets the string indicating the infected system’s processor type, then it uses the additional wget command to download the miner. It will use curl if the system does not have wget.
The three miners that can be used for this attack are listed below, all of which are delivered by the same URL.
To optimize the mining activity, the script also enhances the victim’s memory by enabling HugePages, which will help the system support memory pages that are greater than its default size. This ability can be seen in the script as “/sbin/sysctl -w vm.nr_hugepages=128”.
This botnet malware also tries to block its competitor by modifying /etc/hosts. By adding the additional record “0.0.0.0 miningv2.duckdns.org”, it blocks the URL of the competing miner. It also kills that competitor’s process with the command “pkill -9 r32”.
Lastly, it employs an evasion technique that involves deleting the downloaded files. After spreading to other devices connected to the system, it deletes its payload files, removing the traces on the victim host.
Another notable aspect of this attack, although certainly not unique to it, is the presence of a spreading mechanism that uses SSH. Any system that has connected to the original victim being attacked via SSH is likely to have been listed as a “known” device on its operating system. Being a known device means the system can communicate with the other system without any further authentication after the initial key exchange, i.e., each system considers the other as safe. The presence of a spreading mechanism may mean that this malware can abuse the widely used process of making SSH connections.
This list of known devices and the SSH settings are saved in known_hosts, which can be seen in the malware’s code. The combination of known hosts and the victim’s public key makes it possible for the malware to connect to smart devices or systems that have previously connected to the infected system. It does so using two spreaders, as can be seen in Figures 3 and 4.
The first spreader takes all the systems from known hosts by IPv4 addresses, accesses them, and installs the same miner used in the originally attacked system. The second script has the same purpose, but it searches in a different directory for the “known_hosts”. These two spreaders allow the malware to attack and likely infect the other systems that communicate with the first affected system.
Conclusion and security recommendations
Although ADB is a useful feature for administrators and developers, it is important to remember that an enabled ADB might expose the device and those connected to it to threats.
Users can also follow other best practices for defending against illicit cryptocurrency-mining activities and botnets, such as:
- Checking and changing default settings when necessary to increase security
- Updating device firmware and applying available patches
- Being aware of methods attackers use to spread these types of malware and tailoring defenses against them
Android users can take advantage of Trend Micro™ Mobile Security for Android™ (available on Google Play) to block malicious apps that may exploit this vulnerability. End users and enterprises can also benefit from its multilayered security capabilities that secure devices’ data and privacy and safeguard them from ransomware, fraudulent websites, and identity theft. For organizations, Trend Micro™ Mobile Security for Enterprise provides device, compliance and application management, data protection, and configuration provisioning. It also protects devices from attacks that leverage vulnerabilities, prevents unauthorized access to apps, and detects and blocks malware and access to fraudulent websites.
Users can also adopt multilayered security solutions that can provide protection from various iterations of cryptocurrency-mining malware. Trend Micro XGen™ security provides high-fidelity machine learning that can secure the gateway and endpoints, and protect physical, virtual, and cloud workloads.
Indicators of Compromise (IoCs)