What are HoneyPots?
A honeypot is a computer security mechanism set to detect, deflect, or, in some manner, counteract attempts at unauthorized use of information systems. Generally, a honeypot consists of data (for example, in a network site) that appears to be a legitimate part of the site and contains information or resources of value to attackers. It is actually isolated, monitored, and capable of blocking or analyzing the attackers. A physical world example of HoneyPots would be a car left outside for criminals to steal, while the police waits to catch the criminal red handed.
Why would you use HoneyPots?
A benefit of running HoneyPots that mimic services your organization uses, is understanding what the real and most likely threats are that your systems face. Preparing for imaginary scenarios is a hit or miss situation. With the use of deliberately vulnerable systems, you can catch the types of scans and attacks that your systems are likely to face. This will give you a good understanding of the threat landscape that surrounds your organization.
The threats that exist out in cyberspace are invisible to most people. They might read about them in the news, but would have no clue what the actual risks are or what these attacks might look like. For a lot of people, the numbers of automated scans, botnets and other non-human activity are hard to grasp. Using HoneyPots, we can visualize the attacks that hit our systems. This helps in creating awareness in decision makers, customers or the general public. Using this inside your own organization for example, can mean the difference between budget or no budget for that security measure you’ve been asking for.
A lot of HoneyPots are capable of providing some interactivity for the attacker. This gives you the option to for example catch actual malware samples. Or provide huge amounts of data into what passwords are mostly used in attacks. The options are vast and depending on your use-case, there will be options for capturing the data you want to research.
One benefit of HoneyPots is their capability to keep attackers engaged. Although a lot of scanning and attacks happening these days are fully automated. So the sinking of an attack or scan does not have a great effect. There are still plenty of times where a human being will interact with your HoneyPot, or where an automated system will keep trying because your HoneyPot just looks too good not to. Either way, in some capacity, the HoneyPot will waste an attackers time. Time and resources that were not used on attacking an actual victim.
Training analysts, SOC teams, blue and red teams, everyone benefits from seeing and playing with attack data in a controlled environment. Being able to see the data and learn what things to spot, is invaluable training. Having large datasets of attack data to query and learn from is a truly amazing training tool.
What types of HoneyPots are there?
Typically these are divided in the following categories:
– Low Interaction
– Medium Interaction
– High Interaction
As the names suggest, HoneyPots have different levels of interactivity. A low interaction HoneyPot typically only registers data, for example the IP address and port that was scanned. Medium Interaction HoneyPots go a little further, these might provide the attacker with the possibility to try credentials, send strings, queries and will generally get some response back. Interaction is however still limited to a few commands and is mostly used to for example catch credentials or attempts at exploiting a vulnerability. High interaction HoneyPots go much further, they allow the attacker to engage the system in depth. Examples of this can be a website, complete with login and admin panel backend. Or a containerized OS where the attacker can go on a quest to fully exploit the system. Not realizing this is a sandbox where all their actions are logged. A very simple example of this, would be the Virtual Machines used by Scam-baiters, letting the scammer play around in their VM, while recording an entertaining but cringe worthy YouTube video.
How to get started with a HoneyPot?
First thing to ask: What do you want to do? Depending on your use-case, you might have different options available. Where is the system located you want to test? In your LAN, is it an internet connected system? What services would you like to see? Once you’ve figured out what, where, why and how you want to capture data, you can go about finding or building the HoneyPot that best suits your use-case.
My HoneyPot Setup
Alright enough with the theory, let’s get our packets dirty. For the past month I’ve been running a HoneyPot service called T-Pot. This is a platform that combines several HoneyPots, available in a few configurations depending on what you’re trying to achieve. As described by the author on the Github page:
T-Pot is the all in one, optionally distributed, multiarch (amd64, arm64) honeypot platform, supporting 20+ honeypots and countless visualization options using the Elastic Stack, animated live attack maps and lots of security tools to further improve the deception experience.
Head over the Github page: https://github.com/telekom-security/tpotce
Make sure your system meets the following requirement:
|8-16GB||>=128GB SSD||RAM requirements depend on the edition,
storage on how much data you want to persist.
|Hive||>=8GB||>=256GB SSD||As a rule of thumb, the more sensors & data,
the more RAM and storage is needed.
|>=8GB||>=128GB SSD||Since honeypot logs are persisted (/data)
for 30 days, storage depends on attack volume.
Now it does say that 8GB RAM should be enough, in my experience it’s not. Often the HoneyPot’s Docker containers did not have enough resources and would not start. Getting 16GB of RAM for this is very much advisable.
For my project I am using Digital Ocean. Their services are excellent for projects like these. Unlike Amazon or Google, their pricing tiers are simple, transparent and they have billing alerts. Getting set-up is a breeze, not plugging for paid advertisement here, I genuinely have been using their platform for several years now for all sorts of projects.
Few side notes here. The Server “Droplet” in Digital Ocean terms, goes behind a firewall to prevent finger printing and will override a lot of settings you make. So I opted for a password instead of key pair. For production environments that are not disposable HoneyPots, always use a key pair instead. See here the firewall used against finger printing. This is used so that the attacker has a harder time figuring out they’ve ran into a HoneyPot.
Okay so now we have a Debian Droplet running with direct IP4 internet access, a firewall to prevent finger printing, and we’re bleeding dollars on this fairly hefty VPS (Udemy course creds for the free Droplet might have been used). Let’s get on with the installation.
SSH into your server and get the script ready to run. There are many ways of installing T-Pot, but for my setup I am using the User Installation method using a script.
Post Install User Method
The post install method must be executed by the
sudo su -,
su -), just follow the following steps:
git clone https://github.com/telekom-security/tpotce cd tpotce/iso/installer/ ./install.sh --type=user
What this did, was download the files from Github, change into the newly downloaded folder and executed the installation script with the “user” option. This will prompt you for input during the installation. Make sure git is installed, on Debian it was not. Install on Debian based distros:
apt install git
First selection is the Network setup, this is to confirm that you have not previously configured services that will conflict with the HoneyPots.
Username and password. Mind you this is not for the server management, this is for the web user to use the web interface.
The HoneyPot selection screen gives you the option to install different configurations. This allows you to for example only focus on Medical, Industrial or specific use cases. Join the HoneyPot to a Hive of several sensors, or install the Standard version. This will install all the tools and most common HoneyPots. It is also the version I’ve used for this article.
Running the HoneyPot
After letting the installation process finish, which usually takes between 15-30 minutes depending on your server resources and available download speed. You get several tools at your disposal. What makes this HoneyPot setup so amazing, is the all-in-one nature of the platform. Let’s go over the components one by one.
At the bottom we have the OS being Debian 11, running Docker. Both the HoneyPots and tools run inside Docker containers. We see Elestic-Search, Logstash, Kibana as the ELK stack. NGINX and EWS Poster to provide you a shiny web-interface. With the HoneyPots also running in their own containers. Data from all of this has a 30 day persistent data lifecycle. Beyond this, the services have their corresponding network ports mapped to the correct Docker containers. This also visualizes why the firewall I showed earlier makes sense for this setup.
T-Pot Landing Page
The landing page gives you access to all the tools needed, as you can see this also provides access to tools used for investigating the data received in your HoneyPots.
SSH and Cockpit
According to the User Types you can login from your browser and access Cockpit:
https://<your.ip>:64294 or via SSH to access the command line:
ssh -l [tsec,<os_username>] -p 64295 <your.ip>:
- user: [
- pass: [password]
Especially if you do not have a SSH client at hand and still want to access the machine with a command line option you can do so by accessing Cockpit. You can also add two factor authentication to Cockpit just by running
2fa.sh on the command line.
Kibana is the place to be, it’s where all your HoneyPot data gets displayed in a visual way. You can create, modify or delete dashboards. By default all the dashboards will be there, depending on your setup you may not need all of them, or will want to create your own. So if a few dashboards are empty, check the Github page for your installation type, these dashboards may not have the correct HoneyPots installed to generate data and can therefor be safely deleted to prevent confusion later on.
T-Pot provides a live attack map, this tool is great for getting an understanding where your current attacks are happening, or to show to clients the intensity of cyber warfare going on all around you.
CyberChef is a fantastic tool also available directly online, where you can use various encryption, encoding and other methods to work with data. https://gchq.github.io/CyberChef/
Using T-Pot you get an instance of CyberChef running on your own server.
Using and querying all the logs, using the raw data, changing log rotations or making other adjustments can be done on the Elasticvue dashboard. Especially if it’s the collected data you’re after, this is the place to visit.
Spiderfoot has both a managed version running on their infrastructure, as well as local installation options. With the T-Pot installation, you get a pre-configured Docker container running Spiderfoot. This is a great combination with the built in links on the dashboard to CVE-Details, Greynoise, Cisco Talos and Cyberchef. Giving you the tools needed to investigate suspicious traffic, without installing additional tools or revealing any more IP addresses than the system already targeted by the attacker anyway.
Alright there you have it, you’re all set to start collecting data and immersing yourself in all the threats hitting the average internet connected IP address. My key take-away from using HoneyPots, is just the insane volume of automated scanning and attacks happening all the time. This just shows the absolute importance of patch management, firewalls and using other security best practices.
I hope this got your curiosity going and you’re ready to give HoneyPots a try yourself. If you want to do a more budget friendly version, it is possible to install this inside a Virtual Machine. Just be aware that the IP address used needs to be exposed to the internet without any filtering. And that this IP address will get a lot of unwanted attention by appearing so vulnerable, exposing all these services. Also, keep in mind that certain counter activities you have in mind and are itching to use on whoever or whatever hit your HoneyPot, may be illegal. Hacktoria takes and the author take no responsibility in what you do with your own systems, or the information provided in this article.
Next time I will be back with a dive into the data collected in my own HoneyPots.