Cowrie Honeypot Project

Lounge Fly
6 min readNov 10, 2021

Summary

This project took place in 2020 and it was something that I simply never got around to uploading. The goal was to demonstrate what kind of threat activity was observed from having a simple Cowrie honeypot deployed on a Linux machine. and record our findings.

The Tools

The Virtual Machine(s)

Digital Ocean droplets were created with the following specifications

Honeypot Server

  • Ubuntu 18.04 (LTS) x64
  • 2GB RAM
  • 1CPU
  • 50GB Disk

Honeypot Sensor

  • Ubuntu 18.04 (LTS) x64
  • 1GB RAM
  • 1CPU
  • 25GB Disk

Honeypot Server Software

The Honeypot server selected was Community Honey Network or CHN. This is a derivative of Modern Honey Network. The reason for choosing CHN over MHN is due to compatibility with newer operating systems and continued development.

https://communityhoneynetwork.readthedocs.io/en/stable/ (Links to an external site.)

The Honeypot Sensors

More sensors may be deployed in the future but for now I am using Cowrie. Cowrie is an SSH/Telnet Honeypot that emulates a customizable Debian environment when accessed. It is actively maintained and provides sufficient command-line level logging making for good data to analyze. Other Honeypots considered include Dionaea and RDPHoney.

https://cowrie.readthedocs.io/en/latest/index.html (Links to an external site.)

Installation

The CHN install was pretty straight-forward but like most projects not without it’s fair share of speed bumps. First, I had trouble running the initial installation commands that had something to do with the Ubuntu version being 16. I had no trouble when I switched to 18 and I think it may have had something to do with the Python repositories in the earlier versions not getting the later versions of Python 3 (at least 3.6).

In the lab, we setup the Server and the Sensors on the same VM. This does not work (or at least I couldn’t figure out how to) with CHN since everything is through Docker containers. I couldn’t run both the server container when I’m running the sensor container. That’s why we have them separate and possibly why the labs chose to go with MHN in the first place.

I had to make sure the Digital Ocean virtual firewall allowed communication between the machines since they’re separate. That meant the server allowing traffic to ports 443, 80, and 10000 from the sensor machine.

Cowrie operates on port 2222 instead of the traditional 22 for SSH, which makes it potentially suspect to attackers. We can change the default port to 22, but since we manage the server ourselves via SSH legitimately on 22 I had to change our default SSH listening port to something else. In this case I used 2202. It can be anything you want as long as there’s no conflicts with other services. It was as simple as editing the sshd config

nano /etc/ssh/sshd_config

Set the line Port 22 to your desired port and restart SSH with the command service ssh restart.

I also added something to Cowrie called a ‘personality’. Basically, you can control certain aspects of the environment to make it seem more real to an attacker. Things such as available commands, file structures and user/password combos that work. The Cowrie documentation explains this in greater detail.

Results

11/13/21 UPDATE

It’s been up for about an hour or two and there’s 13 pages of attack data translating to about 130 unique attacks. In fact, I’m pretty sure someone attacked it before I even had a chance to actually test that it was working from my own IP.

They also all seem to be running the same series of commands once logged in.

Lastly, looking at username login usage we can see nproc being used at a much higher rate than other usernames. We could theorize that nproc, being a Linux command, it being supplied at the login prompt as part of an automated script.

11/17 UPDATE

It turns out disk space on the Honeypot server fills up fast with this Docker container. It completely exhausted my server’s limited resources and essentially crashed it so I don’t have logs for some of 11/16 and 11/17. I expanded the disk space on the machine and it’s running again. Anyway, to the fun stuff.

Pulling the log file into Splunk, I was able to highlight a few interesting metrics. From the smaller subset of logs that we previously analyzed we noticed that much of the activity appeared to be automated (bots) and most of them issues primarily the same commands in what appeared to be an attempt to change the root password, remove SSH keys and set their own presumably for passwordless login.

We can group the activity together by attack (src_ip) in Splunk to identify the lists of commands.

index=main signature=”command attempted on cowrie honeypot”
| stats values(command) as command count by src_ip

Seeing what the majority of attackers are doing is nice, but what’s more fun is looking at the more rare events, which could help us identify non-automated threats (human actors).

A few commands stand out in this list but I especially hope to look at some of the wget commands to determine what the attackers are trying to accomplish.

Busybox is software that provides a number of Linux/Unix tools within a single executable. We also see some encoded hex toward the end that translates to the string ‘connected’ if decoded in Cyberchef (Links to an external site.).

Moving away from these attacks and filtering on the “File downloaded on cowrie honeypot” signature we can take a look at some hashes to see what attackers are attempting to copy to the machine.

A quick examination of the file uploaded the most yields some results in Virustotal if we search the hash. The ELF files contained within the gzip have signatures that match Yara rules for a Monero coin miner. If we trust those rules, we can be fairly confident that’s what is going on here.

In fact, all of the files examined appear to fit the same description, despite varying hashes. They are all gzip compressed files containing ELF files and various scripts within.

Here is an article from 2018 that explains how some of these coin miner malware variants function.

https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/cryptocurrency-mining-malware-targets-linux-systems-uses-rootkit-for-stealth

I observed much more of the same over the course of a couple weeks and admittedly suspended my data collection shortly after. I may spin up another honeypot of a different type in the future and record those results as well. Cheers!

--

--