{'fraction_non_alphanumeric': 0.030279284079867096, 'fraction_numerical': 0.008557188979092875, 'mean_word_length': 4.948815961215738, 'pattern_counts': {'":': 0, '<': 8, '<?xml version=': 0, '>': 9, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Machine Learning-Based Early Detection of IoT Botnets Using Network-Edge Traffic

In this work, we present a lightweight IoT botnet detection solution, EDIMA, which is designed to be deployed at the edge gateway installed in home networks and targets early detection of botnets prior to the launch of an attack. EDIMA includes a novel two-stage Machine Learning (ML)-based detector developed specifically for IoT bot detection at the edge gateway. The ML-based bot detector first employs ML algorithms for aggregate traffic classification and subsequently Autocorrelation Function (ACF)-based tests to detect individual bots. The EDIMA architecture also comprises a malware traffic database, a policy engine, a feature extractor and a traffic parser. Performance evaluation results show that EDIMA achieves high bot scanning and bot-CnC traffic detection accuracies with very low false positive rates. The detection performance is also shown to be robust to an increase in the number of IoT devices connected to the edge gateway where EDIMA is deployed. Further, the runtime performance analysis of a Python implementation of EDIMA deployed on a Raspberry Pi reveals low bot detection delays and low RAM consumption. EDIMA is also shown to outperform existing detection techniques for bot scanning traffic and bot-CnC server communication.


I. INTRODUCTION
The Internet of Things (IoT) [2] is a network of sensing devices with low-power and limited processing capability, which exchange data with each other and/or systems (e.g., gateways, cloud servers), normally using wired (e.g., Ethernet) and wireless technologies (e.g., RFID, Zigbee, WiFi, Bluetooth, 3G/4G). IoT devices are used in a number of applications such as wearables (fitness trackers, smart watches), home automation (lighting systems, thermostats, cameras, door locks) and industrial automation (manufacturing equipment/asset management, process control, plant safety). Globally, the total number of IoT devices deployed by 2025 is estimated to reach 41.6 billion [3].
Unfortunately, hackers are increasingly targeting IoT devices using malware (malicious software) due to the following reasons [4]- [6]: • Many legacy IoT devices are connected to the Internet for which security updates are not installed regularly. • Low priority is given to security within the development cycle of IoT devices. • It is computationally expensive and often infeasible to implement conventional cryptography in IoT devices due to processing power and memory constraints.
• Weak login credentials are present in many IoT devices which are either hard-coded by the manufacturer or configured by users. IoT device manufacturers to provide remote support for the device. • Consumer IoT devices or the gateway through which they connect to the Internet, often do not have a firewall installed.
On October 21, 2016, attackers launched the biggest Distributed Denial-of-Service (DDoS) attack on record using a botnet consisting of IoT devices (IP cameras, DVRs) infected with the IoT malware Mirai, targeting the Dyn Domain Name Service (DNS) servers [7]. The Mirai source code was leaked in 2017 and since then, it has been re-used by script "kiddies" as well as professional hackers to build their own IoT malware. These malware are either variants of Mirai, which perform a similar brute force scan of random IP addresses for IoT devices with open TELNET ports and attempt to login using a built-in dictionary of credentials (e.g., Remaiten, Hajime), or more sophisticated ones that exploit software vulnerabilities in IoT devices to execute remote command injections (e.g., Reaper, Satori, Masuta, Linux.Darlloz, Amnesia). The various components of a typical IoT botnet and how they work with each other is explained in [8] by taking the example of Mirai.
Bots compromised by IoT malware can be used for DDoS attacks, spamming, phishing and bitcoin mining [9], [10]. These attacks can cause network downtime for long periods leading to financial losses for Internet Service Providers (ISP), leakage of users' confidential data, and unauthorized exploitation of computational resources. Attacks originating from IoT botnets have continued unabated and have in fact, increased since the infamous 2016 Mirai DDoS attack. The author of IoT malware Satori and its improved versions (Masuta, Okiru), pleaded guilty in September 2019 to creating and managing botnets enslaving hundreds of thousands of IoT devices (including security cameras, DVR systems, home routers), launching DDoS attacks against various targets (e.g., ProxyPipe, a DDoS mitigation firm) using these botnets and running DDoS-for-hire services during the 2017-18 period [11]. Kaspersky claimed to have detected 105 million attacks on its IoT honeypots spread over the globe in the first six months of 2019, a significant increase from the 12 million attacks detected in 2018 [12]. On April 24, 2019, a botnet consisting of more than 400,000 IoT devices (home routers, modems, and other CPEs) launched a massive DDoS attack against a Content Distribution Network (CDN) company in the entertainment industry that lasted 13 days with peak attack flows reaching 292,000 HTTP GET/POST requests per second, making it one of the largest Layer 7 attacks handled by the DDoS mitigation firm, Imperva [13]. DDoS attacks using IoT botnets continue to grow in number as well as frequency, according to The State of DDoS Weapons report published by A10 Networks for the fourth quarter of 2019 [14].
Furthermore, it is to be expected that many of the infected devices will remain so for a long time. Most IoT malware do not persist after the host device undergoes a reboot, but the device is likely to be reinfected soon by the same or another malware. Therefore, there exists a strong motivation to detect these IoT bots and manage them appropriately. It has been pointed out in [15] that it is futile to attempt to ensure that all IoT devices are secure-by-construction. Deploying traditional host-based detection and prevention mechanisms such as antivirus and firewalls for IoT devices is practically infeasible. Therefore, security mechanisms for the IoT ecosystem should be designed to be network-based rather than host-based.
We propose a lightweight IoT botnet detection solution, EDIMA (Early Detection of IoT Malware Scanning and CnC Communication Activity), which is designed to be deployed at the edge gateway installed in home networks and targets the detection of botnets at an early stage of their evolution before they can be used for further attacks. EDIMA employs a two-stage detection mechanism which first uses Machine Learning (ML) algorithms for aggregate traffic classification based on bot scanning traffic patterns, and subsequently Autocorrelation Function (ACF)-based tests which leverage bot-CnC messaging characteristics at the per-device traffic level to detect individual bots. We only target IoT botnets with centralized Command-and-Control (CnC) architecture in this work. Historically, centralized botnets have been more widely deployed in real-world networks (PC-based as well as IoT), compared to Peer-to-Peer (P2P) botnets [16] as they are easier to set up and manage, though P2P botnets that avoid the single point-of-failure in centralized botnets are growing in number.
EDIMA also includes a database that stores malware traffic packet captures, a policy engine which determines the further course of action if gateway traffic has been classified as malicious and a traffic parser/sub-sampler which sorts the aggregate gateway traffic and optionally sub-samples the traffic at a specified rate. EDIMA can be deployed both on physical edge gateways or as Network Function Virtualization (NFV) functions at the customer premises in an SDN-NFV based network architecture, where SDN stands for Software-Defined Networking. EDIMA can also be deployed alongside an intrusion detection system at the gateway.
Justification For ML-based Detection: While TELNET port scanning can be countered by deploying a firewall or intrusion detection system (at the edge gateway) which blocks incoming/outgoing TELNET traffic, malware that exploit software vulnerabilities targeting application protocols such as HTTP, SOAP, PHP, etc., are difficult to block using a rule-based approach because these protocols are used by legitimate traffic as well. Furthermore, deep-packet inspection IDS is not a practically viable solution for consumer IoT devices (connected to ISP networks through gateways) which are the focus of our work. It is computationally too expensive to be deployed at such gateways and requires specialized hardware. Hence, we propose to use an ML-based approach instead for detecting those sophisticated IoT malware. Utilizing carefully selected malware traffic features independent of application protocols, ML algorithms can be trained to distinguish between benign and malicious traffic (containing malware-generated packets).
EDIMA targets IoT botnets at an early stage of their evolution, when they are scanning for and infecting vulnerable devices, as the scanning and propagation phase of the botnet life-cycle stretches over several months [17]. This means that IoT bots can be detected and isolated long before they can be used for attacks such as DDoS. If a botnet has reached substantial size and started launching attacks already, they can be detected using existing methods in literature and industry to defend against such attacks.
The major contributions of this paper are listed below: 1) We characterize the scanning and bot-CnC server communication traffic patterns for IoT malware. 2) We propose a lightweight IoT botnet detection solution, EDIMA, employing a two-stage detection mechanism which first uses ML techniques for aggregate traffic classification at the edge gateway and subsequently, ACFbased tests to detect individual bots. We also evaluate EDIMA's detection performance comprehensively. 3) We implement EDIMA using Python, deploy it on a Raspberry Pi and evaluate its runtime performance.
A preliminary version of this work was presented in [1]. The following points illustrate the ways in which we have expanded upon our previous work: • We have refined the architecture for our proposed IoT botnet detection solution, EDIMA, and explained the functions of its modules in greater detail. • New features have been added for detection of scanning activity in aggregate gateway traffic. • We have introduced a novel, second stage for individual bot detection after the first stage of aggregate gateway traffic classification. • The performance evaluation testbed has been expanded to include more IoT devices. • Instead of emulating the behavior of IoT malware to generate malicious traffic training data as done in our previous work, we use real, live malware samples. • Unlike our previous work, we have followed all the required steps for data processing before applying ML classifiers. • We have done a performance comparison with few existing works in literature. • We have also evaluated the scalability performance and runtime performance of a software implementation of EDIMA. The rest of this paper is organized as follows. In Section II,  we review a few prominent works on detecting botnets exploiting CnC communication features, intrusion and anomaly detection systems for IoT, detecting attacks originating from IoT  botnets, and IoT device traffic fingerprinting. Subsequently,  in Section III, our proposed IoT botnet detection solution, EDIMA is presented while in Section IV, the operation of EDIMA's modules is described in more detail. Finally, in Section V, we present the aggregate traffic classification and bot detection performance results for EDIMA, evaluate the runtime performance of its Python implementation and compare EDIMA's performance with previous works.

