What are Attackers after on IoT Devices?

In recent years, IoT devices have become ubiquitous and essential tools people use every day. The number of Internet-connected devices continues to rise every year. It was estimated that by 2025 there will be at least 41.6 billion IoT devices connected to the Internet (idc_2019, ). Business Insider projected (newman_2020, ) a 512 % increase compared to 2018 (8 billion IoT devices). The exponential growth raises serious security concerns. For example, many IoT devices have simple vulnerabilities like default username and password as well as open telnet/ssh ports. Oftentimes these devices are placed in weak or insecure networks, such as home or public space. In reality, IoT devices are subject to attacks just as much as traditional computing systems, if not more so. New IoT devices could open up new entry points for adversaries and expose the entire network. Around 20 % of businesses around the world have experienced at least one IoT-related attack in the past few years (arubanetworks, ).

In the past, cyber-attacks have mostly taken the form of data breaches or compromised devices used as spamming or Distributed Denial of Service (DDoS) agents. In general, breaches affect important systems in industry, computer devices, banks, automated vehicles, smartphones, and so on. Moreover, there are a lot of examples where they have caused serious and significant damages. Because IoT devices are now an integral part of most people’s lives, cyber-attacks have become more dangerous because of the widespread use of them. Compared to the the past, now many more people are at risk and need to be aware of them. As IoT devices become more common, cyber-attacks are likely to change significantly both in terms of reasons and methods. Due to the high level of intimacy IoT devices possess to people’s lives, attacks on them could have much more devastating consequences compared to cyber-attacks in the past. These threats not only affect more people, but they have also expanded in scope. Cyber criminals, for example, can cause unprecedented levels of privacy invasion if they hack into camera devices. These attacks can even endanger people’s lives (imagine an intruder attempting to take control of an autonomous vehicle).

Another factor exacerbating the situation is a pattern in the IoT industry where speed to market overrides security concerns. For example, many IoT devices have simple vulnerabilities like default username and password as well as open telnet/ssh ports. Weak or unsecured networks like home or public places are frequent locations where these devices are installed. The exposure to attacks against IoT devices has unfortunately become a reality, if not worse than traditional computing systems. The number of IoT attacks increased significantly in 2017 according to a report by Symantec (symantec_2018, ). They identified 50 000 attacks which had an increase of 600 % compared to 2016. In 2021 Kaspersky reported that IoT attacks more than doubled in the first six months of 2021 compared to the six-month period before (seals21:threatpost, ). In addition, attackers have also improved their skills to make these attacks even more sophisticated with new attacks such as VPNFilter (vpnfilter, ), Wicked (wicked, ), UPnProxy (akamai_2018, ), Hajime (edwards2016hajime, ), Masuta (newsky_security_2018, ) and Mirai (antonakakis2017understanding, ) botnet. Adversaries are continuously improving their skills to make these forms of attacks even more sophisticated. At present, however, few systematic studies have been conducted on the nature or scope of such attacks in the wild. As of now, most large-scale attacks on IoT devices in the news have been DDoS attacks (e.g., the Mirai attack (antonakakis2017understanding, )). Understanding what attackers are doing with IoT devices and what their motives could be is of utmost importance.

In cyber security, a honeypot is a device set up for the purpose of attracting attack activity. Usually, such systems are Internet-facing devices that either emulate or contain real systems for attackers to target. Since these devices are not intended to serve any other purpose, any access to them would be considered malicious. Security researchers have used honeypots for a long time to understand various types of attacker behavior. Honeypots facilitate researchers’ ability to uncover new methods, tools, and attacks by analyzing data collected by them (network logs, downloaded files, etc.). This allows for the discovery of zero-day vulnerabilities as well as attack trends. As a result of this information, cyber security measures can be improved, especially for organizations with limited resources when it comes to fixing security vulnerabilities.

