{'fraction_non_alphanumeric': 0.02622327450136318, 'fraction_numerical': 0.008466063997704118, 'mean_word_length': 4.87874314635175, 'pattern_counts': {'":': 0, '<': 1, '<?xml version=': 0, '>': 1, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 8, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
A First Step Towards Understanding Real-world Attacks on IoT Devices

With the rapid growth of Internet of Things (IoT) devices, it is imperative to proactively understand the real-world cybersecurity threats posed to them. This paper describes our initial efforts towards building a honeypot ecosystem as a means to gathering and analyzing real attack data against IoT devices. A primary condition for a honeypot to yield useful insights is to let attackers believe they are real systems used by humans and organizations. IoT devices pose unique challenges in this respect, due to the large variety of device types and the physical-connectedness nature. We thus create a multiphased approach in building a honeypot ecosystem, where researchers can gradually increase a low-interaction honeypot's sophistication in emulating an IoT device by observing real-world attackers' behaviors. We deployed honeypots both on-premise and in the cloud, with associated analysis and vetting infrastructures to ensure these honeypots cannot be easily identified as such and appear to be real systems. In doing so we were able to attract increasingly sophisticated attack data. We present the design of this honeypot ecosystem and our observation on the attack data so far. Our data shows that real-world attackers are explicitly going after IoT devices, and some captured activities seem to involve direct human interaction (as opposed to scripted automatic activities). We also build a low interaction honeypot for IoT cameras, called Honeycamera, that present to attackers seemingly real videos. This is our first step towards building a more comprehensive honeypot ecosystem that will allow researchers to gain concrete understanding of what attackers are going after on IoT devices, so as to more proactively protect them.


Introduction
Over the past few years, a variety of devices used by people on a daily basis has found their way to the Internet. IoT has become one of the most hyped terminologies in industry. According to IDC research [1], nowadays people use various electronic devices at least three of which are usually connected to the Internet. This number is estimated to increase to 10 devices per person in the near future. Gartner [2] expects the world to see more than 20 billion IoT devices by 2020. Due to the increase in IoT device usage, attacks on them have also increased. For instance, more than 20% of companies around the world have experienced at least one IoT-related attack in the past few years [3,4].
Historically cyber-attacks have mostly manifest as data breaches or compromised devices used as spamming or DDoS agents. The emerging of IoT devices could significantly change the landscape of cyber-attacks both in terms of motives and methods. Due to the much higher level of intimacy IoT devices possess to people's life, attacks on them could result in much more devastating consequences compared with cyber-attacks in the past. Not only do they affect more people, but the range of possible threats has also expanded. For instance, if cyber criminals break into an IoT camera, they can invade people's privacy at an unprecedented level. Such attacks can even put people's life in real danger (imagine an intruder takes control of an autonomous vehicle).
Further exacerbating the situation is the repeated pattern in the IoT industry where speed to market dominates concern for security. Most IoT devices have simple accessible vulnerabilities including default username and password and open telnet/ssh port, to name just two. Those devices are often installed in weak or unsecured networks like home or public area. We are unfortunately at a time when exposure to attacks against IoT devices has become a reality, if not worse compared to traditional computing systems. According to Symantec's report [5], the number of IoT attacks dramatically increased in 2017. They identified 50,000 attacks which had an increase of 600% compared to 2016. New attacks such as VPNFilter [6], Wicked [7], UPnProxy [8], Hajime [9], Masuta [10] and Mirai [11] botnet also show that adversaries are continuously improving their skills to make these forms of attacks even more sophisticated. However, there is currently very little systematic study on the nature and scope of those attacks carried out in the wild. So far, large-scale attacks on IoT devices seen in the news have been mostly about using IoT in DDoS attacks (e.g., the Mirai attack [11]). It is impor- understand in fuller scope what activities attackers are  engaging with IoT devices and what their motives could be. A honeypot is a device set up for the purpose of attracting cyber attack activities. It is typically an Internet-facing device with either emulated or real systems for attackers to target. Since these devices are not meant to have other useful purposes, any access to them are deemed malicious. Honeypots have helped security researchers for a long time to understand various types of attacker behaviors. By analyzing data (network logs, downloaded files, etc.) captured by honeypots, researchers can uncover new tools and methods used by hackers, attack trends, and zero-day vulnerabilities. This information is highly valuable to improve cyber security measures, especially when organizations are resource-strapped when it comes to fixing security vulnerabilities.
In this paper we present our first step towards a comprehensive experimentation and engineering framework for capturing and analyzing real-world cyber-attacks on IoT devices using honeypots. There are two main challenges for creating IoT honeypots that can yield useful data for research.
1. The types of different IoT devices are vast, each of which has unique features that an attacker may wish to access. It is infeasible to build one honeypot system that can capture even a significant portion of all IoT devices. Thus, we adopt a multi-faceted approach to IoT honeypot engineering. We both adapt existing off-the-shelf honeypot systems and build ones from scratch to create a variety of honeypot systems for attackers to target.
2. The specific nature of attackers' activities towards IoT devices is largely unknown at this point, and there could be very different focuses on the attacker's side. Moreover, the richness of response from an IoT device is much greater than traditional IT systems due to the interaction with the physical world. For example, an IoT camera will need to return some real video to look like a real device. It would require significant amount of engineering work to emulate those different types of responses for different devices. Thus, we adopt a multi-phased approach where the sophistication of the emulated responses are gradually increased as data is gathered and analyzed to understand what the attackers might be going after.
In the remainder of the paper, we describe this multifaceted, multi-phased approach in building a IoT honeypot ecosystem, where various types of honeypots, deployed both on-premise and in the cloud, work in concert with a vetting system (to ensure the honeypot device looks like a real device) and data analytics infrastructure (for collecting and analyzing the captured data). Our ultimate goal is to attract real human attackers and understand their motives and modus operandi, so as to inform research on securing IoT devices in the real world.

Honeypot Background and Related Work
The first honeypot was introduced in 2000 [12]. Honeypots can be categorized into two classes: Low-interaction honeypot and high-interaction honeypot. 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 [12]. Honeypots are also categorized based on their purpose [13]. Production honeypots help companies mitigate possible risks, and research honeypots provide new information for the research community. Alba et al. [14] 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 [11]. 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. [15] 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. This approach provides an easy way to have a realistic interaction with adversaries, although it may inadvertently bring harm to otherwise innocent IoT devices exposed on the Internet. Guarnizo et al. [16] proposed a high-interaction IoT honeypot. They used real IoT devices to capture and analyze malicious activities. Another solution proposed by Pa et al. [17] was a combination of low interaction honeypots with sandbox-based high-interaction honeypots implemented as IoTPot. IoTPot only monitors telnet-based attacks. A honeypot for monitoring Zigbee protocol was offered by Dowling et al. [18]. Logs from a Zigbee honeypot were analyzed in this work. Six types of honeypots were deployed by Chamotra et al. [19] to understand IoT attacks in the broadband network. Compared to the prior work mentioned above, our main contribution is the design, implementation, and deployment of a honeypot ecosystem that addresses the challenges of capturing useful attack data on IoT devices (section 1).

A Honeypot Ecosystem
For honeypots to be useful for IoT security research, it is not sufficient to just have boxes running the various emulated or real IoT systems. These boxes need to be organized in a way that allow intelligent adaptation on the way they respond to different types of traffic, so an attacker can be "hooked" and made interested in further exploring it. The deeper an attacker becomes interested in a device, the more sophisticated it needs to be in "fooling the attacker" into thinking it is a real device. This inevitably becomes an arms race, the effectiveness of which lies in the return of useful insights per Step Towards a Honeypot Ecosystem the amount of engineering efforts spent. Our goal is to create a carefully designed ecosystem where a variety of honeypot devices working together with a vetting and analysis infrastructure, so that we can achieve good "return on investment." Figure 1 illustrates our first step towards building such an ecosystem. There are three distinct component: 1) honeypot server farms (on premise and in cloud), 2) a vetting system to ensure it is adequtely difficult for an adversary to detect the honeypot device is a honeypot, and 3) an analysis infrastructure that is used to collect and analyze the captured data. The honeypot server farms host the honeypot devices. We use both on-premise server and cloud instances from AWS [20] and Azure [21] in multiple countries, to create a wide geological coverage. Figure 2 shows the geographical locations of the deployed honeypot instances in our server farms. The countries include France, United Kingdom, India, Australia, Canada and Singapore. The on-premise server farm consists of a PowerEdge R830 server with 256 GB RAM running as VMware ESXi server, and a Synology NAS server for storing logs. Three Fedora instances and one Windows instance run on the ESXi server. The Windows instance and two of the Fedora instances are used for deploying honeypots. The third Fedora instance is used to run Splunk [22] to support data analytics. The instances in AWS and Azure run Ubuntu or Windows depending on the type of honeypots deployed. At this stage of our research, we only use low-interaction honeypots. For Fedora and Ubuntu instances we use docker containers to run honeypots in them. The generated logs are sent through syslog protocol to splunk. Networking controls are configured through security groups so that ports open for communication between entities within the honeypot ecosystem are not visible by Internet attackers.

