OK, so last week we took an overview of SSH scans and probes and we dug a bit deeper by examining one of our HoneyPoints and the SSH scans and probes it received in a 24 hour period.

This weekend, we reconfigured that same SSH HoneyPoint to appear as a known vulnerable version. And, just in time for some Monday morning review activity and our blog posting, we got what appears to be an automated probe and then about an hour later, a few attempts to access the vulnerable “service” by a real human attacker.

Here is some of the information we gathered:

The initial probe occurred from a 62.103.x.x IP address. It was the same as before, a simple connection and banner grab. The probe was repeated twice, as per the usual activity, just a few seconds apart.

This time, ~40 minutes later, we received more connections from the same source IP. The IP address only connected to port 22, they did no port scanning, web probes or other activity from that address or in that time frame.

The attacker made several connections using the DropBear SSH client. The attacker seemed to be using 0.47, which has a couple of known security issues, according to the banner the client sent to the HoneyPoint.

The attacker performed various SSH handshake attempts and a couple more versions of banner grabbing tests. Over the next ~20 minutes, the attacker connected 5 times to the HoneyPoint, each time, probing the handshake mechanism and grabbing the banner.

Finally, the attacker decided to move on and no more activity has been seen from the source IP range for a day and a half.

The attacker source IP was from a Linux system in Athens, Greece that appears to belong to an ISP. That system has both OpenSSH 3.9p1 and regular telnet exposed to the Internet. The system advertises itself by hostname via the telnet prompt and the name matches its reverse DNS entry.

We contacted the abuse contact of the ISP about the probes, but have not received any comment as of yet.

The interesting thing about this specific set of probes was that the human connections originated from the same place as one of the banner grabbing scans. This is not usual and is not something that we have observed in the recent past. Usually, the probes come from various IP addresses (likely some form of worm/bot-net) and we rarely see any specifically identifiable human traffic. So, getting the attention of the human attacker is certainly a statistical anomaly.

The other interesting behavior piece here was that the attacker did not bother to perform even a basic port scan of the target. They specifically focused on SSH and when it did not yield to their probes, they moved on. There were several common ports populated with interesting HoneyPoints, but this attacker did not even look beyond the initial approach. Perhaps they were suspicious of the SSH behavior, perhaps they were lazy or simply concentrating on SSH only attacks. Perhaps, their field of targets is simply so deep that they just moved on to easier – more usual targets. It is likely we will never know, but it is certainly interesting, no doubt.

Thanks for the readers who dropped me emails about their specific history of SSH problems. I appreciate your interest in the topic and I very much appreciate the great feedback on the running commentary! I hope this helps some security administrators out there, as they learn more about understanding threats against their networks, incident handling and basic event research. If there are other topics you would like to see covered in the future, don’t hesitate to let me know.

Today, I wanted to take a deeper dive into several port 22 (SSH) scans that a single HoneyPoint deployment received over the last 24 hours. SSH scanning is very common thing right now and our HoneyPoints and firewalls continually experience scans from hosts around the world.

The particular HoneyPoint we are using for this look at the issue is located outside of the US on a business-class network in South America.

Over the last 24 hours this HoneyPoint received SSH probes from 4 specific hosts. These hosts are detailed below:

60.191.x.x – a Linux system located in China on a telecomm company’s network

83.16.x.x – an unknown system located on a consumer (DHCP) iDSL segment in Poland – we could go no further with this host since it is likely to have changed IP addresses since the probe…

218.108.x.x – another Chinese Linux system on yet another Chinese telecomm company’s network (is there anything else in China??? )

216.63.x.x – a NAT device that is front-ending a business network and web server deployment for an optical company in El Paso, TX, USA

The pattern of the probes in each case was the same. Each host completed the 3 way TCP handshake and waited for the banner of the responding daemon. The system then disconnected and repeated the process again in about 90-120 seconds. Basically, simple banner grabbing. The probing system did not send any traffic, just grabbed the banner and moved on.

The HoneyPoint in question was configured to emulate the current version of OpenSSH, so the banner may not have been what the probing attack tool was looking for. It has since been reconfigured to emulate historic versions with known security vulnerabilities.

But, what of the hosts performing the scans? Well, all 3 of them that could be reliably analyzed were found to be running OpenSSH. Two were running 3.6.1p2 and the other was running 3.4p1. Both of these are older versions with known issues.

It is very likely that these are worm/bot infected hosts and the malware is merely looking for new hosts to spread to. Interestingly, 2 of these hosts appeared to be used for regular commerce. Both were acting as a primary web server for the company and one of them even had an e-commerce site running (it also had MySQL exposed to the Internet). No doubt, any commercial activity taking place on the device is also compromised.

MSI has alerted the relevant owners of these systems and at least one of them is moving to handle the security incident. Hopefully, their damage will be minimal and they can rebuild the system easily, since at this point it is likely to also be infected with a root kit. We will advise them as they need help and assist them until they get their problem solved.

In the meantime, I hope this gives you a better look at some of the SSH scanning that goes on routinely. On average, this particular HoneyPoint deployment is scanned for SSH every 5.25 hours. This time varies from locale to locale, with US sites getting scanned more often, particularly on commercial networks. The majority of these scans come from China, with Eastern Europe pulling a distant second. In some cases, some of our US HoneyPoint deployments get scanned for SSH every 1.5 hours on average, so it is a very common attack, indeed.

Obviously, you should check your own network for SSH exposures. You should also take a look at your logs and see if you can identify how your site stacks up against the average time between scans. Feel free to post comments with any insights or time averages you come up. It could make for some interesting reading.