Intrusion Attack & Anomaly

Detection in IoT using Honeypots

Linus Kulle

Bachelor’s Thesis in Computer and Information Sciences

End Seminar: August 28 2020
180 Credits
Malmö University Spring 2020
Supervisor: Victor Kebande
-0-
Examiner: Joseph Bugeja
Abstract
This thesis is presented as an artifact of a project conducted at Malmö
University IoTaP LABS. The Internet of Things (IoT) is a growing field and its use
has been adopted in many aspects of our daily lives, which has led to
digitalization and the creation of smart IoT ecosystems. However, with the rapid
adoption of IoT, little or no focus has been put on the security implications,
device proliferations and its advancements. This thesis takes a step forward to
explore the usefulness of implementing a security mechanism that can
proactively be used to aid understanding attacker behaviour in an IoT
environment. To achieve this, this thesis has outlined a number of objectives
that ranges from how to create a deliberate vulnerability by using honeypots in
order to lure attacker’s in order to study their modus operandi. Furthermore,
an Intrusion Attack Detection (Model) has been constructed that has aided with
this implementation. The IAD model, has been successfully implemented with
the help of interaction and dependence of key modules that have allowed
honeypots to be executed in a controlled IoT environment. Detailed descriptions
regarding the technologies that have been used in this thesis have also been
explored to a greater extent. On the same note, the implemented system with
the help of an attack scenario allowed an attacker to access the system and
circumnavigate throughout the camouflaged network, thereafter, the attacker’s
footprints are mapped based on the mode of attack. Consequently, given that
this implementation has been conducted in MAU environment, the results that
have been generated as a result of this implementations have been reported
correctly. Eventually, based on the results that have been generated by the
system, it is worth to note that the research questions and the objective posed
by the thesis have been met.

-1-
Acknowledgement

This thesis has been completed with the help of personnel at MAU Faculty of
Society and Technology. A special thanks to MAU IT department for providing
space and equipment used to host the environment and the IoTaP research as
a whole. I also want to thank my supervisor: Victor Kebande, who has guided
me along the way throughout the length of the project.

-2-
-3-
Table of content

Contents
List of Figures ............................................................................................ - 1 -
List of Abbreviations .................................................................................. - 2 -
List of Tables.............................................................................................. - 3 -
Chapter 1: Introduction ........................................................................... - 4 -
1.1 Introduction ................................................................................. - 4 -
1.2 Statement of the Problem ............................................................. - 5 -
1.3 Motivation .................................................................................... - 6 -
1.4 Research Objectives ..................................................................... - 6 -
1.5 Methodology ................................................................................. - 7 -
1.6 Contributions ............................................................................... - 7 -
1.7 Thesis Layout ............................................................................... - 8 -
1.8 Conclusion ................................................................................... - 8 -
Chapter 2: Background ............................................................................ - 8 -
2.1 Internet of Things (IoT) ................................................................. - 9 -
2.2 Honeypots ...................................................................................- 10 -
2.2.1 Low-Interaction Honeypots (LIH) .................................................................... - 10 -
2.2.2 High-Interaction Honeypots (HIH)................................................................... - 11 -
2.2.3 Medium-Interaction Honeypot (MIH) ............................................................. - 13 -
2.2.4 Production/Research Honeypots .................................................................... - 13 -
2.3 Security Issues in IoT ..................................................................- 14 -
2.3.1 Intrusion Attacks ............................................................................................. - 14 -
2.4 Conclusion ..................................................................................- 16 -
Chapter 3: Intrusion Attack Detection (IAD) Model ..............................- 17 -
3.1 Introduction .................................................................................- 17 -
3.2 Intrusion Attack Detection Model .................................................- 17 -
3.2.1 High-Level View of IAD Model ......................................................................... - 18 -
3.2.2 Detailed Description of the System ................................................................ - 18 -
3.2.3 The Intrusion Attack Detection Model in its Entirety ..................................... - 19 -
3.2.4 Module 1: Simulated Environment ................................................................. - 20 -
3.2.5 Module 2: Host Environment .......................................................................... - 21 -
3.2.6 Module 3: Surface Environment ..................................................................... - 22 -

-4-
 3.3 Conclusion ...................................................................................- 22 -
Chapter 4: Implementation and Results ................................................- 23 -
4.1 Introduction ................................................................................- 24 -
4.2 Intrusion Attack Detection (IAD) Implementation ........................- 24 -
4.2.1 Relationships among Implemented IAD Modules........................................... - 24 -
4.3 Honeypot Implementation ...........................................................- 26 -
4.4 Experimental Results ..................................................................- 26 -
4.4.1 Attack scenario ................................................................................................ - 26 -
4.4.2 State-of-the-art Attacks................................................................................... - 28 -
4.4.3 Results Regarding the Simulated Environment ............................................... - 28 -
4.4.4 Detected Attacks ............................................................................................. - 33 -
4.5 Conclusion ..................................................................................- 35 -
Chapter 5: Analysis and Discussion .......................................................- 36 -
5.1 Introduction ................................................................................- 36 -
5.2 Analysis of the Results ................................................................- 36 -
5.2.1 Research Questions and Answers ................................................................... - 37 -
5.2.2 Research Objectives ........................................................................................ - 38 -
5.2.3 Discussion of the Actual Results ...................................................................... - 39 -
5.3 Discussion of the propositions......................................................- 40 -
Chapter 6: Conclusion ............................................................................- 43 -
6.1 Summary and conclusion ............................................................- 43 -
6.2 Future work ................................................................................- 43 -
References ...............................................................................................- 45 -

-5-
List of Figures

Figure 2.1. Low-Interaction-Honeypot attack flow.

Figure 2.2 High-Interaction-Honeypot attack flow.

Figure 3.1. A high-level description of the system and its modules.

Figure 3.2. A detailed system overview of the model framework.

Figure 4.1. Diagram showing the implemented structure in relation to the

modules.

Figure 4.2. Attackers path in the attack scenario.

Figure 4.3. BevyWise dashboard showing the active devices and real-time
traffic.

Figure 4.4. A look into how a simulated device is set up.

Figure 4.5. Sample data packet sent to a simulated device.

Figure 4.6. How the data looks like from the moderator’s perspective.

Figure 4.7. The BevyWise Broker command prompt.

Figure 4.8. Example of a failed and successful login attempt.

Figure 4.9. Attempted logins seen through Splunk.

Figure 4.10. An example of a successful login session.

Figure 4.11. Scenario step 1, showing the connection log.

Figure 4.12. Commands used by the attacker to explore the system.

Figure 4.13. Commands used by the attacker to download and run malicious
code.

-1-
List of Abbreviations

ADS: Anomaly Detection System

CIA: Confidentiality, Integrity, Availability

DDOS: Distributed Denial of Service

DTK: Deception Toolkit

HIH: High-Interaction-Honeypot

HTML: Hypertext Markup Language

IAD: Intrusion Attack Detection

IDS: Intrusion Detection System

IoT: Internet of Things

IP: Internet Protocol

LIH: Low-Interaction-Honeypot

MAU: Malmö University

MIH: Medium-Interaction-Honeypot

MQTT: Message Queueing Telemetry Transport

PSAD: Port Scan Attack Detector

PrivEsc: Privilege Escalation

RDP: Remote Desktop Protocol

SSH: Secure Shell

STRIDE: Spoofing, Tampering, Repudiation, Integrity, Denial of Service,

Elevation of Privileges

VIP: Virtual Internet Protocol

VLAN: Virtual LAN

-2-
List of Tables

Table 5.1 Research Questions and Answers.

