# Detection and Blockchain-Based Collaborative Mitigation of Internet of Things Botnets

Authors: Syed Muhammad Sajjad; Muhammad Rafiq Mufti; Muhammad Yousaf; Waqar Aslam; Reem Alshahrani; Nadhem Nemri; Humaira Afzal; Muhammad Asghar Khan; Chien-Ming Chen
Journal: Wireless Communications and Mobile Computing
 (2022)

---

## Abstract

DDoS (distributed denial of service) attacks have drastically effected the functioning of Internet-based services in recent years. Following the release of the Mirai botnet source code on GitHub, the scope of these exploitations has grown. The attackers have been able to construct and launch variations of the Mirai botnet thanks to the open-sourcing of the Mirai code. These variants make the signature-based detection of these attacks challenging. Moreover, DDoS attacks are typically detected and mitigated reactively, making DDoS mitigation solutions very expensive. This paper presents a proactive IoT botnet detection system that detects the anomalies in the behavior of the IoT device and mitigates the DDoS botnet exploitation at the source end, which makes our proposal a low-cost solution. Further, this paper uses a collaborative trust relationship-based threat intelligence-sharing mechanism to prevent other IoT devices from being compromised by the detected botnet. The researchers have evaluated the collaborative threat intelligence sharing mechanism using Ethereum Virtual Machine and Hyperledger. The performance of our proposed system can detect 97% of the Mirai botnet attack activities. Furthermore, our collaborative threat intelligence sharing mechanism based on the Ethereum Virtual Machine showed more scalability.


---

## Body

## 1. Introduction

Due to the advancements in microelectromechanical systems (MEMS), wireless technologies, microservices, and the Internet, IoT has evolved rapidly in recent times, anything connected to the Internet, a ubiquitous device, for example, a heart monitor or health monitoring sensors implanted in a person or biochip transponders implanted in animals in a form [1]. The ample space of IP address due to IPv6 is one of the essential factors in the massive development of the Internet of Things [2]. IoT applications can be found in energy, transportation, health care, building management, cattle farms, and agriculture.Other than trend-setters, architects, sellers, and clients, IoT has too pulled into consideration of assailants. These IoT devices are generally set up with fewer security controls. This inborn imperfection has made the IoT millions of insecure devices [3]. The more significant volume of the Web of Things makes its assault surface more noteworthy [4, 5]. Time to showcase, low-cost thought, and the need for related security regulations have empowered vendors to make less secure gadgets. Security specialists have, numerous times, issued notices concerning the utilization of these less ensured gadgets [6].Numerous hosts and autonomous systems attacked GitHub with a 1.35 Tbps attack in February 2018 [7]. In May 2018, malware infecting particular network-attached storage devices and home routers was identified as “VPNFilter.” This malware has affected around 500,000 home routers worldwide [8–10]. The exploitation of these insecure IoT devices for initiating well-coordinated Distributed Denial of Service (DDoS) was attacked by Mirai malware in October 2016. Such kinds of attacks affect user trust in adopting the IoT paradigm. After the Mirai malware source code release, many Mirai malware variants were authored by black hat hackers.Traditional detection and mitigation of DDoS are carried out at the destination of the attack. However, enterprises are deploying costly and complicated solutions for DDoS protection to continue their core business processes. Therefore, there is a limitation in detecting and mitigating DDoS at the destination end.


### 1.1. Research Motivation

Collaborative security is a technique that is characterized by many vital features, including “collective responsibility” and “think globally, act locally” [11]. Different players, manufacturers, and vendors should collaborate by sharing attack knowledge to provide proactive detection and real-time mitigation of attacks. They also have a significant role in the mitigation and prevention of botnets. They are well placed to identify malicious activities produced by infected systems and subsequently separate them from the network to safeguard the system. However, detecting and stopping a single source of DDoS attack traffic is not sufficient.This paper presents detection and a collaborative mitigation system for the Mirai IoT type of malware. The main contributions of this paper are the following:(i)
Based on the performed Mirai malware analysis, this paper presented a model for detecting the attempts of device compromise and subsequent installation of the malware binaries on it(ii)
This research proposed a mitigation mechanism that prevents a device from becoming a part of the Mirai type of botnets(iii)
This paper also proposed a collaborative mitigation mechanism for threat intelligence sharing among trusted peers. This paper used smart contracts and blockchain-based methodologies for trust establishment and collaboration that helped implement the proactive defense mechanism against the IoT botnetsThe remaining of the paper is structured as follows. Section2 discusses the existing state of the art. Section 3 is about the threat model, and it includes an analysis of the complete functionality of Mirai malware, command and control server, its scanning for vulnerable devices as potential bot targets, and malware loading process on these vulnerable devices. Section 4 elaborates on the particulars of the proposed detection system. Section 5 contains the specifics of the anticipated collaborative mitigation system. Implementation and deployment specifications are presented in Section 6. Section 7 provides results and analysis of both detection and mitigation systems. Finally, Section 8 concludes the paper.


### 1.2. Significance of Work

Significance and potential benefits of this work are the following:(i)
IoT malware attack can be detected at its source end(ii)
Timely informing the network administrator of the compromised device during the attack(iii)
Availability of a mechanism for sharing the attacker information with the peers in a proactive way(iv)
Significant addition in the enhancement of the security and sustainability of the global Internet(v)
Significant addition in the enhancement of the consumer trust on the Internet of Things


## 1.1. Research Motivation

Collaborative security is a technique that is characterized by many vital features, including “collective responsibility” and “think globally, act locally” [11]. Different players, manufacturers, and vendors should collaborate by sharing attack knowledge to provide proactive detection and real-time mitigation of attacks. They also have a significant role in the mitigation and prevention of botnets. They are well placed to identify malicious activities produced by infected systems and subsequently separate them from the network to safeguard the system. However, detecting and stopping a single source of DDoS attack traffic is not sufficient.This paper presents detection and a collaborative mitigation system for the Mirai IoT type of malware. The main contributions of this paper are the following:(i)
Based on the performed Mirai malware analysis, this paper presented a model for detecting the attempts of device compromise and subsequent installation of the malware binaries on it(ii)
This research proposed a mitigation mechanism that prevents a device from becoming a part of the Mirai type of botnets(iii)
This paper also proposed a collaborative mitigation mechanism for threat intelligence sharing among trusted peers. This paper used smart contracts and blockchain-based methodologies for trust establishment and collaboration that helped implement the proactive defense mechanism against the IoT botnetsThe remaining of the paper is structured as follows. Section2 discusses the existing state of the art. Section 3 is about the threat model, and it includes an analysis of the complete functionality of Mirai malware, command and control server, its scanning for vulnerable devices as potential bot targets, and malware loading process on these vulnerable devices. Section 4 elaborates on the particulars of the proposed detection system. Section 5 contains the specifics of the anticipated collaborative mitigation system. Implementation and deployment specifications are presented in Section 6. Section 7 provides results and analysis of both detection and mitigation systems. Finally, Section 8 concludes the paper.


## 1.2. Significance of Work

Significance and potential benefits of this work are the following:(i)
IoT malware attack can be detected at its source end(ii)
Timely informing the network administrator of the compromised device during the attack(iii)
Availability of a mechanism for sharing the attacker information with the peers in a proactive way(iv)
Significant addition in the enhancement of the security and sustainability of the global Internet(v)
Significant addition in the enhancement of the consumer trust on the Internet of Things


## 2. Related Work

In recent times, IoT security has been a popular area of research. This study divided the related work section into two subsections for a focused discussion. The first subsection discusses the approaches related to IoT botnet detection, and the second subsection discusses the collaborative mitigation approaches and their limitations.


### 2.1. IoT Botnet Detection

Due to diverse reasons, from comparatively fewer computing capabilities to the pressure on the market, there has been a trend to ship and deploy the IoT devices and applications with less secure security controls. Security researchers in academia [12] and industry [13, 14] have been identifying the severe risks associated with this trend of negligence in IoT security [15].There have been numerous honeypot-based IoT botnet detection efforts. Pa et al. [16] proposed the IoT honeypot. Another attempt in this regard is [17]. These are low-interaction honeypots, an emulated package that provides the attacker with a limited level of interaction and is of little use for the practical deployments in the IoT devices.Numan et al. discussed that DDoS mitigation solutions at the service provider’s end have many business advantages for Internet service providers. In this way, not only ISPs can safeguard themselves from DDoS attacks, but they also can offer DDoS mitigation protection to their customers, leading to secure and reliable Internet services [18]. However, these solutions are costly and protect DDoS at its destination end rather than the source end. Therefore, ISP-based DDoS detection and mitigation solutions that block the CNC during the IoT Botnet propagation stage before the launch of actual DDoS are more effective. Therefore, there is a need for such kinds of solutions.There have been some efforts on the DDoS preventive techniques in the Internet of Things [19]. For example, Dao et al. proposed to install Smart filters at the edge of the attack source or destination. A central controller is deployed, performing coordination among the smart filters. The main controller restricts each smart filter by adopting suitable parameters into its self-organizing map module, built on the attacking behavior. However, the proposed solution fails to define how to identify the source of the attack. Moreover, the complexity of the proposed method made it unsuitable for smart home and smart office scenarios.An access control mechanism, Manufacturer Usage Description (MUD) enables functional correctness to devices [20, 21]. MUD profiles are available on MUD servers openly. The MUD profile consists of private consumer information. Therefore, there is a chance of leakage of the consumer’s data.Furthermore, a compromised device might direct toward an illegitimate or corrupted profile as the MUD’s DHCP and LLDP methods do not authenticate the device. MUD standard suggests the use of an X.509 extension. However, most Internet of Things home gateways and WiFi access routers do not possess X.509 certification. The deployment of the proposed MUD solution is based and dependent on the manufacturer of the devices. The implementation of the defense solution must not be dependent on the manufacturer. Consumers and users must be capable of deploying the defense solution independently.Heimdal is an intrusion detection solution based on the principle of whitelisting aimed at the IoT devices [22]. It can operate on gateway routers and offer protection to all the devices behind the gateway router. It is continually applied on every device present in the network. Although the whitelisting-based mechanism proposed in Heimdal produces good results, the limitation of this approach is its reliance on VirusTotal, which would hinder the detection of zero-day malware.A collaborative defense scheme to confront Mirai is proposed by [23]. The authors deployed a white Mirai, which expels the Mirai malware and blocks the communication ports in case of a Mirai attack. Although collaborative defense mechanisms are more productive, yet these solutions have shortcomings. The limitation of this scheme is that it only defeats the original Mirai malware. Furthermore, the Mirai variant may use other ports and vulnerabilities. Therefore, there is a need for a collaborative defense scheme to detect any Internet of Things malware.A SIEM-based system for the accurate identification of malicious activities in the Internet of Things is proposed [24]. The authors discuss vulnerabilities presented in IoT devices. The detection of malicious activities in IoT devices is detected using SIEM. However, SIEM deployment for IoT devices in the smart home scenario is costly and not cost-effective. Moreover, the integrity of the security events generated by SIEM is critical. Its alteration would lead to the generation of false alarms. Also, a centralized design for detecting abnormalities in IoT systems creates a single point of failure and attack.An e-MUD for IoT botnets prevention on home WiFi routers is presented in [25]. As MUD does not consider identifying and patching vulnerabilities present in the device before the issuance of the MUD profile, a device can be compromised even in the presence of the Manufacturer Usage Description profile by exploiting either the configuration vulnerabilities or firmware vulnerabilities present in the device. E-MUD presents an evaluation study of the Manufacturer Usage Description (MUD), identifies its weaknesses, and proposed enhancements in its architecture. It proposed a mechanism for identifying and eliminating the configuration vulnerabilities before creating the MUD profile for a device to minimize the attack surface. The authors adopt the OWASP firmware testing methodology for discovering vulnerabilities in the firmware of WiFi home routers. The device is allowed to request the MUD profile only if the identified firmware vulnerabilities are low. A Usage, Communication and Access Monitoring Based Botnets Detection System for IoT is proposed in [26] . The proposed solution has three main components, i.e., descriptor, monitor, and comparator. Descriptor defines device usage, communication, and access policies. Monitor observes the current state of device usage, communication, and access. Anomalies are detected by the comparator. Results show that the proposed detection system successfully detects Mirai IoT malware.


### 2.2. Collaborative Mitigation Approaches

