HoneyTraps in the Cloud 101

Updated 2021-03-01: Give the reader a heads up that restarting SSH will kick them from their current session.

Overview

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.

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.

Please wait to restart the SSH service else you may lock yourself out.

Firewall Changes

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

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

Restart the ssh service with sudo systemctl restart sshd. If you connected to this VM over SSH you’ll be kicked at this point.

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.

You can confirm the docker container is running with the command docker container ls:

$ sudo docker container ls
CONTAINER ID   IMAGE                        COMMAND                  CREATED          STATUS          PORTS                            NAMES
713be5f8fa05   honeytrap/honeytrap:latest   "/honeytrap/honeytra…"   33 seconds ago   Up 32 seconds   5900/tcp, 0.0.0.0:22->8022/tcp   happy_freebird

Logs can be viewed by running sudo docker logs CONTAINER_NAME:

$ sudo docker logs angry_chatterjee
2021/03/01 18:30:18 Using config file /config/config.toml

 _   _                       _____                🍯
| | | | ___  _ __   ___ _   |_   _| __ __ _ _ __
| |_| |/ _ \| '_ \ / _ \ | | || || '__/ _' | '_ \
|  _  | (_) | | | |  __/ |_| || || | | (_| | |_) |
|_| |_|\___/|_| |_|\___|\__, ||_||_|  \__,_| .__/
                        |___/              |_|

Honeytrap starting...
Version: DEVELOPMENT.GOGET (DEVELOPMENT.)

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.

Any attempted commands appear in the logs character by character. An exit command would appear in the logs as:

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

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.

Additionally, the default username of the cloud machine will be the username of the gmail address used by GCP. A researcher using firstnameLastname@gmail[dot]com may allow an attacker to identify the first and last name of the researcher. This can be mitigated by adding a new user to the honeypot and removing the old firstnameLastname user. Usernames associated with social media account present similar concerns. Note also at the time of compute instance creation, the hostname set in the networking section defaults to HOSTNAME.REGION.PROJECT_NAME.internal where PROJECT_NAME and hosting region are exposed.