Table 5.2 Research Objectives and Answers.

Table 5.3 Attacks and Descriptions.

-3-
 Chapter 1: Introduction

1.1 Introduction

Advances in the Internet of Things (IoT) field and connectivity have become more
prevalent over time in the past decade and it is predicted to keep rising in the
future with the current prediction standing at over 20 billion devices in 2020
[1]. This technology has been implemented in many areas due to the availability
of low-cost sensing techniques and as a result of miniaturization and
pervasiveness of the internet [2]. Currently, this has been achieved in almost all
areas and has led to the development of smart “things” like smart transport,
smart cities, smart health, smart agriculture, smart home, smart universities
etc. The importance of this has been the rapid interactions and effective
interoperability of people, things, and infrastructures [3][4]. Consequently, the
device that you have in your home does not differ from the ones used by major
corporations neither in security nor vulnerability.

While it is important to note that the continuous growth of IoT comes with a
more positive side, it is also important to acknowledge that the heterogeneity
has also seen a number of formidable security-related challenges. The core
challenge as this technology becomes more and more common to people and
companies, is the increase of security related threats and attacks [5]. IoT devices
have on multiple occasions been the keystone of botnet attacks where threat
agents enslave vast number of vulnerable devices in order to preform malicious
actions such as DDoS attacks [6]. Most of the connected IoT ecosystems are
more susceptible to attacks because of the amount of data that is generated and
transferred between devices and people. This is owing to the fact that; the threat
landscape and attack techniques are both becoming more sophisticated each
day.

There is a constant need to anonymously detect suspicious and conspicuous

activity in the IoT landscape, based on the data that is generated by these
devices, for example, by trying to understand attack patterns and motives of the
attacker through deception.

-4-
In any typical intrusion system, triggers will be in place to aid in the detection
of any malice, abnormal or suspicious activity. It is desirable to master the
footprints or attack paths that attackers follow in this perspective by detecting
an attack in real-time.

Honeypots and anomaly detection have been prevalent in information security

in the past to one degree or another. Honeypots have been a staple in
understanding threat agent’s patterns and techniques and have given security
researchers the opportunity to understand how a vulnerability is being exploited
and what to do to protect their assets after the fact.

1.2 Statement of the Problem

The increase of devices, sensor platforms and IoT in general has increased the
security concerns of these systems. These concerns consist of threats, attacks,
and vulnerable endpoints that require in depth analysis to understand their
existence in order to deploy countermeasures. Attackers can easily invade these
platforms which in real-life are part of our daily lives which allows them to
control a multitude of diverse smart ecosystems. Adopting IoT in various
ecosystem means that we need to be aware of the trade-off between the privacy
of these platforms and the security involved. It is possible for attackers to
remotely control these devices or compromise their security.

Therefore, the problem that is being addressed in this thesis, is that there lacks
an effective way of detecting attacks over IoT without learning the attacker’s
patterns or motives. The proposed work pinpoints effective strategies of attack
detection where honeypots are employed coupled with anomaly detection
techniques. As a result, the research questions are formulated in a matter to
look at the following two factors:

• Can intruder’s attack patterns be detected in IoT environment?

• Can honeypots be used as decoys to help discover intruder’s footprints
in an IoT environment?

-5-
 1.3 Motivation

The concern in an IoT connected environment is the complexity of attacks,

changes in attack patterns, and scheme [7]. Failure to address these concerns
from the security perspectives always leads to detrimental effects and creates
more vulnerable environment. There is currently a rise in cyber-related
incidents and increased complexity from attacker’s point of view. On the other
hand, most honeypots by themselves do not apply anomaly detection
approaches and are not specific to what attacks needs to be detected. The ability
to analyse and prevent attacks in real time gives security researchers and
specialists an upper hand in the constant struggle to protect an organization’s
asset. By monitoring the attacker’s behaviour and modus operandi, tailor made
countermeasures can be developed for every new zero-day attack. To counter
the aforementioned, the work presented in this thesis, therefore, proposes the
solution of leveraging honeypots to analyse anomalies and patterns based on
the data generated by honeypots.

1.4 Research Objectives

This thesis aims to identify suitable techniques of attack detections in IoT

environment using honeypots by developing a prototype as a proof of concept.
The findings from this thesis will be used to practically further research in the
field of intrusion attack detection in the IoT field. Therefore, the specific
objectives of this project are as follows:

• To conduct state-of-the-art IoT attacks in IoT

• To use honeypots to aid in attack detection in an IoT environment
• To develop a prototype as a proof of concept

The core objective of the project outlined in this thesis is to build an IoT-based
honeypot that captured attackers’ patterns and then evaluate the extracted data
for usefulness as far as intrusion detection is concerned.

-6-
 1.5 Methodology

This thesis has been presented in several steps. Firstly, in order to understand
how honeypots, operate and how their architecture operates, a literature review
on the state-of-the-art of honeypots is carried out. In order to understand how
honeypots could work, an IAD model is then developed, which sets the stage for
experimentation. Experiments are designed, which are then implemented
through a simulated approach as a proof of concept that ultimately has the goal
of gathering information needed in an intrusion detection approach. Based on
the data that is gathered an analysis is then conducted. This analysis allows for
identification of malicious behaviour.

To achieve the research objectives stated in the study, a proof-of-concept

prototype is developed, implemented and evaluated through a live experiment.

1.6 Contributions

This work proposes techniques of detecting attacks by designing an intrusion

detection system by leveraging honeypots in an IoT environment. This then
builds upon and works together with anomaly detection to be able to analyse
the data that is generated by the honeypots. The main contribution of this
project are as follows:

1. To use honeypots as a means of improving attack and anomaly detection

in an IoT environment. Honeypots in IoT allows for a safe medium where
attackers acts can be analysed and understood. It is crucial to study this
in order to develop intrusion attack and anomaly detection methods.
2. Implement anomaly detection to detect and categorize anomalies and
intrusion attempts. Allowing for real-time autonomous detection.
3. To analyse and understand attacks and anomalies in a live IoT
environment. To study how the attacker acts in a simulated environment
and learn from their behaviours.

-7-
 1.7 Thesis Layout

The remainder of this thesis is organized as follows: Background work is covered

in Chapter 2 which gives an insight into IoT, Honeypots, Intrusion attacks and
anomaly detection. Chapter 3 discusses the proposed model and framework
used for intrusion attack detection in IoT. The prototype, findings and results
are presented in Chapter 4. Next, Chapter 5 contains a discussion of the results
and their importance and uses. Finally, the thesis ends with a conclusion in
Chapter 6 which summarizes and concludes the thesis.

1.8 Conclusion

IoT is a rapidly growing market and has expended into almost every section of
our environment and can be found in everything from large scale corporations
to your own home. This expansion of “things” however, also comes with more
complicated security challenges that affect all the users, companies, and private
users alike. This chapter has set the scene of the proposed project by
introducing the statement of the problem, motivation of the study and the
research objectives. Furthermore, the chapter has also outlined the main
contributions that are set to be achieved in this thesis and a layout that gives
the roadmap of the thesis.

Chapter 2: Background

-8-
 2.1 Internet of Things (IoT)

Internet of Things (IoT) represent a large collection of devices of varying

capabilities and appearances, connected to the internet [8]. It can be viewed as
a network of networks communicating with each other. Due to its nature IoT
devices are not strongly standardized and variances occur during connectivity
and based on the technologies used. The technology, however, have enabled a
more intimate connection between human and computer.

The basic anatomy of an IoT device is a special-purpose device, that through an