Honeypot Server Farms
As explained in Section 1, given that different IoT devices have different specifications and configurations, each honeypot needs to be designed and configured in a unique way. We adopt a multi-faceted approach to building the various honyepot instances. We both use off-the-shelf honeypot emulators and adapt them, and build specific emulators from scratch.

Off-the-shelf Honeypots
Many popular off-the-shelf honeypots emulate general services and protocols that are not specific to IoT. However since many IoT devices have those services, it is still useful to adapt these existing honeypots for studying IoT attacks. We evaluated various open-source and commercial honeypots and selected three off-the-shelf software to use in the first step: Cowrie [23], Dionaea [24] and KFSensor [25]. In the rest of this section, a brief introuduction of these honeypots is presented.
Cowrie is a low-interaction honeypot 1 that attempts to imitate SSH and telnet services to attract adversaries and capture their interaction. Cowrie provides a fake file system, a fake ssh shell and is also able to capture files from input. It can log every activity in JSON format for ease of analysis [23]. Since many IoT devices still use telnet and SSH protocols for management purposes, Cowrie is a useful honeypot for understanding some facets of attacks on IoT devices. We run Cowrie on Debian inside a docker container.
Dionaea is a low-interaction honeypot that emulates various vulnerable protocols commonly found in a Windows system. The main goal of this honeypot is to lure adversaries and capture their malicious files such as worms and malware. Dionaea is able to simulate various protocols including HTTP, MYSQL, SMB, MSSQL, FTP, and MQTT. This honeypot also logs all the detected events in JSON format or inside a SQLite database. Dionaea was released in 2013 and is a useful tool for traping malware that exploits vulnerabilities [24]. We run Dionaea on Debian inside a docker container.
KFSensor is a commercial Intrusion Detection System (IDS) that acts as a low-interaction honeypot to attract potential adversaries and record their activities. It is a windowsbased honeypot. By acting as a bait, KFSensor draws the attention of adversaries from the real systems to itself and provides valuable intelligence for both research and operation. KFSensor also has some features useful for this work: managing the sytem remotely, easy integration with other IDSs like Snort [26], and emulating Windows network protocols [25]. Since Windows has substantial footprint as an IoT operating systems, both Dionaea and KFSensor can shed light on attacks on IoT systems. We run KFSensor in the Windows VMs on our server farms. To capture attacks on specific IoT devices, we build a honeypot for IoT camera and coined it HoneyCamera. This is our first step towards understanding what attackers are going after for various types of specific IoT devices. Figure 3 shows the architecture of this honeypot. Honeycamera is a low-interaction honeypot for D-Link IoT cameras. We implemented it using python3. To achieve this objective, we studied a D-Link camera and its responses to various types of inputs were captured carefully. Honeycamera uses basic authentication for login and repeatly plays a few seconds' of real video as a fake video stream from the emulated camera device. We also built six different pages which emulate the various services supported by this IoT camera, such as password changing, reading network information, and creating new users. This helps us understand the behavior of the adversaries. We also created a fake firmware upload service to capture and analyze tools and exploits used during attack sessions. Honeycamera logs all activities in JSON format. HoneyCamera runs in Clear Linux [27] that in turn runs inside a docker container.