This paper presents our approach toward a comprehensive experimentation and engineering framework for capturing and analyzing real-world cyber-attacks on IoT devices using honeypots. There are a number of challenges to creating IoT honeypots that can produce useful data for research. We address these challenges through a number of techniques.

1. (1)

   Various types of IoT devices exist, each of which has unique features that an attacker may wish to access. In order to capture even a small percentage of all IoT devices, it is not feasible to build one honeypot system. Hence, we take a multi-faceted approach to IoT honeypot development. In order to build a variety of honeypot systems for attackers to target, we adapt off-the-shelf honeypot systems and build some new ones.

2. (2)

   At this point, there has not been a deep and systematic understanding of the specific natures of attackers’ activity towards IoT devices, and attackers may have very different focuses. Furthermore, IoT devices offer much more varieties of responses than traditional IT systems due to its interaction with a physical environment. An IoT camera, for example, will need to display some real video to look like a real device. It would take an impressive amount of engineering work to replicate these different types of responses. In this regard, we adopt a multi-phased approach whereby the sophistication of the emulated responses is increased, as gathered data is analyzed to understand what the attackers might be trying to accomplish.

3. (3)

   Our data indicates that IoT honeypots can collect huge amounts of data, inundating an analyst’s ability to interpret and identify actionable intelligence. By utilizing the speed and convenience of Cosine Similarity and Gaussian Mixture Models (GMMs), we create an clustering algorithm for automatically grouping adversarial activities in an unsupervised way. This provides an opporutnity for revealing more stealthy activities that would otherwise be buried in the large amount of background noise.

The rest of the paper is organized as follows. Section 2 discusses related work. In Section 3, we describe the IoT honeypot ecosystem we designed and used in this research. In Section 4 we present a multifaceted and multiphased approach for the purpose of eliciting richer attacker behaviors. Section 5 describes the clustering approach we created to analyze the data. We present our experimentation results in Section 6.

The first honeypot recorded in the literature was introduced in 2000 (honsurv, ). Honeypots can be categorized into two classes: Low-interaction honeypots and high-interaction honeypots. Low-interaction honeypots only emulate some services such as SSH or HTTP, whereas high-interaction honeypots provide a real operating system with lots of vulnerable services (honsurv, ).

Honeypots are also categorized based on their purpose (spitzner_2001, ). Production honeypots help companies mitigate possible risks, and research honeypots provide new information for the research community.

Alba et al. (alaba_othman_hashem_alotaibi_2017, ) conducted a survey of existing threats and vulnerabilities on IoT devices. The first time IoT devices were used as a platform for large Internet-scale attack dates back to the summer of 2016, when the French hosting company OVH was targeted with the first wave of Mirai attacks (antonakakis2017understanding, ). In the follow-up attack in October 2016, Mirai brought down the Dyn DNS provider which at the time was hosting major companies’ websites including Twitter, Github, Paypal and so on. Luo et al. (luo2017iotcandyjar, ) designed an intelligent-interaction honeypot for IoT devices called IoTCandyJar. It actively scans other IoT devices around the world and sends some part of the received attacks to these devices. Wang et al. (IoTCMal, ) presented an IoT honeypot called IoTCMal, which is a hybrid IoT honeypot framework, and includes low-interaction component with Telnet/SSH service and high-interaction vulnerable IoT devices. Vetterl et al. (Honware, ) use firmware images to emulate Customer Premise Equipment (CPE) and Internet of Things (IoT) devices and run them as honeypots. Pa et al. (minn2015iotpot, ) designed IoTPot which is a combination of low-interaction honeypots with sandbox-based high-interaction honeypots. Another innovative honeypot is the HoneyPLC honeypot. It develops high-interaction honeypots for Programmable Logic Controllers (PLCs) within Industrial Control Systems (ICS) (honeyplc2020, ). Using a multi-component honeypot, Semic and Mrdovic (miraiiothoneypot, ) investigated Telnet Mirai attacks. Honeypots are designed to recruit and target attackers by exposing a weak, generic password in the front end of the honeypots. In place of using an emulation file, the front-end is programmed to generate responses based on input from the attacker, with logic defined in the code. Anarudh et al. (anirudh2017use, ) developed a honeypot model for the main server to shift Denial of Service (DoS) attacks in IoT networks and to improve the IoT device performance. Hanson et al. (hanson2018iot, ) extended the concept of the IoT honeypot by presenting a hybrid honeynet system that includes virtual and real devices. In order to analyze traffic and predict the next move of the attackers, the system used machine learning algorithms. Puna et al. (pauna2019rewards, ) proposed IRASSH-T to develop an IoT honeypot that can automatically adapt to new threats. To capture more information about target malware, IRISSH-T uses reinforcement learning algorithms to identify optimal rewards for self-adaptive honeypots that communicate with attackers. The study by Lingenfelter et al. (Lingenfelter2020, ) focused on capturing data on IoT botnets by simulating an IoT system through three Cowrie SSH/Telnet honeypots. To facilitate as much traffic as possible, their system sets the prefab command outputs to match those of actual IoT devices, and uses sequence matching connections on ports. Oza et al. (oza2019snaring, ) presented a deception and authorization mechanism called OAuth to mitigate Man-in-the-Middle (MitM) attacks.

