Honeypots are essential tools for threat hunting They are primarily decoys for attackers designed to mimic real systems, applications, or services. By luring malicious actors to interact with these decoy systems, researchers can observe and analyze their tactics, techniques, and procedures (TTPs). This way, researchers can understand the methods used by attackers to build efficient tools and strategies for early detection of malicious behavior.
A one-size-fits-all approach for a honeypot may attract low-level automated attacks, but it might fail to lure sophisticated threat actors. By tailoring the honeypot to match our interests, we can increase the likelihood of attracting advanced adversaries. Moreover, understanding the target’s motivations and objectives allows the creation of more realistic scenarios, leading attackers to interact with the honeypot in ways that reflect their actual intentions.
Honeypots are typically isolated from production environments and have no legitimate use. Therefore, any activity on a honeypot will be likely associated with an attack. When an attacker engages with a honeypot, it provides an early warning that an intrusion attempt is underway. With this information, threat hunters can discover new attack vectors, malware variants, and emerging threat trends, enhancing their understanding of the evolving threat landscape.
In this blog post, we detail the steps for setting up and utilizing an IoT honeypot in the real world. We’ll also walk through an example setup, taking the Winbox protocol as a case study, as it is commonly misused by attackers.
Step 1: Identify a specific protocol or device to simulate
Start by identifying a specific protocol and/or device of interest, for example, something that has previously been exploited, and gathering sources of available information. If the protocol specification is closed, it could be that someone has already implemented the targeted protocol in some programming language. It is possible that a Wireshark dissector exists for the proprietary protocol.
Next, check the reported public exploits to understand how the device/protocol is being targeted or manipulated. This should give you enough information to pinpoint what is valuable to capture in a honeypot, and what technical activities you want to look for. Once you are in the position to be able to reproduce the exploit example, it is now the time to set up a testing environment to see it in the wild.
Step 2: Set up a testing environment
One possible way to set up a test environment is to acquire the affected device and set it up in a vulnerable configuration. The exploit can then be used to ensure the device is vulnerable and later to gather artifacts such as a PCAP and logs of the active exploitation attempts and activities.
The simplest way to attract threat actors to the device is to put the affected device in a vulnerable configuration on the public internet. This can be a relatively cheap and effective approach, however, there are multiple drawbacks. For example, restoring the device to the initial clean state may be more difficult. Another approach is to set up a virtualized version of the vulnerable device, leveraging technology like OpenWRT or even a Windows virtual machine. This kind of system will be easy to revert to previous states. However, it also makes it easier for the attackers to realize that this is a research environment.
Unfortunately, these two options also have a common disadvantage. Logging the attacker’s actions in a unified way may be more difficult to achieve in some scenarios. For example, some exploits can potentially leverage unexpected and unmonitored system functionalities. In addition, if improperly configured, attackers may be able to cause real damage to third parties by misusing this system, so particular attention should be paid to its vulnerable state and connectivity.
Lastly, the more complex approach is to emulate the system’s intended operation as much as possible. This is typically what honeypots such as Cowrie do. They provide a fake Linux shell via SSH that looks real, with a fake filesystem and supported set of commands. This option is arguably among the best as it gives the operators advanced control over the honeypot, though this option also takes the most time to implement.
Step 3: Detection & monitoring
Once you decide how to set up the test environment, the next phase often consists of building some detection rules for the alerting when the system is misused, or exploitation occurs. There are many ways to achieve this, from using Snort rules to more complex alerting based on the system logs. It is best to enable all relevant system logs to register all potentially interesting actions an attacker takes. Unfortunately, not all systems allow you to log some important events, nor do they allow you to easily understand their protocols. In general, try to get as much visibility as possible. This will enable you to figure out what the adversary did and attempted to do with the system, which is extremely valuable and actionable information. Analysis of threat actor activities and tools often leads to the creation of new rules and signatures, and helps the cybersecurity community to better understand the motives and objectives of adversaries. Are they looking to set up a VPN network they can use to anonymize their traffic? Maybe. Or, maybe they are using the compromised device to launch DDoS attacks. These questions can only be answered if detection and monitoring are in place.
Step 4: Hardening
This step is crucial, as there might be some legal obligation you may have to follow. How can you minimize the risk of the adversary leveraging the honeypot to perform other malicious activity, especially if the honeypot is highly interactive? Sandboxing and robust firewall rules are crucial at this stage. The goal here is to prevent attackers from making any external requests from the honeypot instance or changing the system settings to become able to do so.
Step 5: Automate
Once an attacker successfully accesses and exploits the target device, a lot of useful information can be retrieved from the attacked machine. Manually retrieving the different sources of information is not an option, as there are likely different honeypots running in at the same time and malware is able to instantly remove its traces. Also, we need our honeypot to be ready for the next attacker as soon as possible. All the information needs to be put together to analyze it and have a global picture of it. For example, automating event logging by using SSH / WINRM or some message queue to access logs, you can begin to sort and review the actions and activities taken by the threat actor within the system.
Sometimes, attackers close the door they used to enter to make sure nobody enters after them. The next step will be to recover useful artifacts and logs from the honeypot. Once all of the artifacts have been recovered, think about how to reset the honeypot to a clean and exploitable state while minimizing human interaction required.
Final Considerations
There are several ways to place the honeypot in a specific geographic location, or hide its true location. One way would be to host multiple honeypot instances with public IPs associated with different countries of interest since most hosting providers allow customers to choose the location of their instances. Another approach could be to set up proxy forwarding requests to the actual honeypot instance. This allows you to host the actual honeypot in one location and make it visible on the internet with multiple public IP addresses associated with different countries.
In the end, you should have a publicly accessible honeypot capable of rule detection and log monitoring. As a result, you will be able to collect all of the relevant pieces of information needed to analyze and understand the threat. You can also analyze ways in which an attacker might automate the exploitation of your honeypot and/or similar vulnerable devices. Take some time to test your setup, have other people test it, and make sure everything behaves as expected. Be sure that the adversary cannot pivot to any other system within the honeypot range. Then you should be ready to go live. Remember to keep monitoring the honeypot as long as the instance is running, and take time to regularly review the logs and connection flows to ensure the honeypot continues operating as expected.
Case Study: Winbox
Let’s apply this approach to build a honeypot for the Winbox protocol, commonly misused by attackers. Probably the most famous example of this attack would be the Meris botnet that used it for propagation and abused devices at scale to launch some of the biggest DDoS attacks in history.
Winbox is a graphical user interface (GUI) application used to manage and configure MikroTik RouterOS devices. Some exploits make use of its protocol (basically a TLV-based protocol) to take advantage of unpatched devices that have different vulnerabilities. Below, we describe two vulnerabilities that allow reading and writing important system files without authentication or to escape the sandbox (CVE-2019-3943). We are going to analyze step by step, from Winbox’s point of view, how attackers leverage CVE-2018-14847.
The first step requires reading the content of the user.dat file. The Winbox protocol requires to first send the open-file request. The message for this opening request is conformed by 3 main values: SYS_TO, which tells the MikroTik device which system executable to use, the SYS_CMD which will select the specific action to perform, and the variable string.1 (set to user.dat) with the target file to operate with.
The device answers with the size of the file in the variable u32.2 to allow the client to allocate the required memory.
Now, setting SYS_CMD to 4 instructs the device to actually read u32.2 bytes from the file specified before.
To what the device answers with bytes read.
The file user.dat contains credentials of the system’s users. The weak “encryption scheme” allows attackers to instantly obtain the password set for any user: for the affected versions, the password is xored with a key, which is the result of applying MD5 hashing to the username and the 283i4jfkai3389 string. This MD5 hash can be instantly generated and the XOR operation can be instantly reverted this way.
When the administrator’s credentials are recovered, another vulnerability allows the attackers to access the system via SSH with the “devel” username. This traffic capture shows the creation of the devel-login file:
As the dissector is not able to tell us which command was executed, we can deduce that SYS_CMD=1 plus SYS_TO=[2,2] with a string variable and with a file-like path may indicate the creation of a file. In this case, the file was created to enable SSH access.
After the attackers have root shell access to the MikroTik system, they are able to perform any action they need for their purposes. For example, Meris/Glupteba, after exploiting CVE-2018-14847 to get root access, is used to enable a VPN server of the device and/or SOCKS proxy and configure scheduled tasks to keep its persistence.
Setting up a Winbox Honeypot
Because most of the interaction will then happen over SSH, this is where Cowrie comes into play. Cowrie can be configured to act as an SSH proxy, forwarding the traffic to the actual honeypot. That is why we set up the Mikrotik honeypot behind Cowrie. Cowrie can manage a pool of Mikrotik VMs and spin them up according to the config.
With this setup, we’ll also need to monitor interactions between the attacker and the victim performed via the Winbox protocol. If we capture the traffic, the dissector may be helpful, but not always. Sometimes some packets are not detected as a Winboxm protocol. Also, the dissector doesn't explain what the purpose of each command is.
For this purpose, we started working on pywinbox (https://github.com/NozomiNetworks/pywinbox) to help us understand what the attackers use the Winbox protocol for. The work of the security community in analyzing and understanding the Winbox protocol (particularly on Mikrotik’s ECSRP5 authentication protocol, the namespaces and Winbox innner workings) has been extremely important to better understand the vulnerabilities and improve the detection of these kinds of attacks.
pywinbox manages plaintext protocol and ECSRP5 authentication decrypting the Winbox packets (if the attackers are not using a plaintext connection), it decodes the Winbox protocol to be able to log all commands sent by the attackers and explain what is happening into the wire.
Figure 6 shows that pywinbox has logged the CVE-2018-14847 exploitation to read the user.dat file. First, the log shows the variables of the Winbox message so we can precisely see what was sent to the server. This is very useful when some unknown operation is performed in the system. Then, pywinbox interprets the meaning of the message and shows two different messages. The cyan-colored log entry explains what the purpose of the message is (opening a file in this case). The red-colored message is the alert that detected the exploitation of CVE-2018-14847 to read the user.dat file.
Since pywinbox logs all of the attacker’s commands, this allows the system to (1) act as a medium interaction honeypot answering to the commands it has been instructed to reply to and (2) forward the traffic to a real/virtualized Mikrotik server to work as a high interaction honeypot.
Conclusions
To leverage the full potential of honeypots it is crucial to understand all the implications of their use. Researchers deploying honeypots should have a deep understanding of the protocols relevant to the honeypot's deployment. Different protocols introduce varying attack vectors and potential vulnerabilities. By comprehending the specific protocol intricacies, security teams can configure honeypots more accurately, replicating legitimate services and attracting attackers effectively. This knowledge aids in accurately detecting and capturing malicious activity, leading to valuable insights for proactive defense strategies.
While honeypots can provide valuable benefits, it's important to acknowledge the legal and ethical considerations surrounding their use. Organizations must ensure compliance with relevant laws and regulations to avoid potential legal repercussions. Moreover, ethical considerations should be taken into account when choosing the kind of honeypot and its restrictions to ensure that the deployment of honeypots does not inadvertently lead to harm or collateral damage.
