Implementation of White-Hat Worms Using Mirai Source Code and Its Optimization through Parameter Tuning

Abstract

Mirai, an IoT malware that emerged in 2016, has been used for large-scale DDoS attacks. The Mirai source code is publicly available and continues to be a threat with a variety of variants still in existence. In this paper, we propose an implementation system for malicious and white-hat worms created using the Mirai source code, as well as a general and detailed implementation method for white-hat worms that is not limited to the Mirai source code. The white-hat worms have the function of a secondary infection, in which the white-hat worm disinfects the malicious worm by infecting devices already infected by the malicious worm, and two parameters, the values of which can be changed to modify the rate at which the white-hat worms can spread their infection. The values of the parameters of the best white-hat worm for disinfection of the malicious botnet and the impact of the value of each parameter on the disinfection of the malicious botnet were analyzed in detail. The analysis revealed that for a white-hat worm to disinfect a malicious botnet, it must be able to infect at least 80% of all devices and maintain that situation for at least 300 s. Then, by tuning and optimizing the values of the white-hat worm’s parameters, we were able to successfully eliminate the malicious botnet, demonstrating the effectiveness of the white-hat botnet’s function of eliminating the malicious botnet.

1. Introduction

The IoT malware Mirai emerged in 2016 and has been used and affected by large-scale DDoS attacks, such as the DDoS attack on DNS provider Dyn in the same year, bringing down Twitter, Spotify, and other services [1]. The creator of Mirai claimed that up to 350,000 devices were connected to the Mirai botnet [2], and Reference [3] showed that at its peak, 600,000 devices were connected to the Mirai botnet. Mirai’s source code was published on a hacker forum on 30 September 2016. Although this post has been removed, some Mirai source code is still available on GitHub [4,5,6]. This has made it easy to extend Mirai, and a number of variants have emerged. In particular, a variant called Meris, which appeared in 2021, is famous for generating larger-scale DDoS attacks than Mirai, and is also known as the “re-emergence of Mirai” [7]. In this paper, we implement a malicious worm and a white-hat worm by ethically using the publicly available Mirai source code.

Mirai infects vulnerable IoT devices and forms botnets. The devices that make up the botnet launch DDoS attacks. In June 2024, Statisca predicted that there will be more than 39.6 billion IoT devices in use worldwide by 2033 [8]. This is about 2.5 times the 15.9 billion in 2023. As the number of IoT devices increases, the number of bot-enabled IoT devices will also increase, potentially leading to attacks on a larger scale than ever before, making dealing with malware that infects IoT devices an even more important issue.

In this paper, we propose an implementation system using malicious and white-hat worms created using the Mirai source code, and we provide the implementation details and a detailed analysis of the parameters of the white-hat worm suitable for disinfecting malicious botnets. Malicious worms, such as Mirai, infect vulnerable devices and form malicious botnets. White-hat worms, like malicious worms, infect vulnerable devices but have a “secondary infection” function that infects devices infected by a malicious worm in order to disinfect them, and a “lifespan” function that terminates its own activity after a certain amount of time. The created white-hat worm has two parameters whose values can be changed to modify the worm’s propagation rate. In this paper, we provide details of the proposed implementation system and a detailed analysis of the parameters of the best white-hat worm for disinfecting malicious botnets. We clarify the impact of each of the two parameters of the white-hat worm on the disinfection of the malicious botnet, and we show the effectiveness of the white-hat worm’s function in disinfecting the malicious botnet by tuning and optimizing the values of the white-hat worm’s parameters.

The major contributions of this paper are listed below.

• We show a general and detailed implementation method for the functions of white-hat worms, such as “secondary infection”, which is to infect a device already infected by a malicious worm to disinfect it, and “lifespan”, which is to terminate its own operation after a certain amount of time has passed after infecting a device. Then, based on the method, we implemented a white-hat worm that works on a physical device using the publicly available Mirai source code.
• Experiments with malicious worms and white-hat worms showed that a white-hat botnet can disinfect a malicious botnet by tuning and optimizing the respective values of two parameters of the white-hat worm, the number of vulnerable devices scanned per attempt, and the lifespan of the white-hat worm. We showed that the function of a white-hat botnet to disinfect a malicious botnet is feasible for practical use.

In Section 2, we describe previous studies targeting the Mirai botnet and using the Mirai source code, as well as the BDS on which the idea of the white-hat worm is based. In Section 3, we describe the implementation system consisting of a malicious worm and a white-hat worm created using the proposed Mirai source code. In Section 4, we describe the parameters of the white-hat worm that can eliminate the malicious botnet through experiments using the proposed implementation system and an analysis of the impact of each parameter. In Section 5, we present conclusions and future works.

2. Related Terms and Works

