# Revealing Human Attacker Behaviors Using an Adaptive Internet of Things Honeypot Ecosystem

Armin Ziaie Tabari, Guojun Liu, Xinming Ou, Anoop Singhal

► To cite this version:

Armin Ziaie Tabari, Guojun Liu, Xinming Ou, Anoop Singhal. Revealing Human Attacker Behaviors Using an Adaptive Internet of Things Honeypot Ecosystem. 19th IFIP International Conference on Digital Forensics (DigitalForensics), Jan 2023, Arlington, VA, United States. pp.73-90, 10.1007/978-3-031-42991-0_5. http://05517472

HAL Id: hal-05517472

https://inria.hal.science/hal-05517472v1

Submitted on 18 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Revealing Human Attacker Behaviors Using an Adaptive Internet of Things Honeypot Ecosystem

Armin Ziaie Tabari¹, Guojun Liu², Xinming Ou², and Anoop Singhal³

¹ OPSWAT, Tampa, Florida, USA

² University of South Florida, Tampa, Florida, USA

xou@usf.edu

³ National Institute of Standards and Technology, Gaithersburg, Maryland, USA

**Abstract.** Honeypots have been used as decoy devices to understand the dynamics of threats on networks and their impacts. However, the questions of whether and how honeypots can elicit rich human attacker behaviors have not been investigated systematically. These capabilities are especially important for Internet of Things devices given the limited knowledge about attacker goals.

This chapter attempts to answer three questions. Can an Internet of Things honeypot that gradually adapts or increases its emulation sophistication elicit richer human attacker behaviors over time? Is it possible to engage human attackers using dynamically-adapting Internet of Things honeypots? Does the large amount of data captured by honeypots embody patterns that can enable security analysts to understand attacker intentions on Internet of Things devices?

To answer the questions, a new approach is presented for creating an adaptive honeypot ecosystem that gradually increases the sophistication of honeypot interactions with adversaries based on observed data. The approach is employed to design custom honeypots that mimic Internet of Things devices and an innovative data analytics method is applied to identify attacker behavior patterns and reveal attacker goals. The honeypots in the experiments actively observed real-world attacker behaviors and collected increasingly sophisticated attack data over more than three years. In the case of Internet of Things camera honeypots, human attack activities were observed after adapting the honeypots based on previous attacker behaviors. The data analytics results indicate that the vast majority of captured attack activities share significant similarities, and can be clustered to better understand the goals, patterns and trends of Internet of Things attacks in the wild.

**Keywords:** Honeypots · Internet of Things Devices · Human Attacker Behaviors

## 1 Introduction

The massive proliferation of Internet-connected devices raises serious security concerns. Many Internet of Things devices have simple vulnerabilities such as
default usernames and passwords, and open SSH and Telnet ports. Often, the
devices are located in weak or insecure networks, such as home or public space
networks. In fact, Internet of Things devices are subject to as many attacks as
traditional computing systems, if not more.

New Internet of Things devices open up new attack entry points and expose their entire networks. According to a report by Symantec [20], 50,000 Internet of Things attacks were detected in 2017, an increase of 600% over 2016. Kaspersky reported that Internet of Things attacks more than doubled in the first six months of 2021 compared with the previous six-month period [19]. In addition, attackers demonstrated improved skills by launching sophisticated attacks such as VPNFilter [21], Wicked [11], UPnProxy [1], Hajime [7], and the Masuta [4] and Mirai [3] botnets.

Unfortunately, few systematic studies have focused on the nature or scope of Internet of Things attacks in the wild. At this time, most large-scale attacks on Internet of Things devices have involved distributed denial-of-service (DDoS) (e.g., Mirai attacks [3]). Understanding what attackers are doing with Internet of Things devices and their motives are of utmost importance.

Honeypots are real or emulated Internet-facing devices that are configured
to attract attackers and attacks. Since they are not intended to serve any other
purpose, any access to them is presumed to be malicious or anomalous. Re-
searchers uncover new methods, tools and attacks by analyzing data such as
network logs and downloaded files collected by honeypots. This enables the dis-
covery of vulnerabilities and attack trends. Honeypots possess significant poten-
tial for improving security defenses based on the intelligence gathered, especially
in organizations with limited resources.

Despite the long history of honeypots, relatively little research has focused on deploying and utilizing them for security defense. In particular, no systematic study has concentrated on increasing the sophistication of human attacker behaviors elicited by honeypots in order to maximize intelligence gathering. While it is often reported that honeypots in the wild collect huge amounts of data, limited research has attempted to investigate whether the data embodies patterns that could contribute to greater understanding of attacker behaviors.

This chapter attempts to answer three questions. Can an Internet of Things honeypot that gradually adapts or increases its emulation sophistication elicit richer human attacker behaviors over time? Is it possible to engage human attackers using dynamically-adapting Internet of Things honeypots? Does the large amount of data captured by honeypots embody patterns that can enable security analysts to understand attacker intentions on Internet of Things devices?

