Introduction
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.
Installation
There are plenty of excellent guides that already cover the installation basics and some advanced tips (Hackertarget, Roger Galobardes, Cryptax), 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).
KEY NOTE!
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:
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:
hxxp://107.189.13[.]7/1
hxxp://107.189.13[.]7/2
hxxp://107.189.13[.]7/3
hxxp://107.189.13[.]7/4
hxxp://107.189.13[.]7/5
hxxp://107.189.13[.]7/xmr.sh
hxxp://109.206.241[.]34/x86.sh
hxxp://125.27.179[.]36/scripts/2.txt
hxxp://125.27.179[.]36/scripts/23
hxxp://125.27.179[.]36/scripts/23.s
hxxp://125.27.179[.]36/scripts/23.sh
hxxp://125.27.179[.]36/scripts/json.js
hxxp://179.43.163[.]105/root
hxxp://179.43.175[.]5/774.sh
hxxp://179.43.175[.]5/wget.sh
hxxp://185.161.208[.]234/oracle|perl
hxxp://79.133.109[.]151/ssh.sh
hxxp://amkbins[.]duckdns[.]org(/)bins(/)ascaris.x86
hxxp://amkbins[.]duckdns[.]org/root.sh
hxxp://apiscontrolm1ln3t[.]duckdns[.]org/sshd
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.
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.
Customisations
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.
steve-adm:x:1000:1000:SteveAdmin:/home/steve-adm:/bin/bash
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.
RegEx support was added which makes wildcarding passwords for certain words or phrases really straight forward.
# Disable common combos
*:x:!123456
*:x:!password
*:x:!nproc
*:x:!1234
*:x:!admin
*:x:!centos
*:x:!ubnt
*:x:!cameras
*:x:!user
*:x:!minecraft
*:x:!toor
*:x:!ftpuser
*:x:!postgres
*:x:!default
*:x:!support
*:x:!git
*:x:!devops
*:x:!ansible
*:x:!abc123
*:x:!www
# Disable permutations of 'test'
/test[0-9a-z-A-Z]*/i:x:!*
# Disable common passwords for 'oracle'
oracle:x:!/Oracle[0-9a-zA-Z]*/i
# Disable all passwords containing popular words
*:x:!/[a-zA-Z0-9]*honey[a-zA-Z0-9]*/i
*:x:!/[a-zA-Z0-9]*test[a-zA-Z0-9]*/i
*:x:!/[a-zA-Z0-9]*root[a-zA-Z0-9]*/i
*:x:!/[a-zA-Z0-9]*ubuntu[a-zA-Z0-9]*/i
*:x:!/[a-zA-Z0-9]*admin[a-zA-Z0-9]*/i
*:x:!/[a-zA-Z0-9]*password[a-zA-Z0-9]*/i
*:x:!/^[0-9]{1,8}/
# Disable passwords with length less than 3 characters (also disabled empty logins)
*:x:!/^[a-zA-Z0-9]{0,2}$/i
knockknockwhosthere:x:!knockknockwhosthere
*:x:*
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.
Integrations
VirusTotal
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.
#
[output_virustotal]
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.
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
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.
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: https://github.com/cowrie/cowrie/pull/1346
[output_abuseipdb]
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, Abuse.ch, etc) and improve existing integrations.