In this section, we describe Mirai and the BDS on which the white-hat worm concept is based. We then compare the works related to this research in terms of the Mirai botnet and source code, and we explain how they differ from this paper.

2.1. Mirai

Mirai is a malware that spreads by repeatedly infecting multiple vulnerable IoT devices to form a botnet [3]. The following is a list of the elements that make up the Mirai botnet and are included in the Mirai source code.

• Mirai (itself)
• C&C server
• Scan Listener
• Loader

In addition to this, not included in the Mirai source code are the web server and the DNS server, which are used by Mirai to name resolve the C&C server, and the web server, which is used to distribute Mirai when spreading the infection.

Each of the elements that make up Mirai and the botnet works as shown in Figure 1 to spread the infection to other devices.

Each of the behaviors shown in Figure 1 is described below.

• The Mirai that infects Device 1 is registered with the C&C server.
• The Mirai scans for other vulnerable devices and, if found, attempts to log in using a predefined username and password combination. If the login is successful, it reports information about the device and the login credentials used to successfully log in to the Scan Listener.
• Upon receiving the information of the vulnerable device (Device 2) from Mirai, the Scan Listener transmits the information to the Loader.
• Upon receiving information from the Scan Listener, the Loader logs into Device 2 via Telnet.
• The Loader executes commands on Device 2 to download Mirai from a web server that distributes Mirai.
• The Loader launches Mirai, which is downloaded to Device 2.
• The Mirai put into Device 2 by the Loader begins its activity.

The search for vulnerable devices by Mirai does not check whether the target device is infected with Mirai or not. If Mirai is sent again to a device that is already infected with Mirai, the later loaded Mirai will terminate the process of the previously loaded Mirai. This causes the later-loaded Mirai and the already-infected Mirai to switch places.

2.2. BDS (Botnet Defense System)

BDS is a system proposed by Yamaguchi that monitors a network to detect malicious botnets and disinfects them with white-hat worms [9]. BDS eliminates malicious worms by following the steps outlined below.

• Monitor the network and detect malicious botnets.
• Based on the monitoring results, develop a tactic to eliminate malicious botnets.
• Based on the tactic, white-hat worms are sent into the network to build a white-hat botnet.
• Based on the tactic, it directs and controls the white-hat botnets that operate autonomously.

The white-hat botnet used in the BDS is intended to disinfect malicious botnets, and the white-hat worm has the following parameters.

• Primary infection rate $\mathit{\alpha }$: Infection rate to uninfected devices.
• Second infection rate $\mathit{\beta }$: Infection rate to already infected devices.
• Lifespan ℓ: Duration of survival after Infection.

In the BDS research, PN², an agent-oriented Petri net, and its simulator, PN2Simulator [10], are used. PN² can represent agent movement, replication, annihilation, and interaction. PN2Simulator can edit and run PN² models but has the following limitations.

• It is not a method of implementing a white-hat worm that can work on a physical device
  • The white-hat worm used in the PN2Simulator has secondary infection and lifespan functions, all of which are realized using one of the Petri nets, PN². Therefore, the concept of the functions that the white-hat worm has is shown, but not how to implement a white-hat worm that can work on those specific and real devices.

• Cannot reproduce hardware or network
  • Because PN2Simulator uses PN² to represent the infection state, it is limited in its ability to reproduce the internal behavior of a device or the behavior of a real-world worm. In addition, because the simulation is not based on an actual network, it does not reflect network characteristics such as bandwidth, and because it is not a simulation method that reproduces network traffic, it cannot collect network traffic.

2.3. Research Related to the Mirai Botnet

Several studies have been conducted on the Mirai botnet.

Bezzara et al. proposed the Internet of Things Detection System (IoTDS), a botnet detection system [11]. It uses a network of running bots, including Mirai, to detect botnets by determining abnormalities in device behavior by modeling the CPU utilization, temperature, memory usage, and running tasks of devices on a host basis using a classifier. It is a method intended to detect botnets, not to exterminate them.

Mahboudi et al. proposed a model that reproduces the spread of Mirai through mathematical simulations based on the stochastic SIR (Susceptible-Infected-Removed) [12]. Although the simulation takes into account various situations, such as the occurrence of variants and the use of zero-day vulnerabilities, it is only a simulation, discards some things, and does not fully reproduce the actual behavior of the worm.

Griffioen et al. observed infection trends of Mirai and its variants using 7500 IoT honeypots [13]. They found that specific malware trends are closely related and that malware authors have taken over competing strategies over time. They also found that epidemiologically, IoT botnets are not self-sustaining, and without a bootstrapping infrastructure to continuously spread reinfection to vulnerable devices, Mirai and its variants would be wiped out. On the other hand, the research was limited to the analysis of botnets and did not provide botnet disinfection or any findings on the subject.