II. RELATED WORK
Botnet detection using scanning traffic features has not been adequately addressed in the literature. In particular, there are no existing works on IoT botnet detection using scanning traffic features. However, there have been several prominent works on detecting PC-based botnets using their CnC communication features. In [18], ML-based techniques for CnC traffic detection in Internet Relay Chat (IRC) botnets have been presented which first distinguish between IRC and non-IRC traffic and then between bot and real IRC traffic. This approach of classifying traffic into IRC and non-IRC to detect IRC-based botnets has also been used in other works [19]- [21]. A bot infection dialog model has been built in Bothunter [22] based on which the authors have constructed three bot-specific sensors and performed correlation between inbound intrusion/scan alarms and the infection dialog model to generate a consolidated report. In Botsniffer [23], the authors have captured spatio-temporal similarities between bots in a botnet (in terms of bot-CnC coordinated activities) from network traffic and utilized them for botnet detection in a local area network. BotMiner [24] has proposed a botnet detection system in which similar CnC communication traffic and similar malicious activity traffic are clustered, and subsequently cross cluster correlation is performed to detect bots in a monitored network. A number of other works have used clustering of flows with similar characteristics to detect botnets [25]- [27].
A few research works have also dealt with intrusion detection systems for IoT. In [28], the authors have presented a whitelist-based intrusion detection system for IoT devices, Heimdall, which uses dynamic profile learning and runs on IoT gateway routers. An intrusion detection model for IoT backbone networks has been proposed in [29] which employs two-layer dimension reduction and later, two-tier classification techniques for User-to-Root (U2R) and Remote-to-Local attack (R2L) detection. Anthi et al. [30] have proposed a three layer intrusion detection system targeted at smart home IoT devices, which detects network security attacks through normal behaviour profiling of IoT devices connected to the network, malicious packets' identification during the attack and subsequent attack classification.
Of late, the research community has been interested in IoT botnet and attack detection with a number of papers addressing these problems. There have been a few works on anomaly detection systems for IoT that build normal communication profiles for IoT devices, i.e., the profiles are not expected to change much over a long period of time (DEFT [31]). Any deviation from those profiles is flagged as anomalous traffic (DÏoT [32], NETRA [33]). Hamza et al. [34] have proposed a tool to automatically generate Manufacturer Usage Description (MUD) profiles for a number of consumer IoT devices. Using those MUD profiles, the authors have derived flow rules to be configured on SDN switches, identified their limitations in detecting network attacks on IoT devices and addressed those limitations by proposing an anomaly detection-based approach used in conjunction with an off-the-shelf IDS [35].
In [36], an anomaly detection technique built using deepautoencoders has been used to detect attacks launched from IoT botnets. Statistical features have been extracted from behavioural snapshots of normal IoT device traffic captures which are used to train deep learning-based autoencoders (for each IoT device). Subsequently, the reconstruction error for traffic observations is compared with a threshold for normalanomalous classification. Following a slightly different approach, Kitsune [37] proposes an online unsupervised anomaly detection system based on an ensemble of autoencoders which is lightweight in terms of memory footprint and meant to be deployed on network gateways and routers to detect attacks on the local network.
Our work addresses few important gaps in the IoT botnet detection literature. First, botnet detection techniques using CnC communication features [18], [22]- [24] are designed for PC-only networks whereas our botnet detection solution is designed specifically for IoT networks. IoT networks pose a number of unique research challenges as compared to PC-only networks: • In a typical IoT network, multiple IoT/non-IoT devices are connected to the Internet through a gateway which may be a wired/wireless access point (also acting as a modem) or a cellular base-station whereas PC-only networks consist of mostly PCs connected to the Internet directly through modems. • PC traffic is more user driven and diversified since a number of different user-level applications, e.g., browsing, email, word processor, run on a PC simultaneously and generate traffic based on user behaviour. IoT devices, on the other hand, are always-connected, run one or two applications only, and send data to servers regularly without user intervention. As a result, their traffic has discernible patterns [31] different from PC traffic.
Moreover, the PC-only botnet detection schemes proposed in [18], [22]- [24] are designed for enterprise networks whereas our work targets home networks. Also, the PC-only botnet detection solutions are based on detection of bot-CnC traffic only whereas our work is based on detection of scanning activity first and subsequently bot-CnC communication for a more accurate bot detection scheme. Second, our focus is on detecting botnets irrespective of the type of CnC communication protocol used (e.g., IRC, SMTP), unlike [18]. Third, in this work, we aim to detect individual bots (instead of detecting the network of bots in a botnet directly) which can then be used towards detecting the botnet. This can be done, for example, by correlating the positions of detected bots within a network, or by using techniques based on clustering algorithms and cross-cluster correlation proposed in existing works on PC-only botnet detection [23], [24].
Fourth, our aim is to detect IoT bots long before they are used to launch attacks, during the scanning/infection phase, unlike [32], [36]. Finally, instead of using normal IoT devices' traffic fingerprinting [31] and subsequent anomaly detection [32], [33], we follow the approach of misuse-detection where we detect IoT bots by utilizing certain distinguishing features of bot scanning traffic and bot-CnC communication traffic in succession. The former approach suffers from limitations such as an inability to narrow down the cause of anomaly, possibility of misclassification of a bot as a legitimate device type, limited testing against evasive malware which can easily trick the anomaly detection system by manipulating device traffic (because fingerprinting is performed at the device-level), etc.
Kitsune [37] suffers from a similar limitation which is common to most anomaly detection systems, i.e., an inability to point out the source of anomaly. Further, it has been tested with one only IoT malware, Mirai, which is relatively simple to detect and it is difficult to say whether Kitsune will perform well against other IoT malware in the real-world. Again, Kitsune is more focused on attack detection rather than early-stage detection of botnets which is the focus of our work. Though Kitsune advocates online algorithms as it is focused on detecting attacks, for the use-case of early-stage detection of IoT botnets, offline algorithms are deemed to be sufficient as botnets take time to evolve before they are used for attacks. As expected, EDIMA is not free from limitations too, which is explained in Section V-G. Rather, a combined approach consisting of EDIMA and IoT device fingerprinting plus anomaly detection is advocated for a more robust IoT botnet detection performance.

