Setting up a Honeypot Framework (T-Pot) on Azure

What is a Honeypot

A honeypot is a computer or VM that you expose to the internet with the intention of catching malicious login/scan attempts, and it logs them. Over time, you can use the logs to identify trends, for example the most common usernames for bruteforcing, common directories that are crawled, or even spot trends in the latest CVEs being exploited.

There are different categories of honeypot. Some are setup to act as a database, and catch specific attacks against databases. There are other honeypots that can mimic webservers, websites or even for malware. There is a really good resource here which is worth a read.

T-Pot

Enter T-Pot, by Telekom Security, and can be found here. T-Pot is a honeypot framework that contains honeypots for many categories, which are saved into their own Docker containers. This allows us to run many honeypots on one VM, and to use the inbuilt visualisation and search tools to analyse the logs to spot trends. The installation is very straightforward and I have outlined the steps to installing it on Microsoft Azure.

Install Guide

The requirements are a 128GB SSD and 8GB RAM, an the post install steps require Debian 10 Buster.

Create a new VM, going with a suitable SKU – I have gone for the D2s_v3 with 8GB RAM, and allowed connectivity to SSH over Port 22. We will later configure a rule to open all ports to the internet 😀 😀 (So you want to keep this in it’s own Resource Group for sure.)

Now select 128GB Standard SSD on the next selection.

Once this is set up, just hit Review & Create and go for the creation of the VM.

When it is created, use the bell icon to “Go to resource”

From here, you will see your publically facing IP address.

SSH to the server and follow the post install setup commands. You’ll need git first.

sudo apt-get update
sudo apt-get install git
git clone https://github.com/telekom-security/tpotce
cd tpotce/iso/installer/
sudo ./install.sh --type=user

Once you get this kicking off here, things start to look interesting. Hit y to proceed with the default.

You will be presented with the T-Pot-Installer setup, which should look like the linux OS installers of old.

You’ll be prompted to enter in an admin username and password to use. Once you do this, the installer will kick off. Go and grab a cup of tea at this point. It’ll take 15mins.

When the installation has completed, you will lose connection to the VM as it reboots.

Post Install

The installation moves the default SSH port to port 64295, so you will need to connect to that port to access the VM as port 22 will be assigned to the SSH honeypot. (Ah yes!)

If you remember from our VM setup, we only have Port 22 exposed to the internet. That’s no good for our Honeypot. We need to expose all the ports.

Navigate to your Resource Group and open your NSG and add a new Inbound Security rule to expose all ports to the internet like so. Set the priority to 200, so it takes precedence over your other rules. As with all recommended security posturing, we ignore the horrible flashy warning signs. It’s all fine.

A quick nmap scan of the honeypot reveals a large amount of open ports. It’s pretty obvious that this is a honeypot to any serious observer, but for science we continue!

We can connect to the honeypots web interface on https://<your ip>:64297

From here you get access to the main dashboard for T-Pot

From the Cockpit, you can view metrics on the VM

You can see the running containers as well

There is also a Terminal as well, just in case you can’t access SSH for whatever reason

First Thoughts

In the Kibana application, you can view dashboards. There is a main T-Pot dashboard and already I can see that there are metrics being logged. My Dionaea honeypot is getting a lot of activity. Most traffic is targetting 445, so thats SMB. Attackers are probably probing for low hanging SMB vulns, like Eternal Blue. Most attacks are originating from Indonesia at the minute.

The amount of data and metrics is pretty overwhelming.

Drilling into my Dionea dashboard shows more information on the attacks, including source IPs, source ASNs.

The main dashboard shows a tagcloud for usernames and passwords, and the CVEs being tried etc. I think these will build up over time.

Conclusion

This is really a “set it and run it” piece of work. I am looking forward to seeing what data is being collected. My initial thoughts are that this is very fun 😀

I just hope my Azure bill doesn’t rack up, so I’ll set alert conditions on this. I wonder if I’ll get contacted by MS.