What SSH Hacking Attempts Look Like

With jobs that have been so tied to secure software design and government compliance, I constantly fall back on the assumption “if it’s insecure, you’ll eventually be hacked”. But what does being hacked actually look like? If I set up a server and don’t make myself an obviously vulnerable target (i.e. not going to show up in common shodan.io searches) what would actually happen?

Queue the honeypot concept. A “honeypot” is an intentionally vulnerable “thing” that can be used to study malicious traffic and activity on a network. This “thing” can be anything, a single port on a server, an HTML element on a webpage, or even a network with multiple servers. Once it’s set up, any malicious traffic towards the server can be studied and turned into actionable intel.

So I went searching for honeypot software that I could run myself. I ended up using Cowrie, a Python based SSH/Telnet emulator that is based on the prior work of the Kippo project. I was attracted to it for a few reasons: it had a lot of support articles, it was written in Python, and the Cowrie worked with Kippo’s lightweight visualization software Kippo-Graph. With Kippo-Graph I could keep an eye on things from my phone without having to SSH into the server.

I’ll skip the gory details of the setup, but if you’re interested “Use the Cowrie SSH Honeypot to Catch Attackers on Your Network” was an awesome tutorial.

So, I fired up the honeypot software and set the SSH emulator on port 22 to allow the usernames root and admin with the passwords changeme and 1234567, respectively. I sat back and watched and…

Access Attempts on the Honeypot

People tried to guess my SSH password a lot. Anywhere from 200 to just over 1200 times per day. The tries mostly came from:

And with the passwords set at what I thought were very insecure (remember, passwords were just changeme and 1234567) only 4 attempts were successful. I was hacked by:

• Feb 11th: An IP in Hefei, Anhui, China that tried 42 times before guessing user root and password changeme. After the success, it stopped and I was immediately compromised by an IP in Seoul (I assume the same actor changing IP’s). The IP attempted to run the Linux command “uname -srmo” and the command worked, but the emulated honeypot command didn’t handle the “-srmo” options and the actor disconnected.
• Feb 20th: An IP in Haarlem North Holland, Netherlands that tried 15 times with user root and password changeme. It mimicked the same behavior as the last actor.
• Feb 24th: A Tor node using user root and password changeme. It only tried once and then immediately disconnected without running a command. Since it guessed the username/password combination on the first try I assume it was one of the prior actors checking back in on its access.

All of this was honestly pretty anti-climactic and boring. My job is to tell people if they do insecure things they’ll be hacked! And yet here I was, using bad username/password combinations and barely getting compromised. So, I decided to turn it up.

I looked at the graphic that Kippo-Graph provides of the username-password combinations.

I was still a little weary about the consequences of a lot of action in my honeypot, so I avoided all of these default IoT credential-looking passwords and chose two new combinations to add. The first was admin/admin1 (I saw a few attempts on these) and the second was one I thought was very interesting, pi/raspberryraspberry993311.

Pi is the default user for the popular Raspbian distro that is used widely with the Raspberry Pi systems. However, the default password is raspberry not raspberryraspberry993311. A quick Google search of the password brought up a lot of raw honeypot data but no explanation! So, I decided to accept it and see what the deal was.

And right away I was hacked by the French! Well, someone coming from a French IP. And it curiously used that raspberryraspberry993311 password. The threat actor immediately uploaded a bash script and attempted to run it. The bash script was a worm that configured the server to:

• Periodically report back to a Undernet IRC Channel for command and control
• Change the password to raspberryraspberry993311 (so that’s why we were seeing these attempts!)
• Start scanning public IP space to attempt to spread the worm further. When it was doing this scanning, it would try both pi/raspberry and pi/raspberryraspberry993311 presumably as a way to spread updates if command and control went down.

This Raspberry Pi Botnet malware did quite quite a few other things and I plan to get around to an entire post dedicated to dissecting that.

After the French, I was hacked by an IP in Switzerland that switched to an IP in Ireland after it found successful credentials. The threat actor attempted to load malware onto the machine that used the phrase “gweerwe323f” throughout. The malware mostly contained shellcode, and I haven’t had the time to really pick that apart either. But based on further compromises, this was definitely another botnet running through scripted actions.

Finally I wanted to see what would happen if I just set the credentials to accept username admin and password admin. Over the next day I just kept getting hacked by the same gweerwe323f botnet over and over.

At this point the fun had started to dwindle so I killed the honeypot. For those interested, here are the top 10 passwords attempted:

And here are the top 10 username/password combinations that were attempted on my honeypot:

They all felt extremely Internet of Things oriented at first glance. It absolutely shocked me that it is worth the time of these drive-by attacks to try combinations like root/password, root/root, or root/admin. Apparently they have enough successes using those incredibly insecure combinations that it is worth their time.

I also did a quick analysis of my Apache access log to see what was attempted on my password protected web-server. Since the web-server wasn’t vulnerable there was not much malicious activity to dissect, but I did see a lot of requests to access the path /manager/html that would exist by default for an ApacheTomcat installation. Otherwise, it was just the classic attempts to find phpMyAdmin.

I wouldn’t feel like this post is complete without suggesting the open source software Fail2Ban. For those of you who got to the bottom of this and was wondered “well, why don’t I just block those IPs”, you are absolutely correct. Software like Fail2Ban can monitor your log files for malicious activity like this and block future attempts from those IPs. There’s also plenty more you could do with this data or a honeypot. Put a honeypot internally on your company network and watch for malicious activity such as network scanning. Put it in your company’s Public IP space and see if there’s any targeted attacks unique to your company or industry.

Maybe in the future I’ll revisit the data and search for more interesting patterns like what lead me to the Raspberry Pi botnet. For now, my honeypot is turned off and I’d call it a successful experiment.