III. EDIMA ARCHITECTURE
EDIMA is designed to have a modular architecture, as shown in Fig. 1, with the following components: 1) Feature Extractor: This module extracts features from the aggregate traffic at the gateway. These features are then forwarded to the ML-based Bot Detector (MBD), which is described below, for classification during the execution phase. The Feature Extractor (FE) also sends features extracted from the aggregate traffic to the ML Model Constructor (MC), which is also described below, during the training phase. The feature extraction process is explained in Section IV-A. 2) ML-based Bot Detector: This is a 2-stage module with the first stage being a coarse-grained one that classifies the aggregate traffic samples using the features obtained from FE and the ML model trained and forwarded by the MC. Depending on the result of the classification, the second fine-grained stage attempts to identify the infected IoT device(s) from the set of devices connected to the gateway. More details about the classification operation are given in Section IV-A while the bot detection process is described in Section IV-B. 3) Traffic Parser/Sub-sampler: The traffic parser (TP) sorts the combined gateway traffic into traffic sessions. During the bootstrap (training) phase of EDIMA, it also helps replay malware traffic samples along with normal traffic to generate malicious traffic samples. We also propose an option for traffic sub-sampling as introduced in [38]. Under this option, the packet traffic from IoT devices is sampled across the devices and the sub-sampled traffic is then forwarded to the FE. This operation would help reduce the storage overhead but there is a trade-off in terms of detection delay. 4) Malware PCAP Database: This frequently updated database stores malware traffic pcap files captured from private and professional honeypots targeted at IoT malware. We envisage a community of authorized security researchers who will collect the above pcap files and upload them to the database through an online interface. The files will be anonymized before uploading to ensure user privacy. Similarly, the training data representing malicious traffic needs periodic updates due to addition of newly discovered IoT malware to mDB. The MC retrieves the new malware pcap files from mDB and publishes them to the TP which replays those malicious pcap files at the gateway. The malicious traffic so obtained is forwarded to the FE which extracts the malicious traffic features and sends them to the MC through the gateway-MC client. The period for benign and malicious training data set updates should be set separately as the frequency of changes in benign traffic is expected to be lower than in malicious traffic (due to new IoT malware being created and discovered almost every day). 6) Policy Engine: The policy engine (PE) consists of a list of policies defined by the network administrator, which determine the course of actions to be taken once an IoT device connected to the edge gateway has been detected as a bot. For example, the entire traffic originating from bots can be blocked by the network administrator. The underlying IoT devices can be brought back online once they have been cleared of the malware. The details of this module are discussed in Section IV-C.
EDIMA's architecture is designed to be scalable in the sense that, as the number of gateways in a network increases, more MCs can be deployed with each MC catering to a group of gateways. As the MC is implemented in the cloud, the amount of resources allocated to it can be increased easily, depending on the requirement. The cloud service using which MC and mDB are implemented should be secure by industry standards. This can be ensured by employing cloud services offered by well-known commercial cloud service providers (e.g., Amazon, Microsoft, Google).