The faith that sharing security attack evidence amongst systems would enhance the general protective position of the public is gaining popularity. For example, during the post-Morris Worm attack, the government of the US made CERT. Similarly, PDD-63 made ISACs help fight the perceived cyber threats [27]. Gordon et al. assessed the state of attacker information sharing and presented an economic incentive-based prototype that broke down the managerial expense [28]. This effort was then extended by Gal-Or et al. by utilizing game theory to assess the demand-side consequences happening underneath the existing sharing model [29]. The two works lay the foundation for understanding the advantages of sharing. In particular, sharing gives expected benefits to security and cost savings [30].The most promising cyber threat intelligence standards in the market today are the Trusted Automated Exchange of Indicator Information (TAXII) [31] and Structured Threat Information Expression (STIX) [32]. STIX and TAXII are open community efforts that are continually developing. The MITRE Corporation initially served on behalf and under the sponsorship of the US Homeland Security Department as the creator and moderator of both the STIX and TAXII communities. The US Homeland Security Department, in 2015, moved STIX and TAXII for further development to the OASIS Cyber Threat Intelligence Technical Committee (OASIS CTI TC). Today, STIX and TAXII are widely discussed in the community.Moreover, they have already incorporated many platforms and tools, making them a de facto standard for threat sharing to achieve collaborative mitigation. The main drawback of the TAXII STIX combination is its inability to establish trust between the receiver and the sender of the threat data. Trust establishment between the peers before threat information sharing is one of the main requirements for threat data sharing to achieve successful collaborative mitigation.Fidelis Barncat [33] is a threat intelligence database for sharing attacker information. It offers a tight security package that automates, correlates, orchestrates, and integrates metadata from across the network, endpoint, and trickery defenses to help the user swiftly detect, chase, and respond with accuracy to threats. There are privacy issues in the threat feed of Fidelis Barncat. The feed contains private information about the victim. The data generated during the decompilation of the virus includes victim server info: FTP hosts, FTP passwords, usernames, IPs, and passwords of the victim organization. In addition, the threat data contains an attack pattern and hashes. This situation leads to a none GDPR compliant environment. None GDPR compliance may harm the sender of the threat feed [34].Such issues hamper the user’s trust in sharing threat data to achieve collaborative mitigation. The reasons of lack of coordinated efforts in threat intelligence sharing are listed below:(i)
Privacy and secrecy of security posture of the victim [35](ii)
Tradecraft on victim data by attacker [36, 37](iii)
Lack of structure and context of the shared data [38](iv)
The nonexistence of pertinent records [39](v)
Lack of motivations [40]Altogether, these points of interest create a climate where people and organizations are reluctant to share threat data. If sharing takes place, the realities are uncovered so that the moment noteworthiness gets to be far-fetched. Unfortunately, this ends in a worldview where conceivably fundamental focuses that can halt dangers frequently, by no implies, reach the imminent peers in time.The transparency and security features provided by the blockchain can enhance cybersecurity issues. They can connect devices in a decentralized manner employing digital signatures.This decentralized establishment reduces the chance of attack initialization from a central point for the attacker. Once an assault happens, the information concerning the occurrence can be unnoticed, jumbled, and complex. However, blockchain can proficiently outline what takes place.During the recent years, few research initiatives have aimed for a reliable framework that considers the issues occurring during threat sharing [41–47]. This has led to blockchain-based approaches, but still none is comprehensive enough.


## 2.1. IoT Botnet Detection

Due to diverse reasons, from comparatively fewer computing capabilities to the pressure on the market, there has been a trend to ship and deploy the IoT devices and applications with less secure security controls. Security researchers in academia [12] and industry [13, 14] have been identifying the severe risks associated with this trend of negligence in IoT security [15].There have been numerous honeypot-based IoT botnet detection efforts. Pa et al. [16] proposed the IoT honeypot. Another attempt in this regard is [17]. These are low-interaction honeypots, an emulated package that provides the attacker with a limited level of interaction and is of little use for the practical deployments in the IoT devices.Numan et al. discussed that DDoS mitigation solutions at the service provider’s end have many business advantages for Internet service providers. In this way, not only ISPs can safeguard themselves from DDoS attacks, but they also can offer DDoS mitigation protection to their customers, leading to secure and reliable Internet services [18]. However, these solutions are costly and protect DDoS at its destination end rather than the source end. Therefore, ISP-based DDoS detection and mitigation solutions that block the CNC during the IoT Botnet propagation stage before the launch of actual DDoS are more effective. Therefore, there is a need for such kinds of solutions.There have been some efforts on the DDoS preventive techniques in the Internet of Things [19]. For example, Dao et al. proposed to install Smart filters at the edge of the attack source or destination. A central controller is deployed, performing coordination among the smart filters. The main controller restricts each smart filter by adopting suitable parameters into its self-organizing map module, built on the attacking behavior. However, the proposed solution fails to define how to identify the source of the attack. Moreover, the complexity of the proposed method made it unsuitable for smart home and smart office scenarios.An access control mechanism, Manufacturer Usage Description (MUD) enables functional correctness to devices [20, 21]. MUD profiles are available on MUD servers openly. The MUD profile consists of private consumer information. Therefore, there is a chance of leakage of the consumer’s data.Furthermore, a compromised device might direct toward an illegitimate or corrupted profile as the MUD’s DHCP and LLDP methods do not authenticate the device. MUD standard suggests the use of an X.509 extension. However, most Internet of Things home gateways and WiFi access routers do not possess X.509 certification. The deployment of the proposed MUD solution is based and dependent on the manufacturer of the devices. The implementation of the defense solution must not be dependent on the manufacturer. Consumers and users must be capable of deploying the defense solution independently.Heimdal is an intrusion detection solution based on the principle of whitelisting aimed at the IoT devices [22]. It can operate on gateway routers and offer protection to all the devices behind the gateway router. It is continually applied on every device present in the network. Although the whitelisting-based mechanism proposed in Heimdal produces good results, the limitation of this approach is its reliance on VirusTotal, which would hinder the detection of zero-day malware.A collaborative defense scheme to confront Mirai is proposed by [23]. The authors deployed a white Mirai, which expels the Mirai malware and blocks the communication ports in case of a Mirai attack. Although collaborative defense mechanisms are more productive, yet these solutions have shortcomings. The limitation of this scheme is that it only defeats the original Mirai malware. Furthermore, the Mirai variant may use other ports and vulnerabilities. Therefore, there is a need for a collaborative defense scheme to detect any Internet of Things malware.A SIEM-based system for the accurate identification of malicious activities in the Internet of Things is proposed [24]. The authors discuss vulnerabilities presented in IoT devices. The detection of malicious activities in IoT devices is detected using SIEM. However, SIEM deployment for IoT devices in the smart home scenario is costly and not cost-effective. Moreover, the integrity of the security events generated by SIEM is critical. Its alteration would lead to the generation of false alarms. Also, a centralized design for detecting abnormalities in IoT systems creates a single point of failure and attack.An e-MUD for IoT botnets prevention on home WiFi routers is presented in [25]. As MUD does not consider identifying and patching vulnerabilities present in the device before the issuance of the MUD profile, a device can be compromised even in the presence of the Manufacturer Usage Description profile by exploiting either the configuration vulnerabilities or firmware vulnerabilities present in the device. E-MUD presents an evaluation study of the Manufacturer Usage Description (MUD), identifies its weaknesses, and proposed enhancements in its architecture. It proposed a mechanism for identifying and eliminating the configuration vulnerabilities before creating the MUD profile for a device to minimize the attack surface. The authors adopt the OWASP firmware testing methodology for discovering vulnerabilities in the firmware of WiFi home routers. The device is allowed to request the MUD profile only if the identified firmware vulnerabilities are low. A Usage, Communication and Access Monitoring Based Botnets Detection System for IoT is proposed in [26] . The proposed solution has three main components, i.e., descriptor, monitor, and comparator. Descriptor defines device usage, communication, and access policies. Monitor observes the current state of device usage, communication, and access. Anomalies are detected by the comparator. Results show that the proposed detection system successfully detects Mirai IoT malware.


## 2.2. Collaborative Mitigation Approaches

The faith that sharing security attack evidence amongst systems would enhance the general protective position of the public is gaining popularity. For example, during the post-Morris Worm attack, the government of the US made CERT. Similarly, PDD-63 made ISACs help fight the perceived cyber threats [27]. Gordon et al. assessed the state of attacker information sharing and presented an economic incentive-based prototype that broke down the managerial expense [28]. This effort was then extended by Gal-Or et al. by utilizing game theory to assess the demand-side consequences happening underneath the existing sharing model [29]. The two works lay the foundation for understanding the advantages of sharing. In particular, sharing gives expected benefits to security and cost savings [30].The most promising cyber threat intelligence standards in the market today are the Trusted Automated Exchange of Indicator Information (TAXII) [31] and Structured Threat Information Expression (STIX) [32]. STIX and TAXII are open community efforts that are continually developing. The MITRE Corporation initially served on behalf and under the sponsorship of the US Homeland Security Department as the creator and moderator of both the STIX and TAXII communities. The US Homeland Security Department, in 2015, moved STIX and TAXII for further development to the OASIS Cyber Threat Intelligence Technical Committee (OASIS CTI TC). Today, STIX and TAXII are widely discussed in the community.Moreover, they have already incorporated many platforms and tools, making them a de facto standard for threat sharing to achieve collaborative mitigation. The main drawback of the TAXII STIX combination is its inability to establish trust between the receiver and the sender of the threat data. Trust establishment between the peers before threat information sharing is one of the main requirements for threat data sharing to achieve successful collaborative mitigation.Fidelis Barncat [33] is a threat intelligence database for sharing attacker information. It offers a tight security package that automates, correlates, orchestrates, and integrates metadata from across the network, endpoint, and trickery defenses to help the user swiftly detect, chase, and respond with accuracy to threats. There are privacy issues in the threat feed of Fidelis Barncat. The feed contains private information about the victim. The data generated during the decompilation of the virus includes victim server info: FTP hosts, FTP passwords, usernames, IPs, and passwords of the victim organization. In addition, the threat data contains an attack pattern and hashes. This situation leads to a none GDPR compliant environment. None GDPR compliance may harm the sender of the threat feed [34].Such issues hamper the user’s trust in sharing threat data to achieve collaborative mitigation. The reasons of lack of coordinated efforts in threat intelligence sharing are listed below:(i)
Privacy and secrecy of security posture of the victim [35](ii)
Tradecraft on victim data by attacker [36, 37](iii)
Lack of structure and context of the shared data [38](iv)
The nonexistence of pertinent records [39](v)
Lack of motivations [40]Altogether, these points of interest create a climate where people and organizations are reluctant to share threat data. If sharing takes place, the realities are uncovered so that the moment noteworthiness gets to be far-fetched. Unfortunately, this ends in a worldview where conceivably fundamental focuses that can halt dangers frequently, by no implies, reach the imminent peers in time.The transparency and security features provided by the blockchain can enhance cybersecurity issues. They can connect devices in a decentralized manner employing digital signatures.This decentralized establishment reduces the chance of attack initialization from a central point for the attacker. Once an assault happens, the information concerning the occurrence can be unnoticed, jumbled, and complex. However, blockchain can proficiently outline what takes place.During the recent years, few research initiatives have aimed for a reliable framework that considers the issues occurring during threat sharing [41–47]. This has led to blockchain-based approaches, but still none is comprehensive enough.


## 3. Threat Model

Recent past cyber-attacks demonstrate that susceptibilities present in IoT devices are exploited for initiating DDoS. After compromising the IP cameras, DVRs, and WiFi access routers, Mirai malware launches nine different types of attacks: UDP flood, SYN flood, ACK flood, TCP stomp flood, Valve source engine specific flood, GRE IP flood, GRE Ethernet flood, HTTP flood, and DNS water torturing. Figure1 shows the infection process of Mirai malware, and Figure 2 elaborates on the details of the analysis of the functionality flow of the Mirai botnets. Scanner server is responsible for scanning vulnerable devices, brute-forcing the device password, and reporting them to loader server.Figure 1
Compromising and exploiting IoT devices for launching DDoS attack.Figure 2
Analysis of functionality flow of Mirai.The command and control server collaborates with human operators, allowing them to govern the botnets, connected to a database, and provisions three kinds of performers, each permitted to execute different procedures: admin, user, and bot. In addition, the command and control server runs two services, rental services on port 101 and master services listening on port 23.


### 3.1. Mirai Malware Components

Mirai bot operates on compromised and infected devices. It has three submodules, namely, “scanner,” “killer,” and “attacker.” The “scanner” module is responsible for scanning for new vulnerable devices and finding any weak device, directing the scan result to the “reporting server.” The “killer” module is in charge of finding and killing other malware running on the compromised machine. The 'Attacker' component performs the actual DDoS attack; it receives the attack command from the command and control server. On execution, the bot deletes itself, rewrites function pointers, changes code execution and process name, and connects to the CNC server. The reporting server receives scan results of vulnerable devices from the scanner server and newly compromised devices (bots) and forwards them to the loader server. The loader server transfers the Mirai malware binaries to susceptible devices, making them bots, consequently making them part of the botnet.


### 3.2. Mirai Malware Functionality

