Cowrie

Option A: Azure Portal

Search the Marketplace for Cowrie SSH/Telnet Honeypot on Ubuntu 24.04, choose your VM size, and provide your SSH public key. Attach a network security group that allows:

• TCP 22 (your real admin SSH) from your management network only.
• TCP 2222 and 2223 (the emulated honeypot) from the networks you want to expose it to. To collect real internet attack traffic, allow these ports from the internet. To run an internal deception sensor, allow them only from the internal ranges you are monitoring.

Option B: Azure CLI

RG="cowrie-prod"; LOCATION="eastus"; VM_NAME="cowrie-01" IMAGE_URN="sac1647283583153:cowrie-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name cowrie-vnet --address-prefix 10.90.0.0/16 --subnet-name cowrie-subnet --subnet-prefix 10.90.1.0/24 az network nsg create -g "$RG" --name cowrie-nsg az network nsg rule create -g "$RG" --nsg-name cowrie-nsg --name allow-admin-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name cowrie-nsg --name allow-honeypot --priority 110 \
  --source-address-prefixes "Internet" --destination-port-ranges 2222 2223 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:cowrie-ubuntu-24-04:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name cowrie-vnet --subnet cowrie-subnet --nsg cowrie-nsg --public-ip-sku Standard

Connect on the real admin port 22 with your key. This is the administration plane, which is kept completely separate from the honeypot.

ssh azureuser@<vm-ip>

To find the public IP, run az vm show -d -g cowrie-prod -n cowrie-01 --query publicIps -o tsv.

Cowrie runs as a systemd service under the unprivileged cowrie user. Confirm that it is active and listening on the two emulated ports, while your real SSH stays on port 22.

sudo systemctl is-active cowrie ss -tln | grep -E ':2222 |:2223 |:22 ' /opt/cowrie/cowrie-env/bin/python -c 'import importlib.metadata as m; print("cowrie", m.version("cowrie"))'

The output shows cowrie reporting active, listening sockets on 0.0.0.0:2222 (honeypot SSH), 0.0.0.0:2223 (honeypot Telnet) and 0.0.0.0:22 (your real admin SSH), and the Cowrie version.

Read the root-only note that the first-boot service wrote. It describes the two planes and this VM's unique honeypot host key fingerprints. No two VMs share these fingerprints, and none was baked into the image.

sudo cat /root/cowrie-info.txt

The note is owned root:root with mode 0600. It records the honeypot endpoints, the per-VM SSH host key fingerprints and the location of the event log.

Cowrie accepts weak logins on purpose. Run a quick self-test against the local honeypot. It accepts a throwaway credential and drops you into a fully emulated shell that looks like a real server. The test runs against loopback on the VM itself, so it never leaves the box. Real attackers reach the same emulated shell over the public IP on port 2222.

sshpass -p 'hunter2' ssh -n -p 2222 \
  -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null \
  -o PreferredAuthentications=password -o PubkeyAuthentication=no \
  root@127.0.0.1 'whoami; hostname; uname -a; ls -la /; cat /etc/passwd | head -n 3'

The login succeeds and whoami returns root. The hostname and uname present a convincing fake server, and ls -la / shows an emulated filesystem. All of this runs inside a sandbox with no access to the real machine.

Cowrie writes every session to a structured JSON event log. Inspect the events from the session you just ran: the login attempt with the exact credentials, and every command the attacker typed.

sudo tail -n 12 /opt/cowrie/var/log/cowrie/cowrie.json \
  | jq -c '{eventid, username, password, input, src_ip} | with_entries(select(.value != null))'

The log shows a cowrie.login.success event with username and password, and a cowrie.command.input event that captures the exact command line the session ran. Full keystroke replays are stored under /opt/cowrie/var/lib/cowrie/tty/. Replay them with /opt/cowrie/cowrie-env/bin/playlog.

The JSON event log at /opt/cowrie/var/log/cowrie/cowrie.json is designed to be shipped to a log pipeline. Point Filebeat, Fluent Bit, Vector or rsyslog at that file to forward events to Elasticsearch, Splunk, a Graylog input or any SIEM.

Cowrie also ships optional output plugins (Elasticsearch, syslog and others). Enable them in /opt/cowrie/etc/cowrie.cfg under the matching [output_*] section, then run sudo systemctl restart cowrie.

Sign in to the AWS Management Console, open the EC2 service and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Cowrie. Select the SecureAnyCloud listing, choose Select, then choose Continue on the subscription summary.

Pick an instance type of m5.large or larger. Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet, and either create or select a security group that opens port 22 from your management network. Leave the root volume at the default size or larger.

Select Launch instance. First-boot initialisation takes a short time after the instance state becomes Running and the status checks pass. The image resolves the instance address, writes the per-instance welcome notes, generates a unique decoy host key and starts the honeypot.

Run the following command to launch an instance from the SecureAnyCloud Cowrie Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens port 22 from your management network.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --metadata-options "HttpTokens=required" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=cowrie}]'