Çetin et al. investigated Mirai-infected devices and showed that an Internet Service Provider (ISP) can place Mirai-infected devices in a quarantine network to mitigate the botnet and notify the users of the targeted devices, thereby removing Mirai and preventing subsequent re-infection with a high probability [14]. The results showed that Mirai can be removed and subsequent re-infection can be prevented with a high probability. Although this is one of the methods to disinfect botnets, the cooperation of ISPs is important, and there is a limit to the number of applicable networks. The scope of the target network is also limited, making it difficult to apply to a scale, such as the Internet, that cannot be handled by ISPs.

Most of the studies conducted on the Mirai botnet to date have focused on analyzing botnets, and even research aimed at disinfecting botnets has had limited real-world application.

2.4. Research Using the Mirai Source Code

While the public availability of the Mirai source code helps cybercriminals to create new variants of Mirai, it also helps to ensure that ethical research is actively conducted using the Mirai source code.

Based on the analysis of the Mirai source code, Sinanović et al. created rules for Snort, one of the intrusion detection systems, to detect communications between bots, a C&C server, and a DNS server [11]. The effectiveness of the created rules was then checked using the Mirai worm created using the actual Mirai source code. They focused only on the bot alone and not on its behavior as a botnet. The proposed Snort rules are useful in understanding the presence of Mirai-infected devices on a network, but they do not take into account disinfecting the Mirai botnet.

McDermott et al. used the Mirai source code to capture packets by running each of the elements that make up the Mirai botnet on real hardware. The captured packets were then used to create an LSTM model to detect DDoS attacks and bot communications from the botnet, which showed a discrimination performance of over 90% [15]. Unlike [16], which focuses on the behavior of a botnet, it is intended for detection and does not target botnet disinfection.

Zhang et al. proposed a digital forensics technique that uses the Mirai source code to actually run the bot and collect data such as RAM and network traffic from the servers that make up the botnet to obtain evidence about the targets of DDoS attacks that were performed, etc. [17]. In the study, the authors not only ran the Mirai botnet on real hardware, but also analyzed various aspects of Mirai, including the source code and packet capture, with the goal of obtaining information about the DDoS attacks performed by the attackers and the bot-enabled devices; they did not target botnet disinfection.

Hallman et al. analyzed the Mirai source code, including not only the Mirai bots but also the elements that make up Mirai, and pointed out the existence of SQL injection vulnerabilities in the C&C server [18]. It is the first research to reveal vulnerabilities in the components of the Mirai botnet and proposed a new way to fight back against the Mirai botnet, but the research is limited to an analysis of the source code and does not reveal how a SQL injection can actually attack the Mirai botnet or how it can be affected. The research is limited to an analysis of the source code.

Although many studies have been performed using the Mirai source code and methods have been proposed to combat the Mirai botnet, none have proposed specific methods to disinfect Mirai bots.

3. Methodology

In this section, we first describe the features of the implementation system proposed in this paper. We then describe the behavior of the malicious worm, the white-hat worm, and the elements that make up the botnet in the implemented system. We further describe the features of the malicious worm and the white-hat worm, and how we added these features by modifying the publicly available Mirai source code. We then describe the functionality we added to the original Mirai C&C server implementation. We also describe the characteristics of the vulnerable devices used in the implementation system. Finally, we describe the configuration of the network and devices used in the implementation system.

3.1. Features

The implementation system proposed in this paper has the following three features.

• Implementation of a botnet
  • The botnet is implemented by a worm created using the Mirai source code, and the basic behavior of the botnet is based on Mirai, enabling actual bot and botnet behavior.

• Implementation of white-hat worm capable of parameter tuning
  • White-hat worms used in the implementation system have two parameters that can tune the speed at which the worm’s infection spreads, and by tuning these values, they can be optimized to eliminate a malicious botnet.

• Replication of IoT networks with scalability
  • The IoT devices are reproduced by using OpenWrt, an operating system used for routers and other IoT devices, as the vulnerable devices that the worm infects. And all devices in the implemented system are virtualized, making it easy to increase or decrease the number of devices used.

3.2. Behavior of the Implementation System

The behavior of each element of the proposed implementation system is shown in Figure 2. Figure 2 shows the behavior of the malicious worm infected with Device 1 when it spreads the infection to Device 2 and the white-hat worm infected with Device 3 when it spreads the infection to Device 1. The malicious worm and the white-hat worm use multiple components of the malicious botnet to spread infection. Those associated with the malicious botnet are shown in red and those associated with the white-hat botnet are shown in blue. The same applies in the figures that follow.