To answer these questions, an adaptive honeypot approach was employed
in which the sophistication of emulated honeypot responses increased as data
was analyzed to understand what the attackers were attempting to accomplish.
Several facets of honeypots were flexibly composed to mimic a variety of Inter-
net of Things devices. The adaptive Internet of Things honeypot ecosystem was
deployed worldwide over a period of three years. Since the massive amount of
collected data – more than 28 million hits – would inundate human analysts, a
data clustering approach was designed to reveal attack patterns and trends in the data. The experimentation and data analytics suggest that an adaptive honeypot design can elicit richer human attacker behaviors over time. In particular, the experimentation reveals that human attackers can be effectively engaged by adaptive honeypots. The data analytics demonstrates that the huge amount of honeypot data embodies patterns that can be organized to advance the understanding of human attacker behaviors.

## 2 Related Work

The use of honeypots can be traced back in the research literature as early as 2000 [15]. Honeypots are categorized into two classes, low-interaction honeypots and high-interaction honeypots. Low-interaction honeypots emulate services such as SSH and HTTP whereas high-interaction honeypots provide real operating systems with many vulnerable services [15].

Luo et al. [14] designed an intelligent-interaction honeypot for Internet of Things devices. They also created a framework that automated honeypot responses to make honeypots more realistic and attract attackers.

Wang et al. [25] developed a hybrid Internet of Things honeypot framework that incorporated a low-interaction component with Telnet/ SSH services and high-interaction vulnerable Internet of Things devices. Vetterl and Clayton [24] employed firmware images to emulate customer premises equipment and Internet of Things devices, and run them as honeypots. Pa et al. [17] designed a combination of low-interaction honeypots and sandbox-based high-interaction honeypots. HoneyPLC [13] is a collection of high-interaction honeypots targeted at programmable logic controllers in industrial control systems.

Semic and Mrdovic [22] employed multi-component honeypots to investigate Telnet attacks by the Mirai botnet. Honeypots were designed to recruit and target attackers by exposing weak, generic passwords in the honeypot front-ends. Instead of using emulation files, the front-ends were programmed to generate responses to attacker inputs based on logic defined in the code.

Anirudh et al. [2] developed a honeypot model of a main server to shift denial-of-service (DoS) attacks on Internet of Things networks and improve Internet of Things device performance. Hanson et al. [10] extended the Internet of Things honeypot concept by developing a hybrid honeynet system that included virtual and real devices. The system used machine learning algorithms to analyze traffic and predict the next moves of attackers. Pauna et al. [18] proposed IRASSH-T for developing an Internet of Things honeypot that automatically adapts to new threats. To capture more information about target malware, IRISSH-T employs reinforcement learning algorithms to identify optimal rewards for self-adaptive honeypots that communicate with attackers. Lingenfelter et al. [12] captured data on Internet of Things botnets by simulating an Internet of Things system using three Cowrie SSH/Telnet honeypots. To handle as much traffic as possible, their system sets the prefabricated command outputs to match those of actual Internet of Things devices and used sequence matching connections on ports.
<figure><img src="image_3.png" /><figcaption>Fig. 1. Adaptive honeypot ecosystem.</figcaption></figure>

Oza et al. [16] presented deception and authorization mechanisms for mitigating man-in-the-middle attacks. Other researchers have also utilized low-interaction honeypots and high-interaction honeypots either separately or together to study attacks on Internet of Things devices [5, 6, 8, 9, 26].

In comparison with the related work described above, this research has focused on eliciting richer attacker behaviors by adapting Internet of Things honeypots and using data analytics to understand the large amounts of data captured by the honeypots over more than three years.

## 3 Adaptive Honeypot Ecosystem

Figure 1 shows the adaptive Internet of Things honeypot ecosystem [23]. The ecosystem has three components. The first comprises honeypot server farms on premises and in the cloud that host honeypot instances that interact with attackers and collect data. The second is a vetting system, which ensures that attackers find it difficult to identify that the honeypot devices are in fact honeypots. The third component is an analytics infrastructure that is used to analyze the collected data to gain intelligence about attackers and attacker behaviors.

The adaptive honeypot ecosystem employed on-premises servers and cloud instances supported by Amazon Web Services and Microsoft Azure in multiple countries. Since Internet of Things devices have different specifications and configurations, each honeypot instance had to be designed and configured in a unique manner. In creating the ecosystem, off-the-shelf honeypot emulators were adapted and custom emulators were built from scratch.

A honeypot is valuable only as long as it remains undetected, i.e., attackers are unaware that it is a fake system. This is an inherently difficult task because honeypots — especially low-interaction ones — inevitably fail to demonstrate some observable features that only real systems can possess or present features that real systems never manifest. An important goal of the vetting system is to detect information leaks that would indicate a device is a honeypot and to mitigate the leaks promptly.
<table><caption>**Table 1.** Numbers of hits on various honeypot facets.</caption><thead><tr><td>Honeypot</td><td>Uptime</td><td>Hits</td></tr></thead><tbody><tr><td>HoneyShell</td><td>23 months</td><td>23,355,621</td></tr><tr><td>HoneyWindowsBox</td><td>7 months</td><td>1,618,906</td></tr><tr><td>HoneyCamera</td><td>25 months</td><td>3,667,029</td></tr></tbody></table>