A. Detection of Scanning Activity in Aggregate Gateway Traffic
The first coarse-grained stage of the ML-based Bot Detector performs classification on aggregate gateway traffic rather than per-device traffic. According to Basil et al. [39], one needs to keep track of less fine-grained traffic details while monitoring aggregate traffic behaviour, compared to inspecting individual packets. This might result in a lower detection accuracy and false positives, but offers several advantages such as lower computational load and faster analysis, thus contributing to higher scalability. Moreover, using less fine-grained details in the characterization of malicious traffic results in a detection scheme which is more resilient to evasion. The attacker would have to compromise the efficiency of the malicious activity to evade detection.
The aggregate gateway traffic is assumed to belong to either of the following classes: benign or malicious. Here, benign traffic refers to gateway traffic which does not consist of bot scanning packets whereas malicious traffic refers to gateway traffic that does. The gateway traffic is captured in the form of traffic sessions which are defined statically as the set of ingress/egress packets at a network interface over a fixed time interval. Further, the classification algorithm is applied on these traffic sessions rather than individual packets. This is because per-packet classification is computationally much more expensive and does not yield any significant benefits over per-session classification.
In a traffic session, we extract features from TCP packet headers only and not the payloads. Though payloads may be quite helpful for classification, it is possible that are encrypted (e.g., HTTPS traffic). By not depending on payload information, we ensure that our aggregate traffic classification method works on unencrypted as well as encrypted traffic. Below are the steps for gateway-level traffic classification: 1) Filter each gateway traffic session to include only TCP packets.  The intuition behind selecting the first feature is that most IoT bots generate random IP addresses and send malicious packets to them. Hence, the number of unique destination IP addresses in the presence of malware-induced scanning traffic will be significantly higher than benign traffic. The second set of features was selected because malware typically send very few scanning packets to the same IP address, in order to cover as many devices as possible. The third feature seeks to exploit the fact that while scanning, a bot opens multiple TCP connections to random IP addresses, the majority of which do not respond and so the connections remain half-open. Finally, compared to packet length in benign TCP connections, malware scanning packet lengths are generally shorter, making the fourth set of features useful for classification.

B. Detection of Individual Bots using Bot-CnC Communication Patterns
Once the aggregate traffic at an edge gateway has been classified as malicious, the second fine-grained stage of the ML-based bot detector attempts to detect the underlying bots by checking the ingress/egress traffic from each IoT device for the presence of bot-CnC communication patterns. The set of IoT devices is sorted according to their IP addresses. For the sake of efficiency, we propose that the set be divided into two halves, and each half should be checked for bots in parallel. Here, we are not making any assumptions about the likely locations of the infected devices in the set. The complete bot detection algorithm is shown in Algorithm 1. The degree of parallelization in our algorithm can be increased depending on the delay requirements.
Periodicity Detection in Bot-CnC Communication In most existing IoT botnets, including the Mirai-variants [8], there is a periodic exchange of TCP messages ([PSH, ACK], [ACK]) or UDP messages between the bot and the CnC server. This assumption is supported by our empirical analysis of a number of IoT malware samples belonging to different malware categories (Appendix A-A) as detailed in Section V-B, all of which exhibited the above bot-CnC communication behaviour. We would like to point out here that it is practically infeasible to analyse all possible IoT malware and it is a general practice followed in botnet detection literature to test if Detect_bot_cnc_comm (devindL) = PERIOD_DETECTED then 12: Append (InfectedDevList, devindL) 13: end if 14: end for 15: return (InfectedDevList) with malware samples belonging to a few distinct malware families.
It seems fairly straightforward that to detect the presence of bot-CnC communication, we filter the traffic from a potential bot for UDP packets or TCP packets (with PSH and ACK flags ON) and check for periodicity in the transmission times of filtered packets. However, IoT devices also send legitimate application data to a cloud server periodically. Filtering the device traffic for TCP/UDP packets alone may lead to false positives, i.e., device-cloud server traffic may be mistaken for bot-CnC server messaging traffic.
Therefore, we further exclude IoT application data packets from our analysis using appropriate packet capture filters. It has been observed from the packet captures of uninfected commercial IoT devices and IoT malware running on embedded devices (Section V-B) that as opposed to the legitimate application data packets from IoT devices, bot-CnC communication TCP/UDP packets have TCP payload consisting of a few bytes only. Hence, we build a packet capture filter to exclude packets consisting of TCP payload greater than a few bytes (e.g., 5 or 10) from our analysis to obtain TCP/UDP packets related to bot-CnC communication. Even then, we may be left with TCP/UDP packets sent by desktops or phones to a server (e.g., user requesting for a web page through HTTP GET), though they are not periodic and can be considered as noise packets.
Subsequently, we sample and encode the filtered packets to produce a uniformly sampled discrete-time signal using the approach suggested in [40] for further signal processing. Let the time of arrival of filtered packets be denoted as t j , where j = 0, . . . , N − 1 and N is the number of packets. Then, the encoding function is represented as: where i = 1, 2, . . . , K and T is the sampling time interval.
To detect periodicity in time series data, the usual approach followed in literature [41] is to calculate the power spectral density (PSD) of the time series (which can be estimated by a periodogram). Then, a statistical hypothesis test (e.g., Schuster's test, Walker's test) is used to compare a statistic computed from the periodogram's frequency components against a threshold to decide between the null hypothesis H 0 (underlying time series is not periodic) and the alternate hypothesis H 1 (underlying time series is periodic). The threshold is calculated from the asymptotic probability distribution (when K → ∞) of the test statistic.
However, in a real-world implementation, we cannot wait to collect so many samples (for the test statistic to converge to its asymptotic distribution) as that would lead to a large delay in bot detection. This is because the typical time interval between consecutive bot-CnC messages is of the order of few minutes. To collect a statistically significant number of samples, for example 500, assuming the bot-CnC messaging interval as 1 minute, we would have to capture an IoT device's traffic for at least 500 minutes ≈ 8 hours. Even the Fisher's test, which gives an exact probability distribution expression for calculating the comparison threshold, exhibits poor statistical power [42] when applied to short length time series (less than 40-50 time points).
In this work, we use the autocorrelation function (ACF). ACF can be used to reveal hidden periodicity in a signal even if it is corrupted by noise. For short length time series signal such as desired in our use case (bot detection), calculating ACF directly is not very computationally expensive. The unbiased ACF of discrete time signal e(i) (with mean e) at a lag l can be estimated as: We calculate the autocorrelation series corresponding to e(i) by applying ACF at various lags. Subsequently, the peaks (with height greater than a pre-defined value) in the autocorrelation series are found and the inter-peak gaps are calculated. If the variance of those gaps is lower than a threshold, the discrete sequence is detected as periodic. The complete algorithm proposed for detecting the presence of bot-CnC communication is shown in Algorithm 2. Handling False Positives/Negatives: EDIMA is designed to handle false positives/negatives in the edge gateway's aggregate traffic session classification. For example, let us assume that there is a false positive, i.e., a traffic session is classified as malicious though it is benign. The ML-based bot detector stage after ML classifier (Fig. 2) which detects the bot device(s) using ACF-based test, would not detect any bot and therefore EDIMA would know that there was a false positive in traffic session classification. However, assuming that there is a false negative, i.e., a traffic session is classified as benign though it is malicious, the ACF-based test stage would not be invoked. We propose to handle this by taking the average of classification results for a fixed number of consecutive traffic sessions subsequent to a session being classified as benign. It is expected that by running over multiple sessions, the classification algorithm would be able to distinguish between true positives and false negative in more sessions than not and thus the averaging of classification results would lead to a true positive classification.