The Mirai CNC initially scans several IP addresses to discover susceptible devices. In the second phase, the pool of the Internet Protocol (IP) addresses of the susceptible devices are transferred to the loader server, which loads the Mirai malware on the reported vulnerable IoT devices for making bots. Malware is a malicious program that is implemented on infested devices. As a next step, malware eliminates itself from the infected machine, altering its surname to a random value. Afterwards, it attempts to shelter itself from any rival malware by a background killer process, which destroys competing worms that ultimately belong to the same device. It also prevents everybody from breaking using additional conventional means, such as Telnet, SSH, or HTTP. The main objective of this action is to extend the attack perspective of every device, making sure the complete readiness of all its computational means for the attack. As a final point, it drives into the main lead implementation phase. This round establishes a connection with the CNC server and keeps it active, waiting for attack instructions. In case it receives an attack command, the bot accomplishes the attack. Next, the bot must complete a domain resolution to connect to the reporting server or main command and control server by getting the corresponding IP address. The process-wise functionality of Mirai malware is given below:(1)
Mirai scanner scans for vulnerable devices(2)
Mirai scanner pass on scans results to loader server(3)
Loader server loads Mirai malware on vulnerable devices(4)
Vulnerable devices act as a bot after Mirai malware is loaded on it(5)
The bot then kills its competitor(6)
The bot starts scanning for more vulnerable devices(7)
It reports new bots to the loader server(8)
The CNC issues the attack commands(9)
Bot initiates DDoS attacks on the destination


## 3.1. Mirai Malware Components

Mirai bot operates on compromised and infected devices. It has three submodules, namely, “scanner,” “killer,” and “attacker.” The “scanner” module is responsible for scanning for new vulnerable devices and finding any weak device, directing the scan result to the “reporting server.” The “killer” module is in charge of finding and killing other malware running on the compromised machine. The 'Attacker' component performs the actual DDoS attack; it receives the attack command from the command and control server. On execution, the bot deletes itself, rewrites function pointers, changes code execution and process name, and connects to the CNC server. The reporting server receives scan results of vulnerable devices from the scanner server and newly compromised devices (bots) and forwards them to the loader server. The loader server transfers the Mirai malware binaries to susceptible devices, making them bots, consequently making them part of the botnet.


## 3.2. Mirai Malware Functionality

The Mirai CNC initially scans several IP addresses to discover susceptible devices. In the second phase, the pool of the Internet Protocol (IP) addresses of the susceptible devices are transferred to the loader server, which loads the Mirai malware on the reported vulnerable IoT devices for making bots. Malware is a malicious program that is implemented on infested devices. As a next step, malware eliminates itself from the infected machine, altering its surname to a random value. Afterwards, it attempts to shelter itself from any rival malware by a background killer process, which destroys competing worms that ultimately belong to the same device. It also prevents everybody from breaking using additional conventional means, such as Telnet, SSH, or HTTP. The main objective of this action is to extend the attack perspective of every device, making sure the complete readiness of all its computational means for the attack. As a final point, it drives into the main lead implementation phase. This round establishes a connection with the CNC server and keeps it active, waiting for attack instructions. In case it receives an attack command, the bot accomplishes the attack. Next, the bot must complete a domain resolution to connect to the reporting server or main command and control server by getting the corresponding IP address. The process-wise functionality of Mirai malware is given below:(1)
Mirai scanner scans for vulnerable devices(2)
Mirai scanner pass on scans results to loader server(3)
Loader server loads Mirai malware on vulnerable devices(4)
Vulnerable devices act as a bot after Mirai malware is loaded on it(5)
The bot then kills its competitor(6)
The bot starts scanning for more vulnerable devices(7)
It reports new bots to the loader server(8)
The CNC issues the attack commands(9)
Bot initiates DDoS attacks on the destination


## 4. The Proposed IoT Botnet Detection System

IoT devices are typically run on specific applications and constitute a network generally termed as a stub network. These devices have well-defined access, communication, and usage. Furthermore, the network administrator these devices are deployed has full authorized access to these devices. Let us consider installing a temperature sensor to pick up the room temperature and transfer the sensed information to the database system to comprehend this concept. In this case, the sensing temperature of the room is the usage of the IoT device, sending sensed data to the database machine is the predefined communication of the IoT device, and the network administrator of the network in which these IoT devices are part has authorized access to these devices. This research proposes a botnet detection solution for the IoT based on the above-explained principle. The proposed botnet detection solution is presented in Figure3.Figure 3
The flow of the proposed IoT botnets detection system.The suggested detection technique has a policy descriptor that refers to the device’s predefined policies for access, communication, and usage. Another component is the policy monitor, whose first job is to observe the present state of access on the device, communication of the device, and device usage. The comparator matches the current access, communication, and usage with predefined access, communication, and usage policies. If immediate access to the device, communication pattern of the device, and usage of the device fit according to the predefined rules, the behavior is called normal. If there is a disparity, the behavior is called attack behavior. The attack classifier categorizes attack behavior as one of the following violations: access policy, communication policy, and usage policy. The access, communication, and usage monitor report these violations of the predefined policies. At this point, the botnet detection scheme produces alarms to network administrators.


### 4.1. System Model

In the proposed botnet detection system, aB number of nodes are in the network. The number of nodes present in a local network is presented as B=b0,b1,b2⋯⋯bn. A node b0 observes its neighbouring nodes. The neighbours of b0 is a set of nodes having one-hop contact with node b0 and are represented as Nbb0=b1,b2⋯⋯bn. Every node bi possesses different attributes. The set of attributes of the node bi can be denoted as Abi=a1⋯⋯am. The node b0 observes the activity of the node bi by observing its attributes. If node b0 observes its neighbouring nodes Nib0=b1⋯⋯bn, it stores the set of the corresponding attribute vectors ANbb0=ab1⋯⋯abm. This can be represented in matrix form as follows.
(1)ANbbo=ab11ab12⋯ab1mab21ab22⋯ab2m⋮⋮⋮⋮abn1abn2⋯abnm.More precisely, the attributes of any node include access policyaccessb0, communication policy comb0, and usage policy usgb0. These are generic attributes and can be of homogenious and hetrogenious setup. The set of defined access attributes vector ADb0 can be represented in matrix form as follows.
(2)AccessDNbbo=accessDb11⋯accessDb1maccessDb21⋯accessDb2m⋮⋮⋮accessDbn1⋯accessDbnm.The set of current access attributes vectorAccessCb0 can be represented in matrix form as follows.
(3)AccessCNbbo=accessCb11⋯accessCb1maccessCb21⋯accessCb2m⋮⋮⋮accessCbn1⋯accessCbnm.The set of defined communication attributes vectorcomDb0 can be represented in matrix form as follows.
(4)ComDNbbo=comDb11comDb12⋯comDb1mcomDb21comDb22⋯comDb2m⋮⋮⋮⋮comDbn1comDbn2⋯comDbnm.The set of current communication attributes vectorcomCb0 can be represented in matrix form as follows.
(5)ComCNbbo=comCb11comCb12⋯comCb1mcomCb21comCb22⋯comCb2m⋮⋮⋮⋮comCbn1comCbn2⋯comCbnm.


### 4.2. Detection of Access Policy Violation

LetAccessCbi is the current access control attribute of the node bi observed by its neighbouring nodes Nibi=b1⋯⋯bn during time interval t and AccessDbi is the Access control of node bi in the defined access policy. At any instant t, if the current access control AccessCbi is the same as AccessDbi defined in policies, node access control behaviour is normal. Mathematically
(6)AccessCbi==AccessDbiaccessCb11accessCb12⋯accessCb1maccessCb21accessCb22⋯accessCb2m⋮⋮⋮⋮accessCbn1accessCbn2⋯accessCbnm==accessDb11accessDb12⋯accessDb1maccessDb21accessDb22⋯accessDb2m⋮⋮⋮⋮accessDbn1accessDbn2⋯accessDbnm.For any nodebi, if both AccessCbi and AccessDbi are not equal, then the behaviour is termed as access policy violation. Mathematically
(7)AccessCbi≠AccessCbiaccessCb11accessCb12⋯accessCb1maccessCb21accessCb22⋯accessCb2m⋮⋮⋮⋮accessCbn1accessCbn2⋯accessCbnm≠accessDb11accessDb12⋯accessDb1maccessDb21accessDb22⋯accessDb2m⋮⋮⋮⋮accessDbn1accessDbn2⋯accessDbnm.The detection system generates an alarm and sends it to the network administrator.


### 4.3. Detection of Communication Policy Violation

LetcomCbi is the current communication attribute of the node bi observed by its neighbouring nodes Nib0=b1⋯⋯bn during time interval t and comDbi is the communication attribute of the node bi in the defined communication policy. At any instant t, if the current communication policy comCbi is the same as comDbi defined in policies, node communication is normal. Mathematically
(8)comCbi==comDbicomCb11comCb12⋯comCb1mcomCb21comCb22⋯comCb2m⋮⋮⋮⋮comCbn1comCbn2⋯comCbnm==comDb11comDb12⋯comDb1mcomDb21comDb22⋯comDb2m⋮⋮⋮⋮comDbn1comDbn2⋯comDbnm.For any nodebi, if both comCbi and comDbi are not equal, then the behavior is termed as communication policy violation. Mathematically
(9)comCbi≠comDbicomCb11comCb12⋯comCb1mcomCb21comCb22⋯comCb2m⋮⋮⋮⋮comCbn1comCbn2⋯comCbnm≠comDb11comDb12⋯comDb1mcomDb21comDb22⋯comDb2m⋮⋮⋮⋮comDbn1comDbn2⋯comDbnm.The detection system generates an alarm and sends it to the network administrator.


### 4.4. Detection of Usage Policy Violation

LetusgCbi is the current usage attribute of the node bi observed by its neighbouring nodes Nib0=b1⋯⋯bn during time interval t and usgDbi is the usage attribute of the node bi in the defined usage policy. At any instant t, if the current usage policy usgCbi is same as usgDbi defined in policies, node usage is normal. Mathematically
(10)usgCbi==usgDbiusgCb11usgCb12⋯usgCb1musgCb21usgCb22⋯usgCb2m⋮⋮⋮⋮usgCbn1usgCbn2⋯usgCbnm==usgDb11usgDb12⋯usgDb1musgDb21usgDb22⋯usgDb2m⋮⋮⋮⋮usgDbn1usgDbn2⋯usgDbnm.For any nodebi, if both usgCbi and usgDbi are not equal, then the behaviour is termed as usage policy violation. Mathematically
(11)comCbi≠comDbiusgCb11usgCb12⋯usgCb1musgCb21usgCb22⋯usgCb2m⋮⋮⋮⋮usgCbn1usgCbn2⋯usgCbnm≠usgDb11usgDb12⋯usgDb1musgDb21usgDb22⋯usgDb2m⋮⋮⋮⋮usgDbn1usgDbn2⋯usgDbnm.The detection system generates an alarm and sends it to the network administrator.


### 4.5. Explicit Notification of Device Health State to Network Administrator

The detection system periodically reports the health status of devices to the network administrator. If the network administrator does not get an explicit notification from the detection system, they assume that all the devices in the network are either under attack or have been compromised. In that case, it reboots all the devices in the network.


### 4.6. Local Mitigation Actions

The detection system initializes the local mitigator. Then, it performs the following three main tasks.(i)
Change device credentials: The attacker gets access to the device by successfully brute-forcing the device login credentials. The local mitigator changes the device login credentials and informs the network administrator about the new access credentials as a first defensive measure(ii)
Block attacker domain and IPs address access to devices: Local mitigator blocks access of the identified “command and control” server’s domain and IPs to devices in the network(iii)
Reboot the device: The Internet of Things malware resides in volatile memory. Rebooting the device would remove the malware from the device. Instead, the local mitigator reboots the infected devices to abolish Mirai from devices


## 4.1. System Model

In the proposed botnet detection system, aB number of nodes are in the network. The number of nodes present in a local network is presented as B=b0,b1,b2⋯⋯bn. A node b0 observes its neighbouring nodes. The neighbours of b0 is a set of nodes having one-hop contact with node b0 and are represented as Nbb0=b1,b2⋯⋯bn. Every node bi possesses different attributes. The set of attributes of the node bi can be denoted as Abi=a1⋯⋯am. The node b0 observes the activity of the node bi by observing its attributes. If node b0 observes its neighbouring nodes Nib0=b1⋯⋯bn, it stores the set of the corresponding attribute vectors ANbb0=ab1⋯⋯abm. This can be represented in matrix form as follows.
(1)ANbbo=ab11ab12⋯ab1mab21ab22⋯ab2m⋮⋮⋮⋮abn1abn2⋯abnm.More precisely, the attributes of any node include access policyaccessb0, communication policy comb0, and usage policy usgb0. These are generic attributes and can be of homogenious and hetrogenious setup. The set of defined access attributes vector ADb0 can be represented in matrix form as follows.
(2)AccessDNbbo=accessDb11⋯accessDb1maccessDb21⋯accessDb2m⋮⋮⋮accessDbn1⋯accessDbnm.The set of current access attributes vectorAccessCb0 can be represented in matrix form as follows.
(3)AccessCNbbo=accessCb11⋯accessCb1maccessCb21⋯accessCb2m⋮⋮⋮accessCbn1⋯accessCbnm.The set of defined communication attributes vectorcomDb0 can be represented in matrix form as follows.
(4)ComDNbbo=comDb11comDb12⋯comDb1mcomDb21comDb22⋯comDb2m⋮⋮⋮⋮comDbn1comDbn2⋯comDbnm.The set of current communication attributes vectorcomCb0 can be represented in matrix form as follows.
(5)ComCNbbo=comCb11comCb12⋯comCb1mcomCb21comCb22⋯comCb2m⋮⋮⋮⋮comCbn1comCbn2⋯comCbnm.