There have also been studies that utilized low-interaction honeypots, high-interaction honeypots seperately or together and studied adversaries’ attacks on IoT devices (guarnizo2017siphon, ; dowling2017zigbee, ; chamotra2016honeypot, ; wang2018thingpot, ; upot, ).

Compared to the prior work mentioned above, our main contribution is the design, implementation, and deployment of a multi-phased multi-faceted honeypot ecosystem that addresses the challenges of capturing useful attack data on IoT devices and study adversaries behaviors in this context.

One-shot deployment of IoT honeypots – simply having boxes running emulated or simulated IoT systems, can only obtain limited attack information. The longer a honeypot can “hook” an attacker on it, the more useful information can be revealed about attacker goal and tactics. The more interested an attacker becomes in a device, the more sophisticated it needs to be to fool them into thinking it is a real device. Due to the rich interaction an IoT device has with its environment, an IoT honeypot must be organized in a way that allows intelligent adaptation to varying types of traffic. The effectiveness of this arms race is measured by how much useful insights can be gleaned for the amount of engineering effort expended. It is our aim to build a carefully designed ecosystem that has a variety of honeypot devices working in concert with a vetting and analysis infrastructure, enabling us to achieve a high “return on investment.”

We designed and implemented a honeypot ecosystem with three components, outlined in Figure 1.

1. (1)

   honeypot server farms (on premise and in the cloud) that include the honeypot instances

2. (2)

   a vetting system to ensure that adversaries have a hard time to detect the honeypot device is a honeypot

3. (3)

   an analysis infrastructure used to monitor, collect, and analyze the captured data

We use a multi-phased approach to introduce sophistication into how our honeypots respond to attacker traffic, based on traffic collected previously. In the first phase, we simply deploy the honeypot at hand and receive attack traffic.

From this point forward, the honeypot ecosystem collects data, and that data will be analyzed in order to create the subsequent phases defined by what attackers seem to be looking for, and we can emulate those responses accordingly. We go through multiple iterations until we are satisfied with the insights we gained and the attacker’s behaviors. The insights from the previous phase are used to drive the creation of more sophisticated low-interaction honeypots. We present this multi-phased process from three facets that our honeypots attempt to capture about IoT attacks: attacks through login service to obtain a command shell, windows service attacks resulting in malware download, and IoT camera attacks.

1. HoneyShell We use the Cowrie honeypots for emulating vulnerable IoT devices over SSH (port 22) and telnet (port 23). Cowrie can be configured to emulate different types of operating systems. A popular Linux distribution for IoT devices is busybox (busybox, ). Therefore, we configure our Cowrie honeypots to emulate Busybox. Three Cowrie honeypots were created for the three phases.