C. Policy Engine
Once a device or set of devices has been detected as bot(s), the policy engine decides the actions to be taken against those devices. We envision a set of default policies pre-configured by the network administrator along with the capability to make and update new policies as part of this module. For instance, some of the expressions for policy configuration can be: policy-engine -create-policy <policy-name> policy-engine -add-action <policy-name> -dev <device-name> -action <action-name> policy-engine -delete-action <policy-name> -dev <device-name> -action <action-name> policy-engine -delete-policy <policy-name> We now mention some of the actions which can be taken by the policy engine. One such action where the bot traffic is blocked by the network administrator was mentioned in Section III. Another alternative is to allow the bot to communicate with a few secure domains only for malware infection remediation [43]. It is also possible to place the bot under continuous monitoring and deny all other communication except that required for the functioning of the underlying IoT device.

A. Testbed Description
To evaluate the performance of EDIMA on real devices, we built a testbed with commercial IoT and non-IoT devices which are listed in Table II. Typical network applications running on the laptops/desktops were web browser (accessing web pages, video streaming sites, e.g., YouTube), email clients, etc. Similarly, applications such as web browser, social media (Facebook/Twitter/LinkedIn), chat (WhatsApp), etc., were running on the smartphones along with a few other network applications in the background. The devices were used by 3 staff members in our lab over a period of 4 weeks, and thus the traffic data collected from those devices reflects real-world users' behaviour.  The edge gateway where the traffic from all the above devices was aggregated was a Linksys WRT32X router with a Marvell Armada 385 88F6820 1.8 GHz dual-core processor, 512MB RAM, 256MB NAND flash memory supporting IEEE 802.11a/b/g/n Wi-Fi standards. The Linksys WRT32X router comes with out-of-the-box OpenWRT [44] support (Version: Bleeding Edge). The packet traces collected from the router were analysed on a Dell OptiPlex 5060 desktop PC with an Intel Corei5-8500T 2.1GHz six-core processor, 8GB RAM running Ubuntu 18.04. The testbed schematic and picture are shown in Fig. 3a and 3b.

B. Data Collection
As mentioned in Section IV-A, we classify aggregate traffic at the gateway into benign or malicious. Therefore, we need training data samples to represent both classes. Benign traffic can be generated through the normal operation of uninfected devices. However, malicious traffic consists of both benign traffic as well as malware scanning/infection packets. To generate malicious traffic, we have three options: 1) Run live malware on the device(s) in our testbed  2) Emulate the malware on our testbed 3) Replay live malware traffic on our testbed The first option, though capable of generating the most realistic malicious traffic, is ruled out as the live malware may infect other devices connected to the Internet and use them for attacks. Moreover, none of the IoT devices in our testbed had any known software vulnerabilities which could have been exploited by existing IoT malware. We used the second option in our earlier work [1]. However, emulating malware requires assumptions about their behaviour (such as scanning, communication with CnC server) which may not be fully representative of live malware.
Therefore, in this work, we adopted the third option. We obtained 23 live IoT malware samples over a period of 3 months (May-July, 2019) from APIs provided by New Sky Security [45] and malware hosting server links posted by Bad Packets Report Twitter account [46], henceforth referred to as the IoT-BPR-NSS dataset. The FANTASM framework, provided by DeterLab [47] team for safe experimentation with live malware based on [48], was used to run the malware samples and collect the packet traffic generated by them.
Many of the malware samples were simple variants of each other as revealed by analysing their traffic using Wireshark. Those simple variants were discarded as they would not have added any value to our classification dataset. We ended up with two malware samples, called loligang and echobot by their authors, which belong to the TELNET and HTTP POST+GET categories (Appendix A-A) respectively. We could not obtain malware samples from other categories, as many of those malware were not active by the time we started collecting samples. We ran loligang and echobot binaries on the FANTASM testbed for 5 minutes each and captured the corresponding traffic pcap files. Malicious traffic was then generated by replaying the malware traffic collected from FANTASM on the edge gateway using the tcpreplay utility. We could not replay the malware traffic on commercial IoT devices in our testbed as they do not provide a shell to users.
We used traffic session durations of 5, 10 and 15 minutes for this study. 1000 traffic sessions were captured for benign traffic and a further 1000 sessions for malicious traffic through our testbed. The malicious traffic sessions consisted of 400 sessions corresponding to loligang, another 400 sessions corresponding to echobot and the remaining 200 sessions corresponding to both loligang and echobot traffic replayed at the OpenWRT router. The features mentioned in Section IV-A were extracted from the captured sessions. Finally, appropriate class labels were assigned to the extracted feature vectors.
Apart from the IoT-BPR-NSS dataset, we also considered the IoT-23 dataset [49] which captured the traffic for 20 IoT malware samples from 2018 to 2019. However, roughly half the dataset consisted of Mirai or Mirai-like malware traffic, which we already had from the live malware samples we had obtained. The other half of the dataset consisted of more sophisticated centralized and P2P architecture botnet malware (e.g., Kenjiru, Okiru, Hakai, Hajime). The pcap files corresponding to centralized architecture malware did not contain scanning packet traffic and therefore, we could not use their data in training EDIMA's ML algorithms for aggregate gateway traffic classification. The P2P botnet malware traffic files were not used as the focus of our work is on centralized botnet malware.
Both the IoT-23 and IoT-BPR-NSS datasets consisted of bot-CnC server communication packets. We used them to verify our assumption that bot-CnC messaging is periodic as stated in Section IV-B. The malware pcap files obtained from those datasets were analysed for bot-CnC messaging packets. This was done by filtering the the pcap files for repetitive connections (including TCP ([PSH, ACK], [ACK]) or UDP messages) with a suspicious CnC server and checking the timings of those connections for periodicity.