Honeypot Vetting
A honeypot is valuable only as long as it remains undetectable, i.e., unknown to the attacker as a fake system. This is inherently a hard task since honeypots (especially low-interaction ones) will inevitably fail to demonstrate some observable features only a real system can possess, or present ones a real system will never show. The goal of the vetting process is to identify any information leakage which leads to the identification of a honeypot and provide remedies accordingly. We use the server farms in the cloud as a testbed to try different fingerprinting approaches to first make sure our honeypots cannot be easily detected. We use some manual and automatic fingerprinting method (e.g., through Metasploit [28]). We use Shodan [29], an IoT search engine that can be used to search for IoT devices on the Internet. Shodan provides information such as service banners and metadata, and a honeyscore in the range from 0 to 1 (1 indicates honeypot while 0 means real system). This score provides a preliminary insight into how good the honeypot impersonates a real device. We use Censys [30], another IoT search engine, to help analyze our honeypot instances to make sure they look like the real ones they imitate. Finally, and most importantly, from the captured data inside honeypots, attackers' fingerprinting approaches can be identified. Based on this insight we can create solutions to make them ineffective. This is built in our multi-phased experimentation process which will be explained in further details in Section 4.

Data Analytics Infrastructure
The success of a honeypot depends on two factors: 1) the way the honeypot software is developed and implemented; and 2) the log analysis process. Carefully analyzing the logs is as important as the honeypot development and implementation. We use Splunk [22] for log management and analysis. Splunk supports composing various queries using its domainspecific language that can be leveraged to achieve various analysis purposes in this work. All the logs captured from our honeypots are sent to the Splunk server for further analy-sis. We created a Splunk app to extract valuable information from the collected logs. Some example analyses done by the app are identifying the combinations of username and password used by attackers, analyzing locations of the attacks, detecting the most and least command executed during attack sessions, analyzing downloaded files and sending them directly to VirusTotal [31], storing the results and checking attackers' IPs through DShield [32] and AbuseIPDB [33], and so on.

