Intrusion Attack & Anomaly Detection in IoT Using Honeypots

(1)

- 0 -

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 Examiner: Joseph Bugeja

(2)

- 1 -

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.

(3)

- 2 -

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.

(4)

(5)

- 4 -

Table of content

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.

(8)

- 2 -

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

(9)

- 3 -

List of Tables

Table 5.1 Research Questions and Answers. Table 5.2 Research Objectives and Answers. Table 5.3 Attacks and Descriptions.

(10)

- 4 -

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.

(11)

- 5 -

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?

(12)

- 6 -

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.

(13)

- 7 -

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.

(14)

- 8 -

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.

(15)

- 9 -

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].

(16)

- 10 -

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

(17)

- 11 -

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

(18)

- 12 -

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

(19)

- 13 -

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.

(20)

- 14 -

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

(21)

- 15 -

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.

(22)

- 16 -

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.

(23)

- 17 -

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.

(24)

- 18 -

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.

(25)

- 19 -

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.

(26)

- 20 -

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

(27)

- 21 -

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.

(28)

- 22 - 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

(29)

- 23 -

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.

(30)

- 24 -

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.

(31)

- 25 -

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.

(32)

- 26 -

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.

(33)

- 27 -

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.

(34)

- 28 - 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.

(35)

- 29 -

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

(36)

- 30 -

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.

(37)

- 31 -

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

(38)

- 32 -

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

(39)

- 33 -

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.

(40)

- 34 - 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.

(41)

- 35 -

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.

(42)

- 36 -

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.

(43)

- 37 -

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

patterns be detected in IoT environment?

Answered by creating a proof of concept with live and moderated data resulting in post-analysis of attack patterns and signatures.

2 Can honeypots be used as decoys to help discover intruders’ footprints in an IoT environment?

Proven as an integral part of the proposed system, allowed for data generation and discover intrusion attacks in a simulated 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.

(44)

- 38 -

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-art IoT attacks in IoT

Discussed in Chapter 3 and later carried out as a moderated attack scenario in Chapter 4 allowing for results directed towards state-of-the-art attacks.

To use honeypots to aid in attack detection in an IoT environment

Discussed throughout the thesis, with focus on its technical components in Chapters 2 and 3. A honeypot was implemented in the system to act as a vulnerable IoT device on the network.

To develop a prototype as a proof of concept

A model and framework were proposed in Chapter 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

(45)

- 39 -

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

(46)

- 40 -

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 Performed an educated dictionary attack to gain access to the system.

2 Malware Execution Once in control of the system, download and execute malicious malware onto the device. 3 Port Detection Utilizing Nmap and access to the network,

see online devices and their open ports. 4 Command and Control 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

(47)

- 41 -

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

(48)

- 42 -

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.

(49)

- 43 -

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.

(50)

Intrusion Attack &amp; Anomaly Detection in IoT Using Honeypots