The primary task of the data analytics infrastructure was to identify attacker interactions and understand attacker behaviors. This information was used to adapt the honeypots. The popular Splunk tool was employed to manage and analyze logs from honeypot devices in the ecosystem. Example analyses include identifying the username-password combinations used by attackers, examining attack locations, identifying the most and least frequent commands executed during attack sessions, scrutinizing downloaded files and sending them to the popular VirusTotal website, storing the results and checking attacker IP addresses using the DShield and AbuseIPDB systems.

## 4 Eliciting Rich Attacker Behaviors

The longer a honeypot can keep an attacker on the hook, the more useful is the information gained about the attacker's goals and tactics. Of course, the more interested an attacker becomes in a honeypot device, the more sophisticated the honeypot needs to be to fool the attacker that it is a real device. The effectiveness of this competition is measured by the number of useful insights gleaned given the amount of engineering effort expended. Therefore, the ecosystem was designed to incorporate a variety of honeypot devices that worked in concert with the vetting system and data analytics infrastructure to achieve a high return on investment.

The first research question was whether rich human attacker behaviors could be elicited by adapting the deployed honeypots based on the observed traffic. A multi-phase process was employed to continuously increase the complexity of the honeypot instances. In the first phase, honeypots were deployed to collect data. This data was analyzed to design adaptations for the next phase. During the second phase, the honeypots emulated responses according to the attackers' perceived goals. Multiple iterations were performed until the insights were deemed to be satisfactory.

Due to the rich interactions that Internet of Things devices have with their environments, an Internet of Things honeypot must be organized to allow a flexible combination of components that provide services such as SSH, Telnet and HTTP. Therefore, honeypot components called facets were constructed to emulate the various services provided by Internet of Things devices.

Table 1 presents the numbers of hits received by three honeypot facets, HoneyShell, HoneyWindowsBox and HoneyCamera, positioned in the adaptive hon-
eypot ecosystem. A total number of 28,641,556 hits were captured by the honeypot ecosystem over more than three years. This section describes two of the facets, HoneyShell and HoneyCamera, how they were adapted to attract attackers, and the experimental results.

## 4.1 Adapting Shell Services

Many Internet of Things devices have shell services such as SSH and Telnet that allow remote logins. Since shell services constituted a major portion of the attack surface based on the collected data, a honeypot version of the shell services dubbed HoneyShell was created.

HoneyShell uses Cowrie honeypots to emulate vulnerable Internet of Things devices that support SSH (port 22) and Telnet (port 23). Cowrie can be configured to emulate different operating systems. HoneyShell was configured to emulate BusyBox, a command suite with Unix utilities that is commonly provided by Internet of Things devices. HoneyShell was adapted during the two phases as follows:

- **Phase 1:** An initial version of HoneyShell was deployed with minimal changes to the original Cowrie code. Data that would be useful in the next phase was collected and responses that might reveal the device as a honeypot were identified. Every possible username-password combination was accepted by HoneyShell during the first phase. Three HoneyShell instances were deployed in this phase, two on premises and one in the cloud (Singapore).

- **Phase 2:** Phase 2 was initiated on one of the two on-premises HoneyShells nine months after the first phase was initiated. The other on-premises HoneyShell kept running in its Phase 1 configuration for comparison purposes. In Phase 2, the top 30 username-password combinations of sessions that executed at least one command after logging in during Phase 1 were accepted as valid authentication credentials; login failure messages were displayed for all other username-password combinations.

The environments provided to attackers were made more meaningful by incorporating new users and filesystems. Additional commands were implemented to attract more activity. Also, Phase 1 logs were analyzed for fingerprinting techniques used by attackers and efforts were made to ensure that the Phase 2 honeypot handled them properly. An example was emulating responses to the file command.

**Does Adaptation Elicit Rich Behaviors?** Figure 2 shows the numbers of hits received by the two on-premises HoneyShells and the Singapore cloud HoneyShell. The Phase 1 on-premises HoneyShell ran from January 2018 to November 2019. The Phase 2 on-premises HoneyShell ran from October 2018 to November 2019; it operated as a Phase 1 honeypot for the first nine months before moving to Phase 2 and ran in parallel with the Phase 1 honeypot. The two on-premises HoneyShell instances operated simultaneously (except for the first
<figure><img src="image_4.png" /><figcaption>Fig. 2. Hits captured by HoneyShells in the two phases.</figcaption></figure>

six months) at the same location with very similar public-facing IP addresses. This made it possible to examine the effects of adapting honeypot responses with as few confounding factors as possible. The Singapore HoneyShell, which ran as a Phase 1 honeypot in the cloud, was deployed from January 2018 to January 2019.

Several observations were made regarding the data collected by the two on-premises HoneyShell instances:

- **Hits:** The on-premises Phase 2 HoneyShell received many more hits than the on-premises Phase 1 HoneyShell. Specifically, the Phase 2 HoneyShell received 10 million hits over 13 months whereas its Phase 1 counterpart received five million hits in 23 months. It appears that the differences in the numbers of hits received were due to the different responses produced by the two honeypots. This is a strong indication that the adaptation implemented in the Phase 2 HoneyShell made it more interesting to attackers.