Multi-phased Deployment/Experimentation
We employ a multi-phased approach, as explained in Section 1, to introduce sophistication in how our honeypots respond to attackers' traffic, based on traffic collected previously. In the first phase, we simply deploy the honeypot at hand and receive attack traffic. From this point, the honeypot ecosystem starts to collect data, and the analyzed data inform the creation of the subsequent phases by understanding what cybercriminals are looking for, so we can provide emulated responses accordingly. This second phase goes through many iterations until we are satisfied with the insights we gained and the attackers' behaviors elicited. Then in the third phase these insights are used to create more advanced 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.
HoneyShell We use the Cowrie honeypots to emulate vulnerable IoT devices with open SSH (port 22) or telnet (port 23). Cowrie can be configured to emulate different types of OS platforms. Busybox [34] is a Linux distribution popular among IoT devices. Thus we configure our Cowrie honeypots to emulate Busybox. We created three Cowrie honeypots for the three phases.
• Phase 1: the system is allowed to accept every possible combination of usernames and passwords. Two of these honeypots were deployed, one in Singapore (cloud) and the other on-premise.
• Phase 2: deployed on-premise and started after 6 months. The top 30 username/password combinations with at least one command execution after login in phase 1 were selected. All other username/password combinations would fail in this version of honeypot. Moreover, the emulation mechanisms are configured so that those commands will produce a meaningful response to attackers, e.g., new usernames and file systems were added in the configuration. Also, phase 1 logs were analyzed to identify possible fingerprinting techniques by attackers so they will be taken care of in phase 2.
Examples include file command's response added to the honeypot configuration. • Phase 3: all information collected before is used to create a more sophisticated honeypot. As a result, a complex password was generated, and the number of possible successful login combinations was limited to only one. Since the password was set to be complicated, every successful login would imply that it was possibly done by a real hacker which consequently could provide valuable information.
HoneyWindowsBox We use Dionaea to emulate IoT devices based on Windows platform. These attacks mostly result in malware being downloaded on the device. It would involve non-trivial work to further emulate the downloaded malware's behavior inside a honeypot; we leave this 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.
• Phase 1: a default version of Dionaea was deployed in the cloud. Our vetting system quickly identified it as a honeypot. • Phase 2: the various services were broken down into two different combinations. The first honeypot has FTP, HTTP and HTTPS while the second only contains SMB and MSSQL services. We deployed the two versions to three locations (India, Canada, and on-premise). The IPs popped up as a real system in Shodan. We also deployed KFSensor during this step. Paris and on-premise were chosen as the locations and all deployed instances passed our vetting system.
HoneyCamera This is our latest effort in emulating behaviors of a more specific IoT device. We plan to use data collected in phase 1 to inform the HoneyShell configuration in phase 2. This phase is still work in progress.
• Phase 1: three honeypots were deployed. Two in Sydney and Paris had only port 8080 open while the other 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. • Phase 2: a combination of HoneyCamera and Hon-eyShell will enable us to elicit attacker's behaviors that involve both common Unix commands and camera-specific commands.

