I often come across various communities that strongly encourage people to self-host for a variety of reasons: in the interest of data sovereignty, to break free from big tech, or simply because it’s “FUN”. However, I believe that many of these encouragements do not take into account the risks associated with running your infrastructure, nor do they take into account the competence required to correctly configure specific products, systems, applications so that they can provide a secure solution. And if you can’t accomplish this (or if you run outdated, vulnerable software), you might end up with an entry point in your setup, allowing an outsider to gain access to your server. Moreover, without the ability to respond promptly 24/7, you may not be able to react in a timely manner — assuming you’ve even set up some kind of intrusion detection.
As an experiment, I spun up a server and redirected the SSH daemon on the host away from the default port 22. In its place, I deployed an SSH honeypot called sshesame and let it run for a few hours. I configured it to accept any combination of usernames and passwords, allowing me to monitor the commands being sent.
The results provide valuable insights into the modus operandi of these threat actors. The initial actions seem always to be to ascertain what they have gained access to by looking at the current running kernel, what CPU/GPU is present, geographic location of the server, and if the server has GSM capabilities. One interesting aspect is that a search for a [Mm]iner process was made, which would indicate that the machine is vulnerable and has the potential to be exploited.
Funny enough, they always seem to ignore the MOTD banner saying in capital letters “THIS IS A SSH HONEYPOT. EVERYTHING WILL BE LOGGED AND MONITORED” :-)
I would like to take this a step further and provide a useful response back when the probing commands are issued; my current setup simply responds command not found to each command invoked, and a response closer to a real-world scenario would yield more interesting results. However, my gut feeling is that these probes are only after bitcoin mining candidates, considering that the threat actors’ initial commands are probing for the hardware capacity of the machine and if other miners are present.
You can access the full raw log here to get an idea of how threat actors operate (or just see what credentials they use to log in).
If you’re interested in setting up your honeypot, it’s as simple as running the following Docker command:
sudo docker run -it --rm -p 22:2022 ghcr.io/jaksi/sshesame
Do note that the antagonists in this example are not particularly sophisticated; a persistent threat actor might act in a similar way during the initial foothold, but would probably act very differently shortly thereafter (or probably stop at the warning sign that they are entering a honeypot).
You can find more honeypots on this awesome list and read up more in depth about running a custom honeypot on the honeynetwork