At first glance, it is questionable that adaptation would increase the number of hits because hits occur before any interactions with a honeypot. However, individual hits may not be totally independent. Multiple hits are very likely to have come from the same attacker or group of attackers. It is likely that a device deemed to be fake by attackers would be blacklisted and ignored, resulting in few hits.

- **Sessions:** Many more sessions were established with the on-premises HoneyShell during Phase 2 compared with Phase 1. Specifically, there were 2,933,646 sessions in Phase 2 compared with 1,314,465 sessions in Phase 1.
This is another indicator that attackers were drawn to the adapted Phase 2 HoneyShell.

- **Successful Logins:** The on-premises Phase 2 HoneyShell had many more successful logins than the on-premises Phase 1 HoneyShell. The Phase 2 HoneyShell had 1,311,227 successful logins in 4,919,923 login attempts corresponding to a 27% success rate. In contrast, the Phase 1 HoneyShell had 409,771 successful logins in 2,279,376 login attempts, corresponding to a 18% success rate.

The Phase 2 HoneyShell only accepted the top 30 username-password combinations whereas the Phase 1 HoneyShell accepted all username-password combinations. Despite its stringent password policy, the Phase 2 HoneyShell login success rate of 27% is much higher than the Phase 1 HoneyShell success rate of 18%. This indicates that the Phase 1 login attempts were more indiscriminate, using the wrong protocols and incorrect parameters that resulted in login failures. In contrast, Phase 2 login attempts were much more methodical – the 27% success rate is reasonable given that attackers had to correctly guess one of the 30 accepted username-password to succeed, which would involve multiple failed login attempts.

- **Commands:** Attackers executed various commands after logging into the Phase 1 and Phase 2 HoneyShells. The commands collected by the Phase 1 HoneyShell were dominated by scripted commands such as:

```
echo -e '\x47\\x72\\x6f\\x70/' > //..nippon;
cat //..nippon;
rm -f //..nippon
```

```
uname -a;unset HISTORY HISTFILE HISTSAVE HISTZONE HISTORY HIS
TLOG WATCH;history -n;export HISTFILE=/dev/null;export HISTSI
ZE=0;export HISTFILESIZE=0;cd;mkdir .ssh;rm -rf .ssh/authoriz
ed_keys;touch .ssh/authorized_keys;echo 'ssh-rsa AAAAB3NzaC1y
c2EAAAABJQAQAQEAvN5GkpS25Z9eA2bARaXTVfVN2m/N5V5dd0TyVPftA3lj
o rQitmh1pyuZDty9oTWF+J0c0tGBvRaQ7NvZCaDC2q6QR0iM0fq7zs+4b18W08
UnaQcVVIBeEt3YPo8PXwVm5fR4wgoq9SZp29/2jFz0UmA0hiUyImh9/P7jFW
qpv3gSxZ8neq+4pSCUfE240GiFBpJGkAE+wMmJcBXOWjFfjedcbBs1FO/C+x8
WY9bFkQ3NnwjVbh3c3mYy9zqdPhm6GI/heVAZUWSKHausOwb+Rem+eKhkrKv
oeteqJXEIr1LbHyRhn+12nN/qgG5kIcICv4TRD59GHMYZH3ILngyFJQ==' >>
.ssh/authorized_keys;cd
```

The first sample above was one of 1,128 occurrences produced by the Mirai botnet with 1,128 occurrences. In the second sample above, the attacker disabled shell history logging and attempted to plant an SSH public key on the server. The type of command and its large number of occurrences (562) indicate that the sample was likely due to an automated script.

In contrast, the commands collected by the Phase 2 HoneyShell comprised fewer scripted commands and commands from known botnets such as Mirai.

In fact, many commands collected by the Phase 2 HoneyShell resembled human actions, such as the following three independent commands:
<table><caption>**Table 2.** Top ten username-password combinations captured by HoneyShells.</caption><thead><tr><th>Username/Password Occurrences</th><th></th></tr></thead><tbody><tr><td>admin/1234</td><td>975,729</td></tr><tr><td>root/(empty)</td><td>167,869</td></tr><tr><td>admin/(empty)</td><td>82,018</td></tr><tr><td>0/(empty)</td><td>62,140</td></tr><tr><td>(empty)/root</td><td>52,780</td></tr><tr><td>1234/1234</td><td>50,305</td></tr><tr><td>admin/admin</td><td>39,349</td></tr><tr><td>admin/1234567890</td><td>12,444</td></tr><tr><td>root/admin</td><td>10,359</td></tr></tbody></table>

```
ls -la /var/run/gcc.pid
```

```
ifconfig
```

```
rm -rf /var/tmp/dota*
```

The Phase 1 HoneyShell had very few such commands. Clearly, the Phase 2 HoneyShell commands are more interesting and more of them are likely due to direct human actions than automated programs.

Analysis of the data collected by the on-premises Phase 1 HoneyShell and Phase 1 HoneyShell deployed in the Singapore cloud indicated they had similar characteristics in terms of command patterns. In fact, the vast majority of commands collected by the two Phase 1 HoneyShells appeared to be issued by automated programs.