## 4.2. Detection of Access Policy Violation

LetAccessCbi is the current access control attribute of the node bi observed by its neighbouring nodes Nibi=b1⋯⋯bn during time interval t and AccessDbi is the Access control of node bi in the defined access policy. At any instant t, if the current access control AccessCbi is the same as AccessDbi defined in policies, node access control behaviour is normal. Mathematically
(6)AccessCbi==AccessDbiaccessCb11accessCb12⋯accessCb1maccessCb21accessCb22⋯accessCb2m⋮⋮⋮⋮accessCbn1accessCbn2⋯accessCbnm==accessDb11accessDb12⋯accessDb1maccessDb21accessDb22⋯accessDb2m⋮⋮⋮⋮accessDbn1accessDbn2⋯accessDbnm.For any nodebi, if both AccessCbi and AccessDbi are not equal, then the behaviour is termed as access policy violation. Mathematically
(7)AccessCbi≠AccessCbiaccessCb11accessCb12⋯accessCb1maccessCb21accessCb22⋯accessCb2m⋮⋮⋮⋮accessCbn1accessCbn2⋯accessCbnm≠accessDb11accessDb12⋯accessDb1maccessDb21accessDb22⋯accessDb2m⋮⋮⋮⋮accessDbn1accessDbn2⋯accessDbnm.The detection system generates an alarm and sends it to the network administrator.


## 4.3. Detection of Communication Policy Violation

LetcomCbi is the current communication attribute of the node bi observed by its neighbouring nodes Nib0=b1⋯⋯bn during time interval t and comDbi is the communication attribute of the node bi in the defined communication policy. At any instant t, if the current communication policy comCbi is the same as comDbi defined in policies, node communication is normal. Mathematically
(8)comCbi==comDbicomCb11comCb12⋯comCb1mcomCb21comCb22⋯comCb2m⋮⋮⋮⋮comCbn1comCbn2⋯comCbnm==comDb11comDb12⋯comDb1mcomDb21comDb22⋯comDb2m⋮⋮⋮⋮comDbn1comDbn2⋯comDbnm.For any nodebi, if both comCbi and comDbi are not equal, then the behavior is termed as communication policy violation. Mathematically
(9)comCbi≠comDbicomCb11comCb12⋯comCb1mcomCb21comCb22⋯comCb2m⋮⋮⋮⋮comCbn1comCbn2⋯comCbnm≠comDb11comDb12⋯comDb1mcomDb21comDb22⋯comDb2m⋮⋮⋮⋮comDbn1comDbn2⋯comDbnm.The detection system generates an alarm and sends it to the network administrator.


## 4.4. Detection of Usage Policy Violation

LetusgCbi is the current usage attribute of the node bi observed by its neighbouring nodes Nib0=b1⋯⋯bn during time interval t and usgDbi is the usage attribute of the node bi in the defined usage policy. At any instant t, if the current usage policy usgCbi is same as usgDbi defined in policies, node usage is normal. Mathematically
(10)usgCbi==usgDbiusgCb11usgCb12⋯usgCb1musgCb21usgCb22⋯usgCb2m⋮⋮⋮⋮usgCbn1usgCbn2⋯usgCbnm==usgDb11usgDb12⋯usgDb1musgDb21usgDb22⋯usgDb2m⋮⋮⋮⋮usgDbn1usgDbn2⋯usgDbnm.For any nodebi, if both usgCbi and usgDbi are not equal, then the behaviour is termed as usage policy violation. Mathematically
(11)comCbi≠comDbiusgCb11usgCb12⋯usgCb1musgCb21usgCb22⋯usgCb2m⋮⋮⋮⋮usgCbn1usgCbn2⋯usgCbnm≠usgDb11usgDb12⋯usgDb1musgDb21usgDb22⋯usgDb2m⋮⋮⋮⋮usgDbn1usgDbn2⋯usgDbnm.The detection system generates an alarm and sends it to the network administrator.


## 4.5. Explicit Notification of Device Health State to Network Administrator

The detection system periodically reports the health status of devices to the network administrator. If the network administrator does not get an explicit notification from the detection system, they assume that all the devices in the network are either under attack or have been compromised. In that case, it reboots all the devices in the network.


## 4.6. Local Mitigation Actions

The detection system initializes the local mitigator. Then, it performs the following three main tasks.(i)
Change device credentials: The attacker gets access to the device by successfully brute-forcing the device login credentials. The local mitigator changes the device login credentials and informs the network administrator about the new access credentials as a first defensive measure(ii)
Block attacker domain and IPs address access to devices: Local mitigator blocks access of the identified “command and control” server’s domain and IPs to devices in the network(iii)
Reboot the device: The Internet of Things malware resides in volatile memory. Rebooting the device would remove the malware from the device. Instead, the local mitigator reboots the infected devices to abolish Mirai from devices


## 5. Proposed Collaborative IoT Botnets Mitigation System

The proposed collaborative mitigation system is depicted in Figures4 and 5. Table 1 illustrates the mathematical notations used in the collaborative mitigation system. In the suggested collaborative mitigation technique, members in the blockchain-based smart contract agree to share attacker information to the members present in the smart contract through its peer mitigator. Every member of the smart contract has its detection system deployed at its premises responsible for detecting the abnormal activities defined in Section 4. After getting attacker evidence from the used detection system, every fellow takes defensive actions via its local mitigator.Figure 4
Functionality flow of the proposed collaborative mitigation system.Figure 5
Functionality flow of the collaborative mitigation system between different vendors.Table 1
Used mathematical notations.
NotationDescriptionTxTransactionSTxTransaction with signatureESTxAn encrypted transaction with a signatureDSTxA decrypted transaction with a signatureSPrKPrivate key of the senderSPpKPublic key of the senderRPrKPrivate key of the receiver or group private keyRPpKPublic key of the receiver or group public keyIf one of the members of the smart contract is an Internet service provider, it also safeguards its customers by blocking access to attacker domains and IPs on their network. In case the CNC server is using the internet connection from one of the smart contract signatory Internet service providers, the Internet service provider takes action and blocks command and control server IP addresses, leading to the prevention of the source of the attack provides proactive defense against IoT botnets. Next are the stages of the anticipated collaborative mitigation system.As a first step, a smart contract is formed. This smart contract confines every contributing member to share invader info with the fellow of the smart contract in case of an attack on IoT devices deployed within their network. This smart contract is joined by various enterprises of IoT devices capable of comprehensive threat intelligence abilities.Figure6 explains the smart contract management stack. Initially, the like-minded vendors form a consortium. The consortium management unit, responsible for managing the consortium, executes the smart contract operation. First, the public-private key pairs would be generated by registration with the certificate authority and certificates from trusted CAs (certificate authorities). In the next phase of the stack, the block is generated, leading to blockchain formation.Figure 6
Smart contract management stack.Suppose an attack is launched on IoT devices deployed by any members. In that case, the proposed botnet detection system becomes aware of the attack based on the violation of the defined policies and reports it to the peer mitigator.The peer mitigator signs it asESPrKTx=STx.The peer mitigator encrypts with group public key or with public keys asERPpKSTx=ESTx .The peer mitigator decrypts this transaction with his/her private key asDRPrKESTx=STx.The peer mitigator then validates the digital signature of the sender by decrypting the message with either the public keys of the or group public key asDSPPKSTx=Tx.Upon receiving attacker information, local mitigators block the attacker access at receiving members end to the network through firewall policies. In the attacker’s case, the IP addresses pole belongs to one of the smart contract signatory ISP; the ISP filters out attack traffic by taking down the CNC server and blocking allocated public IPs.


## 6. Deployment and Implementation

This unit details the implementation and deployment of the Mirai botnet attack setup, proposed detection, and collaborative mitigation system. This research established the lab setup for deploying and implementing the proposed solution, as depicted in Figure7.Figure 7
Topology of the deployed lab setup.


### 6.1. Deployment of Mirai Setup

This study set up the Mirai CNC server (IP address is 192.168.2.11 and domain name “cnc.sajjad.local.”) from its source code [48], having a database, loader, and scanner server “192.168.2.12.” A DNS server “IP address 192.168.2.53” is established to resolve the domain queries made by the devices, two WiFi home routers as IoT devices. A system (IP address 192.168.2.141) is also set up as a DDoS destination target system. The IP addresses of the two WiFi home routers are 192.168.2.71 and 192.168.2.72, respectively. In the initial stage, a scanner server starts scanning for compromised devices. The scan results are reported to the loader server. The binaries of the Mirai malware are loaded on the compromised WiFi home Router by the loader server.


### 6.2. Implementation of Suggested IoT Botnet Detection System

For the implementation of the detection, OSSIM [49] is used. This research first defined the standard policies for the access on the device, communication of the device, and usage of the device for both WiFi access routers. Sample predefined rules are presented in Table 2. At that point, these predefined policies are implemented in the form of OSSIM rules. Those rules were then included in the native rules of Suricata IDS present in the OSSIM. In the attack, the suggested botnet detection system produced alarms. Mitigator started actions required for local mitigation and subsequently initialized collaborative mitigation procedures.Table 2
Example of defined policies for a device.
PolicyDefinitionPolicy for accessing deviceAdministrate access allowed from 192.168.20.201Policy for device communicationCommunicate with 192.168.2.201Policy for device usageCollection of permitted commands


### 6.3. Implementation of Proposed Collaborative Mitigation System

The proposed mitigation system consists of two parts, namely, local mitigator and peer mitigator. This study implemented a local mitigator by implementing a software module. It then executes necessary administrative commands to perform the following three tasks.(i)
Change device credentials: An attacker could compromise the device by successfully brute-forcing the device’s login credentials. Therefore, the local mitigator changes the device login credentials and informs the network administrator about the new access credentials as a first defensive measure(ii)
Block attacker access to devices: The detection system provides the identified command and control server’s domain name and IP addresses to the local mitigator. The local mitigator automatically updates firewall rules for blocking the attacker access to the previously compromised devices in the local network(iii)
Reboot the device: As Mirai malware resides in the volatile memory, rebooting the device can remove the malware from the device. For example, local mitigator reboots the infected devices to remove Mirai from devicesThe collaborative mitigation system uses Hyperledger and Ethereum [50, 51]. Attack information, including attacker domain and IP addresses, is shared with the participants of the smart contract. Figure 8 illustrates the operational flow of a smart contract. Initially, a smart contract is compiled using an online solidity browser [52]. Then, the variables returned by Web3 [53] are executed in the geth terminal [53].Figure 8
Operational flow of smart contract.


## 6.1. Deployment of Mirai Setup

This study set up the Mirai CNC server (IP address is 192.168.2.11 and domain name “cnc.sajjad.local.”) from its source code [48], having a database, loader, and scanner server “192.168.2.12.” A DNS server “IP address 192.168.2.53” is established to resolve the domain queries made by the devices, two WiFi home routers as IoT devices. A system (IP address 192.168.2.141) is also set up as a DDoS destination target system. The IP addresses of the two WiFi home routers are 192.168.2.71 and 192.168.2.72, respectively. In the initial stage, a scanner server starts scanning for compromised devices. The scan results are reported to the loader server. The binaries of the Mirai malware are loaded on the compromised WiFi home Router by the loader server.


## 6.2. Implementation of Suggested IoT Botnet Detection System

For the implementation of the detection, OSSIM [49] is used. This research first defined the standard policies for the access on the device, communication of the device, and usage of the device for both WiFi access routers. Sample predefined rules are presented in Table 2. At that point, these predefined policies are implemented in the form of OSSIM rules. Those rules were then included in the native rules of Suricata IDS present in the OSSIM. In the attack, the suggested botnet detection system produced alarms. Mitigator started actions required for local mitigation and subsequently initialized collaborative mitigation procedures.Table 2
Example of defined policies for a device.
PolicyDefinitionPolicy for accessing deviceAdministrate access allowed from 192.168.20.201Policy for device communicationCommunicate with 192.168.2.201Policy for device usageCollection of permitted commands


## 6.3. Implementation of Proposed Collaborative Mitigation System

The proposed mitigation system consists of two parts, namely, local mitigator and peer mitigator. This study implemented a local mitigator by implementing a software module. It then executes necessary administrative commands to perform the following three tasks.(i)
Change device credentials: An attacker could compromise the device by successfully brute-forcing the device’s login credentials. Therefore, the local mitigator changes the device login credentials and informs the network administrator about the new access credentials as a first defensive measure(ii)
Block attacker access to devices: The detection system provides the identified command and control server’s domain name and IP addresses to the local mitigator. The local mitigator automatically updates firewall rules for blocking the attacker access to the previously compromised devices in the local network(iii)
Reboot the device: As Mirai malware resides in the volatile memory, rebooting the device can remove the malware from the device. For example, local mitigator reboots the infected devices to remove Mirai from devicesThe collaborative mitigation system uses Hyperledger and Ethereum [50, 51]. Attack information, including attacker domain and IP addresses, is shared with the participants of the smart contract. Figure 8 illustrates the operational flow of a smart contract. Initially, a smart contract is compiled using an online solidity browser [52]. Then, the variables returned by Web3 [53] are executed in the geth terminal [53].Figure 8
Operational flow of smart contract.