• •

  During Phase 1, an initial version of cowrie is deployed with minimal changes to the original code. This step was designed to begin collecting data that would be used in the next step and identify any information leakage. Every possible combination of usernames and passwords are accepted by the honeypot at this stage. We deployed four honeypot instances – two on-premise and two in the cloud (Singapore, United states).

• •

  In Phase 2, honeypot instances were deployed on-premises after six months of testing the phase 1 infrastructure. Our honeypot instances are filled with more data as we fix bugs. We selected the top 30 username/password combinations that executed at least one command after logging in as the authentication credentials for our honeypot. We gathered this information from our analysis component. The honeypot will display login failure messages for any other combination of username and password. A further modification of the emulation mechanism is that it is configured in such a way that attackers are provided with more meaningful responses, such as adding new usernames and file systems to the configuration. In addition, we emulated new commands and added them to the honeypot configuration files in order to attract more activity. We also analyzed phase 1 logs for fingerprinting techniques used by attackers, in order to handle them properly in phase 2. Examples include file command’s response being added to the honeypot configuration.

• •

  Phase 3 involves using all the information collected so far to create a more sophisticated honeypot. The purpose of this step was to design a honeypot instance that could attract a real human (attacker) into it. Therefore, a complex password was generated, and only one possible login combination was possible. Due to the complexity of the password, a successful login indicated it was probably a real hacker, and therefore extremely valuable information could be gathered. The honeypot filesystem was replaced by a cloned version of the operational system’s filesystem. All confidential information is replaced with fake information, so in case a hacker successfully logged into the honeypot, it is not exposing any real data.

2. HoneyWindowsBox Using Dionaea, we emulate IoT devices running on Windows. The majority of these attacks result in malware being downloaded on the device. It would require some additional work to further emulate the downloaded malware’s behavior inside a honeypot, so this is reserved for future work. In this work, we use phase 2 of this honeypot to apply our vetting system to ensure they are not easily identifiable as honeypots.

• •

  In Phase 1 a default version of Dionaea was deployed in the cloud. To identify the weak point of Dionaea, we used the cloud infrastructure as a test bed. AWS France hosts an instance of this honeypot. This instance was detected quickly as a honeypot by our vetting system. Nevertheless, it continued to capture automated malicious activities, which helped us create phase 2.

• •

  During Phase 2, various services were broken down into two different combinations. The first honeypot provides FTP, HTTP, and HTTPS, whereas the second only provides SMB and MSSQL. These two versions were deployed across three locations (India, Canada, and on-premise). In our vetting system, these IP addresses appeared as real systems. We enhanced the HoneyWindowsBox by introducing the KFSensor into the ecosystem to add more coverage into our honeypot. As for the locations, we chose Paris and on-premise, and each instance was vetted.

3. HoneyCamera is the last honeypot to be implemented. A camera’s port availability varies depending on its type. Through this approach, we are attempting to emulate the behavior of a more specific IoT device. The D-Link camera was chosen for this study and was used in the first version of this honeypot on the cloud infrastructure. Phase 1 data was used to identify possible weaknesses of HoneyCamera. Furthermore, we used phase 1 data to guide HoneyShell configuration in phase 2.

• •

  Phase 1 involved the deployment of three honeypots. The two instances in Sydney and Paris only had port 8080 open, while the one in London had port 80. The first two honeypots were used to emulate D-Link DCS-5020L and the other one to imitate D-Link DCS-5030L camera. Instances of this type are configured in such a way that they provide as much information as an interaction-based honeypot can. These instances of HoneyCameras were identified as real IoT devices by our vetting system. Data collected in this phase indicated that attackers were also trying to exploit known vulnerabilities related to the IoT cameras.