The behavior of the implemented system can be divided into four categories: “Discover (Figure 2a)”, “Login (Figure 2b)”, “Infect (Figure 2c)” and “Disinfect (Figure 2d)”. First, as shown in Figure 2a, the malicious worm and white-hat worm search for vulnerable devices and report information on the found device to the Scan Listener. In Figure 2a, it is assumed that a malicious worm infected by Device 1 discovers Device 2 and a white-hat worm infected by Device 3 discovers Device 1.

Next, as shown in Figure 2b, the information that the Scan Listener receives from the worm about the vulnerable device is communicated to the Loader. The Loader then logs in to the vulnerable device after receiving the information about the vulnerable device.

Next, as shown in Figure 2c, the Loader executes commands on the logged-in target device to download the worm from the web server that distributes the worm, and launches it.

Finally, as shown in Figure 2d, the worms loaded by the Loader (the malicious worm loaded to Device 2 and the white-hat worm loaded to Device 1) become active. The white-hat worm loaded to Device 1 detects that the device is already infected by the malicious worm and removes the malicious worm.

The sequence of malicious worms and white-hat worms infecting vulnerable devices is shown in Figure 3.

Although only 5 devices are included in Figure 3 due to limited space, there are actually more devices than this in the implemented system, as described below. Also, as indicated in green, there is a period of time during which both white-hat and malicious worms exist on the same device at the same time because of the time required for the white-hat worms to disinfect the malicious worms.

For the malicious worm and white-hat worm to spread, each worm must infect at least one vulnerable device. Therefore, each malicious worm and white-hat worm is manually infected one at a time on different devices. The flow of infection spread after this is described below, but since the infection targets are randomly determined, the behavior is not necessarily as shown in Figure 3.

• The malicious worm that manually infected Device 0 is registered on the malicious C&C server.
• The white-hat worm that manually infected Device 4 is registered on the white-hat C&C server.
• Device 2 is infected by the malicious worm that infected Device 0 (primary infection).
• The malicious worm that infected Device 2 is registered on the malicious C&C server.
• Device 3 is infected by the white-hat worm that infected Device 4 (primary infection).
• The white-hat worm that infected Device 3 is registered on the white-hat C&C server.
• The white-hat worm infecting Device 4 causes Device 2, which is already infected by the malicious worm, to be infected by the white-hat worm (secondary infection).
• The white-hat worm that infected Device 2 is registered on the white-hat C&C server.
• Device 1 is infected by the malicious worm that infected Device 0 (primary infection).
• The malicious worm that infected Device 1 is registered on the malicious C&C server.
• The white-hat worm that has reached its predefined lifespan and infected Device 4 stops its process (back to the state where it is not infected by any worm).
• Device 4 is infected by the malicious worm that infected Device 1 (primary infection).
• The malicious worm that infected Device 4 is registered on the malicious C&C server.

Once infected by a white-hat worm and terminated by its lifespan, the device is no longer infected by either worm and can be infected by both malicious and white-hat worms.

The behavior of malicious worms and white-hat worms, focusing on the device internals, is shown in Figure 4. Figure 4 shows the behavior of each worm when a malicious worm is loaded multiple times or a white-hat worm infects a single vulnerable device.

The behavior of the worm is focused on the device internals in Figure 4 is described below.

• The commands executed by the Loader download and launch the malicious worm.
• The command executed by the Loader downloads and launches the malicious worm (the second time).
• The malicious worm launched a second time detects that a malicious worm is already running on the device and terminates its own operation, which is launched later.
• The command executed by the Loader downloads and launches the white-hat worm.
• The launched white-hat worm detects that a malicious worm is running on the device and disinfects it.
• The commands executed by the Loader download and launch the malicious worm.
• The launched malicious worm detects that a white-hat worm is running on the device and terminates the malicious worm’s own process.
• When the white-hat worm reaches the end of its lifespan, the white-hat worm terminates its own process.

3.3. Creating a Malicious and a White-Hat Worm

In creating a malicious worm and a white-hat worm, more than 100 lines of changes were made to the original Mirai source code [4], which has approximately 5700 lines. The source code of a malicious worm and a white-hat worm is publicly available at [19]. In particular, we needed to make many changes to achieve the following points.

• Enabling the secondary infection function
  • Mirai does not have the concept of primary or secondary infection, and in order to implement malicious worms and white-hat worms, processes related to primary and secondary infection were added. For example, a process was added to check whether the device into which the worm was submitted was already infected by a malicious worm or a white-hat worm, and depending on the results, the white-hat worm would disinfect the malicious worm or terminate its own process.

• Implementation of lifespan
  • Mirai does not have a lifespan function because once it starts operating, it will continue to operate until another Mirai is submitted to the same device. In order to implement the white-hat worm, a process was added to allow it to terminate its own operation after a pre-designated period of time and return to a state where the device is not infected by any of the devices (both a malicious worm and a white-hat worm can be infected).

