Honeypots, in the context of computer security, are a form of bait or a decoy; a kind of a “net” that catches vicious visitors into its threads. We are talking about a security system that captures uninvited guests and visitors, who often would not have a good reason to access services in such area, or have no authorization to do so.
A properly set and placed honeypot can capture both automated and human visitors, who are trying to scan the network and find vulnerable systems. Information about these snoopers can then be used as part of an investigation into a security incident.
Honeypots are distinguished mainly according to the “interaction level”, i.e. what are their capabilities in faithfully reproducing the target environment. Basically, we have three:
The great advantage of honeypots is that every event generated by a honeypot is valid and can be processed in some way, whether as a false alarm or as a real intrusion (IoC). There are plenty of information in an event, including the source IP address, date and time, but also client information, commands entered, and the collected URLs, or even malicious code that was downloaded. For services that require login credentials, you can collect these as well and then use them, for example, to determine whether someone's credentials have been compromised.
The risk of honeypots, like any similar service, is that they can be attacked by an exploit, so it is important to take care of their proper security. Ideally, a honeypot should not be able to access the internal network of the organization. The incoming traffic should also be appropriately limited to the simulated service ports. To reduce the risk of exploit, containerization and virtualization can also be used – that's why we distribute our honeypots as virtual machine images.
Today's honeypots are not always just a service that runs somewhere; there are various places in the network where traps can be laid, e.g. by introducing a file share with credentials left unattended, with only a simple password required to access. Then the proper reporting of unauthorized access is important. However, here we will try to limit ourselves to basic services such as Cowrie, nepenthes, or Dionaea. Specifically, we will discuss Cowrie and Dionaea services in more detail in the separate chapter below.
Most honeypots try to cover their protocol or a relatively narrow area of interest. It is possible to mention ADBHoney (for Android Debug Bridge), ElasticPot (fake ElasticSearch), or honeypots simulating the components of the industrial control systems (ICS/OT honeypots), such as Conpot. To simulate web applications, there is a known tandem SNARE and TANNER. To waste snooper's resources, an acceptable way may be to send crawlers that do not respect robots.txt to a hellpot. And if you want nothing more than to collect login credentials, then you may choose Heralding.
There are also honeypots created for specific vulnerabilities such as ciscoasa (CVE-2018-0101), Log4Pot (Log4Shell – CVE-2021-44228), and others. The main goal of these honeypots is to collect source IP addresses and malicious code.
Sometimes, if the system is complex enough, it makes sense to expose a real system in the public network in order to study the behaviour of the attacker after the intrusion. An example is this Exchange Server 2019 containing an unpatched vulnerability ProxyLogon. In this case, however, it is necessary to introduce protective elements, such as the blocking of outgoing traffic and DNS queries, so that the attackers can get in, but can no longer communicate with their servers, nor attack other objects of interest. If such a system is operated in a virtual machine (VM), there are projects, such as DRAKVUF, which can hook and analyse the behavior of the VM without a need for additional software in the VM.
Cowrie is a traditional honeypot which emulates SSH and Telnet servers. It can operate in two modes:
In both modes, you can track the user's behavior and record their commands and downloaded files, or attempts to create TCP tunnels (direct-tcp) through SSH. The used credentials are also collected, including login attempts using SSH keys.
Dionaea, the successor of the nepenthes project, is a modularized honeypot covering a lot of protocols. It offers shell code emulation through libemu and allows scripting in Python. Various output modules are available, such as SQLite, MySQL, JSON, log files, or IDEA event files (through a Warden connector).
Supported protocols include:
The modules usually implement a simplified version of the protocol. For example, the MS-SQL module implements the historical version of the protocol. However, useful data or exploits can and are still captured.
For Hugo honeypots, we have chosen protocols where we tested their functionality and there is a reasonable chance that they will provide interesting data.