## 7. Results and Analysis

This section includes the results and analysis of both detection and mitigation systems.


### 7.1. Results and Analysis of Detection System

The process of compromising the devices entails the following six steps.(1)
Compromising the initial login access of the device by the attacker(2)
Getting access to the device shell(3)
Connection establishment with CNC(4)
Getting malware from CNC(5)
Malware execution on the compromised device(6)
A compromised device acting as a botTable2 depicts the defined policies for a device. The proposed botnet detection system produces alarms at each step of the device compromise if there is a violation of predefined policies. Table 3 describes the plotting of the alarms generated by the proposed botnet detection system during each stage of the device compromise. A thorough study of the packets taken by the proposed botnet detection system during every step of the device compromise is carried out in the subsequent subsections.Table 3
Alarms generated at every step of making a device bot.
AlarmStepsViolation of access policyCompromising the initial login accessGetting access to the device shellCommunication policy violationConnection establishment with CNCGetting malware from CNCUsage policy violationCommand execution in BusyBoxA compromised device acting as bot


#### 7.1.1. Compromising the Initial Login Access of the Device by the Attacker

As a first step, CNC attempts to access the target device through login. The traffic packets transferred between the CNC server and the target device are captured during this process. The CNC server succeeded in getting access to the target using the username root and default password device, as shown in Figure9.Figure 9
Packets taken by botnet detection system during attacker efforts of compromising the initial login access of the device.


#### 7.1.2. Getting Access to the Device Shell

After successfully logging into the target device, the CNC servers’ next job is to get into the BusyBox of the compromised device. The packet captured during the attempt of the CNC server to access the BusyBox of compromised is shown in Figure10.Figure 10
Packets taken by botnet detection system during attackers getting access of the device shell.


#### 7.1.3. Connection Establishment with CNC

After getting access to the BusyBox, the CNC server directs the compromised device to the web server having Mirai malware binaries. The packets are swapped between the CNC server, and the target device is shown in Figure11.Figure 11
Packets taken by the botnet detection system during Bot Plea of establishing connection with CNC to download malware binaries.


#### 7.1.4. Getting Malware from CNC

After a successful connection establishment, the Mirai binaries are downloaded. The packets captured during this process are shown in Figure12.Figure 12
Packets taken by the botnet detection system during bot acknowledging download of malware binaries.


#### 7.1.5. Malware Execution on the Compromised Device

The CNC server executes the downloaded Mirai binaries attack in this step, as shown in Figure13.Figure 13
Packets taken by the botnet detection system during the execution of the malware binaries downloaded earlier.


#### 7.1.6. Compromised Device Acting as a Bot

After getting access and making the target device a bot, the CNC starts the scan process to find the vulnerabilities in other devices to make them part of the bot.


#### 7.1.7. Mapping between Predefined Policies and Alarms Generated by the Proposed IoT Botnet Detection System

Table2 demonstrates the predefined usage, communication, and access policies. The mapping between violations of predefined policies and the alarms generated by the proposed IoT botnet detection system is depicted in Table 3. Access to devices by the CNC and its shell (BusyBox) is the abuse of the predefined policy for accessing the device. Device communication with CNC Server for downloading Mirai malware binaries is the abuse of the predefined communication policy. Finally, implementation of Mirai malware on the device and the compromised device acting as the bot is the abuse of the predefined policy for usage.


#### 7.1.8. Alarms Generated against Each Attacked Host

In the lab setup, two WiFi access routers having DD-WRT firmware are deployed as vulnerable devices. The command and control server attacks these two devices during the experiment. This research draw alarms generated against each attacked device, as shown in Figure14. Three hundred sixty alarms are made during the attack on the WiFi access router having IP 192.168.2.71. The number of generated alarms is 280 when the router having IP 192.168.2.72 is attacked.Figure 14
Packets taken by the botnet detection system during compromised device acting as bot.


#### 7.1.9. Alarms Generated by Each Attacker Host

The command and control server (192.168.2.11) and scanner (192.168.2.12) are primarily the attacker hosts. In addition, two WiFi access routers, after becoming bots, act as the scanner. Alarms generated against each attacking host are shown in Figure15. The figure depicts that the detection system generates around 540 alerts if the attacker is the command and control server. The number of generated alerts is 150, 110, and 105 in case attacker, WiFi access router 1 has IP address 192.168.2.71, WiFi access router 2 has IP address 192.168.2.72, and scanner server has IP address 192.168.2.12.Figure 15
Alarms generated by each attacking host.


#### 7.1.10. Alarms Generated against Each Attacked Port

During the attack process, the attacker tries to gain access to the WiFi access router by scanning different ports of the target bot. The number of alarms generated against different ports is shown in Figure16. It shows that the detection system against telnet access generates around 520 alerts.Figure 16
Alarms generated against each attacked port.


### 7.2. Results and Analysis of Mitigation

The local mitigator changes the device login credentials and informs the network administrator about the new access credentials as a first defensive measure. The detection system provides the identified command and control server’s domain name, i.e., cnc.sajjad.local, and IP addresses, i.e., 192.168.2.11, to the local mitigator. The local mitigator automatically updates firewall rules for blocking the attacker access to the previously compromised devices in the local network. As Mirai malware resides in the volatile memory, rebooting the device can remove the malware from the device. Local mitigator reboots the infected devices to remove Mirai from devices. The collaborative mitigator writes the attacker IP addresses and the attacked ports to the smart contract and shares them with the member of the smart contract. This information is received by all the members of the smart contract. The local mitigator of each member blocks the access of the attacker IP address and the attacked ports. After the mitigation steps, this research again launched the attack on the WiFi access router from the Mirai scanner. Mirai scanner (scanrec.sajjad.local having IP 192.168.2.12) cannot compromise WiFi access routers as attacker access on the WiFi access router is blocked by the firewall. The peer mitigator of any organization takes the proactive defense steps. The peer mitigator of any vendor or peer Internet service provider safeguards the users or customers of the vendors or Internet service provider from becoming part of the IoT botnets.Similarly, the proactive defense steps taken by the attacker organization, vendor, or Internet service provider completely stop the source of the attack. In this way, smart contract and blockchain-based collaborative mitigation provide a means of proactive defense to all the members of the smart contract without members experiencing the attack themselves. The actions taken by the collaborative mitigator of the attacker vendor or Internet service provider completely stop the attack source.


#### 7.2.1. Throughput

The measurement of the per second transactions is called throughput. Figure17 elaborates the throughput of the proposed system. Due to the complexity and difficulty of the Ethereum’s consensus protocol “proof of work,” the initial transaction occurred after 360 seconds. Contrary to this, in Hyperledger, the initial transaction occurred after 7 seconds.Figure 17
Throughput of the proposed collaborative mitigation system.


#### 7.2.2. Scalability

Figure18 shows the scalability evaluation of the collaborative mitigation. Hyperledger is less scalable than Ethereum. Nevertheless, it is also eminent that transactions per second also declined with the number of peer nodes.Figure 18
Scalability of the proposed collaborative mitigation system.


#### 7.2.3. Latency

As shown in Figure17, the occurrence of the first transaction is at 350 seconds. Due to the higher difficulty level of Ethereum’s “proof of work” consensus algorithm, 10,000 transactions occurred in 440 seconds. In Hyperledger’s case, an initial transaction happens at around 4 seconds, while 10000 transactions occur in 440 seconds.


#### 7.2.4. Performance Discussion

Ethereum Casper, an improved version of the Ethereum consensus protocol, was launched in May 2018 [54]. Version 2 of the said protocol utilizing a “proof of stake” based improved consensus mechanism is expected to resolve the issues present in Ethereum [55]. This release targets enhanced scalability and performance. These improvements would probably solve performance issues at Ethereum.


#### 7.2.5. Encryption Overhead

By default, blockchain does not include data encryption. In the proposed collaborative mitigation system, the peer mitigator in the proposed collaborative mitigation system sends the signed transaction by encrypting it with the receiver public keys one by one. This process causes an extra encryption overhead at the sender side and additionally may cause delays. Figure19 depicts the comparison of the time taken by the arrival of threat data at the receiver end in a proposed scheme with OpenTAXII [56], Anomali STAXX [57], MISP [58], and Soltra Edge [59]. The proposed scheme implementation with Ethereum takes the most time compared to the proposed scheme implementation with Hyperledger and other threat data-sharing platforms. The symmetric group encryption key can be used to avoid the encryption overhead on the sender side.Figure 19
Delay caused by the encryption overhead.


### 7.3. Comparative Analysis

There are numerous threat exchange protocols. Each protocol has a specific exchange format. An exchange protocol is a set of rules describing how network devices across a computer network can be interconnected to create a channel for transmitting data through exchange formats [60, 61]. Table 4 describes some of the threat exchange protocols and their formats.Table 4
List of threat exchange protocols and their formats.
S#ProtocolFormat1“Common Intrusion Detection Framework (CIDF)” [62]“Common Intrusion Specification Language (CISL) Messages” [63]2Real-time Inter-network Defense (RID) [64]“Incident Object Description Exchange Format (IODEF)” [65–67]3XEP-0268 Incident Handling [68–71]Incident Object Description Exchange Format (IODEF)4“Intrusion Detection Exchange Protocol (IDXP)” [72]“The Intrusion Detection Message Exchange Format (IDMEF)” [73, 74]5Simple Mail Transfer Protocol (SMTP) [75]Common Announcement Interchange Format (CAIF), Abuse Reporting Format(ARF) [76]6CEE Log Transport (CLT) [77]Command Event Expression (CEE) [78]7Syslog Protocol [79]Syslog [80]


#### 7.3.1. Evaluation Parameter and Criteria

The exchange protocols are assessed on the following twelve parameters:(1)
Confidentiality(2)
Nonrepudiation(3)
Authenticity(4)
Trust(5)
Integrity(6)
Reliable message transport(7)
Scalability(8)
Product based on standardThe confidentiality principle defines the capacity to safeguard sensitive information from exposure to unauthorized parties. The authenticity defines the ability to assess if the exchanging parties are really whom they have claimed to be and therefore use authentication mechanisms. The potential to secure data from unauthorized parties’ alteration or deletion is defined by the integrity. If the transmission of a threat data uses a guaranteed delivery to prevent duplicate messages and message loss, an exchange protocol uses “reliable message transport.” The ability to manage various network sizes is defined by the metric of “scalability.” Ensuring that the sender and receiver cannot deny the transmission and receiving of data is termed nonrepudiation.The sender and receiver should have a trusting relationship with each other. The recipient of the threat data should authenticate the origins of the received data and verify the correctness of the received data and the sender. Thus the threat sharing platform should have a mechanism that should provide correctness of the received data.


#### 7.3.2. Evaluation Results

