Honeypots — Easy and Insightful
Creating cybersecurity tools in order to protect systems from malicious activity often starts by identifying the issue — this can consist of, for example, the investigation and analyzation of common viruses and malware. As the modern world is becoming more and more digitalized, prioritizing the level of security has consequently grown. Furthermore, in order to enhance the security methods and systems, knowledge about threats is needed, and tools such as honeypots can be a great option to achieve this because of their versatility.
We had a small team consisting of Teemu Herttua, Jani Kettunen, Jonte Jomppanen and Sonja Rytinki, and as our project for Computer Security Project course, we investigated one of the protective and research-based tools — honeypots. This project included a series of smaller experiments, and the research interest was on how honeypots work as tools in investigation of network traffic. The aim of this project was to look into the ongoing network traffic and the possible malicious activities it included. During the project, we tried the following five honeypots:
- Cowrie (Amsterdam server)
- Cowrie (London server)
- Dionaea
- PostgreSQL
- MySQL
We also made tutorials on how to set up SQL database honeypots and Cowrie SSH honeypot, that were used in our experiments. These tutorials were written by Jonte and Jani.
The variety makes honeypots such a good and versatile tool — they can be used to investigate almost anything varying from viruses and trojans to spam emails. Results of our honeypots show that not only the attackers are completely spread out around the globe, but the number of different malicious programs is also alarmingly high. The amount of login attempts, installation of programs and spam emails felt like it was off the charts — some of the honeypots received so much activity that it was impossible to analyze everything. While this is worrying, it also gave us a confirmation on the usefulness of honeypots; the fact that we were able to collect so much data, and most of it was something that could be tracked or analysed, showed that malicious network activity can definitely be investigated with honeypots.
Information gathering and keeping up to date
One of the main benefits of using honeypots is finding up to date information on what would happen, if I currently had an exposed server or device. Reading the honeypot logs we found a plethora of the most common username password combinations. The bar charts show the top username password combinations attempted on our two Cowrie honeypots over 7 days:
Just as expected, the top 5 consisted of default and basic combinations with ”root:password”, “root:admin” and ”root:root” being the most common. After the top 5, the most common combinations included mostly names of services or devices as the username password combination. Aside from the combinations shown, there were numerous attempts with seemingly random combinations tried less than five times. However, together there were more than 300 000 login attempts, which means that strong credentials are recommended because if you’re unlucky, your weak password might be quite quickly guessed upon exposing your service!
Malware analysis
Honeypots are a great tool for finding malware as well. The two cowrie honeypots, and the database honeypots deployed by us caught several pieces of malware during this project. Better yet, we didn’t only catch different kinds of malware but we caught malware that is currently being spread around on the net.
Reading the system logs you can observe how an attacker tries to perform malicious deeds. In our cowrie honeypots, the most common way was a series of commands that first attempted to download an executable, then change the permissions of the downloaded file and execute it. In our honeypots, the downloaded files consisted mostly of BASH and Perl scripts used for DDoSing. There were also a handful of attemps to install crypto miners. A large amount of the downloaded files showed that the downloaded programs were connected to different variations of Mirai malware.
On our database honeypots, there were a couple of interesting pieces of malware that were successfully executed. All of the malware were targeted at PostgreSQL and they turned out to be cryptocurrency miners. Our guess is that MySQL is not interesting enough for the attackers, because with default settings it doesn’t support shell commands.
One of the malware used the following SQL query:
DROP TABLE IF EXISTS abroxu;CREATE TABLE abroxu(cmd_output text);COPY abroxu FROM PROGRAM ‘echo <SCRIPT>|base64 -d|bash’;SELECT * FROM abroxu;DROP TABLE IF EXISTS abroxu;Because in question is the root user of the database, shell commands are authorized and thus a pipe to bash is enough. The script downloads a program with cURL, resolves tor2socks service’s address and then opens socks5 connection to the tor network via the service mentioned. We assume that the program is part of a botnet and connects to its master over Tor network.
All together, there were over 300 files being downloaded onto our honeypots. While some of them are similar to each other or a variation of a certain malware, the amount of different malware is still formidable, and analysing them gives further insight in what is going on just right now.
Botnets
As mentioned earlier, honeypots are often considered as tools when looking at individual attacks or worms, but they are also used to attract botnets. A honeypot can be considered as a spy in the botnet — specialized honeypots are used for, for example, investigating the botnet attacker behaviours in order to improve defences. There are multiple honeypot-based systems related to detecting attacks and analysing them that have been introduced in the past two decades. For example, tracking botnets as a way to identify their behaviour has been pretty common for years. Additionally, honeypots are often a better way of detecting botnets in general when compared to classic antivirus and malware detection products, since botnets might not behave in a similar way to ordinary malware — that is, they might act maliciously only when they receive a command from their master server. Of course there are programs that specialize in botnet detection, but setting up a honeypot could turn out to be more cost-efficient.
In addition to this, the improved botnets that can automatically exploit vulnerabilities and act on them, have often been baited with honeypots. Exposing a system to a malicious network can instantly cause attraction from the botnet; this is usually caused by a dropper that installs a malicious program, which starts to communicate with the botnet. However, in the past couple of years botnets have been improved to the level where the advanced ones are honeypot-aware. This means that a botnet can, for example, send fake malicious traffic towards a system in order to detect if it is a honeypot, or a real, vulnerable machine. The construction of these types of botnets that are able to detect a honeypot, and thus ignore it, causes problems with the usage of honeypots as defence mechanisms. Honeypots also need to be upgraded to keep them current — and that requires proper research.
Differences in geographical location and service providers
As we had our Cowrie honeypots in geographically different locations, we used this opportunity to analyse if we can link any differences in attacker behaviour to the geolocation of the servers. While the malware, the commands executed and password username combinations were mostly the same, there was evidence indicating geolocation having an impact. Below are our findings visualized.
As we can see from the results, there were attacks from almost every country. On London server the most attacks came from China and USA unsurprisingly. Ireland and France also got their places in the list. Interestingly the Amsterdam server was targeted the most by attacks originating from Netherlands, USA and Ireland. On top of that, London server was the target of more than twice as many attacks than Amsterdam server. The variance in results got us more interested and this is something that should be looked more into. It must be kept in mind, that some of the attacks may come behind proxies.
As you might have noticed, there is no trace of Russia in these results. This is due to the fact that Russia has blocked all the Digital Ocean’s IP addresses. Sometimes the blocking may not be effective, and it was interesting to see, if we could find traces of network traffic originating from Russia. On that tangent, different service providers may be a bigger target than another service provider might be. Together, the geolocation and service provider both are interesting topics that could be looked more into!
Final thoughts
One of the reasons why we looked at honeypots for our project, and why we made this blog post, was to spread awareness. Not only about the possible dangers of open networks or malware, but also about the positive aspects of honeypots.
The most relevant take-away from all of this is on how honeypots can be used to improve the security of systems; catching malware and malicious attacks with the purpose of analysing them is a great way of gathering knowledge of the current state of attacks and the existing malware. In addition to this, the knowledge can be used to fix the possible vulnerabilities and issues with current systems.
Honeypots are often advertised as something that a common user cannot use, or as something that is too difficult and time-consuming to install — however, we think that our project shows that setting up different honeypots, that can detect a variety of activity, aren’t as intimidating as presented. Some services are sold with this type of thinking — and instead of commercialising these services, we believe that this information should be available for a larger crowd. After all, in the long run, spreading knowledge and know-how is a good way of improving security on an individual level, as well as on a larger scale.