Mirai attempts to log in to vulnerable devices using predefined username and password combinations, but we did not make any changes to this behavior. The behavior is also similar to Mitai in that the worm does not spread the infection by itself, but it uses several elements that make up the botnet to spread the infection.

Given that the malicious and white-hat worms created in this research are based on publicly available malicious code, we made them harmless by removing code that would enable malicious behavior such as DDoS attacks. In addition, to prevent the worm from behaving unexpectedly, the worm terminates itself if it can no longer connect to the C&C server. If necessary, the C&C server then sends a disinfection command to the worm so that the C&C server can terminate the worm’s operation. We deployed the white-hat worms in accordance with the ethical guidelines of the EC-Council Code of Ethics [20].

The features of each malicious worm and white-hat worm are shown in

Table 1. Features of malicious worms and white-hat worms. The features that each worm possesses are checked.

Features	Malicious Worms	White-Hat Worms
Primary infection to vulnerable devices	✔	✔
Secondary infection to devices infected with a malicious worm		✔
Secondary infection to devices infected with a white-hat worm
Lifespan features		✔
The number of devices discovered per attempt can be changed		✔

. The checked features represent the features that each worm has. Both malicious and white-hat worms can infect vulnerable devices, but a malicious worm cannot infect a device already infected by a malicious or white-hat worm, and a white-hat worm can infect a device infected by a malicious worm but not a device infected by a white-hat worm. The white-hat worm also has a lifespan function and can change the number of devices it scans at a time.

3.3.1. Malicious Worm

Malicious worms used in the proposed implementation system have the following features.

(i)

They infect vulnerable devices and then form and expand a malicious botnet.

(ii)

If the device being loaded is already infected with a worm, a malicious worm terminates its own operation.

The first function is necessary for worms and a botnet, and it is generally possessed by worms that form botnets, such as Mirai.

The second function is necessary to prevent malicious worms from having secondary infection functionality. Only white-hat worms have secondary infection capabilities, while malicious worms have the primary infection capabilities, which can only infect devices that are not infected by either worm.

To create a malicious worm with these features, the following changes were made to the Mirai source code to create the malicious worm.

(i)

Check whether the loaded device is already infected with a malicious worm or a white-hat worm, and if so, the malicious worm self-terminates the process.

The purpose of this change is to ensure that the malicious worm has only primary infection functionality (and not secondary infection functionality). It checks for the presence of a process using a specific port number, which is used by the malicious worm and the white-hat worm, and if a process using that port is present, it determines that the device is infected by the malicious worm or the white-hat worm.

Mirai originally uses a specific port number to prevent multiple launches, and if that port number is used when Mirai is launched, a process that terminates the process using that port number (i.e., Mirai) is implemented and used. Since malicious worms and white-hat worms use different port numbers, it is possible to distinguish whether a worm infecting a device is a malicious worm or a white-hat worm.

On the other hand, the ability to infect vulnerable devices to form and grow malicious botnets uses the original functionality of Mirai, so no major changes were made to the source code.

3.3.2. White-Hat Worm

White-hat worms used in the proposed implementation system have the following features.

(i)

They infect vulnerable devices and then form and expand a white-hat botnet.

(ii)

If the device being loaded is already infected with a malicious worm, a white-hat worm disinfects the malicious worm.

(iii)

If the loaded device is already infected with a white-hat worm, the white-hat worm terminates its own operation.

(iv)

By changing the value of the parameters, the speed of the white-hat worm’s infection spread can be modified.

(v)

They have the lifespan feature that terminates their own operation after a pre-defined time has elapsed.

The first feature is necessary to create and grow a white-hat botnet, as well as a malicious botnet.

The second feature is necessary to give the white-hat worm the capability of secondary infection to disinfect the malicious worm. On the other hand, since the white-hat worm does not need to be disinfected, the third feature prevents the white-hat worm that originally infected the device from being disinfected when the white-hat worm is loaded onto a device infected with the white-hat worm.

The fourth feature is necessary to optimize parameter values through parameter tuning so that a malicious botnet can be disinfected. The fifth feature is designed to reduce the impact of the white-hat worm’s operation on the device and network by automatically terminating its own operation after a certain amount of time has elapsed.

To create a white-hat worm with these features, the following changes were made to the Mirai source code.

(i)

Check to see if the device being loaded is already infected with a malicious worm, and if so, remove the malicious worm.

(ii)

It checks to see if the loaded device is already infected with the white-hat worm, and if so, it terminates its own process.

(iii)

The number of vulnerable devices discovered per time is parameterized to adjust the speed of infection spread.

(iv)

Add a lifespan feature and automatically terminate its own process after a pre-specified time has elapsed.

The first and second changes, like the malicious worm, use the process originally implemented in Mirai but differ from the malicious worm in that they eliminate the malicious worm if the device is already infected by the malicious worm.

