Cowrie is a medium-to-high interaction SSH honeypot project maintained by Michel Oosterhof (@micheloosterhof on GitHub) designed to emulate a vulnerable Debian-based system. Cowrie is able to track attacker interactions, log commands used, save downloaded payloads, and bring third-party integrations such as VirusTotal, Greynoise, and AbuseIPDB.

In this blog I will go through my second experience with Cowrie, what I’ve learned, brief findings and analysis, and what I feel can benefit the honeypot/blue team community.

This is my first writeup/post like this so I hope it is insightful and can help others. I would really appreciate some feedback. I hope to write a few more posts about this topic, including modifications to Cowrie and malware analysis.


There are plenty of excellent guides that already cover the installation basics and some advanced tips (HackertargetRoger GalobardesCryptax), including the official documentation, so I won’t focus too much on this aspect of Cowrie. The customisations/changes I’ve made are addressed later in this blog.

I used Azure to host an Ubuntu 20.04 VM, and I followed the additional documentation steps to ingest the Cowrie logs into Azure Sentinel.

To visualise the Cowrie events in Sentinel, there is a provided event parser and Sentinel Workbook under ‘cowrie/docs/sentinel’, originally authored by @phage_nz. (Go and check out their work!). The default parser does not handle any events triggered by third-party integrations. So, I’ve updated these files and added them to my Github to include extra default tables and queries (that also include VirusTotal events).


The ‘Install Cowrie in 7 Steps’ guide gets you to install Cowrie under ‘/home/cowrie/cowrie’ but the guide to set up Azure Sentinel ingestion assumes you have installed Cowrie under ‘/opt/cowrie/’. When following the Azure Sentinel set up guide, keep this in mind.

Your Azure Sentinel Workbook should appear like this:

A screenshot of the Azure Sentinel Workbook to view Cowrie event data

Results at a glance

I’ve been running Cowrie since September 26th, 2022 which has been ample time to record some initial trends and observations.

Malicious/Suspicious IP Reports

1,038 IP addresses reported via AbuseIPDB’s API

First-seen Malware Detections

Malware samples submitted to VirusTotal that had not been seen before.

Process killer bash script — 69d7eaf7c6577a84acaed30e4d0cad77c8e75ced4ff16b2a18811e19c8476650

Mirai — 369e5c20deb65ead3d1e13b8461884908989d1d5f0a106843a1890ce5dc70f8d

IRC Botnet — 6219350256e5404374c4e99e71ecc1db0a0e3893a09b6aec4c15763023eeffc3

Bash file retrieving further payloads — fc742220219dc7449cde1e8458ddcbe442c2829a2399533803bc464f0182b431

Other Malware Detections

Malware was downloaded from the following sources, with a combination of curl and wget:


Command Execution

The most common commands used are all related to service/host discovery and identification. Unfortunately, majority of attacker interactions begin with a login, execution of ‘uname-a’ and then a logoff. The attacker wastes no time when scanning the internet.

A screenshot of a KQL query and results for commonly executed commands
KQL query for the most common command inputs

It was also a common occurrence to see attackers write SSH keys to ‘~/.ssh/authorized_keys’ after successfully brute forcing their account of choice, or adding users to ‘/etc/passwd’.

The attackers tried to access a range of files on the system, some of which are not included by default in Cowrie’s emulated file system. Below is a list of files that if added could unlock further attacker activity.