**HoneyShell Statistics** Most of the logins used random username-password combinations, which indicates that automated scripts were used to guess the correct credentials. Table 2 shows the top ten username-password combinations used by attackers. The login data indicates that attackers preferentially targeted users with high privileges and weak passwords. However, other username-password combinations such as university-florida, root-university and university-student were used on the on-premises honeypot located at a university. This indicates that attackers were aware that the honeypot was located at a university and attempted to customize their attacks accordingly.

Only 314,112 (13%) unique sessions were detected with at least one successful honeypot command execution. This indicates that only a small proportion of the attacks proceeded to the next attack step. Also, the remaining (87%) attacks focused on discovering a correct username-password combination.

Table 3 provides information about the files captured by the HoneyShells. A total of 236 unique files were collected. In all, 46% of the downloaded files were collected by the on-premises university honeypots whereas the remaining 54% were collected by the Singapore cloud honeypot. VirusTotal flagged all the collected files as malicious.
<table><caption>**Table 3.** Downloaded files captured by HoneyShells.</caption><thead><tr><th>Malicious File Campaign Count</th></tr></thead><tbody><tr><td>DoS/DDoS</td></tr><tr><td>IRCBot/Mirai</td></tr><tr><td>Shell Downloader</td></tr><tr><td>Backdoor</td></tr><tr><td>CoinMiner</td></tr><tr><td>Others</td></tr></tbody></table>

Denial-of-service and distributed-denial-of-service executables were the most common files. IRCBot/Mirai and Shell Downloader were the second most common files. This demonstrates that Mirai, which surfaced in 2016, is still an active botnet and continues to attempt to add more devices to its botnet. As expected, Shell Downloader attempted to download files in various formats that execute on operating system architectures such as x86, ARM, i686 and MIPS. Often, adversaries gained access in their first attempt and proceeded to run all the executable files. The Others category in Table 3 includes SSH scanner, mass scan and Domain Name System (DNS) poisoning executables.

<table><caption>**Table 4.** Top ten commands captured by the Phase 2 HoneyShell.</caption><thead><tr><th>Command</th><th>Occurrences</th></tr></thead><tbody><tr><td>/gisdfoewrsfdf</td><td>1,243</td></tr><tr><td>mount ;/gisdfoewrsfdf</td><td>1,240</td></tr><tr><td>/bin/busybox cp; /gisdfoewrsfdf'</td><td>1,240</td></tr><tr><td>cat /proc/cpuinfo | grep name | wc -l</td><td>1,024</td></tr><tr><td>sudo /bin/sh</td><td>819</td></tr><tr><td>ls -la /var/run/gcc.pid</td><td>765</td></tr><tr><td>uname -a</td><td>248</td></tr><tr><td>cat /proc/cpuinfo</td><td>204</td></tr><tr><td>/ip cloud print</td><td>165</td></tr><tr><td>ifconfig</td><td>162</td></tr></tbody></table>

In addition to placing files in the HoneyShells, attackers attempted to execute numerous commands. Table 4 shows the top ten commands captured by the Phase 2 HoneyShell along with their occurrences. The top three commands in the table were issued by the Mirai botnet.
## 4.2 Adapting Honeypots to Device Types

An Internet of Things camera (D-Link) was chosen for the honeypot emulation of an Internet of Things device. The first HoneyCamera instance was placed in the cloud infrastructure. Phase 1 data was used to identify the possible weaknesses of HoneyCamera. The collected data was used to adapt the HoneyCamera configuration in its Phase 2 implementation. The following paragraphs provide details about the two phases:

- **Phase 1:** Three HoneyCamera instances were deployed. Two instances, which were deployed in the cloud in Sydney and Paris, only had port 8080 open. The third instance deployed in the cloud in London only had port 80 open. The first two HoneyCamera instances emulated D-Link DCS-5020L cameras and the third instance emulated a D-Link DCS-5030L camera. The HoneyCamera instances were configured as interaction-based honeypots to collect as much data as possible. The vetting system identified the three HoneyCamera instances as real Internet of Things devices. Data collected during Phase 1 indicated that attackers were attempting to exploit known vulnerabilities in Internet of Things cameras.

- **Phase 2:** The data collected in Phase 1 revealed that attackers attempted to exploit six HoneyCamera vulnerabilities, the most common being authentication information leakage. These vulnerabilities were carefully studied and the corresponding responses were incorporated in the Phase 2 HoneyCamera instances. Additionally, the Internet of Things cameras were equipped with SSH/Telnet ports for remote configuration and diagnostics. In order to replicate these activities, the HoneyShell and HoneyCamera implementations were integrated and deployed as single instances in the on-premises and cloud (Tokyo) infrastructures. The integrated instances were able to identify attacker behavior involving Unix command-line and camera-specific commands.

Six Internet of Things camera devices were emulated as HoneyCamera instances. Attackers attempted to install several malicious files on the honeypots, mainly CoinMiner and Mirai variants. Analysis of the captured logs revealed that the honeypots attracted many attacks that specifically targeted Internet of Things cameras. The following are some example attacks:

- The first attack sought to brute force the camera credentials (`/?action=str eam/snapshot.cgi?user=[USERNAME]&pwd=[PASSWORD]&count=0`). The attackers attempted to obtain a correct username-password combination to access a video streaming service.

- The second attack sought to exploit the CVE-2018-9995 vulnerability to bypass camera credentials using a `Cookie: uid=admin` header and gain access to the camera (`/device.rsp?opt=user&cmd=list`).

- Table 5 shows additional types of attacks executed on the HoneyCamera instances. The data collected from the honeypots revealed that the targets included D-Link, Hikvision, Netwave, AIVI, IP and Foscam cameras.
<table><caption>**Table 5.** Attack types executed on HoneyCamera instances.</caption><thead><tr><th colspan="2">HoneyCamera Instance Attack</th></tr></thead><tbody><tr><td>DLINK Camera</td><td>CVE-2013-1599</td></tr><tr><td>Hikvision IP Camera</td><td>Bypass Authentication</td></tr><tr><td>Netwave IP Camera</td><td>Password Disclosure</td></tr><tr><td>AIVI Tech Camera</td><td>Command Injection</td></tr><tr><td>IP Camera</td><td>Shellshock</td></tr><tr><td>Foscam IP Camera</td><td>Bypass Authentication</td></tr><tr><td>All Instances</td><td>Malicious Activity</td></tr></tbody></table>

**Does Adaptation Elicit Rich Behaviors?** A vulnerability that attackers leveraged to target the HoneyCamera was identified in Phase 1. The vulnerability, Exploit-DB ID-38853, enabled the exploitation of the web interface login page to view the username and password.

The Phase 2 honeypot implemented the correct response to the vulnerability, revealing the username and password for the login page. The vulnerable page was instrumented so that an exploit attempt would reveal the username and password in an image on the HTML page, which a human could not distinguish from what would be presented by a real Internet of Things camera.

Log file analysis revealed that attacks originating from 29 IP addresses exploited the vulnerability and successfully logged into the HoneyCamera web console using the username and password displayed in the image. The pattern of attacker movements between web pages and the fact that the username and password were embedded in an image that could be read by humans (machine recognition would be extremely unlikely) indicate that the activities were performed by humans as opposed to automated programs.

## 4.3 Summary

The experiments involving the three Internet of Things honeypot facets, HoneyShell, HoneyWindowsBox and HoneyCamera, revealed a consistent pattern – more malicious traffic was seen when the honeypots were adapted based on the observed traffic to provide attackers with information they would want to see. In all the experiments, richer attacker behaviors were discerned, such as more logins and human-like commands in the HoneyShell instance and human attack activities in the HoneyCamera instances.

# 5 Data Analytics

The third research question sought to investigate if the data captured by honeypots embodies patterns that enable security analysts to understand the intentions of human attackers. Analysis of the data revealed that the honeypot instances collected huge amounts of attack activities, most of them belonging
to a few categories. Also, activities in the same category had similarities. This inspired the application of an unsupervised clustering approach to gain insights into attacker activities before attempting to discern attacker intentions.

## 5.1 Clustering Captured Commands

This section describes the similarity metric used for clustering and the clustering approach.

**Similarity Metric** The deployed honeypots captured large numbers of commands of varying lengths in SSH login sessions. Cosine similarity was selected as the metric for determining the similarity between two commands. It measures the cosine of the angle between two vectors – in this case, command embeddings – in multidimensional space. Frequency-based embedding was employed, where each vector component represents the number of occurrences of a given word in the command text. A smaller angle means a higher similarity value.

The similarity between two vectors **A** and **B** is computed as:

$$ \text{similarity}(\mathbf{A}, \mathbf{B}) = \frac{\mathbf{A} \cdot \mathbf{B}}{\|\mathbf{A}\| \|\mathbf{B}\|} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \sqrt{\sum_{i=1}^{n} B_i^2}} $$

where $A_i$ and $B_i$ are components of vectors **A** and **B**, respectively.

Similarity values range from zero to one. A similarity value of zero means that the two vectors are orthogonal and have no similarity. The closer a similarity value is to one, the smaller the angle and the greater the match between the two vectors.

As an example, consider the two commands:

- Command A: `cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq -c`

- Command B: `cat /proc/cpuinfo | grep name | head -n 1 | awk {print $4, $5, $6, $7, $8, $9;}`

Executing Commands A and B on a real device reveals that both commands provide similar information. However, the manner in which the two commands are parsed and represented can lead to very different cosine similarity results:

- Case 1: Assume that all the commands, command options, variables and positional parameters are included in the word vocabulary. The unique vocabulary for Commands A and B is:

* `[awk, cat, cpuinfo, cut, f2, grep, head, print, proc, uniq, -n, -d, -c, 1, 4, 5, 6, 7, 8, 9]`

The similarity value of Commands A and B is 0.3953.