The third change is to parameterize the number of vulnerable devices to scan at once, which was fixed in Mirai, and to allow for the value to be changed. Lowering this value reduces the number of devices that can be infected by a single worm, resulting in a slower rate of infection spread. For the Mirai and malicious worms, the value of this parameter is 160.

The malicious worm and the white-hat worm randomly scan for vulnerable devices by the number specified as the number of devices to scan at a time. The behavior is shown in Figure 5. In Figure 5, the blue arrows represent successful attempts to find vulnerable devices, and the red arrows represent unsuccessful attempts. As shown in Figure 5, the devices to be discovered are randomly selected from a range of specified IP addresses. If there are no vulnerable devices assigned to the specified IP address, the infection cannot spread, and it will not necessarily spread by the number of devices specified as a parameter.

The fourth change is to set the time until the process is terminated and terminate its own process when the specified time elapses. The lifespan feature prevents the number of devices infected by the white-hat worm from increasing too much and minimizes the impact of the white-hat worm on the devices and the network.

3.4. C&C Server

For the C&C server, a logging function was added to the original implementation of Mirai. This log is recorded when a new worm is registered on the C&C server or when a registered bot is de-registered due to its disinfection or the termination of its process due to life span. The contents of the log are as follows.

• Time when the bot was registered (or de-registered).
• IP address of the registered (or de-registered) bot.
• Whether the worm has been registered or de-registered.
• Number of bots registered with the C&C server at the time the log was logged.

The contents of the logs recorded by the C&C server can be used to determine which devices are infected by the malicious worm and the white-hat worm. In addition, to prevent unexpected worm behavior, the C&C server can send a disinfection command to the worm to terminate its operation, if necessary.

3.5. Vulnerable Devices

The vulnerable devices used in the implementation system proposed in this paper were installed with OpenWrt [21], a Linux-based OS for routers and other IoT devices. To enable the Telnet server on OpenWrt, we need to rebuild the image ourselves, [22], so we built an image with the Telnet server enabled and installed it on the device.

Each device has a Telnet server that is running and always accepting access, while Mirai uses predefined, multiple login credentials (username and password) to try to break into the device [23]. The same is true for both the malicious and white-hat worms created. Therefore, vulnerable devices were configured to allow for login using predefined login credentials.

3.6. Network

Each of the vulnerable devices shown in Figure 6 and the machines used to build the botnet were virtualized and connected by VirtualBox virtual networks. Therefore, the proposed implementation system is scalable because it is easy to change the IP address space and increase or decrease the number of vulnerable devices. In this research, 30 vulnerable devices were placed in an IP address space of 65,536.

A list of devices (virtual machines) to be used in the implementation system proposed in this paper is shown in

Table 2. List of devices used in the implementation system.

Role	OS	IP Address
DNS and DHCP server	OpenWrt 23.05.0	192.168.0.1
C&C server for malicious botnet	Ubuntu 22.04.3 LTS	192.168.0.3
Scan Listener and Loader for malicious botnet	Ubuntu 22.04.3 LTS	192.168.0.4
Web server for malicious botnet	Ubuntu 22.04.3 LTS	192.168.0.5
C&C server for white-hat botnet	Ubuntu 22.04.3 LTS	192.168.0.13
Scan Listener and Loader for white-hat botnet	Ubuntu 22.04.3 LTS	192.168.0.14
Web server for white-hat botnet	Ubuntu 22.04.3 LTS	192.168.0.15
Vulnerable device (in this study, we used 10 or 30 devices)	OpenWrt 23.05.0	192.168.0.∗ (“∗” means IP addresses for vulnerable devices are randomly assigned by DHCP server)

. As shown in Table 2, the proposed implementation system also includes DNS servers and other devices necessary to build a botnet.

4. Experiments and Evaluations

4.1. Purpose

We conducted experiments using the implementation system proposed in this paper. The purpose of the experiments was to show the optimal parameters for a malicious botnet to be disinfected by a white-hat worm, and to determine how each parameter of the white-hat worm affects the disinfection of the malicious botnet.

4.2. Experimental Methods

Based on the aforementioned purpose, this study used both malicious and white-hat worms and varied the parameters of the white-hat worms to determine whether the white-hat worms could eliminate malicious botnets and how each parameter affected the elimination of the malicious botnet. In this experiment, we investigated the parameters that can eliminate malicious botnets by changing the number of white-hat worms scanned per attempt n and the lifespan ℓ, respectively. We conducted experiments with a total of nine patterns by changing the number of white-hat worms scanned per attempt n to 50, 100, and 160, and the lifespan ℓ to 60, 180, and 300, respectively. As mentioned, the number of devices scanned per attempt in Mirai and malicious worms n is 160. In order to clarify that the results obtained by the experiments were independent of the number of vulnerable devices, the experiments described in this paper were conducted with 10 and 30 vulnerable devices, respectively, with the values of the nine patterns of parameters described above.