When the instance state is Running and both status checks pass, note its public or private IP address for the SSH step.

Connect to the instance on the real administrative port 22 with your key pair. This is your normal, untouched admin access, not the honeypot.

Connecting to your instance

On Ubuntu 24.04, the SSH login user is ubuntu.

ssh -i /path/to/<key-name>.pem ubuntu@<public-ip>

On first boot, the image writes a root-only notes file that records this instance's decoy ports and the paths where captured evidence is stored. It is an information file, not a credential file, because Cowrie ships no real login secret.

sudo cat /root/cowrie-info.txt

The file lists the decoy SSH and Telnet port numbers, the JSON and text event log paths, the session recording and downloaded payload directories, and the fake user database path:

# Cowrie 3.0.8 - generated on first boot. Unique to this instance. COWRIE_ADMIN_SSH_PORT=22 COWRIE_SSH_DECOY_PORT=2222 COWRIE_TELNET_DECOY_PORT=2223 COWRIE_JSON_LOG=/home/cowrie/cowrie/var/log/cowrie/cowrie.json COWRIE_TTY_DIR=/home/cowrie/cowrie/var/lib/cowrie/tty COWRIE_USERDB=/home/cowrie/cowrie/etc/userdb.txt

Check that the honeypot service is active:

systemctl is-active cowrie.service

The command returns active. For the full unit detail, including the Python process that runs the honeypot, run:

systemctl status cowrie.service --no-pager

The decoy SSH and your real administrative SSH are two entirely separate listeners. Confirm that all three ports are bound: the real sshd on 22, the decoy SSH on 2222 and the decoy Telnet on 2223.

ss -ltn | grep -E ':(22|2222|2223)\b'

The decoy SSH deliberately presents a fake server identity, so it looks like a different, older machine to an attacker. The admin sshd on port 22 is your genuine access. Compare the two banners side by side:

echo "decoy SSH 2222:"; timeout 8 bash -c 'exec 3<>/dev/tcp/127.0.0.1/2222; head -1 <&3' | tr -d '\r'
echo "admin sshd 22:"; timeout 8 bash -c 'exec 3<>/dev/tcp/127.0.0.1/22; head -1 <&3' | tr -d '\r'

The shipped security group opens port 22 only, so out of the box nothing can reach the decoy. To start attracting and logging activity, open the decoy ports in the instance security group to the networks you want to observe. Expose a honeypot only deliberately, and only to networks you understand. Replace <security-group-id> with your instance's security group and <your-mgmt-cidr> with the range you want to watch.

aws ec2 authorize-security-group-ingress \
  --group-id <security-group-id> \
  --ip-permissions \
  IpProtocol=tcp,FromPort=2222,ToPort=2223,IpRanges='[{CidrIp=<your-mgmt-cidr>}]'

Cowrie writes every connection, login attempt, command and download to the JSON event log as it happens. Tail the log and watch the events arrive:

sudo tail -n 20 /home/cowrie/cowrie/var/log/cowrie/cowrie.json

A successful brute-force login and the commands that follow appear as structured events, ready for a SIEM or analytics pipeline. The cowrie.login.success event records the username and password the attacker tried. Each cowrie.command.input event records exactly what they ran inside the emulated shell.

Cowrie records each interactive session as a replayable TTY log under the session recordings directory. List the recordings, then replay one with the bundled playlog tool. Replace <session-id> with a filename from the listing.

sudo -u cowrie /home/cowrie/cowrie/bin/playlog /home/cowrie/cowrie/var/lib/cowrie/tty/<session-id>

The fake user database at /home/cowrie/cowrie/etc/userdb.txt controls which username and password combinations the honeypot accepts. Each line is a rule. The shipped default accepts common brute-force guesses, so the honeypot is inviting out of the box. To make the honeypot pickier or more permissive, edit this file and restart the service. This changes the running honeypot, so make the change only when you are ready.

sudo -u cowrie nano /home/cowrie/cowrie/etc/userdb.txt
# edit your accept/deny rules
sudo systemctl restart cowrie.service
# apply the changes

Some operators want the decoy to answer on the standard SSH port 22 so it catches untargeted scans. Port 22 is your real administrative access, so first move your admin sshd to another port and confirm that you can still log in there. Then redirect inbound port 22 traffic to the decoy on 2222. This changes how you reach the instance, so plan it carefully. Replace <admin-port> with the new administrative port you moved sshd to.

# Only AFTER you have moved your admin sshd to <admin-port> and confirmed access there:
sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222

The entire honeypot home at /home/cowrie lives on a dedicated, independently resizable EBS data volume rather than the operating system root. It holds the JSON and text logs, the TTY session recordings and any downloaded payload samples. Confirm that it is its own filesystem:

findmnt /home/cowrie

Because the evidence store is on its own disk, you can grow it as your sensor collects more data without touching the boot volume. Snapshots of just the evidence are also simple to take.