- Case 2: Assume that all the commands and command options are included in the word vocabulary. However, command variables and positional parameters are not included in the word vocabulary. In this case, the unique vocabulary for Commands A and B is:
* `[awk, cat, cpuinfo, cut, f2, grep, head, print, proc, uniq, -n, -d, -c]`

The similarity value for Commands A and B is 0.5270.

- **Case 3:** Assume that only the commands are included in the word vocabulary. In this case, the unique vocabulary for Commands A and B is:

* `[awk, cat, cpuinfo, cut, grep, head, print, proc, uniq]`

The similarity value for Commands A and B is 0.6249.

The example demonstrates that command options and variables possess low relevance with regard to command similarity. Further analysis of the data revealed that IP addresses and port numbers also have low relevance. Therefore, command options and variables were ignored and IP addresses and port numbers were replaced by dummy values in a data pre-processing step before computing the command similarity values.

**Clustering Approach** Five clustering approaches, *k*-means clustering, agglomerative hierarchical clustering, spectral clustering, density-based spatial clustering of applications with noise (DBSCAN) and Gaussian mixture model (GMM) clustering, were investigated to find a suitable model that fitted the data. Except for agglomerative hierarchical clustering and DBSCAN, all the other clustering approaches require the *a priori* specification of the number of clusters *k*. The silhouette coefficient method was employed to determine the cluster number *k* that would partition the commands into clearly distinguishable clusters.

The first set of experiments focused on the commands collected by the Singapore HoneyShell. After evaluating the five clustering approaches with their optimal *k* values, it was determined that GMM clustering with *k* = 150 partitioned the commands into the most meaningful clusters.

Following the same approach, the optimal cluster numbers *k* were computed for the larger on-premises data. The results revealed that GMM clustering with *k* = 250 produced the most meaningful command clusters in reasonable time. Next, the unique commands in each cluster were examined to determine if they could be merged into larger clusters based on similar activities. Ultimately, the 526 unique commands were grouped into 41 clusters.

The objectives behind each cluster were identified. Some commands had multiple subcommands and attackers executed them together in single composite commands. Such composite commands were clustered with other commands that shared some, but not all, characteristics. Thus, clusters were labeled with multiple objectives, but not every command in the clusters met all the cluster objectives. Interested readers are referred to www.arguslab.org/honeyshell-clusters.html for details about the clusters, including their objectives and constituent commands.

## 5.2 Clustering Results

To experiment with the clustering approach, all the commands executed by attackers were extracted from the Singapore HoneyShell logs and clustered. Fig-
<figure><img src="image_5.png" /><figcaption>Fig. 3. Unique commands in each cluster (Singapore).</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Fig. 4. Occurrences of commands in each cluster (Singapore).</figcaption></figure>

ure 3 shows the distribution of the numbers of unique commands found in each cluster.

Figure 4 shows the occurrences of commands executed in each cluster corresponding to the Singapore HoneyShell logs. The vast majority of commands (79%) belong to just five clusters that contain 5, 17, 28, 29, 41 commands, respectively. Some of these clusters correspond to activities from the Mirai botnet and its variants. The others correspond to fingerprinting.

The same clustering experiments were performed on commands from the on-premises HoneyShell logs. Figure 5 shows the distribution of the numbers of unique commands found in each cluster. Figure 6 shows the occurrences of commands executed in each cluster.

# 6 Conclusions

The adaptive Internet of Things honeypot ecosystem presented in this chapter is a first step towards understanding human attacker behaviors targeting Internet of Things devices. Analysis of the data collected by the honeypot ecosystem over more than three years reveals that adversaries are actively looking for vulnerable Internet of Things devices to exploit. The results also demonstrate that adapting honeypot responses based on observed attacker activities elicits and captures increasingly sophisticated attacker behaviors, far exceeding the capabilities of a
<figure><img src="image_7.png" /><figcaption>Fig. 5. Unique commands in each cluster (on premises).</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Fig. 6. Occurrences of commands in each cluster (on premises).</figcaption></figure>

non-adaptive honeypot. Additionally, a clustering approach developed to understand the large number of attacker-executed commands captured by the Internet of Things honeypot ecosystem provides valuable insights into attacker intentions and modes of operation.

Commercial products are identified in this chapter in order to adequately specify certain procedures. In no case does such identification imply a recommendation or an 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.

## References

1. Akamai Technologies, UPnProxy: Blackhat Proxies via NAT Injections, Akamai White Paper, Cambridge, Massachusetts, 2018.

2. M. Anirudh, S. Thileeban and D. Nallathambi, Use of honeypots for mitigating DoS attacks targeted on IoT networks, *Proceedings of the International Conference on Computer, Communications and Signal Processing*, 2017.

3. M. Antonakakis, T. April, M. Bailey, M. Bernhard, E. Bursztein, J. Cochran, Z. Durumeric, J. Halderman, L. Invernizzi, M. Kallitsis, D. Kumar, C. Lever, Z. Ma, J. Mason, D. Menscher, C. Seaman, N. Sullivan, K. Thomas and Y. Zhou,
Understanding the Mirai botnet, *Proceedings of the Twenty-Sixth USENIX Security Symposium*, pp. 1093–1110, 2017.