4.3. Evaluation Metric

To identify the parameters of a white-hat worm that can eliminate malicious botnets, the evaluation indicator is whether the malicious botnet is eliminated (i.e., whether the number of devices infected by the malicious worm is reduced to 0).

4.4. Evaluation Results

The results of the experiment with 10 vulnerable devices are shown in Figure 7. The horizontal axis of each graph is time (seconds) and the vertical axis is the number of devices infected by each worm. For $n=100$ and $\ell =180$ (Figure 7e), the malicious botnet was eliminated in 500 s; for $n=100$ and $\ell =300$ (Figure 7f), in 394 s; for $n=160$ and $\ell =180$ (Figure 7h), in 361 s; and for $n=160$ and $\ell =300$ (Figure 7i), in 170 s. On the other hand, for $n=50$ and $\ell =180$ (Figure 7b), the white-hat worm was able to infect multiple devices but could not maintain that state and failed to disinfect the malicious botnet. Also, for $n=50$ and $\ell =60$ (Figure 7a), $n=50$ and $\ell =300$ (Figure 7c), $n=100$ and $\ell =60$ (Figure 7d), and $n=160$ and $\ell =60$ (Figure 7g), the white-hat worm was unable to infect multiple devices and failed to disinfect the malicious botnet.

Next, the results of the experiments with 30 vulnerable devices are shown in Figure 8. As in Figure 7, the horizontal axis of each graph is time (seconds) and the vertical axis is the number of devices (units) infected by each worm. For $n=50$ and $\ell =180$ (Figure 8b), the malicious botnet was eliminated in 965 s, for $n=100$ and $\ell =180$ (Figure 8e) in 542 s, and for $n=100$ and $\ell =300$ (Figure 8f), in 1610 s. On the other hand, for $n=50$ and $\ell =180$ (Figure 8b), $n=100$ and $\ell =180$ (Figure 8e), and $n=100$ and $\ell =60$ (Figure 8d), the malicious botnet could not be disinfected because the white-hat worm failed to infect multiple devices. For $n=160$ and $\ell =60$ (Figure 8g), $n=160$ and $\ell =180$ (Figure 8h), and $n=160$ and $\ell =300$ (Figure 8i), the white-hat worm was able to infect multiple devices but failed to disinfect the malicious botnet. The repeated increase and decrease in the number of white-hat worms can be attributed to the fact that multiple white-hat worms that started operating at approximately the same time ended their operation due to lifespan, or that multiple devices were infected and started operating simultaneously by the white-hat worms. In addition, the time it took to disinfect the last malicious worm and for the malicious worm to infect the last device may be due to the fact that the search area was so large that it took a long time to find it.

4.5. Evaluation

Based on the results of the experiment, as shown in Figure 7 and Figure 8, the values of two parameters of the white-hat worm, the number of scans per attempt n, and the lifespan ℓ, respectively, were analyzed to determine how they affect the disinfection of the malicious botnet.

First, we found that increasing the value of n makes the white-hat worm less susceptible to the effects of randomness and makes it more likely to infect multiple devices.

Table 3. Parameters that enabled the white-hat worm to infect multiple devices. The parameters that allowed the white-hat worm to infect multiple devices are checked.

	$\mathit{\ell }=60$	$\mathit{\ell }=180$	$\mathit{\ell }=300$
$n=50$		✔✔
$n=100$		✔✔	✔✔
$n=160$	✔	✔✔	✔✔

shows the parameters that allowed the white-hat worm to infect multiple devices. In Table 3, we checked for the parameters that allowed the white-hat worm to infect multiple devices.

For $n=50$, the white-hat worm spread only when $\ell =180$, but for $n=100$, the white-hat worm spread at $\ell =180$ and $\ell =300$, and for $n=160$, the white-hat worm spread regardless of the value of ℓ. For $n=50$, the white-hat worm spread only when $\ell =180$ and $\ell =300$, and the white-hat worm failed to spread the infection. This result indicates that for smaller values of n, the worm is more susceptible to the effects of randomness in searching for vulnerable devices, making it more difficult to find vulnerable devices and spread infection, even if the time until the operation is terminated is set to be long by lifespan. Thus, the larger the value of n, the smaller the impact of randomness in searching for vulnerable devices, indicating that the white-hat worm is more likely to spread infection to multiple devices.

Increasing the value of ℓ decreased the number of devices infected by the white-hat worm, making it easier to prevent the occurrence of a situation in which the malicious botnet is more likely to spread.