internet connection transmits and receives data in order to monitor or control a
“thing” [9]. An example is a humidity controller, where a sensor determines the
humidity of a room and sends data to an actuator that controls an air
conditioning unit. The data can also be forwarded to a phone application
notifying you of any changes in humidity.

IoT have become a target due to the fact that the connected “things” usually
handle large amount of data. From the individual sensor to a connected smart
home device, all handle valuable data to some degree. Data and the information
that these devices capture have in the past and will always be a lucrative target
for attackers. IoT also lays the foundation to many DDoS attacks as the devices
themselves are not always monitored. IoT generally faces a number of security
and privacy challenges and there is a constant need for developing mitigation
strategies based on device levels, how communication is conducted among
devices and the services’ offered [10] , by way of identifying the existing
vulnerabilities in smart connected environments in the perspective of security
[11].

-9-
 2.2 Honeypots

Honeypots as a concept has existed for over 30 years at the time of writing this
thesis, although, they first became publicly available in 1998 with the Deception
Toolkit (DTK) created by Fred Cohen. The DTK’s mission statement was “The
DTK is intended to make it appear to attackers as if the system running TK has a
large number of widely known vulnerabilities.” [20]. Since then, this technology
has moved forward, and new implementations and software become available
every day.

A honeypot is a system configured to run on either hardware or as software with

known implemented vulnerabilities and attack surfaces with which to trap and
lure in attackers [12]. The system over which a honeypot runs is commonly
disguised so that it is inferred that it contains valuable information or access
that can be used to illegally break further into another system or network.
However, it only appears so, to gain the attackers trust while behind the scenes
it listens and logs everything the intruder is executing which can be analysed to
improve security for the actual systems and prevent further similar attacks [12].

There are different categories of honeypots that can be divided according to

various parameters based on its level of interaction [13].

2.2.1 Low-Interaction Honeypots (LIH)

A Low Interaction Honeypot (LIH) is usually limited in its functionality and

interaction with the attacker and may only offer minimum functionality such as
an emulation of an operating system and its services. The main advantages of a
low interaction honeypot lie in its simplicity and the fact that they do not require
many resources and are easily maintained. The implementation of this type of
honeypot generally only require one to install a hypervisor that is able to
emulate the preferred Operating System and setting up a way to monitor the
system as it runs untouched. This method can easily contain or detect any
attacker to the resources that you give the honeypot, therefore, mitigating the
risk of further penetration as the real operating system is never exposed. The

- 10 -
main usage of a low interaction honeypot is generally to track the origin of an
attack rather than the intent or methods [14],[15].

Figure 2.1. LIH attack flow [18]

The figure above describes the attack path available to the attacker when
targeting a LIH. It enters at the disguised front the honeypot puts up to emulate
a service or system from which they have access to the basic components of the
allowed system. In the case of LIH resources are limited and usually lay out of
the attacker’s path.

An example of a LIH is HoneyRJ. It is implemented on a single system occupying

an IP address dedicated solely to the honeypot in order to try and locate the
origin of attackers attacking the system. HoneyRJ is designed with simplicity
and expandability in mind, it logs every connection as if it were malicious and
stores the connection information for later analysis [19].

2.2.2 High-Interaction Honeypots (HIH)

The High Interaction Honeypots (HIH) on the opposite end constitutes a more
complex solution where the attacker interacts with real operating systems
running on physical hardware usually directly tied into the network in proximity

- 11 -
of servers or other vital systems. This solution offers two main advantages
compared to LIH. Firstly, the scope of which the monitoring captures is wide
range as the attacker is interacting with a real fully-fledged system allowing for
more data and patterns to be captured and analysed. This allows for the study
of the attacker’s methods and tactics with which they intend to utilize to gain
further access or preform malicious tasks. The second advantage is that, the
honeypot environment doesn’t assume anything about the attacker as it allows
for full interaction with the system and won’t influence the attacker to perform
certain tasks or actions, instead giving them a wide range of services and
information nodes. This, however, increases the risk of the attacker using the
honeypot as a platform with which to attack the rest of the network and
information nodes. Therefore, precautions are needed to segregate the honeypot
from any vital system disabling the option of unwanted spread to non-Honeypot
systems [14],[15].

Figure 2.2. HIH attack flow. [18]

Figure 2.2 depicts the paths available to an attacker targeting a HIH. Here, the
attacker enters through the simulated front and has access to the full extent of
the operating system and its resources. The Operating System in turn also has
access to nearby machines in the network and can communicate freely.

An example of a HIH is HoneyBow. HoneyBow is built upon the GenIII method

of implementing HIH, the most common one when it comes to HIH. A Gen III

- 12 -
honeynet is made of a containment gateway (Honeywall) that controls the
honeypots [21]. The honeypot can be deployed both physically and virtually and
contains three main building blocks use to capture malware. MwWatcher,
MwFetch and MwHunter. Together they make up an advanced malware
collection and analysis honeypot that can be added on to servers [17].

2.2.3 Medium-Interaction Honeypot (MIH)

A Medium-Interaction-Honeypot is the middle ground where the two other meet.

It is used as an in-between option where analysis and knowledge of the attacker
is necessary but further attacks and large-scale honeypot environments are not.
It offers more interaction to the attacker than the Low-Interaction-Honeypot but
fewer options and functionality than the High-Interaction-Honeypot. Often used
as a specified, controllable option, the MIH can be set up to detect specific
attacks or gather log interaction data on a node in a system. Further, this middle
of the pack option seeks to combine the best of both worlds by offering a higher
level of interaction while still being light and easy to set up and scale. The
honeypot used in this solution falls under this category.

2.2.4 Production/Research Honeypots

Honeypots can also be categorized according to their implementation. In this

category there are two different types: Production Honeypots and Research
Honeypots. Production Honeypots are implemented in organizations to actively
protect in a real operating environment. They are implemented alongside live
infrastructures and are susceptible to attack 24/7. These types of honeypots
are becoming more and more common in organizations as they allow for
intrusion detection and goes well with existing security measures.

Research Honeypots are implemented without the objective of protecting live

systems. They provide a way to study attack patterns and threats and only
provide educational value.

- 13 -
The honeypot used in this experiment and surrounding environment would be
classified as a Research Honeypot as the main objective is to study and
understand attacker’s behaviour in an IoT environment.

In conclusion, therefore, honeypots allow for a tactile way to observe and gather
data regarding attack steps and attacker behavioural patterns which can be
analysed to create signatures and prevent further attacks. Adding this to an IDS
or ADS would help enhance their functionality by allowing for the study of attack
behaviour.

2.3 Security Issues in IoT

Heterogeneity in IoT has led to a number of security challenges and given that
a majority of IoT devices and applications are not proactively designed to deal
with potential breaches, it is important to highlight that a set of vulnerabilities
opens the IoT threat landscape further. While the security goals of such an
ecosystem are to uphold confidentiality, integrity, and availability (CIA) [4], the
same could also be defeated and strengthening the CIA in IoT is a major security
goal that can limit the number of threats. In the context of this thesis we
concentrate on intrusion attacks in IoT and anomaly detection techniques
relevant to the subject.

2.3.1 Intrusion Attacks

Intrusion attacks is an attack that poses a possible threat towards information

confidentiality, integrity, or availability. These attacks in most cases come as
coordinated or targeted attacks, where sometimes they can be experienced in
multiple attacks in a simultaneous manner. Most of these attacks are
propagated by exploiting Spoofing Tampering Repudiation Integrity, Denial-of
Service and Elevation of privilege (STRIDE). Mostly, it is through the open nature
and scalable nature of the internet that makes it vulnerable and an easy attack
platform for intrusion attacks [22] Mostly, attacks targeted towards IoT in this
capacity can be considered as intrusion attacks. The need for Intrusion