• •

  Phase 2 We discovered 6 vulnerabilities that attackers attempted to exploit inside HoneyCamera from the data collected in Phase 1. The most common bug was Authentication Information leakage. These vulnerabilities were carefully studied, and we incorporated the corresponding responses into HoneyCamera instances. Additionally, the IoT cameras are equipped with a telnet/SSH port for remote configuration and diagnostic purposes. In order to replicate these types of activities, we combined our HoneyShell and HoneyCamera and deployed them as single instances into the on-premise and cloud (Tokyo) infrastructures. Using HoneyCamera and HoneyShell, we were able to identify attacker behavior that involves both Unix command-line and camera-specific commands.

For the unique nature of IoT devices’ communication and the various types of commands, it can be difficult to discover new or unknown cyber attacks against these devices. One key observation from our data is that the honeypot instances collect huge amount of attack activities, but most of these activities belong to a few categories. Activities in the same category show similarity among one another. This inspires us to design an unsupervised approach using clustering, so that we can group similar attacks together to make the attackers’ intentions clear.

We adopt a distance-based clustering method, which utilizes cosine similarity and the unsupervised learning algorithm Gaussian Mixture Model (GMM) to calculate the distances between different commands executed in the honeypot and perform clustering based on this metric. We then identify “actors” (represented as unique IP addresses) that share similar commands according to the clustering results, and group the actors based on this similarity. The attacker intentions then emerge from those groupings. In the rest of this section we describe the clustering and grouping algorithms and the intuitions behind them.

A total number of 22 629 347 hits were captured by our honeypot ecosystem over a period of three year. As shown in Table 1, HoneyShell attracted the most hits. This information is described in detail in the rest of this section.

In the following subsections, we present the results from the experimentation of the multi-phased honeypot evolution as described in Section 4. The analysis presented therein is based on data collected in the last phase in each experiment²²2In the discussion we sometimes mention data from earlier phases for the purpose of comparison..

Analyzing the data from our IoT honeypot ecosystem in several phases yielded some interesting results. As it turns out, IoT devices are under heavy attack by automated tools and bots. The Mirai and its variants are still active, looking for targets to add to their arsenal. Additionally, the increasing sophistication in the data we collected in each phase proves that the multi-faceted multi-phased approach is a useful approach for designing an IoT honeypot ecosystem to study and identify unknown novel attacks. This was further supported by human activities we captured in HoneyCamera as presented in section 6.3. The vast majority of data captured in our ecosystem was bot-related. This makes it difficult to detect unknown and stealthy attacks. Our clustering algorithm provides the insight that by utilizing a syntax-based similarity metrics we can group the most executed commands together, providing important insights for understanding the background noise.

In addition, our grouping algorithm attempts to identify the various intentions of the attackers based on their commands as they show up in the various clusters. A future direction is to further research the granularity of such intentions to visualize more fine-grained steps of attackers’ mode of operations.

In this paper we presented a multi-faceted and multi-phased approach to building a honeypot ecosystem. Furthermore, a new low-interaction honeypot for camera devices was introduced. Analysis on the information captured during this work shows that adversaries are actively looking for vulnerable IoT devices to exploit. Our results indicate that a multi-faceted and multi-phased approach to building an IoT honeypot ecosystem can capture increasingly sophisticated attacker activities, compared to a build-once honeypot. Moreover, analysis of HoneyCamera’s logs shows that IoT camera devices have become an interesting target for attackers. We presented a clustering approach to understanding the large number of commands captured in the honeypot, and a grouping algorithm that uses the command clusters to infer attackers’ intentions and mode of operations.

We are grateful to Raj Rajagopalan for insightful comments and discussions throughout this work. We also thank Danielle Ward and Nathan Schurr for helpful input to this research

This paper is not subject to copyright in the United States. Commercial products are identified in order to adequately specify certain procedures. In no case does such identification imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the identified products are necessarily the best available for the purpose.