C. Data preparation
The feature vectors obtained in the previous section for benign and malicious classes were checked for missing values and handled appropriately. Next, all the values in a feature vector were scaled using a MinMaxScaler [50] to lie within the range (0,1). This was done to avoid bias due to different scales of features. Further, the feature vectors were randomly permuted so that the sequence in which they were extracted does not affect the training of the classifier. The combined benign and malicious feature vectors were randomly divided into training and test datasets using an 80:20 split.

D. Feature selection
It is possible that some of the features extracted from training data are redundant or irrelevant with little to no contribution in improving the ML classifier's performance. Feature selection, or selecting a subset of relevant features, can help in simplifying the ML classifier model, shortening the time for training and reducing over-fitting. We used the χ 2 statistical test to compute the χ 2 test statistic for each feature from the sample data. The χ 2 test values for features extracted from the 15 minutes traffic session dataset are shown in Table III. Subsequently, we selected the best k= 6 features (having test statistic value more than zero) for training our ML classifiers. In order to visualize the final data obtained in the previous sub-section and check if the benign and malicious data points are separable using the features proposed, we performed a Principle Component Analysis (PCA). PCA reduces the dimensionality and captures the big principal variance in a set of observations (feature vectors in our case) by generating new variables, called principle components (PCs). These PCs are orthogonal to each other and obtained as the eigenvectors of the largest eigenvalues of the covariance matrix of the original set of observations. A 2D scatter plot of two PCA components extracted from the final data for 15 minutes traffic session is shown in Fig. 4. The benign and malicious PC points seem to be separable using a pair of decision boundaries on either side of the benign PC points cluster. There will still be a small number of outliers though, especially around the left decision boundary which does not provide a clear separation.