- 14 -
Detection Systems (IDS) presents a key component that can be adopted as
defence measures for intrusion attacks. This is owing to the fact that; IDS
possess some monitoring components that could collect data in real time [23].
Common IDS include Snort, Fwsnort, Port Scan Attack detector (Psad). The
architecture of Honeypots qualifies them to have requirements that may be
needed to act as IDS in an IoT environment, this is a consideration that is
explored further on in this thesis. They could also be added as an addition to
IDS’s to further increase their capabilities.

2.3.1.1 Requirements for an IDS

An IDS’s main task is to scan a system or network for malicious activity or

intrusion attempts. In order to function it also has to have a way to collect and
report this data through an event management system. This implies that an IDS
must satisfy some requirements in order for it to accomplish tasks effectively.
According to [26], the following has been pointed out as key requirements that
an IDS should satisfy. Accuracy in detecting attacks, minimal overhead while
collecting or correlating intrusion alerts, scalability where the performance of
the IDS should increase with the size of resources, resilience in the presence of
failures, privacy of sensitive information, self-configuration and the ability to
interoperate with the instances from the same system that are executed across
other IDS.

2.3.1.2 Attacks detected by IDS

Attacks detected by an IDS are commonly discovered during behavioural

monitoring of the device [25]. If, for example a sensors output is increased by
2000% it would raise a flag in the system and be picked up by the IDS. Another
method used to discover attacks is to look for “bad” actions. If a device for
example tries to access restricted data or use commands outside of its toolkit.
Attacks like these can be discovered by looking at logs or implementing
automatic triggers rigged to go off in case of a certain scenario or quota being
filled.

- 15 -
 2.4 Conclusion

IoT represents a vast number of varying connected devices in every sector of the
economy. The IoT devices can be described as a special-purpose devices or
application that through a connection to the internet transmits and receives
data in order to monitor or control a “thing”. The topic of security has grown
substantially the last couple of years and raises questions on how to best protect
such a varying array of connected devices.

A honeypot is a system used to lure attackers by simulating a lucrative target

containing valuable information and is exposed to exploits. Honeypots can be
described as three different categories, Low-Interaction Honeypot (HIH),
Medium-Interaction Honeypot (MIH), and High-Interaction Honeypot (HIH). A
LIH is a honeypot that is easy to implement and only captures connection data,
used to locate the origin of a potential attack. A HIH simulates entire operating
systems and allows for the attacker to roam free in either a virtual or physical
system. HIH is used to monitor attackers’ behaviours and discover Zero-Day. A
MIH is an in between of the two other categories.

- 16 -
Chapter 3: Intrusion Attack Detection (IAD) Model

3.1 Introduction

The previous chapters focused on the introduction and background; however,

this chapter focuses on giving a discussion on the Intrusion attack detection
model that has been followed toward the implementation. This model builds
upon the ability to attain both real-world and controlled test results.
Furthermore, this model allows the system to be built in a manner that allows
it to not only be accessible freely over the internet but also to have a secure
deliberate backdoor that is used by the tester to replicate specific attacks and
patterns.

This chapter also shows how different components interact in an environment

that this attack is implemented, however, more details on implementation will
become apparent in the next chapter of this thesis. This is illustrated by giving
a step-by-step approach on the vulnerable locations within the IoT environment
and how deception can allow detection and analysis of intrusions in real time.
The composition of the model is explained in the following sections.

3.2 Intrusion Attack Detection Model

The intrusion attack detection (IAD) model has been presented and discussed
in two distinct approaches. First, a high-level description of the model in Figure
3.1 is given with the respective components, which is then expanded in a
detailed description in Figure 4.2. It is important to highlight that this
description is important because it gives the reader an abstract view of what
constitutes the work that is being discussed in this thesis.

- 17 -
 3.2.1 High-Level View of IAD Model

This section gives a description of a high-level view of the IAD model, which is
shown in Figure 3. The IAD model is broken down into three distinct modules
each with its own components: The simulated environment, Host environment
and Surface environment. The Simulated Environment holds the simulated IoT
devices and the emulated IoT honeypot disguised to look like a part of an office
network.

Figure 3.1. A high-level description of the system and its modules.

The Host Environment represents the two virtual hosts that hosts the simulated
environment on a segmented VLAN of MAU (Malmö University) faculty network.
Finally, the Surface Environment is where the log files are captured, isolated for
purposes of analysis for possible attack detection. More description on how the
modules that have been shown in Figure 3.1 communicate and operate has been
given in the detailed description section which is given in the next section.

3.2.2 Detailed Description of the System

This section will provide further in-depth description of the different modules in
the system, which is mainly an expansion of the high-level model (modules,
labelled 1 to 3) that was given in Figure 3. However, a description of the model
in its entirety is given first.

- 18 -
 3.2.3 The Intrusion Attack Detection Model in its Entirety

The modules that are labelled 1 to 3 above, when seen as a whole makes up a
simulated system which in real implementation has been hosted on the MAU
network infrastructure. This detailed model consists of a number of modules
that collectively are able through effective communication to detect potential
intrusions and malicious activities from a multitude of sources. Once the
intrusions are detected, the activities are captured and stored as a log file, which
is then analysed in order generate attack patterns for purposes of further
detection. Based on how, the intrusions are captured, it is important to note
that the success of this approach is based on the effective interconnection of the
models’ components. This system model has been constructed to emulate to an
office environment, through which, the management of these intrusions are
done in a more proactive manner. A more detailed representation is given in
Figure 4 and each of the component of Figure 4 is explained next.

Figure 3.2. A detailed system overview of the model framework.

- 19 -
 3.2.4 Module 1: Simulated Environment

Module one consists of the environment in which the honeypot sits and the
environment that the attacker interacts with. This module is made up to look
like an office environment that allows the simulation of IoT devices which could
exist in a real-life counterpart. Module one consists of the following components:
Simulated sensors, honeypot and emulated environment which are described in
the subsections to follow.

3.2.4.1 Simulated Sensors

These devices are able to send relevant data over the network via MQTT so as
to emulate an active environment for the attacker to interact with. MQTT is the
most common Machine-to-Machine communication protocol used by IoT devices
to send data over the network. Additionally, the simulated IoT devices are hosted
on a Windows machine that sits in module two. The devices cannot be access
from this module but can be viewed and interacted with.

The sensors that are being simulated in the implementation ranges from
anything you might find in an office, for example an air conditioning unit,
temperature sensor, motion sensors, humidity, etc. In the proof-of-concept we
implemented AC unit sensor, door sensors, humidity sensor, motion sensor,
temperature sensor, among others.

3.2.4.2 The Honeypot

The honeypot (in the arrow labelled 1 in Figure 4) listens on port 2222 (SSH)
and 2223 (Telnet) for incoming connection attempts. When a connection is
established an attacker will be prompted to the username with which they want
to gain access and a password. The SSH connection only allows for the
username “root” to connect. This is to maintain the illusion of a real system, if
an attacker connected with for example “pfsense” they would think that the
device they gained access to be a gateway and not an IoT device. Both the
username and the password are logged by the honeypot and depending on

- 20 -
whether it was successful or not a shell is presented and gives access to a file
system. The honeypot and its virtual environment are hosted on a Linux
machine. Everything the attacker does from the point where a connection is
established is logged and saved by the honeypot to its Ubuntu host. It can be
access from both the internet and the host system.