ls: cannot access /dev/ttyGSM*: No such file or directory
ls: cannot access /dev/ttyUSB-mod*: No such file or directory
ls: cannot access /var/spool/sms/*: No such file or directory
ls: cannot access /var/log/smsd.log: No such file or directory
ls: cannot access /etc/smsd.conf*: No such file or directory
ls: cannot access /usr/bin/qmuxd: No such file or directory
ls: cannot access /var/qmux_connect_socket: No such file or directory
ls: cannot access /etc/config/simman: No such file or directory
ls: cannot access /dev/modem*: No such file or directory
ls: cannot access /var/config/sms/*: No such file or directory

Brief analysis

I took the time to analyse one of the IPs hosting several malicious files — hxxp://125.27.179[.]36, and I found a publicly facing Centaur Nanometrics control panel.

Some digging into this application shows that Centaur is some sort of seismic activity monitoring solution that “ is also well-suited for infrasound and similar geophysical sensor recording applications”. But why is this server hosting malicious files? Is it being used to disguise malicious activity? Or, this device a victim of other malicious activity and is being used as a staging location?

hxxp://125.27.179[.]36 has been taken down since I accessed it via a sandbox, but Shodan has a few results for other IPs that have the same software installed.

These other servers are all publicly accessible, but I couldn’t find any malware hosted on them like hxxp://125.27.179[.]36.


Cowrie’s hostname, default users, and kernel version are all values that can be used by an attacker to detect the presence of a honeypot.

In ‘cowrie/etc/cowrie.cfg’ I set the hostname value to ‘ubuntu-c3491b’ and changed the kernel version and build strings as shown below.

 hostname = ubuntu-c3491b
kernel_version = 5.15.0-1020-azure
kernel_version = 3.2.0-4-amd64
kernel_build_string = 25~20.04.1-Ubuntu SMP Thu Sep 1 19:20:56 UTC 2022

In ‘cowrie/honeyfs/etc/passwd’ I removed the default ‘Phil’ user and replaced it with something random, enter ‘steve-adm’. Check the official documentation here for the complete set of steps for changing the default user.


Updated the OpenSSH version that is printed by “ssh -V” in Cowrie’s shell emulation:

ssh_version = OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f  31 Mar 2020

After seeing majority of logins succeed after only a few attempts, I tuned ‘cowrie/etc/userdb.txt’ based on the logs collected at around the 6 week stage.

Overall top 15 username/password combinations for successful logins 26/09/22 to 12/11/22

RegEx support was added which makes wildcarding passwords for certain words or phrases really straight forward.

# Disable common combos

# Disable permutations of 'test'

# Disable common passwords for 'oracle'

# Disable all passwords containing popular words

# Disable passwords with length less than 3 characters (also disabled empty logins)



This change took the ratio of failed logins to successful logins from 2:7 to around 1:1, and I began to see more complex passwords being used.

Top 15 username/password combinations for succesful logins 10/11/2022 to 12/11/22



First create an API key with a free account, and paste that into ‘cowrie/etc/cowrie.cfg’ under [output_virustotal]. Enable the integration settings as desired. And remember to enable the plugin!

 # VirusTotal output module
# You must signup for an api key.
enabled = true
api_key = # Your API key here
upload = True
debug = False
scan_file = True
scan_url = True

When your honeypot is up and running, your API activity chart should appear something like this.

A chart showing the usage of the VirusTotal API
VirusTotal API quota usage for a 30-day period

Whenever a payload is uploaded to your honeypot, Cowrie will use the VirusTotal API to submit the payload for analysis. If the payload hasn’t been seen before, Cowrie will create a new VirusTotal report and add a helpful comment to show the new detection.

This is probably my favourite integration used so far, reporting investigating potentially unseen malware is a great way to support the blue team community as these details are available for everyone.


AbuseIPDB is a free to use IP identification and activity reporting project that can enrich the data collected by Cowrie. Register an account here, to get access to your API key here.

A screenshot of the AbuseIPDB website page to generate an API key
Generate an AbuseIPDB API key

Enter the API key under the [output_abuseipdb] section of ‘cowrie/etc/cowrie.cfg’ and remember to enable the plugin!

Other fields that you may want to change are: ‘tolerance_attempts’ – the number of login attempts that would trigger a report. ‘rereport_after’ – the number of hours that the plugin will wait for before reporting the same IP address. ‘tolerance_window’ sets the duration (in minutes) that logins from the same IP will be tracked before no longer being counted.

 # Reports login attempts to AbuseIPDB. A short guide is in the original
# pull request on GitHub:
enabled = true
api_key = #Your API key here
rereport_after = 24
#tolerance_window is in minutes
tolerance_window = 120
tolerance_attempts = 10
# WARNING: A binary file is read from this directory on start-up. Do not
# change unless you understand the security implications!
dump_path = ${honeypot:state_path}/abuseipdb

Final thoughts

Cowrie is an excellent honeypot project to experiment with. I really recommend spinning up a VM and chucking this on it, or even us the docker image. I hope to move to other honeypot platforms, as well as develop other integrations (Malware Bazaar,, etc) and improve existing integrations.