The following sections discuss the evaluation results. Table5 presents the numerical evaluation criteria.Table 5
Description of evaluation criteria.
S. noLevelScore1Low52Medium103High154Very high20(1)Confidentiality. Figure 20 depicts the comparison of the confidentiality of the CTI platforms to the proposed mechanism. CIDF offers a matchmaking service with the help of which CIDF components use authenticated and secured communications between CIDF components. The matchmaker service also acts as a certificate authority (CA).Figure 20
Data confidentiality in Information Sharing Platform concerning proposed blockchain platform.Therefore, the confidentiality, integrity, and authentication capabilities of the CIDF are great. RID utilizes XML encryption to offer confidentiality in the “IODEF’ and “IODEF-RID” [132] systems, based on the iodef: restriction attribute. To provide confidentiality, IDXP uses TLS’ underlying BEEP protection profile with the “TLS DHE DSS WITH 3DES EDE CBC SHA” cipher suite. XMPP employs TLS to guarantee privacy and confidentiality, making the confidentiality services and capabilities of XMPP and XEP-0268 strong enough. SMTP does not include the usage of any technique to guarantee protection. The potential for secrecy is, therefore, low in SMTP. To counter security event disclosure, CLT and Syslog RFC 5424 use TLS; thus, the confidentiality capacity is high. In the proposed blockchain-based threat information sharing, encrypting the digitally signed transaction with the receiver’s public keys provides a high level of confidentiality.(2)Nonrepudiation. As trust in CIDF is high due to origin authentication provided by Generalized Intrusion Detection Objects (GIDO) messages exchanged between CIDF-compliant components, nonrepudiation is high. As RID, CLT, and Syslog (RFC 5425) have high trust due to TLS based authentication and authorization, it has high nonrepudiation. XEP-0268 has low nonrepudiation as sharing incident reports with trusted peers is optional. IDXP has high nonrepudiation due to high trust as it employs a BEEP security profile. A user cannot deny a transaction as its private key signs in the proposed blockchain-based threat information sharing. Figure 21 demonstrates the comparison of the nonrepudiation property of the CTI platforms regarding the proposed mechanism.Figure 21
Nonrepudiation in Information Sharing Platform with respect to proposed blockchain platform.(3)Authenticity. Figure 22 shows the comparison of the authenticity of the CTI platforms to the proposed mechanism. To authenticate the sender of the RID message, RID utilizes digital signatures on the hash of the RID message with an X.509v3 certificate provided by the trusted authority. XEP-0268 is XMPP-based. The authentication capabilities of XEP-0268 are considered to be strong because XMPP uses the “Simple Authentication and Security Layer (SASL)” for peer authentication. IDXP provides mutual authentication by employing the public-key certificates of the TLS security profile of underlying BEEP protocol. Syslog RFC 5425 also uses mutually authenticated channels with cryptographic algorithms and protocols commonly deployed. As CLT is Syslog RFC 5424, the CLT has the same features as Syslog RFC 5424. The authentication capacity of the “RID, IDXP, CLT, and Syslog RFC 5425” exchange protocols is high. The SMTP exchange protocols cannot verify that the declared sender is the message-sending peer, so the SMTP authentication functionality is low. IDXP utilizes the underlying BEEP protection profile of TLS with the “TLS DHE DSS WITH 3DES EDE CBC SHA” cipher suite to provide high authentication capabilities. In the proposed blockchain-based mechanism, the user sends a digital signature (encryption with its private key) to the data, ensuring user and data authentication.Figure 22
Authentication process in Information Sharing Platform with respect to proposed blockchain platform.(4)Trust. Trust in CIDF is high due to origin authentication provided by Generalized Intrusion Detection Objects (GIDO) messages exchanged between CIDF-compliant components. RID, CLT, and Syslog (RFC 5425) have high trust due to TLS-based authentication and authorization. XEP-0268 has low trust as sharing incident reports with trusted peers is optional. IDXP has high trust as it employs a BEEP security profile. A BEEP security profile is used to establish trust between end-to-end peers of the IDXP. In the proposed blockchain-based solution, trust is established via the smart contract.Additionally, each transaction contains the hash of the previous transaction forming the data origin authentication. Moreover, the sender encrypts the data with its private key before sending it to the receiver. Figure23 elaborates the comparison of the trust of the CTI platforms with respect to the proposed mechanism.Figure 23
Trust in Information Sharing Platform with respect to proposed blockchain platforms.(5)Integrity. Figure 24 depicts the comparison of the integrity of the CTI platforms with respect to the proposed mechanism. The integrity of messages sent over the network is tackled using authentication methods. The “RID, XEP-0268, IDXP, CTL and Syslog RFC 5424” TLS-based protocols support message integrity by using TLS message authentication, TLS security profile of BEEP, or SASL profile members. The capacity of “RID, XEP-0368, IDXP, CTL, and Syslog RFC 5424” TLS-based exchange protocols to maintain the integrity of the transmitted message is high. On the other hand, SMTP does not have any mechanisms to guarantee integrity, and thus, the integrity capacity is low. In the proposed blockchain-based threat, information sharing digital signature of the receiver and hashes of the transaction provides temper proof integrity.Figure 24
Data Integrity in Information Sharing Platform with respect to proposed blockchain platform.(6)Reliable Message Transport. Figure 25 demonstrates the comparison of the reliable message transport of the CTI platforms regarding the proposed mechanism. Reliable CIDF messaging over UDP is the default transport layer protocol for CIDF messages. However, CIDF also uses (i) the message layer directly over UDP without acknowledgement and retransmission, (ii) message layer of the CIDF with acknowledgement and retransmission through UDP, and (iii) the CIDF message layer explicitly over TCP. “RID, XEP-0268, and IDXP” include the use of connection-oriented protocols and therefore use TCP. SMTP is independent of the specific transmission protocol, but a stable, organized data stream channel is necessary. Hence, the ability of a reliable message transport of the protocols “CIDF, RID, XEP-0268, IDXP, SMTP, CLT, and Syslog RFC 5425” is high. In the proposed blockchain-based mechanism, the receiver sends an acknowledgement message upon receiving the information. Secondly, the consensus algorithm does not allow the duplication or replay of the actual message.Figure 25
Reliable message transportation in Information Sharing Platform with respect to proposed blockchain platform.(7)Scalability. The scalability of “CIDF, IDXP, XEP-0268, SMTP, CLT, and Syslog” is high. RID’s capacity to support various network sizes is low; hence, it does not scale up to the mark. The EVM implementation of the suggested threat data sharing scheme is more scalable as compared to Hyperledger. Figure 26 shows the comparison of the scalability of the CTI platforms with respect to the proposed mechanism.Figure 26
Scalability in Information Sharing Platform with respect to proposed blockchain platform.(8)Practical Application (Product Based on Standard). CIDF was not meant to be a standard impacting the commercial marketplace. There are no practical applications that allow CIDF, CTL, and XEP-0268 since CIDF was a research project and the work on CEE and XEP-0268 is currently stopped. The availability of practical applications is, therefore, low. Some implementations that use RID and IDXP are available, so the practical application is average. Most businesses use SMTP and Syslog, and thus, the realistic implementation of these two is robust. The practical applicability of blockchain-based information sharing is high since the platform is readily deployed. Figure 27 shows the comparison of the practical application of the CTI platforms with respect to the proposed mechanism.Figure 27
Practical application of Information Sharing Platform with respect to proposed blockchain platform.


## 7.1. Results and Analysis of Detection System

The process of compromising the devices entails the following six steps.(1)
Compromising the initial login access of the device by the attacker(2)
Getting access to the device shell(3)
Connection establishment with CNC(4)
Getting malware from CNC(5)
Malware execution on the compromised device(6)
A compromised device acting as a botTable2 depicts the defined policies for a device. The proposed botnet detection system produces alarms at each step of the device compromise if there is a violation of predefined policies. Table 3 describes the plotting of the alarms generated by the proposed botnet detection system during each stage of the device compromise. A thorough study of the packets taken by the proposed botnet detection system during every step of the device compromise is carried out in the subsequent subsections.Table 3
Alarms generated at every step of making a device bot.
AlarmStepsViolation of access policyCompromising the initial login accessGetting access to the device shellCommunication policy violationConnection establishment with CNCGetting malware from CNCUsage policy violationCommand execution in BusyBoxA compromised device acting as bot


### 7.1.1. Compromising the Initial Login Access of the Device by the Attacker

As a first step, CNC attempts to access the target device through login. The traffic packets transferred between the CNC server and the target device are captured during this process. The CNC server succeeded in getting access to the target using the username root and default password device, as shown in Figure9.Figure 9
Packets taken by botnet detection system during attacker efforts of compromising the initial login access of the device.


### 7.1.2. Getting Access to the Device Shell

After successfully logging into the target device, the CNC servers’ next job is to get into the BusyBox of the compromised device. The packet captured during the attempt of the CNC server to access the BusyBox of compromised is shown in Figure10.Figure 10
Packets taken by botnet detection system during attackers getting access of the device shell.


### 7.1.3. Connection Establishment with CNC

After getting access to the BusyBox, the CNC server directs the compromised device to the web server having Mirai malware binaries. The packets are swapped between the CNC server, and the target device is shown in Figure11.Figure 11
Packets taken by the botnet detection system during Bot Plea of establishing connection with CNC to download malware binaries.


### 7.1.4. Getting Malware from CNC

After a successful connection establishment, the Mirai binaries are downloaded. The packets captured during this process are shown in Figure12.Figure 12
Packets taken by the botnet detection system during bot acknowledging download of malware binaries.


### 7.1.5. Malware Execution on the Compromised Device

The CNC server executes the downloaded Mirai binaries attack in this step, as shown in Figure13.Figure 13
Packets taken by the botnet detection system during the execution of the malware binaries downloaded earlier.


### 7.1.6. Compromised Device Acting as a Bot

After getting access and making the target device a bot, the CNC starts the scan process to find the vulnerabilities in other devices to make them part of the bot.


### 7.1.7. Mapping between Predefined Policies and Alarms Generated by the Proposed IoT Botnet Detection System

Table2 demonstrates the predefined usage, communication, and access policies. The mapping between violations of predefined policies and the alarms generated by the proposed IoT botnet detection system is depicted in Table 3. Access to devices by the CNC and its shell (BusyBox) is the abuse of the predefined policy for accessing the device. Device communication with CNC Server for downloading Mirai malware binaries is the abuse of the predefined communication policy. Finally, implementation of Mirai malware on the device and the compromised device acting as the bot is the abuse of the predefined policy for usage.


### 7.1.8. Alarms Generated against Each Attacked Host

In the lab setup, two WiFi access routers having DD-WRT firmware are deployed as vulnerable devices. The command and control server attacks these two devices during the experiment. This research draw alarms generated against each attacked device, as shown in Figure14. Three hundred sixty alarms are made during the attack on the WiFi access router having IP 192.168.2.71. The number of generated alarms is 280 when the router having IP 192.168.2.72 is attacked.Figure 14
Packets taken by the botnet detection system during compromised device acting as bot.


### 7.1.9. Alarms Generated by Each Attacker Host

The command and control server (192.168.2.11) and scanner (192.168.2.12) are primarily the attacker hosts. In addition, two WiFi access routers, after becoming bots, act as the scanner. Alarms generated against each attacking host are shown in Figure15. The figure depicts that the detection system generates around 540 alerts if the attacker is the command and control server. The number of generated alerts is 150, 110, and 105 in case attacker, WiFi access router 1 has IP address 192.168.2.71, WiFi access router 2 has IP address 192.168.2.72, and scanner server has IP address 192.168.2.12.Figure 15
Alarms generated by each attacking host.


### 7.1.10. Alarms Generated against Each Attacked Port

During the attack process, the attacker tries to gain access to the WiFi access router by scanning different ports of the target bot. The number of alarms generated against different ports is shown in Figure16. It shows that the detection system against telnet access generates around 520 alerts.Figure 16
Alarms generated against each attacked port.


## 7.1.1. Compromising the Initial Login Access of the Device by the Attacker

As a first step, CNC attempts to access the target device through login. The traffic packets transferred between the CNC server and the target device are captured during this process. The CNC server succeeded in getting access to the target using the username root and default password device, as shown in Figure9.Figure 9
Packets taken by botnet detection system during attacker efforts of compromising the initial login access of the device.


## 7.1.2. Getting Access to the Device Shell

After successfully logging into the target device, the CNC servers’ next job is to get into the BusyBox of the compromised device. The packet captured during the attempt of the CNC server to access the BusyBox of compromised is shown in Figure10.Figure 10
Packets taken by botnet detection system during attackers getting access of the device shell.


## 7.1.3. Connection Establishment with CNC

After getting access to the BusyBox, the CNC server directs the compromised device to the web server having Mirai malware binaries. The packets are swapped between the CNC server, and the target device is shown in Figure11.Figure 11
Packets taken by the botnet detection system during Bot Plea of establishing connection with CNC to download malware binaries.


## 7.1.4. Getting Malware from CNC

After a successful connection establishment, the Mirai binaries are downloaded. The packets captured during this process are shown in Figure12.Figure 12
Packets taken by the botnet detection system during bot acknowledging download of malware binaries.


## 7.1.5. Malware Execution on the Compromised Device

The CNC server executes the downloaded Mirai binaries attack in this step, as shown in Figure13.Figure 13
Packets taken by the botnet detection system during the execution of the malware binaries downloaded earlier.


## 7.1.6. Compromised Device Acting as a Bot

After getting access and making the target device a bot, the CNC starts the scan process to find the vulnerabilities in other devices to make them part of the bot.


## 7.1.7. Mapping between Predefined Policies and Alarms Generated by the Proposed IoT Botnet Detection System

Table2 demonstrates the predefined usage, communication, and access policies. The mapping between violations of predefined policies and the alarms generated by the proposed IoT botnet detection system is depicted in Table 3. Access to devices by the CNC and its shell (BusyBox) is the abuse of the predefined policy for accessing the device. Device communication with CNC Server for downloading Mirai malware binaries is the abuse of the predefined communication policy. Finally, implementation of Mirai malware on the device and the compromised device acting as the bot is the abuse of the predefined policy for usage.


## 7.1.8. Alarms Generated against Each Attacked Host

In the lab setup, two WiFi access routers having DD-WRT firmware are deployed as vulnerable devices. The command and control server attacks these two devices during the experiment. This research draw alarms generated against each attacked device, as shown in Figure14. Three hundred sixty alarms are made during the attack on the WiFi access router having IP 192.168.2.71. The number of generated alarms is 280 when the router having IP 192.168.2.72 is attacked.Figure 14
Packets taken by the botnet detection system during compromised device acting as bot.


## 7.1.9. Alarms Generated by Each Attacker Host

