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.