3.2.4.3 Emulated Environment

The honeypot itself also sits within an emulated python virtual environment.
This is preferred because it presents a believable façade for the attacker to
interact with it. This is achieved by offering a basic Debian environment with
access to a rudimentary file system and shell access. The file system contains
the default Linux files and directories such as /etc/shadow, /home/user and
/bin/bash.

3.2.5 Module 2: Host Environment

The second module represents the virtual hosts that sit on the MAU VLAN and
defines how and who gains access to the simulated system. It consists of the
following components: Virtual Window Host and Virtual Linux Host, an
explanation about them follows next.

3.2.5.1 Virtual Window Host

Windows 10 machine with an internal IP only has been used as a host. It utilises
port 3389 opened for access via RDP (Remote Desktop Protocol) and is only used
to simulate the IoT environment-that act as a backup location for log files
generated by the honeypot to be stored. The IoT environment is simulated using
a simulation broker (BevyWise) that lets the moderator chose and configure an
amount of IoT devices to simulate and generates MQTT traffic between the
different nodes. The machine also hosts an APACHE server on which it displays
the traffic in real time.

- 21 -
 3.2.5.2 Virtual Linux Host

The Linux, Ubuntu machine is an Ubuntu v. 20.04 machine with ports 22 and
23 open has been used as a virtual host. It also has both an internal and
outwards facing IP accessible from the internet. This machine acts as the host
to the python virtual environment where the honeypot sits and collects data
from the honeypot to send to log files in module three. Its ports 22 and 23 are
being redirected to their high-level counterpart ports: 2222 and 2223 in order
to allow for the honeypot to listen on the default 22 and 23 ports. The default
SSH and Telnet ports wants to be remained as port 22 and port 23 in order to
look more genuine and lure attackers by tricking them into thinking they are
attacking the machine and the default ports when they are in reality accessing
2222 and 2223 on the honeypot.

3.2.6 Module 3: Surface Environment

This module describes the analysis phase of the model. Log files which are
captured and sent from the Ubuntu to the Windows host are forwarded for
possible anomaly detection. This module also allows for analysis in the form of
log management by utilizing Splunk, which is a log management system. This
allows for efficient representation of the logs allowing for easier identification of
anomalies. The logs move from the honeypot to the Ubuntu host to the Windows
host that stores a backup and then sends them to the anomaly detection
system.

3.3 Conclusion

The goal of the IAD model is to be able to capture attack metric data in real time
and run it through an anomaly detection system to specify the attacker’s
intents. The model has shown how this can be achieved by setting up a honeypot
in a simulated IoT environment with vulnerable security and weak
authentication protocol. This chapter has presented this using a high-level and

- 22 -
a detailed description of the model based on module dependency and
interaction, where an environment can be simulated, and potential attack are
induced by the honeypot.

Chapter 4: Implementation and Results

- 23 -
4.1 Introduction

The previous chapter discussed the Intrusion Attack Detection (IAD) model
which has set a precedent for this chapter. This chapter is more focused on
presenting the implementation approaches and the results. Additionally, this
chapter mainly show how the research objectives that were described in Chapter
1 of this thesis have been achieved. This has been successful, owing to the fact
that different modules in the constructed IAD model have been able to
communicate effectively over the network (see Chapter 3). More description on
the implementation and results has been given in the subsequent sections of
this chapter.

4.2 Intrusion Attack Detection (IAD) Implementation

The implementation and generation of results is based upon the IAD model that
has been presented in Chapter 3 of this thesis. This system has been
implemented in such a manner that it produces log files containing information
about an attacker’s interaction with the system as is shown in Figure 4.1, which
are explained in the section to follow.

Figure 4.1. Diagram showing the implemented structure in relation to the modules.

4.2.1 Relationships among Implemented IAD Modules

- 24 -
Figure 4.1, which relies on the IAD model that was presented in Chapter 3
shows the relationships among the implemented modules. The IAD model is
implemented on a segmented VLAN of the MAU faculty network allowing real-
time traffic to enter the simulation. Implementing the system on an already
established network assures the attacker that he is actually attacking an
already established environment, while in reality he’s attacking the simulated
system running on the network. The relationship among the implemented
modules are discussed. It is important to highlight that the relationship is being
discussed in order to show how their interdependence supplements the tasks
that are played by intrusion detectors.

4.2.1.1 Simulated Environment (Set-up)

The simulated environment module and its devices are installed on the host
computers running on the segmented VLAN of the MAU network. They are set
up as Virtual Machines (VMs) using a hypervisor known as VMWare. Each one
of them runs the latest version of their respective Operating Systems (OS). As
both the machines sit on the same VLAN they can see and interact with each
other and have access to the same network settings. The simulated Environment
module, therefore, depends on Module two to provide the network infrastructure
and the hardware on which the run.

4.2.1.2 Host Environment (Set-up)

The two host computers in this module are part of the segmented VLAN on
MAU’s network. Both the hosts are set up with a 64-bit Operating System
running on 4 GB of RAM and an Intel Xenon 3.6GHz CPU.

4.2.1.3 Surface Environment (Set-up)

The surface environment module is made up of the outwards facing MAU

network, anomaly detection and log management system. The network is
exposed to all incoming traffic directed towards MAU. This module also
implements a public VIP (Virtual IP) for the Linux machine to use in order to be
accessible from the internet.

- 25 -
 4.3 Honeypot Implementation

The honeypot has been implemented through an installation of Cowrie Medium-

Interaction-Honeypot with both SSH and Telnet features unlocked. The file
system has been slightly modified to look more like an IoT device and the host
has been named “iot-room-4”. It is installed on the virtual Linux machine on its
own user called “cowrie” in order to limit any damage in case the attacker
notices that it is a honeypot and attempts to break into the host. The SSH
session has been configured to accept all login attempts with the user “root”
using any password. The Telnet session has been configured to allow any
incoming connections. Cowrie runs inside a python virtual environment which
is a self-contained directory tree with a python installation.

Having looked at IAD implementation, the next section focuses on the

experimental results.

4.4 Experimental Results

The experimental results that have been realised as a result of the

aforementioned set-up have been discussed in two-folds. Firstly, an attack
scenario is discussed which has been used as a basis for generating the results.
It is worth to note that the results generated by this system are both natural
and moderated by a tester.

4.4.1 Attack scenario

- 26 -
 Figure 4.2 Attackers path in the attack scenario.

This attack scenario was conducted within the set up as follows: An attacker
was allowed to gain access using SSH or Telnet (Red arrow labelled 1 in the
Figure 4.2). When prompted to log in the SSH session would allow any root
credentials to gain access (Red arrow labelled 2). The attacker would then
attempt to further explore the machine for vulnerabilities (Red arrow labelled 3).
Once satisfied, the attacker would attempt to download and execute malicious
code onto the system (Red arrow labelled 4). In this attack, a deliberate
vulnerability is assumed whose main task is to deceive the attacker of possible
weakness in the system, where in essence, the task is to study the attacker’s
path and attack styles.

4.4.1.1 Technical Assumptions

The attacker would find the host with a public IP accessible from the Internet.
Next, a simple port scan of this IP reveals that ports 22 (SSH) and 23 (Telnet)
are open, exploring these ports further, the attacker would find that both
sessions are password protected but with root as username and any password
access can be gained. Once inside the system, the attacker would notice that
the device is named as “iot-room-4” and runs a Debian version. This would lead
the attacker to think that they are inside an IoT device. Probing further, the
attacker would notice the network that looks like an office network (Simulated
environment) and its devices. Since the attacker logged in as root, he has full
access to the shell and is a su-doer. Depending on the attacker’s intents, he
could chose to attempt to install malicious software through “scp” or “wget” in
order to use the device as his launch platform which in this scenario is what he
choose to do. Another option would be to cause harm to the system and attempt
to preform DDoS attack by disabling the networks different devices or protocol.