The command and control server (192.168.2.11) and scanner (192.168.2.12) are primarily the attacker hosts. In addition, two WiFi access routers, after becoming bots, act as the scanner. Alarms generated against each attacking host are shown in Figure15. The figure depicts that the detection system generates around 540 alerts if the attacker is the command and control server. The number of generated alerts is 150, 110, and 105 in case attacker, WiFi access router 1 has IP address 192.168.2.71, WiFi access router 2 has IP address 192.168.2.72, and scanner server has IP address 192.168.2.12.Figure 15
Alarms generated by each attacking host.


## 7.1.10. Alarms Generated against Each Attacked Port

During the attack process, the attacker tries to gain access to the WiFi access router by scanning different ports of the target bot. The number of alarms generated against different ports is shown in Figure16. It shows that the detection system against telnet access generates around 520 alerts.Figure 16
Alarms generated against each attacked port.


## 7.2. Results and Analysis of Mitigation

The local mitigator changes the device login credentials and informs the network administrator about the new access credentials as a first defensive measure. The detection system provides the identified command and control server’s domain name, i.e., cnc.sajjad.local, and IP addresses, i.e., 192.168.2.11, to the local mitigator. The local mitigator automatically updates firewall rules for blocking the attacker access to the previously compromised devices in the local network. As Mirai malware resides in the volatile memory, rebooting the device can remove the malware from the device. Local mitigator reboots the infected devices to remove Mirai from devices. The collaborative mitigator writes the attacker IP addresses and the attacked ports to the smart contract and shares them with the member of the smart contract. This information is received by all the members of the smart contract. The local mitigator of each member blocks the access of the attacker IP address and the attacked ports. After the mitigation steps, this research again launched the attack on the WiFi access router from the Mirai scanner. Mirai scanner (scanrec.sajjad.local having IP 192.168.2.12) cannot compromise WiFi access routers as attacker access on the WiFi access router is blocked by the firewall. The peer mitigator of any organization takes the proactive defense steps. The peer mitigator of any vendor or peer Internet service provider safeguards the users or customers of the vendors or Internet service provider from becoming part of the IoT botnets.Similarly, the proactive defense steps taken by the attacker organization, vendor, or Internet service provider completely stop the source of the attack. In this way, smart contract and blockchain-based collaborative mitigation provide a means of proactive defense to all the members of the smart contract without members experiencing the attack themselves. The actions taken by the collaborative mitigator of the attacker vendor or Internet service provider completely stop the attack source.


### 7.2.1. Throughput

The measurement of the per second transactions is called throughput. Figure17 elaborates the throughput of the proposed system. Due to the complexity and difficulty of the Ethereum’s consensus protocol “proof of work,” the initial transaction occurred after 360 seconds. Contrary to this, in Hyperledger, the initial transaction occurred after 7 seconds.Figure 17
Throughput of the proposed collaborative mitigation system.


### 7.2.2. Scalability

Figure18 shows the scalability evaluation of the collaborative mitigation. Hyperledger is less scalable than Ethereum. Nevertheless, it is also eminent that transactions per second also declined with the number of peer nodes.Figure 18
Scalability of the proposed collaborative mitigation system.


### 7.2.3. Latency

As shown in Figure17, the occurrence of the first transaction is at 350 seconds. Due to the higher difficulty level of Ethereum’s “proof of work” consensus algorithm, 10,000 transactions occurred in 440 seconds. In Hyperledger’s case, an initial transaction happens at around 4 seconds, while 10000 transactions occur in 440 seconds.


### 7.2.4. Performance Discussion

Ethereum Casper, an improved version of the Ethereum consensus protocol, was launched in May 2018 [54]. Version 2 of the said protocol utilizing a “proof of stake” based improved consensus mechanism is expected to resolve the issues present in Ethereum [55]. This release targets enhanced scalability and performance. These improvements would probably solve performance issues at Ethereum.


### 7.2.5. Encryption Overhead

By default, blockchain does not include data encryption. In the proposed collaborative mitigation system, the peer mitigator in the proposed collaborative mitigation system sends the signed transaction by encrypting it with the receiver public keys one by one. This process causes an extra encryption overhead at the sender side and additionally may cause delays. Figure19 depicts the comparison of the time taken by the arrival of threat data at the receiver end in a proposed scheme with OpenTAXII [56], Anomali STAXX [57], MISP [58], and Soltra Edge [59]. The proposed scheme implementation with Ethereum takes the most time compared to the proposed scheme implementation with Hyperledger and other threat data-sharing platforms. The symmetric group encryption key can be used to avoid the encryption overhead on the sender side.Figure 19
Delay caused by the encryption overhead.


## 7.2.1. Throughput

The measurement of the per second transactions is called throughput. Figure17 elaborates the throughput of the proposed system. Due to the complexity and difficulty of the Ethereum’s consensus protocol “proof of work,” the initial transaction occurred after 360 seconds. Contrary to this, in Hyperledger, the initial transaction occurred after 7 seconds.Figure 17
Throughput of the proposed collaborative mitigation system.


## 7.2.2. Scalability

Figure18 shows the scalability evaluation of the collaborative mitigation. Hyperledger is less scalable than Ethereum. Nevertheless, it is also eminent that transactions per second also declined with the number of peer nodes.Figure 18
Scalability of the proposed collaborative mitigation system.


## 7.2.3. Latency

As shown in Figure17, the occurrence of the first transaction is at 350 seconds. Due to the higher difficulty level of Ethereum’s “proof of work” consensus algorithm, 10,000 transactions occurred in 440 seconds. In Hyperledger’s case, an initial transaction happens at around 4 seconds, while 10000 transactions occur in 440 seconds.


## 7.2.4. Performance Discussion

Ethereum Casper, an improved version of the Ethereum consensus protocol, was launched in May 2018 [54]. Version 2 of the said protocol utilizing a “proof of stake” based improved consensus mechanism is expected to resolve the issues present in Ethereum [55]. This release targets enhanced scalability and performance. These improvements would probably solve performance issues at Ethereum.


## 7.2.5. Encryption Overhead

By default, blockchain does not include data encryption. In the proposed collaborative mitigation system, the peer mitigator in the proposed collaborative mitigation system sends the signed transaction by encrypting it with the receiver public keys one by one. This process causes an extra encryption overhead at the sender side and additionally may cause delays. Figure19 depicts the comparison of the time taken by the arrival of threat data at the receiver end in a proposed scheme with OpenTAXII [56], Anomali STAXX [57], MISP [58], and Soltra Edge [59]. The proposed scheme implementation with Ethereum takes the most time compared to the proposed scheme implementation with Hyperledger and other threat data-sharing platforms. The symmetric group encryption key can be used to avoid the encryption overhead on the sender side.Figure 19
Delay caused by the encryption overhead.


## 7.3. Comparative Analysis

There are numerous threat exchange protocols. Each protocol has a specific exchange format. An exchange protocol is a set of rules describing how network devices across a computer network can be interconnected to create a channel for transmitting data through exchange formats [60, 61]. Table 4 describes some of the threat exchange protocols and their formats.Table 4
List of threat exchange protocols and their formats.
S#ProtocolFormat1“Common Intrusion Detection Framework (CIDF)” [62]“Common Intrusion Specification Language (CISL) Messages” [63]2Real-time Inter-network Defense (RID) [64]“Incident Object Description Exchange Format (IODEF)” [65–67]3XEP-0268 Incident Handling [68–71]Incident Object Description Exchange Format (IODEF)4“Intrusion Detection Exchange Protocol (IDXP)” [72]“The Intrusion Detection Message Exchange Format (IDMEF)” [73, 74]5Simple Mail Transfer Protocol (SMTP) [75]Common Announcement Interchange Format (CAIF), Abuse Reporting Format(ARF) [76]6CEE Log Transport (CLT) [77]Command Event Expression (CEE) [78]7Syslog Protocol [79]Syslog [80]


### 7.3.1. Evaluation Parameter and Criteria

The exchange protocols are assessed on the following twelve parameters:(1)
Confidentiality(2)
Nonrepudiation(3)
Authenticity(4)
Trust(5)
Integrity(6)
Reliable message transport(7)
Scalability(8)
Product based on standardThe confidentiality principle defines the capacity to safeguard sensitive information from exposure to unauthorized parties. The authenticity defines the ability to assess if the exchanging parties are really whom they have claimed to be and therefore use authentication mechanisms. The potential to secure data from unauthorized parties’ alteration or deletion is defined by the integrity. If the transmission of a threat data uses a guaranteed delivery to prevent duplicate messages and message loss, an exchange protocol uses “reliable message transport.” The ability to manage various network sizes is defined by the metric of “scalability.” Ensuring that the sender and receiver cannot deny the transmission and receiving of data is termed nonrepudiation.The sender and receiver should have a trusting relationship with each other. The recipient of the threat data should authenticate the origins of the received data and verify the correctness of the received data and the sender. Thus the threat sharing platform should have a mechanism that should provide correctness of the received data.


### 7.3.2. Evaluation Results

The following sections discuss the evaluation results. Table5 presents the numerical evaluation criteria.Table 5
Description of evaluation criteria.
S. noLevelScore1Low52Medium103High154Very high20(1)Confidentiality. Figure 20 depicts the comparison of the confidentiality of the CTI platforms to the proposed mechanism. CIDF offers a matchmaking service with the help of which CIDF components use authenticated and secured communications between CIDF components. The matchmaker service also acts as a certificate authority (CA).Figure 20
Data confidentiality in Information Sharing Platform concerning proposed blockchain platform.Therefore, the confidentiality, integrity, and authentication capabilities of the CIDF are great. RID utilizes XML encryption to offer confidentiality in the “IODEF’ and “IODEF-RID” [132] systems, based on the iodef: restriction attribute. To provide confidentiality, IDXP uses TLS’ underlying BEEP protection profile with the “TLS DHE DSS WITH 3DES EDE CBC SHA” cipher suite. XMPP employs TLS to guarantee privacy and confidentiality, making the confidentiality services and capabilities of XMPP and XEP-0268 strong enough. SMTP does not include the usage of any technique to guarantee protection. The potential for secrecy is, therefore, low in SMTP. To counter security event disclosure, CLT and Syslog RFC 5424 use TLS; thus, the confidentiality capacity is high. In the proposed blockchain-based threat information sharing, encrypting the digitally signed transaction with the receiver’s public keys provides a high level of confidentiality.(2)Nonrepudiation. As trust in CIDF is high due to origin authentication provided by Generalized Intrusion Detection Objects (GIDO) messages exchanged between CIDF-compliant components, nonrepudiation is high. As RID, CLT, and Syslog (RFC 5425) have high trust due to TLS based authentication and authorization, it has high nonrepudiation. XEP-0268 has low nonrepudiation as sharing incident reports with trusted peers is optional. IDXP has high nonrepudiation due to high trust as it employs a BEEP security profile. A user cannot deny a transaction as its private key signs in the proposed blockchain-based threat information sharing. Figure 21 demonstrates the comparison of the nonrepudiation property of the CTI platforms regarding the proposed mechanism.Figure 21
Nonrepudiation in Information Sharing Platform with respect to proposed blockchain platform.(3)Authenticity. Figure 22 shows the comparison of the authenticity of the CTI platforms to the proposed mechanism. To authenticate the sender of the RID message, RID utilizes digital signatures on the hash of the RID message with an X.509v3 certificate provided by the trusted authority. XEP-0268 is XMPP-based. The authentication capabilities of XEP-0268 are considered to be strong because XMPP uses the “Simple Authentication and Security Layer (SASL)” for peer authentication. IDXP provides mutual authentication by employing the public-key certificates of the TLS security profile of underlying BEEP protocol. Syslog RFC 5425 also uses mutually authenticated channels with cryptographic algorithms and protocols commonly deployed. As CLT is Syslog RFC 5424, the CLT has the same features as Syslog RFC 5424. The authentication capacity of the “RID, IDXP, CLT, and Syslog RFC 5425” exchange protocols is high. The SMTP exchange protocols cannot verify that the declared sender is the message-sending peer, so the SMTP authentication functionality is low. IDXP utilizes the underlying BEEP protection profile of TLS with the “TLS DHE DSS WITH 3DES EDE CBC SHA” cipher suite to provide high authentication capabilities. In the proposed blockchain-based mechanism, the user sends a digital signature (encryption with its private key) to the data, ensuring user and data authentication.Figure 22
Authentication process in Information Sharing Platform with respect to proposed blockchain platform.(4)Trust. Trust in CIDF is high due to origin authentication provided by Generalized Intrusion Detection Objects (GIDO) messages exchanged between CIDF-compliant components. RID, CLT, and Syslog (RFC 5425) have high trust due to TLS-based authentication and authorization. XEP-0268 has low trust as sharing incident reports with trusted peers is optional. IDXP has high trust as it employs a BEEP security profile. A BEEP security profile is used to establish trust between end-to-end peers of the IDXP. In the proposed blockchain-based solution, trust is established via the smart contract.Additionally, each transaction contains the hash of the previous transaction forming the data origin authentication. Moreover, the sender encrypts the data with its private key before sending it to the receiver. Figure23 elaborates the comparison of the trust of the CTI platforms with respect to the proposed mechanism.Figure 23
Trust in Information Sharing Platform with respect to proposed blockchain platforms.(5)Integrity. Figure 24 depicts the comparison of the integrity of the CTI platforms with respect to the proposed mechanism. The integrity of messages sent over the network is tackled using authentication methods. The “RID, XEP-0268, IDXP, CTL and Syslog RFC 5424” TLS-based protocols support message integrity by using TLS message authentication, TLS security profile of BEEP, or SASL profile members. The capacity of “RID, XEP-0368, IDXP, CTL, and Syslog RFC 5424” TLS-based exchange protocols to maintain the integrity of the transmitted message is high. On the other hand, SMTP does not have any mechanisms to guarantee integrity, and thus, the integrity capacity is low. In the proposed blockchain-based threat, information sharing digital signature of the receiver and hashes of the transaction provides temper proof integrity.Figure 24
Data Integrity in Information Sharing Platform with respect to proposed blockchain platform.(6)Reliable Message Transport. Figure 25 demonstrates the comparison of the reliable message transport of the CTI platforms regarding the proposed mechanism. Reliable CIDF messaging over UDP is the default transport layer protocol for CIDF messages. However, CIDF also uses (i) the message layer directly over UDP without acknowledgement and retransmission, (ii) message layer of the CIDF with acknowledgement and retransmission through UDP, and (iii) the CIDF message layer explicitly over TCP. “RID, XEP-0268, and IDXP” include the use of connection-oriented protocols and therefore use TCP. SMTP is independent of the specific transmission protocol, but a stable, organized data stream channel is necessary. Hence, the ability of a reliable message transport of the protocols “CIDF, RID, XEP-0268, IDXP, SMTP, CLT, and Syslog RFC 5425” is high. In the proposed blockchain-based mechanism, the receiver sends an acknowledgement message upon receiving the information. Secondly, the consensus algorithm does not allow the duplication or replay of the actual message.Figure 25
Reliable message transportation in Information Sharing Platform with respect to proposed blockchain platform.(7)Scalability. The scalability of “CIDF, IDXP, XEP-0268, SMTP, CLT, and Syslog” is high. RID’s capacity to support various network sizes is low; hence, it does not scale up to the mark. The EVM implementation of the suggested threat data sharing scheme is more scalable as compared to Hyperledger. Figure 26 shows the comparison of the scalability of the CTI platforms with respect to the proposed mechanism.Figure 26
Scalability in Information Sharing Platform with respect to proposed blockchain platform.(8)Practical Application (Product Based on Standard). CIDF was not meant to be a standard impacting the commercial marketplace. There are no practical applications that allow CIDF, CTL, and XEP-0268 since CIDF was a research project and the work on CEE and XEP-0268 is currently stopped. The availability of practical applications is, therefore, low. Some implementations that use RID and IDXP are available, so the practical application is average. Most businesses use SMTP and Syslog, and thus, the realistic implementation of these two is robust. The practical applicability of blockchain-based information sharing is high since the platform is readily deployed. Figure 27 shows the comparison of the practical application of the CTI platforms with respect to the proposed mechanism.Figure 27
Practical application of Information Sharing Platform with respect to proposed blockchain platform.