Experimentation and Data Analysis
A total number of 18,972,475 hits were captured by our honeypot ecosystem over a period of one year. As shown in table 1, HoneyShell attracted the most hits. This information is described in detail in the rest of this section.

HoneyShell
Cowrie honeypots were able to capture the largest portion of the hits during this period. Figure 4 represents the number of hits based on locations and phases. It is notable that the on-premise phase 2 honeypot captured more hits in 6 months' time than the on-premise phase 1 honeypot did in a year, clearly showing the effectiveness of the multi-phased approach. Figure 5 shows that the majority of connections came from China, Ireland and the United Kingdom.
Singapore Phase 1 On-premise Phase 1 On-premise Phase 2 On-premise Phase 3 2.5 Furthermore, statistics shows that 15% of the total number of hits belong to successful logins. Most of these logins used random combinations of username and password which shows that automated scripts were used to find the correct authentications blindly. Table 2 represents the top 10 username/password combinations that were used by attackers. The information seems to indicate that attackers commonly look for high-value user with a weak password. However, by looking into the database, some other combinations such as university/<florida>, root/university and university/student were found inside the on-premise honeypot (inside a university) which indicates that attackers were aware of the organization's nature. and tried to customize their attacks based on that.
In addition, only 314,112 (13%) unique sessions were detected with at least one successful command execution inside   Besides downloading files, attackers tried to run different commands. Table 4 shows the top 10 commands executed with their occurrence number. By examining SSH version banner information, the difference between human attacks and bot attacks was identified. While 61% of the attacks are carried by a bot, the rest (39%) are likely human attacks.

.2 HoneyWindowsBox
Dionaea was representing a vulnerable Windows operating system. Most of the connections came from the United States followed by China and Brazil. During the usage of Dionaea, 43 unique files were captured. HTTP was the protocol used the most by attackers. FTP and smb were also used to download malicious files. In addition, a noticeable amount of SIP communication was found in the process of examination. SIP is mostly used by VoIP technology, and like other services, it suffers from common vulnerabilities such as buffer overflow and code injection. Collected data from these honeypots was used to create a more realistic file system for other honeypots.
KFSensor is an IDS-based honeypot. It listens to all ports and tries to create a proper response for each request it re-  Figure 6: Top 10 countries with most attacks ceives. The information gathered from this honeypot was also used to create a better environment and file system for Dionaea.

HoneyCamera
HoneyCamera was employed to emulate three IoT camera devices. As shown in Figure 6, most attacks captured inside HoneyCamera were from China. Two types of malicious files were downloaded with this honeypot: CoinMiner and Mirai. Analyzing the captured logs reveals that this honeypot attracted many attacks specifically targeted at IoT cameras. Below are some examples: • The first attack found was camera credential brute-force (/?action=stream/snapshot.cgi?user=[USERNAME]& pwd=[PASSWORD]&count=0). On this attack, adversaries tried to find a correct combination of username and password to get access to the video streaming service.
• The second attack found was trying to exploit CVE-2018-9995 vulnerability. This vulnerability allows attackers to bypass credential via a "Cookie: uid=admin" header and get access to the camera (/device.rsp?opt=user&cmd=list).
• A list of more attacks can be found in Table 5. D-Link, Foscam, Hikvision, Netwave and AIVI were only some of the targeted cameras inside this honeypot.
In addition, attackers mostly (74%) used GET protocol to communicate with the honeypot and 23% used POST method.

Conclusion
In this paper we present a multi-faceted and multi-phased approach in building a honeypot ecosystem. Furthermore, a new low-interaction honeypot for camera devices was introduced. Although this honeypot is still wrok in process, it has provided much insightful information. Analysis on the information captured during this work shows that adversaries generally look for vulnerable IoT devices to exploit them. Also, results indicate that in the same network , a more realistic and well-configured low-interaction honeypot can attract more attacks compared to honeypots which is configured poorly. Moreover, analysis of HoneyCamera's logs shows that IoT camera devices have become an interesting target for attackers. Different types of vulnerabilities were found in this process.