- 27 -
 4.4.1.2 Summary of Attack Scenario

Based on the aforementioned scenario and the technical assumptions, it is the

author’s opinion that there exist intrusive actions that are exacerbated by
activities deemed nefarious by the attacker. Based on this, the results are
systematically discussed.

4.4.2 State-of-the-art Attacks

The state-of-the-art attacks that the attack scenario focuses on is mainly that
of malware execution and command and control. The scenario proposes an
attacker’s means of breaking into the system, further looking for vulnerabilities
as well as corrupting the node by downloading and running malicious malware
onto the system with varying intentions. These types of attacks are a common
occurrence in IoT systems. [28]

4.4.3 Results Regarding the Simulated Environment

The outcome of implementing the simulated environment (Module 1) is

discussed in this section as follows:

4.4.3.1 Simulated IoT

Figure 4.3 shows the BevyWise dashboard which is the software used to
simulate and control the IoT devices.

- 28 -
 Figure 4.3. BevyWise dashboard showing the active devices and real-time traffic.

The simulated IoT devices running on the Windows machine allowed for 12
simultaneous devices to run on the network. The devices were named in order
to look like it could be a part of an office environment furthering the authenticity
of the test.

Figure 4.4. A look into how a simulated device is set up.

Each of these devices send traffic via MQTT with predetermined, randomly
generated JSON data. In the case of the device shown in Figure 4.4 above, it is
set to simulate an air conditioner by sending a random value within parameters

- 29 -
every five seconds representing the speed and temperature of the air
conditioner.

Figure 4.5. Sample data packet sent to a simulated device.

Figure 4.5 shows one of those data packages sent via MQTT over the network to
the simulated device.

Figure 4.6. How the data looks like from the moderator’s perspective.

- 30 -
Figure 4.6 depicts the data as it is coming from the BevyWise broker that is
running on the Windows machine. This is what generates and provides the data
to the simulated devices.

Figure 4.7. The BevyWise Broker command prompt.

The broker running on the Windows host uses port 1883 to send MQTT data.
Figure 4.7 above depicts the command prompt from the moderator’s
perspective.

4.4.3.2 The Honeypot Log Data

The honeypot that sits inside the simulated environment that is being attacked
by a threat agent logs all the shell interactions, connections and any file that is
being downloaded. The data is stored in a .log file and a .JSON file. For easier
readability, the .log file has been uploaded to Splunk log management system
and searches has been performed in order to locate and display the relevant
information.

Figure 4.8. Example of a failed and successful login attempt.

The honeypot starts to log as soon as it gets a connection request on either of

its two ports. The first thing it logs is the timestamp of the connection and the
connecting clients IP. Once the attacker has entered a username and password,
it logs the attempt. In the figure above both a failed and successful attempt is

- 31 -
shown, along with the status it also shows the username and password that
was used as well as the IP which is shown in the highlighted section of Figure
4.8.

Figure 4.9. Attempted logins seen through Splunk.

The honeypot has been able to collect over 300 attack attempts in a span of a
weekend, a sample of them are displayed in figure 4.9. It is estimated that of
these, around 60-70% are bots or botnets trying to use default techniques to
break into the system.

Figure 4.10. An example of a successful login session.

Looking at a successful login attempt directly from the logfile we can see the
same information as described above along with some more useful information
highlighted in figure 4.10. Along with the IP and authentication details, it also

- 32 -
logs the SSH version, system information and terminal information before
getting the shell.

4.4.4 Detected Attacks

The results on how the system performed is discussed in this section in three
sequence of steps in Section 4.4.4.1, 4.4.4.2 and 4.4.4.3 respectively. The
following data was captured as a result of the attack that was conducted as was
highlighted in the attack scenario and the sequence of steps as follows:

4.4.4.1 Step one, Establishing Connection

This step which is shown in Figure 4.10 shows how the connection is
established-which is useful because it allows monitoring how the attacker
interacts with the system.

Figure 4.11 Scenario step 1, showing the connection log.

The first step that was described in the scenario was that- an attacker connects
to the system using root credential and any password. The honeypot logged an
incoming SSH connection from the testers IP with the username “root” and
password “Adm1n” which can be seen in figure 4.11. This leads to step two,
where the attacker is required to look around.

- 33 -
 4.4.4.2 Step two, explore the system

The scenario then describes the attacker exploring the system using the
available tools to see if he can find out more about the network and the IoT
device he has gained access to.

Figure 4.12 Commands used by the attacker to explore the system.

The attacker examines the emulated file system finding all the default files he
would expect to find in an IoT device running a Debian version using the cd and
ls commands to navigate depicted in figure 4.12. The attacker then proceeds to
look for further information by looking into the password file of all the users on
the device, noting this down for a later time. He then attempts to find out more
about the network and its information by running netstat and installing Nmap.
Nmap is a tool used to discover devices and ports on a local network.

4.4.4.3 Step three, download and execute malicious code

After exploring the system and discovering its vulnerabilities the attacker
attempts to download a script from a malicious website using the command
wget which allows him to establish a connection to an HTML server in order to
download its content shown in figure 4.13. In this case, the file that is
downloaded is a net worm used to spread and corrupt networks. After
downloading, he modifies the files permissions and runs it using the emulated
python environment available on the honeypot.

- 34 -
 Figure 4.13 Commands used by the attacker to download and run malicious code.

Having looked at the implementation of the IAD model and the results, the
honeypot has performed as intended, capturing the attacker’s interactions and
behaviour allowing for analysis and to further understand their intent.

4.5 Conclusion

The scope of this chapter was mainly to discuss the implementation and the
results. As a result, this chapter has presented and discussed the results which
was one of the core objectives if this thesis. An IAD approach that was
implemented on MAU’s faculty network in order to produce both natural and
controlled results have been presented using an attack scenario. The results are
based on a moderated attack scenario carried out by a tester. The honeypot
logged all the interactions by the attacker and presented them in a .log file and
sanitized for ease of readability through Splunk.

- 35 -
 Chapter 5: Analysis and Discussion

5.1 Introduction

This chapter focuses on giving an analysis of the results that were presented in
Chapter 4 of this thesis. Further, the chapter also gives a discussion on the
propositions and how instrumental they were in achieving the objectives that
were previously highlighted in Chapter 1 of this thesis. Additionally, the chapter
tries to map the propositions as to whether they contribute to the body of
knowledge or not. Basically, the thesis in discussion leverages Honeypots in a
connected IoT environment in order to detect potential intrusions and attacks.
The author started by exploring the state-of-the-art research on intrusion
detection techniques and honeypot technologies, followed by a construction of
an IAD model that was modelled, implemented, and subjected to both organic
and moderated attacks, which was later used to aid in conducting experiments
as a proof of concept. The organic attacks were conducted by unknown threat-
agents that were emanating from different regions of the world while the
moderated attacks were performed by a moderator in a controlled scenario. The
result that was presented, focused mainly on the moderated attack scenario to
highlight the systems actual usefulness as an ADS (Anomaly Detection System).
Analysis and discussion will form the major contribution of this chapter.

5.2 Analysis of the Results

This section focuses on presenting an analysis of the propositions, results and

arguments that have been coined in this thesis. The results that are being
discussed are realised as a result of the implementation of honeypot and its
surrounding environment. The section starts by exploring whether the set
research questions and objectives are met, after which a discussion of the actual
results follows.