## 7.3.1. Evaluation Parameter and Criteria

The exchange protocols are assessed on the following twelve parameters:(1)
Confidentiality(2)
Nonrepudiation(3)
Authenticity(4)
Trust(5)
Integrity(6)
Reliable message transport(7)
Scalability(8)
Product based on standardThe confidentiality principle defines the capacity to safeguard sensitive information from exposure to unauthorized parties. The authenticity defines the ability to assess if the exchanging parties are really whom they have claimed to be and therefore use authentication mechanisms. The potential to secure data from unauthorized parties’ alteration or deletion is defined by the integrity. If the transmission of a threat data uses a guaranteed delivery to prevent duplicate messages and message loss, an exchange protocol uses “reliable message transport.” The ability to manage various network sizes is defined by the metric of “scalability.” Ensuring that the sender and receiver cannot deny the transmission and receiving of data is termed nonrepudiation.The sender and receiver should have a trusting relationship with each other. The recipient of the threat data should authenticate the origins of the received data and verify the correctness of the received data and the sender. Thus the threat sharing platform should have a mechanism that should provide correctness of the received data.


## 7.3.2. Evaluation Results

The following sections discuss the evaluation results. Table5 presents the numerical evaluation criteria.Table 5
Description of evaluation criteria.
S. noLevelScore1Low52Medium103High154Very high20(1)Confidentiality. Figure 20 depicts the comparison of the confidentiality of the CTI platforms to the proposed mechanism. CIDF offers a matchmaking service with the help of which CIDF components use authenticated and secured communications between CIDF components. The matchmaker service also acts as a certificate authority (CA).Figure 20
Data confidentiality in Information Sharing Platform concerning proposed blockchain platform.Therefore, the confidentiality, integrity, and authentication capabilities of the CIDF are great. RID utilizes XML encryption to offer confidentiality in the “IODEF’ and “IODEF-RID” [132] systems, based on the iodef: restriction attribute. To provide confidentiality, IDXP uses TLS’ underlying BEEP protection profile with the “TLS DHE DSS WITH 3DES EDE CBC SHA” cipher suite. XMPP employs TLS to guarantee privacy and confidentiality, making the confidentiality services and capabilities of XMPP and XEP-0268 strong enough. SMTP does not include the usage of any technique to guarantee protection. The potential for secrecy is, therefore, low in SMTP. To counter security event disclosure, CLT and Syslog RFC 5424 use TLS; thus, the confidentiality capacity is high. In the proposed blockchain-based threat information sharing, encrypting the digitally signed transaction with the receiver’s public keys provides a high level of confidentiality.(2)Nonrepudiation. As trust in CIDF is high due to origin authentication provided by Generalized Intrusion Detection Objects (GIDO) messages exchanged between CIDF-compliant components, nonrepudiation is high. As RID, CLT, and Syslog (RFC 5425) have high trust due to TLS based authentication and authorization, it has high nonrepudiation. XEP-0268 has low nonrepudiation as sharing incident reports with trusted peers is optional. IDXP has high nonrepudiation due to high trust as it employs a BEEP security profile. A user cannot deny a transaction as its private key signs in the proposed blockchain-based threat information sharing. Figure 21 demonstrates the comparison of the nonrepudiation property of the CTI platforms regarding the proposed mechanism.Figure 21
Nonrepudiation in Information Sharing Platform with respect to proposed blockchain platform.(3)Authenticity. Figure 22 shows the comparison of the authenticity of the CTI platforms to the proposed mechanism. To authenticate the sender of the RID message, RID utilizes digital signatures on the hash of the RID message with an X.509v3 certificate provided by the trusted authority. XEP-0268 is XMPP-based. The authentication capabilities of XEP-0268 are considered to be strong because XMPP uses the “Simple Authentication and Security Layer (SASL)” for peer authentication. IDXP provides mutual authentication by employing the public-key certificates of the TLS security profile of underlying BEEP protocol. Syslog RFC 5425 also uses mutually authenticated channels with cryptographic algorithms and protocols commonly deployed. As CLT is Syslog RFC 5424, the CLT has the same features as Syslog RFC 5424. The authentication capacity of the “RID, IDXP, CLT, and Syslog RFC 5425” exchange protocols is high. The SMTP exchange protocols cannot verify that the declared sender is the message-sending peer, so the SMTP authentication functionality is low. IDXP utilizes the underlying BEEP protection profile of TLS with the “TLS DHE DSS WITH 3DES EDE CBC SHA” cipher suite to provide high authentication capabilities. In the proposed blockchain-based mechanism, the user sends a digital signature (encryption with its private key) to the data, ensuring user and data authentication.Figure 22
Authentication process in Information Sharing Platform with respect to proposed blockchain platform.(4)Trust. Trust in CIDF is high due to origin authentication provided by Generalized Intrusion Detection Objects (GIDO) messages exchanged between CIDF-compliant components. RID, CLT, and Syslog (RFC 5425) have high trust due to TLS-based authentication and authorization. XEP-0268 has low trust as sharing incident reports with trusted peers is optional. IDXP has high trust as it employs a BEEP security profile. A BEEP security profile is used to establish trust between end-to-end peers of the IDXP. In the proposed blockchain-based solution, trust is established via the smart contract.Additionally, each transaction contains the hash of the previous transaction forming the data origin authentication. Moreover, the sender encrypts the data with its private key before sending it to the receiver. Figure23 elaborates the comparison of the trust of the CTI platforms with respect to the proposed mechanism.Figure 23
Trust in Information Sharing Platform with respect to proposed blockchain platforms.(5)Integrity. Figure 24 depicts the comparison of the integrity of the CTI platforms with respect to the proposed mechanism. The integrity of messages sent over the network is tackled using authentication methods. The “RID, XEP-0268, IDXP, CTL and Syslog RFC 5424” TLS-based protocols support message integrity by using TLS message authentication, TLS security profile of BEEP, or SASL profile members. The capacity of “RID, XEP-0368, IDXP, CTL, and Syslog RFC 5424” TLS-based exchange protocols to maintain the integrity of the transmitted message is high. On the other hand, SMTP does not have any mechanisms to guarantee integrity, and thus, the integrity capacity is low. In the proposed blockchain-based threat, information sharing digital signature of the receiver and hashes of the transaction provides temper proof integrity.Figure 24
Data Integrity in Information Sharing Platform with respect to proposed blockchain platform.(6)Reliable Message Transport. Figure 25 demonstrates the comparison of the reliable message transport of the CTI platforms regarding the proposed mechanism. Reliable CIDF messaging over UDP is the default transport layer protocol for CIDF messages. However, CIDF also uses (i) the message layer directly over UDP without acknowledgement and retransmission, (ii) message layer of the CIDF with acknowledgement and retransmission through UDP, and (iii) the CIDF message layer explicitly over TCP. “RID, XEP-0268, and IDXP” include the use of connection-oriented protocols and therefore use TCP. SMTP is independent of the specific transmission protocol, but a stable, organized data stream channel is necessary. Hence, the ability of a reliable message transport of the protocols “CIDF, RID, XEP-0268, IDXP, SMTP, CLT, and Syslog RFC 5425” is high. In the proposed blockchain-based mechanism, the receiver sends an acknowledgement message upon receiving the information. Secondly, the consensus algorithm does not allow the duplication or replay of the actual message.Figure 25
Reliable message transportation in Information Sharing Platform with respect to proposed blockchain platform.(7)Scalability. The scalability of “CIDF, IDXP, XEP-0268, SMTP, CLT, and Syslog” is high. RID’s capacity to support various network sizes is low; hence, it does not scale up to the mark. The EVM implementation of the suggested threat data sharing scheme is more scalable as compared to Hyperledger. Figure 26 shows the comparison of the scalability of the CTI platforms with respect to the proposed mechanism.Figure 26
Scalability in Information Sharing Platform with respect to proposed blockchain platform.(8)Practical Application (Product Based on Standard). CIDF was not meant to be a standard impacting the commercial marketplace. There are no practical applications that allow CIDF, CTL, and XEP-0268 since CIDF was a research project and the work on CEE and XEP-0268 is currently stopped. The availability of practical applications is, therefore, low. Some implementations that use RID and IDXP are available, so the practical application is average. Most businesses use SMTP and Syslog, and thus, the realistic implementation of these two is robust. The practical applicability of blockchain-based information sharing is high since the platform is readily deployed. Figure 27 shows the comparison of the practical application of the CTI platforms with respect to the proposed mechanism.Figure 27
Practical application of Information Sharing Platform with respect to proposed blockchain platform.


## 8. Conclusion

In this paper, the functionality of Mirai malware was analyzed in detail. This research proposed detection and collaborative mitigation system. The detection system detects the abnormal behavior of the device based on the violation of the defined policies by the device. The local mitigator blocked the command and control server access to the WiFi access router, blocked the attacked ports, and rebooted the device. The collaborative mitigator sends the attack detection report to the peer mitigators. Peer mitigators block the attacker’s access to their network. The attacker was unable to compromise the device after the mitigation actions. A collaborative mitigator provides a means of proactive defense to all the members of the smart contract.Results show that the proposed detection and mitigation system detects Mirai malware and mitigates it successfully. Results demonstrate that the proposed detection system successfully detects each offensive step of the attacker and gives a 97 percent detection rate. Collaborative mitigation system implementation with “Hyperledger” offers a high-throughput and a more negligible latency due to its consensus algorithm’s lesser complexity than its implementation in “Ethereum Virtual Machine.” Ethereum “proof of work” complexity is greater than the Hyperledger. Contrary, its implementation in “Ethereum Virtual Machine” exhibits great scalability compared to its implementation in “Hyperledger.”



---

*Source: 1194899-2022-04-20.xml*