Honeypots

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:

• Low interaction – Only the necessary minimum for establishing and maintaining communication is implemented from the protocol. It is used for simple protocols or collection of attack IoCs, such as new, remotely exploitable threats, where attackers are likely to search for vulnerable systems in the IP address space.
• Medium interaction – More advanced simulation of the real system. You will use it if you need to maintain the illusion of a real system for longer, but do not want to take unnecessary risks. An example is the implementation of the SSH protocol in Cowrie, or FTP in the Dionaea honeypot.
• High interaction – Use of a real (virtualized) system, possibly through a proxy. This is usually considered risky, as these honeypots carry the entire operating system; however, this is redeemed by the ability to monitor the attacker's behavior on the real system, even with the rights of the administrator. A good example is Cowrie in proxy mode, using a virtual machine group.

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:

• Emulated shell – emulates the traditional environment of the UNIX system (Debian) – “medium interaction honeypot”
• Proxy – redirects SSH or Telnet sessions to another machine – “high interaction honeypot”.

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:

• File transfer: FTP, TFTP, SMB/CIFS, NetBIOS
• Database and key-value storage: MS-SQL, MySQL, MongoDB, Memccached
• MQTT
• PPTP
• HTTP(S)
• PJL/PCL Print Server (port 9100)
• UPnP
• Specialties such as Black Hole, EPMAP, Mirror, nfq etc.

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.