- 36 -
 5.2.1 Research Questions and Answers

The research questions that were initially set in this thesis have been explored
and as a result Chapter 3 and 4 contributed towards providing answers for the
research questions a summary and how the response was done is shown in
Table 5.1.

Table 5.1. Research Questions and Answers.

Research Question How it has been answered

1 Can intruder attack Answered by creating a proof of concept with
patterns be detected in live and moderated data resulting in post-
IoT environment? analysis of attack patterns and signatures.

2 Can honeypots be Proven as an integral part of the proposed

used as decoys to help system, allowed for data generation and
discover intruders’ discover intrusion attacks in a simulated
footprints in an IoT environment.
environment?

The first question was formulated in order to help determine a system’s

usefulness in identifying attack patterns and to further study attack behaviour.
This allows for better understanding of what, how and why an attacker interact
with the system. All these aspects can then be used to provide a signature for a
certain type of attacker or attack.

Results that were generated from the honeypots allows for analysis which
answer the first question. This has been achieved by looking at the logs and
shell interactions and cross-referencing them with a timestamp or IP-address.

The second question gives the opportunity to evaluate the system as a whole
when it comes to intrusion detection and analysis. The model and framework
will be further analysed and discussed in section 5.3.

- 37 -
 5.2.2 Research Objectives

The research objectives that were initially set in this thesis have been met
correctly and a summary on how they have been met is interpreted in Table 5.2.

Table 5.2. Research Objectives and Answers

Objective How the objective was met / realised

To conduct state-of-the- Discussed in Chapter 3 and later carried out as a
art IoT attacks in IoT moderated attack scenario in Chapter 4 allowing
for results directed towards state-of-the-art
attacks.
To use honeypots to aid Discussed throughout the thesis, with focus on its
in attack detection in an technical components in Chapters 2 and 3. A
IoT environment honeypot was implemented in the system to act as
a vulnerable IoT device on the network.
To develop a prototype A model and framework were proposed in Chapter
as a proof of concept 3 and later implemented in Chapter 4 as a proof of
concept. The model was used as a framework for
the system and its components.

Objective 1 was formulated due to the need of a way to evaluate the system and
its usefulness as an ADS. This objective allowed for a moderator to complete
certain tasks and attacks on the system which was then analysed in the results
in order to discuss the system’s ability to log and cope with state-of-the-art
attacks.

Objective 2 allows for the use of honeypots in the IoT surrounding/environment.

The honeypot was to be the main node where the data was to originate from.
This helps evaluate their usefulness in such a system. [29]

Objective 3 was necessary to achieve a working prototype from which both

organic and moderated data could be harvested. This also allowed for a tactile

- 38 -
way to test and implemented modules and look at their relationships and
functionality on a real live system.

5.2.3 Discussion of the Actual Results

A discussion of the actual results is given in this section with a focus on

intrusion attack data, organic and controlled attack.

5.2.3.1 Intrusion Attack Data

The intrusion attack data presented in this thesis is divided into two sets:
organic and moderated. They each represent different values and approaches a
full-scale implementation could take if development continued. The different
values posed by the two types of attack data depends on what is needed from
the system. For example, organic data allows for real time gathering in a live
system where assets may need to be protected fast. On the other hand,
moderated data may be more useful in the testing phase or when a system needs
to be evaluated. All this data is explained in more depth further on.

5.2.3.2 Organic Attack Data

Organic data in this context means any and all data produced by threat-agents
without inside knowledge of the system. In this case, this means all attacks that
originates from outside of Malmö University network could be considered as
organic. This means it is in no way influenced by the research or controlled by
the researchers. This type of data helps to create general statistics with which
to evaluate the system. Data such as, origin of attack, success rate/failure rate
and shell interactions could all be considered low-level data and provide a
general overview of what type of attacks the system may encounter. All this data
is naturally captured by a threat agent, whether it is a human trying to break
into a system, live or a script/bot designed to exploit known vulnerabilities. This
data can be further sanitized and analysed to determine who or what is behind
the attack and how to best defend against such threats. It is worth to note that

- 39 -
this project is not aimed at determining the source of the attack, rather its
interactions once on the system and the possible assets that may be subjected
to compromise.

5.2.3.3 Moderated / Controlled Attack Data

The moderated or controlled data is the data produced by a researcher aware of

the environment and its scenario. In the thesis, this data originates from a
predetermined attack scenario where a moderator deliberately performed an
attack on the system to showcase its functionality and provide a base on which
the system can be evaluated. The attack-scenario contained a malware
execution attack common within IoT where the threat agent attempts a break
in and downloads malicious code in order to enslave or further corrupt the
device, depending on the malware. A description of the controlled or moderated
attack is shown in Table 5.3.

Table 5.3. Attacks and Descriptions

Controlled attack Description

1 Intrusion Attack
2 Malware Execution
3 Port Detection
4 Command and Control
Performed an educated dictionary attack to
gain access to the system.
Once in control of the system, download and
execute malicious malware onto the device.
Utilizing Nmap and access to the network,
see online devices and their open ports.
Access to the system allows for the intruder
to use the hardware as a C&C centre.

5.3 Discussion of the propositions

This section will discuss the system as a whole as well as go into detail of its
different part in order to evaluate and further discuss their usefulness. The
proposed system has been broken down into three parts (modules) both for ease

- 40 -
of control and compartmentalization. All three modules had their own set of
tasks, simulation, hosting, and façade/analysis. Having it this way made it
easier to debug and modify each part without intervention of the others.
However, looking back, this system is somewhat ineffective as the same work
could be hosted on one machine rather than two allowing for a more versatile
setup. The constructed model was realised as a result of building modules that
has effective relationships and the system was effectively hosted on MAU
servers. This allowed for more expansion and the final “hardware” setup to be
running two separate machines on a segmented VLAN of the MAU network with
a VIP for the honeypot. Having it hosted on the MAU network came with both
pros and cons. The pros were that the server could be dedicated and segregated
to this experiment. This meant a safe and controllable environment with
multiple fail-safes in case anything went wrong (live backups, no inside access).

Consequently, the proposed system was able to provide the intended tasks as a
result of the existing relationships between modules. All these modules relate to
each other and provides services for one another. Their relationships can be
broken down into a waterfall based on the attacker’s path. This means that the
surface module (modules 3) acts as the starting point and forwards the attacker
to module 2 (host environment) which in turn provides the environment for
module 1 (simulated environment) where the attack will interact with the
system. The modules therefore work in reverse order when looking at it from a
relationship perspective as follows.

• Module 3 provides the surface and VIP that the attacker exploits. It sits
on the outward most layer of the network and provides a tunnel through
the VLAN directly to the honeypot.
• Module 2 provides the hardware and environment that Module 1 operates
on. It forwards the attack to the simulated environment and acts as an
intermediate between module 1 (surface) and module 3 (simulation).
• Module 1 acts as the simulated environment and “end-point” for the
attacker. It relies on Module 2 to provides its infrastructure and hosts
the actual honeypot.

The discussions of the outcome of this work is based on the two types of results
produced during the “live” phase of the project where the honeypot was active