1) Scanning Activity Detection Performance:
We trained the following ML models using the final feature vectors obtained in Section V-D after completing all the data processing steps: Gaussian Naive Bayes' (GNB), Support Vector Machine (SVM) and Random Forest (RForest). Subsequently, the trained ML models are used to predict the class labels of the test dataset and thereby, the detection performance of the models is evaluated and compared. In this work, a 10-fold cross validation (CV) approach is used to tune the hyper-parameters of the ML classifiers for achieving the highest possible CV scores. The cross validation is based on training data only without using any information from the test dataset. The hyper-parameter values so obtained along with the associated CV scores for the 15 minutes traffic session data are displayed in Table IV.
Using the tuned hyper-parameters' values, the average classification accuracy (AC), precision (PR), recall (RC) and F1 scores obtained for the final classifiers over 50 runs are shown in Table V. It can be observed that the Random Forest classifier performs the best in terms of classification accuracy followed by SVM classifier and Gaussian Naive Bayes' classifier. All the classifiers report a precision of close to 1.0, i.e., an extremely low false positive rate, which is a much desired property for bot detection. This is because we do not want benign IoT devices to be classified as bots which could lead to further administrative actions on those devices. Moreover, all the classifiers report a recall of close to 1.0 as well, i.e., an extremely low false negative rate, which is also a much desired property for bot detection. False negatives lead to bots getting Classifier CV Score Hyper-parameter Values GNB 0.98 (+/-0.02) priors=None, var_smoothing=1e-3 SVM 1.00 (+/-0.01) C=1.0, kernel='rbf', degree=3, gamma='scale', coef0=0.0, shrinking=True, probability=False, tol=0.001, cache_size=200, class_weight=None, verbose=False, max_iter=-1, decision_function_shape='ovr', random_state=None RForest 1.00 (+/-0.00) n_estimators=10, crite-rion='gini', max_depth=None, min_samples_split=2, min_samples_leaf=1, min_weight_fraction_leaf=0.0, max_features='auto', max_leaf_nodes=None, min_impurity_decrease=0.0, bootstrap=True, class_weight=None classified as benign IoT devices and as a result, the network administrator could overlook them while the bots continue to pose a security threat without being detected. Based on the classification performance obtained above, we use the Random Forest model for aggregate traffic classification while implementing EDIMA in code.
Performance Comparison With Previous Works: The performance of the proposed aggregate traffic classifier for scanning activity detection is compared with the botnet scanning traffic detector introduced in [51] here. We desist from comparing with Kitsune [37] as it is an anomaly detection system whereas EDIMA is based on a misuse-detection approach. The two approaches are quite different from each other [52] with anomaly detection systems typically performing worse in terms of false positive rates. Further, Kitsune uses per-packet classification whereas EDIMA performs per-session classification. If we wish to use per-session classification with Kitsune, we would have to make significant changes in its source code. Also, it is not possible to use per-packet classification with EDIMA as it is designed to use session-based features due to the reasons explained in Section IV-A. Other anomaly detectionbased systems for IoT [32], [35], [36] are also excluded from performance comparison due to the reason explained above as well as lack of publicly available source code.
We split our benign and malicious traffic datasets into training and test datasets using a 80:20 ratio, which is the split used during the evaluation of our ML-based aggregate traffic classification algorithm. We construct H m , the first conditional entropy vector using samples from malicious training data and H t , the second conditional entropy vector using a test sample and samples from malicious training data. The conditional entropies are calculated using NPEET Python package [53]. Using the KS test, we attempt to decide whether the test sample (or traffic session) is similar to malicious traffic in terms of conditional entropy distribution to classify the test sample as malicious. A low false positive probability, γ = 0.05 is selected, which gives the test threshold K γ as 0.51961.
In applying KS test for classification of test samples, we define true positive (TP) as the event in which a malicious test sample is found similar to malicious training dataset and false positive (FP) when a benign test sample is found similar to malicious training dataset. When the same malicious test   Table V. Thus, based on accuracy and reliability of classification, we can conclude that our ML-based aggregate traffic classification method performs much better than the conditional entropy based KS test in [51].
2) Bot-CnC Communication Detection Performance: To evaluate the performance of our proposed Detect_bot_CnC_comm algorithm, we first consider a scenario where we we use the malicious traffic dataset (with a 15 minutes session duration) generated in Section V-B by replaying the loligang pcap file. We know from the ground truth that the loligang pcap file contains bot-CnC messaging packets with an approximate periodicity of 60 seconds. Each pcap file in the malicious traffic dataset is processed as follows: 1) The packet traffic associated with each connected IP address (corresponding to a device) detected by the gateway was separated from the aggregate traffic. 2) The devices' packet streams were filtered, sampled, encoded and mean subtracted as described in Section IV-B to produce discrete-time sequences. We evaluate the detection performance of Algorithm 2 on the discrete-time sequences so obtained in terms of detection rate (DR) and missed-detection rate (MDR). Detection Rate is the fraction of the total number of malicious traffic pcap files which have been correctly detected as containing bot-CnC traffic, and Missed-detection Rate is the fraction of the total number of malicious traffic pcap files which have been incorrectly detected as not containing bot-CnC traffic.
In the second scenario, we use the malicious traffic dataset (with a 15 minutes session duration) generated in Section V-B by replaying the echobot pcap file. We know from the ground truth that the echobot pcap file contains bot-CnC messaging packets with an approximate periodicity of 210 seconds. Using the parameter values (given in Table VI), the detection performance of Algorithm 2 for both the scenarios specified above is shown in Table VII. It can be seen that our algorithm gives a DR of 1.0 and a MDR of 0.0 for both the scenarios outlined above.
The sub-sampling frequency of 0.1 was selected to keep the number of samples to be processed by our algorithm and hence the processing time within a reasonable limit. The minimum autocorrelation peak height was kept at 0.7 times the maximum autocorrelation peak height (excluding the peak at lag 0) because any value above that corresponds to a significant degree of autocorrelation. The inter-peak gap variance threshold was kept at a low value of 0.01 so that only when the autocorrelation function's peaks are almost equally separated is the underlying discrete-time sequence detected as periodic.
Traffic sampling frequency 0.1 Min. autocorrelation peak height 0.7×(Max. peak height) Inter-peak gap variance threshold 0.01  [39] here. A performance comparison with BotHunter/BotSniffer-/BotMiner [22]- [24] is not provided as those works detect CnC communication at the network level using correlationbased techniques whereas EDIMA's bot-CnC communication detection algorithm runs on the edge gateway directly connected to IoT devices where the above correlation techniques cannot be applied. Further, the source code for those works has not been released, making it difficult for us to replicate their proposed botnet detection systems.
We use the discrete-time sequences produced during the performance evaluation of our proposed Detect_bot_CnC_comm algorithm. In order to confirm that those sequences correspond to the bot-CnC communication traffic as per [39], we apply the Walker's largest sample test (WLST) to the sequences. Keeping the false positive probability, γ at a low value of 0.1, the test gives a DR of 0.0 and a MDR of 1.0 for a session duration of 15 minutes, which is extremely poor compared to a DR of 1.0 and MDR of 0.0 given by our proposed Detect_bot_CnC_comm algorithm. This result was somewhat expected as the Walker's largest sample test requires a large number of time samples to be effective and we had only a limited number of time samples collected in the capture duration. As mentioned earlier in Section IV-B, in a real-world implementation, it is not recommended to have long capture durations as that would lead to a large delay in bot detection.
3) Robustness Test: The number of IoT devices connected to a gateway needs to be scaled up to test EDIMA's robustness and study the effect on its performance. Towards this, we used the UNSW IoT dataset in [54] which provides pcap files for aggregate traffic captured from 28 different uninfected IoT  devices collected at a gateway over 24 hours for 20 days.
Half of the original pcap files were used in generating benign traffic. To generate malicious traffic, we replayed the other half of pcap files at the OpenWRT router in our testbed (with all IoT/non-IoT devices disconnected) in addition to a single loligang pcap file using the malware traffic replay technique mentioned in Section V-B. We captured the packet traffic at the router and followed the same procedure as used for our testbed dataset to train and test ML classifiers. The aggregate traffic classification performance of EDIMA's ML-based bot detector using the UNSW IoT dataset for 15 minutes session duration is presented in Table V. Again, the Random Forest classifier performs the best with accuracy and precision scores the same as that for our testbed dataset. However, SVM and Gaussian Naive Bayes' classifiers register a significant drop in accuracy and precision scores compared to their performance on our testbed dataset. Thus, after more than doubling the number of IoT devices from 11 to 29 with just one bot present among the IoT devices, ML classifiers such as Random Forest are still able to accurately detect malicious aggregate traffic with almost zero false positives.
Theoretically, up to 255 devices can be connected to a consumer edge gateway (e.g., Wi-Fi router or access point). The actual number of devices connected though is usually a lot lower and depends on the type of network in which the gateway is installed, e.g., home, campus, enterprise, with home networks (focus of our work) typically consisting of the lowest number of connected devices out of the three network types. As long as we are targeting current IoT malware whose scanning behaviour is quite similar to the malware tested, it is fair to claim that EDIMA will perform well even when the number of devices connected to a gateway goes up.
4) Runtime Performance of EDIMA: We have implemented EDIMA in Python 1 . Most of the commercially available consumer gateways/routers run proprietary firmware on top of Linux with basic utilities (e.g., Busybox) and a simple web interface. They do not support Python environment, DB services or Linux/Python package management which are required for running EDIMA code. Therefore, it is not possible to run the code directly on all consumer routers as is. Instead, we tested the code on a Raspberry Pi 3B+ (RPi) device with a Broadcom BCM2837B0 1.4GHz quad-core processor, 1GB SDRAM supporting IEEE 802.11.b/g/n/ac wireless LAN which is similar in configuration to a consumer Wi-Fi router. The test setup remains similar to our testbed described in Section V-A, only with the OpenWRT router replaced by RPi 1 The source code has not been publicly released due to the terms of our project funding. and the exclusion of few devices which require wired Internet connectivity (e.g., Samsung SmartThings, Philips Hue bridge). The session duration used for traffic capture is 5 minutes. We considered three performance quantifiers: Throughput, Delay and Memory statistics.
Throughput refers to the average number of packets per second that are successfully processed. Now, EDIMA is an offline detector, so the number of packets processed per second by it are not as important as in the case of an online detector. Further, the percentage of packets dropped (which get excluded from the bot detection process) is completely determined by the packet capture function used in EDIMA's implementation which depends on the capture speed of the network card installed on the gateway where EDIMA is deployed. Therefore, we do not include throughput results in the final runtime performance evaluation.
Two types of Delay can be calculated in the context of EDIMA: 1) average time interval (in seconds) between the arrival of the first malicious packet at the router and the detection of malicious traffic by EDIMA code (T AD ), and 2) average time interval (in seconds) between the detection of malicious traffic by EDIMA code and the detection of the first bot responsible for malicious traffic (T BD ). Memory statistics refers to the amount of local router (flash) storage required for storing EDIMA code and the average RAM consumed when the code is running. The averaging in all the relevant performance metrics is done over 50 code runs each. The evaluation results are shown in Table VIII. The results point towards a system which is quite reasonable in terms of detection delay (considering that EDIMA is designed to be an offline detector), requires minimal storage space and consumes only a small fraction of the total RAM on an average (9.62%).

