A new version of a malicious shell script targeting insecure cloud instances running under Cloud Service Providers such as Tencent, Baidu and Alibaba Cloud has recently been discovered. The shell script prepares the target host for additional compromise over SSH, kills off processes from competing threat actors and persists itself, before downloading an additional ELF executable used to connect to a botnet as part of a campaign dubbed by 360Netlab as “Abcbot”.
Based on function names and other similarities within the code, we believe this shell script is an updated version of an installer used in the Abcbot campaign. An earlier version was originally discovered by Trend Micro and this sample is similar to the one analysed in their report, with some notable differences.
Malware Analysis
Upon execution the shell script calls a number of functions sequentially, the first of which is named nameservercheck. This function disables SELinux protections, weakening the host machine. It also ensures network connectivity by inserting IPs for Google’s public DNS servers (8.8.8.8 & 8.8.4.4) into the /etc/resolv.conf file (if they don’t exist). Perhaps more interestingly, data transfer utilities such as curl and wget are renamed. This includes two with the paths /usr/bin/wgettnt and /usr/bin/curltnt.
Given the prevalence of the TeamTNT threat actor, it seems reasonable that the naming convention here is a reference to them. As we’ll discuss later, it’s clear from this shell script that whoever is behind Abcbot has an awareness of other threat actors working in this area.
In contrast to earlier variants of this sample, the Tor proxy service is no longer installed on the host machine. The code for the installation remains but is commented-out, as can be seen below.
Trend Micro mention that Tor is used by additional payloads to anonymise malicious network connections made by the malware. Updates to the payloads themselves could mean they no longer require this.
Killing Competitors
What’s evident from analysis of this shell script is that the threat actor behind Abcbot is heavily invested in keeping their knowledge of the cloud security threat landscape current. A function named kill_miner_proc, which consists of several hundred lines, is dedicated to removing artifacts of crypto mining and cloud-focused malware from the host machine. In it we can see evidence of searching for processes belonging to prominent Linux malware, such as WatchDog and Kinsing, along with generic mining software often used in crypto-jacking campaigns.
Similarly, the malware searches for Docker images and instances used for crypto mining and removes/kills them as appropriate.
Other notable functionality within kill_miner_proc includes the ability to disable and uninstall cloud monitoring solutions found in smaller CSPs, such as the Aliyun Alibaba Cloud Assistant and Tencent’s monitoring service. This is likely used to avoid detection by such products during the malware’s execution and suggests targeting of specific CSPs by the threat actor.
Maintaining Access
After initial configuration the malware establishes persistence via rc.local and cron, methods common to UNIX and UNIX-like systems. A command to download a copy of the shell script is added to the /etc/rc.d/rc.local file, which ensures that the file is downloaded and executed in the background on each boot.
A similar approach is used to establish persistence via cron. The script cycles through commands, attempting to download and execute the copy of itself via curl, cdt, wget and wdt at a frequency of 31, 32, 33 and 35 minutes respectively.
After both methods of persistence are established, the sample proceeds to configure the Linux iptables firewall via the iptables command. We can observe the iteration of this sample in the function responsible for the iptables setup, as the author has again left some code commented-out.
Network Access
Previously, it appears that those behind abcbot attempted to configure the iptables firewall to accept ingress traffic from the IP address 64[.]225[.]46[.]44/32. They also appear to have, at one point, added a rule to drop ingress traffic from ports associated with the Docker API (2375/2376). These rules are no longer added to iptables if they are not already present. Instead, the malware adds a more generic rule, to allow all ingress traffic on TCP port 26800. This differs from the sample analysed by Trend Micro and likely facilitates communication with a C2 server, as the IP addresses hosting additional payloads also use this port.
Aside from this, the shell script exhibits similar functionality seen in previous versions, with the threat actor removing SSH keys left by similar attacks and inserting their own to guarantee access to the host. The sample also downloads one of the additional ELF binary payloads observed by Trend Micro and saves it as “abchello”. However, the code used to download the third payload appears to be commented-out.
Finally, if a SSH known_hosts file and corresponding public key exists in the root user’s .ssh directory, the script iterates through the known hosts, connecting to each one in turn and installing a copy of itself using the data transfer tools mentioned previously. This allows propagation of the malware in a worm-like fashion and ensures rapid compromise of related hosts.
Detections
Cado Response detects this threat as abcbot_installer.
Indicators of Compromise
| Filename | SHA256 |
| ff.sh | 56d677ed192b5010aa780d09c23b8ee8fdff94d39b20a07c7de76705e5f8c51f |
| newabchello | 22b521f8d605635e1082f3f33a993979c37470fe2980956064aa4917ea1b28d5 |
| IP Addresses/URLs |
| http://103[.]209[.]103[.]16:26800/ff.sh |
| http://103[.]209[.]103[.]16:26800/xlinux |
References
https://blog.netlab.360.com/abcbot_an_evolving_botnet_en/
For guidance on performing cloud IR, check out our playbooks: The Ultimate Guide to Ransomware Incident Response & Forensics and The Ultimate Guide to Docker & Kubernetes Forensics & Incident Response