HoneyTraps in the Cloud 101

Honeypots are useful tools for collecting unauthorized interactions as logs. These logs can be digested to identify new attacking techniques or observe active username/password patterns. In the context of a security team, it could provide actionable information to pre-emptively secure the studied environment.

This tutorial will discuss general SSH honeypot pre-configuration, HoneyTrap installation, logging, and analysis. A docker continer is used to launch a low interaction SSH honeypot HoneyTrap. Check out the HoneyTrap documentation for more information about HoneyTrap and what HoneyTrap can do.

Want to learn more about honeypots first? Read my sister article: “Honeypots Explained: In the Wild and in SecOps”.

Pre-Configuration#

The honeypot workstation for this tutorial is GCP e2-micro instance running Ubuntu 16.04 LTS.

SSH Service#

To log unauthorized interactions with the SSH service the default port 22 will be used by the fake honeypot service. The real SSH service will need to be moved to another port. For this tutorial port 1025 is used.

First change the SSH service port number by editing sshd_config.

sudo vim /etc/ssh/sshd_config

Where the file reads…

# What ports, IPs, and protocols we listen for

… change Port 22 to Port 1025 and uncomment ListenAddress 0.0.0.0 and ListenAddress :: as shown below.

Restart the ssh service with systemctl and verify SSH daemon is listening on port 1025 with aa -an | grep PORT_NUM.


$ sudo systemctl restart ssh $ ss -an | grep 1025 tcp LISTEN 0 128 *:1025 *:* tcp LISTEN 0 128 :::1025 :::*

Firewall Changes#

Use ufw to open up the new port for the SSH service.

$ sudo ufw allow 1025/tcp Rules updated Rules updated (v6)

Now go to the GCP console and navigate to the firewall for the managed instance. In the firewall rule table, click on the name “default-allow-ssh” > Edit. Navigate to “Protocols and Ports” and change the specified port from 22 to the desired port number, we'll use port 1025 for this example.

Now add another rule for wild traffic on port 22. You should now be able to login from the custom port 1025 and honeypot traffic should be able to communicate out port 22.

Return to the honeypot instance. If you are SSH-ing in from the console, use the drop-down selector and choose “Open in browser window on custom port” to login using port 1025.

Install Docker#

Almost done with pre-configuration. Finally, install docker.

Honeypot Installation#

At this point you should be able to install and run any functioning docker honeypot on port 22. We are using HoneyTrap for this tutorial because of ease of installation: you can pull the container and run it on port 22 with this command:

sudo docker run -ditp 22:8022 honeytrap/honeytrap:latest

Be sure to run the container in detached mode -d so that after you log out of the terminal session the container continues to run.

Observing traffic#

Verify this honeypot is running by attempting to login from a remote client. As HoneyTrap runs on the GCP host, custom verbose debug logs are generated and printed to stdout. When an interaction is detected a log is created to record the behavior, otherwise periodically a heartbeat is logged to confirm to the operator the honeypot is alive and listening.

Password Guessing#

We can see an example of password gueesing in the log snippet below. IP 113.128.246.50 attempts to login to HoneyTrap over port 22 using the password adminbigdata:

After successfully guessing or cracking the HoneyTrap login credentials (username="root" password “password") the attacker will see the following fake Ubuntu prompt.

Logging Behaviors#

In another example, the value ssh.exec[] stores the movements of an attacker from source ip 71.214.59.235 sending exec commands over ssh (without logging in). They send 9 commands before realizing they are in a honeypot, at which point they say hello before disconnecting. Below you can see a screenshot of the logs storing ssh.exec[] values and then the entered commands in plaintext.

/ip cloud print
ifconfig
uname -a
cat /proc/cpuinfo
ps | grep '[Mm]iner'
ls -la /dev/ttyGSM* /dev/ttyUSB-mod* /var/spool/sms/* /var/log/smsd.log /etc/smsd.conf* /usr/bin/qmuxd /var/qmux_connect_socket /etc/config/simman /dev/modem* /var/config/sms/*
echo Hi | cat -n

Analysis

To collect information from docker, output the logs to a text file and move the text file to another workstation for log ingestion and analysis.

sudo docker logs CONTAINER_NAME > OUTPUTFILE.txt

Here are some commands you can use to manually parse the log for actionable information. To understand the parsing context, a log sample is provided:

SAMPLE LOG: 
services > ssh > category=ssh, date=2021-01-24 19:55:03.026780504 +0000 UTC m=+2451.851735112, destination-ip=172.17.0.2, destination-port=8022, sensor=services, source-ip=125.75.150.251, source-port=37014, ssh.password=P@$$woRD!, ssh.sessionid=c06t1500f8ng00eauvog, ssh.username=root, token=c06se0o0f8ng00eauvm0, type=password-authentication

Script

I made a script to parse the logs for some basic information including source-IP addresses, commands, and usernames/passwords attempted. Check out the gist here.

Final Thoughts#

Hosting honeypots on cloud architecture enables security researchers to quickly experiement without endangering local networks. It is not without its own considerations, the researcher should monitor and secure the research workstation and have a plan in the event of compromise. Open-source honeypots are commonly criticized for being easy to detect, evade, and come with security vulnerabilities of their own. In additon to making a plan for the honeypot lifecycle, make a plan for log collection and ingestion to automate log analysis and data visualization.

Originally published at https://www.malwaremily.com on January 25, 2021.

I write about DFIR, GRC, and defensive security topics.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store