- 41 -
in the modelled framework and accessible to the public. The honeypot chosen
for this experiment relied on SSH and Telnet to create instances where the
attacker would interact with the simulated environment. Everything that was
expected of the honeypot at the beginning of the project was fulfilled and the
honeypot performed all of the abilities outlined in the beginning. This means
that the honeypot provided adequate interaction data in order for an analysis to
be carried out and result in the identification of the threat agents’ motives and
modus operandi. This, therefore, gives basis for the assumption that honeypots
can be used to detect and categorize attackers’ behaviours and patterns by
looking at shell interactions when confronted with an IoT environment. When
compared to already established ADS’s and security software such as
FortiDeceptor [27] the honeypot provides similar results in an active
environment along with shell interactions.

- 42 -
 Chapter 6: Conclusion

6.1 Summary and conclusion

This thesis set out to explore the usefulness of honeypots in intrusion attack
detection in an IoT environment by utilizing simulated IoT devices in a real-
world scenario. For the cause, a framework was modelled to implement a
prototype on the MAU faculty network open to the public. The model consists of
three modules, each representing a vital part of the system. By exposing the
system to the public, organic data was captured and harvested in order to
explore attacker behaviour and interactions with the system. As well as the
organic data, a moderated attack scenario was produced and carried out by a
moderator in order to highlight the honeypots functionality.

From the data captured, a conclusion could be drawn to that the honeypot
performed as expected and provided information on the attacker’s origin,
behaviour, and interactions with the system. This shows that there is some use
in having a honeypot capable of shell interaction logging in an environment to
further understand and counteract threats against IoT.

6.2 Future work

As mentioned previously in the discussion part of the thesis, the system in its
current state, does not allow for real-time analysis in the form of machine
learning for purposes of anomaly detection. This would, therefore, be the next
logical implementation in order to further improve the model’s usefulness and
allow for active threat prevention in the form of live threat analysis and
countermeasure deployment.

- 43 -
- 44 -
References

[1] S. O’Dea, (2020) IoT: number of connected devices worldwide 2012-2020, Statista,
[Online]. Available at: https://www.statista.com/statistics/471264/iot-number-of-
connected-devices-worldwide/. [Accessed: 20-Apr-2020].
[2] Kebande, V. R., & Ray, I. (2016, August). A generic digital forensic investigation
framework for internet of things (iot). In 2016 IEEE 4th International Conference on
Future Internet of Things and Cloud (FiCloud) (pp. 356-362). IEEE.
[3] C. Kolias, G. Kambourakis, A. Stavrou and J. Voas., "DDoS in the IoT: Mirai and
Other Botnets" in Computer, vol. 50, no. 07, pp. 80-84, 2017.
[4] Khorashadizadeh, S., Ikuesan, A. R., & Kebande, V. R. (2019, September). Generic
5G Infrastructure for IoT Ecosystem. In International Conference of Reliable Information
and Communication Technology (pp. 451-462). Springer, Cham.
[5] Kebande, V. R., Bugeja, J., & Persson, J. A. (2020). Internet of Threats Introspection
in Dynamic Intelligent Virtual Sensing. arXiv preprint arXiv:2006.11801.
[6] Gite, S., & Agrawal, H., (2016). On context awareness for multisensor data fusion in
IoT. In Proceedings of the Second International Conference on Computer and
Communication Technologies (pp. 85-93). Springer, New Delhi.
[7] Jhaveri, R. H., Patel, N. M., Zhong, Y., & Sangaiah, A. K. (2018). Sensitivity analysis
of an attack-pattern discovery based trusted routing scheme for mobile ad-hoc networks
in industrial IoT. IEEE Access, 6, 20085-20103.
[8] Miraz, Dr & Ali, Maaruf & Excell, Peter & Picking, Rich. (2015). A review on Internet
of Things (IoT), Internet of Everything (IoE) and Internet of Nano Things (IoNT). 219-224.
10.1109/ITechA.2015.7317398.
[9] J. Knowles, (2018) Simulating the Effects of Releasing Malware onto the Internet of
Things, Bachelor’s Degree, Cardiff University.
[10] Bugeja, J., Jacobsson, A., & Davidsson, P. (2016, August). On privacy and security
challenges in smart connected homes. In 2016 European Intelligence and Security
Informatics Conference (EISIC) (pp. 172-175). IEEE.

[11] Bugeja, J., Jönsson, D., & Jacobsson, A. (2018, March). An Investigation of
Vulnerabilities in Smart Connected Cameras. In 2018 IEEE International Conference
on Pervasive Computing and Communications Workshops (PerCom Workshops) (pp.
537-542). IEEE.

[12] Peter, E. Schiller, T., (2008) A Practical Guide to Honeypots, Washington University
in St Louis, Missouri.

- 45 -
[13] M. Anirudh, S. A. Thileeban And D. J. Nallathambi., (2017) "Use of Honeypots for
Mitigating DoS Attack Targeted on IoT Networks," 2017 International Conference On
Computer, Communication And Signal Processing (ICCCSP), Chennai, Pp. 1-4,
[14] M. Shukla and P. Verma,. (2015), Honeypot: Concepts, Types, and Working,
Department of Computer Engineering, SOCET, Ahmedabad, India.
[15] Mokue and M. Adams,. (2007). Honeypots: Concepts, Approaches, and Challenges,
Atlantic State University, Savannah, Georgia.
[16] V. Nicomette, M. Kaâniche, E. Alata, M.u Herrb. Set-up and deployment of a high-
interaction honeypot: experiment and lessons learned. Journal in Computer Virology,
Springer Verlag (Germany), 2011, 7 (2), pp.143-157. <10.1007/s11416-010-0144-2>.
<hal00762596>
[17] J, Zhuge, T Holz. X, Han. C, Song. W, Zou. (2007). Collecting Autonomous
Spreading Malware UsingHigh-Interaction Honeypots. International Conference on
Information and Communications
[18] Rahmatullah, D.K., Nasution, S.M., & Azmi, F. (2016). Implementation of low
interaction web server honeypot using cubieboard. 2016 International Conference on
Control, Electronics, Renewable Energy and Communications (ICCEREC), 127-131.
[19] T.W., Schiller (2015). HoneyRJ. GitHub repository:
https://github.com/twschiller/HoneyRJ.
[20] F, Cohen. (1998). The Deception ToolKit. The Risks Digest. Available at:
http://catless.ncl.ac.uk/Risks/19.62.html#subj11
[21] W, Fan. Z, Du. D, Fernández. (2015). Taxonomy of Honeynet Solutions. Sai
Intelligent Systems Conference. London, UK.
[22] Zhou, C. V., Leckie, C., & Karunasekera, S. (2010). A survey of coordinated attacks
and collaborative intrusion detection. Computers & Security, 29(1), 124-140.
[23] Ahmed, M., Mahmood, A. N., & Hu, J. (2016). A survey of network anomaly
detection techniques. Journal of Network and Computer Applications, 60, 19-31.
[24] W, Fan. Z, Du. D, Fernández. (2015). Taxonomy of Honeynet Solutions. Sai
Intelligent Systems Conference. London, UK.
[25] S. E, Samah. (2015). Haystack: An Intrusion Detection System. Tracor Applied
Siences, Inc. Austin, Texas.
[26] Vasilomanolakis, E., Karuppayah, S., Mühlhäuser, M., & Fischer, M. (2015).
Taxonomy and survey of collaborative intrusion detection. ACM Computing Surveys
(CSUR), 4
[27] https://www.fortinet.com/products/fortideceptor
[28] Deogirika,. J., Vidhate, A. (2017). Security Attacks in IoT: A survey. International
conference on I-SMAC (IoT in Social, Mobile, Analytics and Cloud) (I-SMAC 2017).

- 46 -
[29] Farn, K., Lin, S., Ren-Wei Fung, A. (2004). A study on information security
management system evaluation – assets, threat and vulnerability.

- 47 -