Table 4. Parameters that prevented the white-hat worm from expanding the malicious botnet. The parameters for which the white-hat worm was able to prevent the expansion of the malicious botnet are checked.

	$\mathit{\ell }=60$	$\mathit{\ell }=180$	$\mathit{\ell }=300$
$n=50$		✔
$n=100$		✔✔	✔✔
$n=160$		✔	✔✔

shows the parameters under which the white-hat worm was able to prevent the expansion of the malicious botnet. In Table 4, the parameters for which the white-hat worm was able to prevent the expansion of the malicious botnet are checked.

For $\ell =60$, the white-hat worm was unable to prevent the malicious botnet from spreading regardless of the value of n; for $\ell =180$, the white-hat worm was able to prevent the malicious botnet from spreading for $n=50$ and $n=100$; and for $\ell =300$, the white-hat worm was able to prevent the malicious botnet from spreading for $n=100$ and $n=160$. Also, focusing on Figure 8e,f, the number of devices infected by the white-hat worm for $\ell =180$ is below 25 most of the time, while for $\ell =300$, it is above 25 most of the time. In other words, the higher the value of ℓ, the more devices are infected before the operation is terminated by the lifespan, indicating that the white-hat worm can maintain a situation where more devices are infected. Also from Figure 8g through Figure 8i, we can see that for $n=160$, similarly, the larger the value of ℓ, the more devices were infected until the operation was terminated due to lifespan, and the white-hat worm was able to maintain the situation where more devices were infected. Thus, the longer the white-hat worm was able to infect more devices, the easier it was to disinfect the malicious botnet.

These analyses show that the ability of the white-hat worm to infect multiple devices and the ability of the white-hat worm to maintain a situation where many devices are infected by the white-hat worm are important for disinfecting the malicious botnet.

For the parameter of being able to disinfect the malicious botnet, we found that for $n=100$ and $\ell \ge 180$, the white-hat worm was able to disinfect the malicious botnet. However, for $n=100$ and $\ell =300$, the number of devices infected by the malicious worm could not be reduced to 0, but it remained at only one device infected by the malicious worm, preventing the malicious botnet from expanding again on a large scale.

Moreover, as for the impact of the number of scans per attempt n and the value of lifespan ℓ on the disinfection of the malicious botnet, a small value of n means that the white-hat worm is less likely to be able to search vulnerable devices before reaching its lifespan, which makes it more difficult for the white-hat worm to infect multiple devices and disinfect the malicious botnet, and it was shown that the smaller the value of ℓ, the harder it is for the white-hat worm to maintain a situation where it infects many devices, which affects its ability to disinfect the malicious botnet.

5. Conclusions

In this paper, we propose an implementation system that uses a malicious worm created by modifying the Mirai source code and a white-hat worm. Using the publicly available Mirai source code, the study implemented the basic features of the white-hat worm, such as “secondary infection”, in which the malicious worm is disinfected by infecting a device already infected by the malicious worm, and “lifespan”, in which the worm terminates its own operation after a certain amount of time has passed after infecting a device. This paper shows how to implement a white-hat worm in general and specific ways that are not limited to the Mirai source code.

Through experiments, we showed that the white-hat worm can eliminate the malicious botnet by optimizing two parameters of the white-hat worm, namely, the number of searches per attempt n and the lifespan ℓ, respectively, and demonstrated the effectiveness of the white-hat worm’s function of eliminating the malicious botnet, which is to eliminate the malicious botnet. The effectiveness of the feature was demonstrated. A detailed analysis of each of the parameters of the white-hat worm revealed that the larger the value of n, the more likely the white-hat worm is to infect multiple devices, and the larger the value of ℓ, the more likely it is to keep many devices infected with the white-hat worm, thus preventing the malicious botnet from spreading. This means that it is easier to keep a large number of devices infected with the white-hat worm and to prevent the malicious botnet from spreading and to disinfect the malicious botnet.

The future work is to dynamically modify the parameters of the white-hat worm to eliminate malicious botnets with a minimum number of white-hat worms, focusing on efficiency and the ability to optimize the elimination of malicious botnets according to different situations of the malicious botnet. While white-hat worms have the benign property of disinfecting malicious botnets, the impact of communication generated by white-hat worms on the network increases with the number of devices infected by the white-hat worms, and especially in the case of large networks, this may have an impact on the performance and stability of the network. We have not yet conducted any research or simulations to evaluate the impact of white-hat worms on the overall performance and stability of a network. Determining the impact of white-hat worms on a network is one of the future studies to be conducted.

In addition, to apply the proposed method to a network of about 1000 devices, we are working on implementing the distributed virtual machine environment by using multiple physical machines. For very large networks with more than 1000 (e.g., 10,000) devices, we are planning to address this issue in terms of both implemented systems and simulations.