G. Limitations and Future Work
As the Malware PCAP Database consists of pcap samples from only those IoT malware which have been observed infecting honeypots, traffic generated by zero-day malware is not a part of the database and therefore, EDIMA may not be able to detect bots infected by those malware. Also, EDIMA uses supervised ML algorithms which means that it can detect only known malicious traffic patterns. However, supervised ML algorithms are used much more commonly compared to unsupervised algorithms in real-world anti-virus and antimalware products to detect virus/malware behaviour as well as in actual deployments of Network Intrusion Detection Systems [55].
Advanced malware which attempt to evade detection by ED-IMA may slow down the bot scanning activity to confuse the trained ML algorithms classifying aggregate gateway traffic and lower its detection accuracy and precision. However, as mentioned earlier in this paper, this approach decreases the scanning efficiency of the malware resulting in the slowing down of malware's propagation through a network and may not be desirable for the malware author. Further, this evasion technique can be countered by increasing the traffic session duration to capture enough scanning packets though it may lead to longer classification delays.
Evasive malware may also use some other bot-CnC server messaging mechanism than the ([PSH,ACK], [ACK]) one to escape filtering and/or force the bot-CnC communication to be non-periodic (by adding noise traffic for example). If the attacker does change the bot-CnC messaging protocol, the detection method can be changed accordingly. Moreover, our bot-CnC server communication detection algorithm uses an ACF-based approach which can detect periodicity in the presence of noise as well if the noise is uncorrelated with the desired signal (discrete-time sequence extracted from bot-CnC server traffic). Forcing the bot-CnC communication to be non-periodic may result in the CnC server losing control of the bot in between the keep-alive messages and cause the CnC server to have an unreliable estimate of the number of active, connected bots. This may lead to a decrease in the impact of any future attacks launched by the CnC server using its bots.
Adversarial machine learning may also be deployed by malware authors by changing the bot traffic in subtle ways so as to avoid detection by EDIMA's trained ML algorithms. Additionally, it is possible that some IoT devices connected to a gateway may already be infected before EDIMA is deployed and starts running on the gateway. As part of our future work, it may be interesting to explore ways of detecting and filtering traffic samples containing traffic from existing bots before fully deploying EDIMA. One possible approach is to use a reliable statistical test for checking if the captured traffic samples are similar to known malicious traffic samples in some probability measure. Finally, the aggregate traffic classifier trained by ML Model Constructor may have to be re-trained due to a number of reasons (mentioned in Section III) and this may cause a delay in bot detection.

VI. CONCLUSION
We have proposed EDIMA, a lightweight solution for early detection of IoT botnets in home networks. It detects bots connected to an edge gateway in two stages-first by looking for scanning and subsequently bot-CnC server communication traffic patterns. EDIMA consists of a traffic parser, feature extractor, ML-based bot detector, policy engine, ML model constructor and a malware PCAP database. The operation of all the above components was discussed in detail. A comprehensive performance evaluation of EDIMA using our testbed setup revealed that it has a close to 100% accuracy and a very low false positive rate in detecting malicious aggregate gateway traffic with ML algorithms such as the Random Forest. The detection performance holds even when the number of devices is more than doubled, suggesting that EDIMA's performance is robust to an increase in the number of IoT devices connected to the gateway. We also compared EDIMA's performance with existing techniques for bot scanning traffic and bot-CnC communication detection and found that EDIMA performs much better and more reliably. Finally, we analysed the runtime performance of a Python implementation of EDIMA on a Raspberry Pi which showed low bot detection delays and low RAM consumption.

APPENDIX A BACKGROUND ON IOT BOTNETS A. IoT Malware Categorization
We have categorized known IoT malware based on type of protocol vulnerability that they target: TELNET, HTTP POST and HTTP GET. TELNET is an application-layer protocol used for bidirectional byte-oriented communication. Typically, a user with a terminal and running a TELNET client program, accesses a remote host running a TELNET server by requesting a connection to the remote host and logging in by providing its credentials. HTTP GET and POST are methods based on HTTP (HyperText Transfer Protocol) application-layer protocol which are used to request data from and send data to servers, respectively. For example, HTTP GET is commonly used for requesting web pages from remote web servers through a browser. The proposed malware categories, various malware belonging to those categories and brief descriptions of their operation are presented in Table IX.

APPENDIX B BOT DETECTION CONFIDENCE SCORE
Let P(Y i PD |X MC ) be the conditional probability of detecting periodicity due to bot-CnC communication in the i th device's traffic (using the ACF-based algorithm 1) once the aggregate traffic has been classified as malicious. It is defined as follows: where Q is the Ljung-Box test statistic [57], α is the significance level, p-value is the probability that the test statistic assumes a value equal to or greater than the observed value, and χ 2 h is the Chi-square distribution with h degrees of freedom. The Ljung-Box test is a binary hypothesis test [58] which decides if a time series exhibits a significant amount of combined autocorrelation at specified number of lags (h in this case) or if there is zero autocorrelation at those lags. As Q approaches a χ 2 h distribution asymptotically, P(Y i PD |X MC ) is only bounded by Pr(Q > χ 2 1−α,h ) and therefore, the approximation in Equation 3 is not perfect. However, it serves the BCMUPnP_Hunter Exploits an old vulnerability in Broadcom's UPnP (Universal Plug and Play) protocol which is used in millions of routers including D-Link, TP-Link, ZTE etc; uses a selfbuilt proxy network which communicates with email providers, most probably for spamming; employs a complex multi-step infection process. purpose as otherwise, we have no way of approximating the detection performance of the ACF-based algorithm 1. Hence, the BDCS (Bot Detection Confidence Score) for EDIMA, which represents the likelihood/confidence level of the accurate detection of bots among the IoT devices under test, is hereby defined as: Assuming total N number of IoT devices, (P(Y PD = bot |X MC = malicious )) is written as a product of probabilities (P(Y i PD = bot |X MC = malicious )), because we assume that all the devices are likely to be infected independent of each other (which is true in case of most IoT malware as they scan randomly generated IP addresses).