return
Every day, companies receive hundreds or thousands of automated attacks in search of potential new victims. Thousands of bots, scrappers, crawlers and scripts are dedicated to scanning ranges of IP addresses and/or domains looking for exposed services that are insecure, old or misconfigured, for multiple purposes, such as enlarging their botnet, mining cryptocurrencies, exfiltrating information, and much more. This poses a difficult scenario for defenders, where they always have to know 100% of their exposed services, versions, infrastructure, and everything done correctly without any security flaws. An interesting strategy is to use one of the main techniques of Active Cyber Defense, which are the Honeypots to try to find out what they are looking for, what they exploit, and what is the pattern that attackers follow.
A honeypot is a trap or decoy system that aims to lure attackers in order to protect an organization's real computer systems. Some of its functions are to collect information about attackers and their attacks, alert them of possible attacks, slow them down or distract them. They are designed to pretend to be a legitimate system, but with misconfigured services, with known vulnerabilities, pretending to be any attacker's paradise!
In this post we will create one to collect information about the attackers and their techniques. As with everything in the world of cybersecurity, the creation and use of one of these devices, carries a great risk that we must contemplate. As this honeypot is only for research, we do not want it near our organization's network, so we use a cloud provider (Google Cloud, AWS, Azure, Digital Ocean).
For the creation and deployment of our honeypot, we will rely on the "T-Pot" project with more than 8 years of updates and maintenance, which has a suite of more than 20 honeypots, such as Cowrie (Honeypot simulates an SSH and TELNET service), and Dionaea (Simulates an FTP service, MySQL, SMB, among others) and even counts with the Elastic Stack for the visualization of attacks, logs, requests, etc. Since T-Pot uses Docker to create all the services, our virtual server must have enough RAM for the default version, if we disable some honeypots it is possible that the memory consumption decreases. In this case we use a droplet with Debian 11, 8GB of RAM and 80GB of disk.
Once we have created our droplet, the deployment of T-Pot is quite simple and automated, within its repository they have a tutorial which explains in detail all its configurations, but if we want to leave everything by default, it would be as simple as running the following:
This will guide us through the installation period. Once we have configured and installed everything, our server will restart, and something important to keep in mind are the ports where the T-Pot management services listen:
Mostly we use port 64297, for the control panel created in Kibana. If everything was created and is running correctly, when entering the Kibana port, it will ask us for some credentials, which we configured at the time of installation.
These would be the T-Pot utilities. If we go to Kibana, we can see what information each Honeypot collected, and in turn we have a more general panel that shows us the total interactions with each service.
We can see that the "Cowrie" honeypot has already received more than 130 connections,
mostly directed to port 23/TCP (Telnet) and we can see that a large part of these requests
come from the United States, this does not mean that all the source IPs are attacker IPs or
C2, it is also possible that they are devices that were previously breached and they use them
to find new potential victims. If we go down a little further in this panel, we can see some of
the combinations used to log into the SSH and/or telnet service. Some of them are
passwords that are configured by default in real systems or services.
An interesting detail is that the above images were taken within 20 minutes after the honeypot platform was fully installed. In that time we are already receiving attacks, seeing how they act, and what services they are mainly looking for. This information is relevant for further analysis and above all to know what we are up against as defenders.
An hour after the full deployment of the honeypots platform, we continue to see the numbers increasing steadily, so we formulate some hypotheses based on the attacks that we corroborate over time:
Looking again at our control panel, we see what is being attempted against one of our web applications, a blog built with Wordpress.
Here we see attempts to exploit vulnerabilities of the Cross Site Scripting (XSS) type, in turn "index" requests, which if we look at the logs, are actually requests with different routes, looking for known routes or executing known exploits
Digging a little deeper, the first request in the screenshot above seeks to exploit a vulnerability in the Fortinet FortiOS service for older versions (5.6.3 - 5.6.7 / 6.0.0 - 6.0.4) that makes it possible to read credentials in plain text. This vulnerability is already known, has its CVE (CVE-2018-13379))and a public exploit.
The use of honeypots is one of the most effective tactics within active defense, analyzing the attacker's behavior, deceiving him, influencing his actions, are things that we can do with this approach to defensive cybersecurity. As we have already mentioned in previous posts, we play the cat and mouse game, where the latter almost always manages to escape, but with this approach we seek to level things out and stop being at such a technical disadvantage for the defenders. In future posts we will be talking more about this topic, analyzing attacks, testing our hypotheses and proposing new ones. For now, let the attackers fall into our traps.