4. A. Anubhav, Masuta: Satori creators' second botnet weaponizes a new router exploit, *NewSky Security*, January 23, 2018.

5. S. Chamotra, R. Sehgal, S. Ror and B. Singh, Honeypot deployment in broadband networks, *Proceedings of the International Conference on Information Systems Security*, pp. 479–488, 2016.

6. S. Dowling, M. Schukat and H. Melvin, A ZigBee honeypot to assess IoT cyberattack behavior, *Proceedings of the Twenty-Eighth Irish Signals and Systems Conference*, 2017.

7. S. Edwards and I. Profetis, Hajime: Analysis of a Decentralized Internet Worm for IoT Devices, Technical Report, Rapidity Networks, Boulder, Colorado, 2016.

8. J. Guarnizo, A. Tambe, S. Bhunia, M. Ochoa, N. Tippenhauer, A. Shabtai and Y. Elovici, SIPHON: Towards scalable high-interaction physical honeypots, *Proceedings of the Third ACM Workshop on Cyber-Physical System Security*, pp. 57–68, 2017.

9. M. Hakim, H. Aksu, A. Uluagac and K. Akkaya, U-PoT: A honeypot framework for UPnP-based IoT devices, *Proceedings of the Thirty-Seventh IEEE International Performance Computing and Communications Conference*, 2018.

10. P. Hanson, L. Truax and D. Saranchak, IoT honeynet for military deception and indications and warnings, in *Autonomous Systems: Sensors, Vehicles, Security and the Internet of Everything*, M. Dudzik and J. Ricklin (Eds.), International Society for Optics and Photonics (SPIE), Bellingham, Washington, pp. 106431A-1-106431A-11, 2018.

11. R. Joven and K. Yang, A wicked family of bots, *Fortinet Blog/ Threat Research*, May 17, 2018.

12. B. Lingenfelter, I. Vakilinia and S. Sengupta, Analyzing variations among IoT botnets using medium interaction honeypots, *Proceedings of the Tenth Annual Computing and Communications Workshop and Conference*, pp. 761–767, 2020.

13. E. Lopez-Morales, C. Rubio-Medrano, A. Doupe, Y. Shoshitaishvili, R. Wang, T. Bao and G. Ahn, *Proceedings of the ACM SIGSAC Conference on Computer and Communications Security*, pp. 279–291, 2020.

14. T. Luo, Z. Xu, X. Jin, Y. Jia and X. Ouyang, IoTCandyJar: Towards an intelligent-interaction honeypot for IoT devices, presented at *Black Hat USA*, 2017.

15. M. Nawrocki, M. Wahlisch, T. Schmidt, C. Keil and J. Schonfelder, A Survey of Honeypot Software and Data Analysis, arXiv: 1608.06249 (arxiv.org/abs/1608.06249), 2016.

16. A. Oza, G. Kumar, M. Khorajiya and V. Tiwari, Snaring cyber attacks on IoT devices with a honeynet, in *Computing and Network Sustainability*, S. Peng, N. Dey and M. Bundele (Eds.), Springer, Singapore, pp. 1–12, 2019.

17. Y. Pa, S. Suzuki, K. Yoshioka, T. Matsumoto, T. Kasama and C. Rossow, IoT-POT: Analyzing the rise of IoT compromises, *Proceedings of the Ninth USENIX Workshop on Offensive Technologies*, 2015.

18. A. Pauna, I. Bica, F. Pop and A. Castiglione, On the rewards of self-adaptive IoT honeypots, *Annals of Telecommunications*, vol. 74(7-8), pp. 501–515, 2019.

19. T. Seals, IoT attacks skyrocket, doubling in 6 months, *Threatpost*, September 6, 2021.

20. Security Response Team, ISTR 23: Insights into the cyber security threat landscape, *Symantec Enterprise Blogs/Threat Intelligence*, March 21, 2018.

21. Security Response Team, VPNFilter: New router malware with destructive capabilities, *Symantec Enterprise Blogs/Threat Intelligence*, May 23, 2018.
22. H. Semic and M. Sasa, IoT honeypot: A multi-component solution for handling manual and Mirai-based attacks, *Proceedings of the Twenty-Fifth Telecommunications Forum*, 2017.

23. A. Tabari, X. Ou and A. Singhal, What are Attackers After on IoT Devices? An Approach Based on a Multi-Phased Multi-Faceted IoT Honeypot Ecosystem and Data Clustering, arXiv: 2112.10974v1 (arxiv.org/abs/2112.10974v1), 2021.

24. A. Vetterl and R. Clayton, Honware: A virtual honeypot framework for capturing CPE and IoT zero days, *Proceedings of the APWG Symposium on Electronic Crime Research*, 2019.

25. B. Wang, Y. Dou, Y. Sang, Y. Zhang and J. Huang, IoTCMal: Towards a hybrid IoT honeypot for capturing and analyzing malware, *Proceedings of the IEEE International Conference on Communications*, 2020.

26. M. Wang, J. Santillan and F. Kuipers, ThingPot: An Interactive Internet-of-Things Honeypot, arXiv: 1807.04114 (arxiv.org/abs/1807.04114), 2018.