A Characteristic Study of IoT Botnets: Understanding the Design and Behavior

by Aditya K. Sood and Rohit Bansal

(Based on the talk at The Circle of HOPE conference)

Internet-of-Things (IoT) botnets are impacting the Internet on a large scale.

IoT botnets are effectively designed to abuse and exploit the IoT devices.  In this article, we perform an empirical analysis to conduct a characteristic study of IoT botnets to understand the inherent design, architecture, and associated operations.  The study covers analysis of more than five IoT botnets' families but not limited to: Mirai, Hajime, Persirai, Amnesia, Bricker, and others.  The comparative analysis of IoT botnets helps to determine the ongoing trends and expected threat advancements in the IoT world.

Introduction

Cyber attacks are increasing at an alarming rate, thereby impacting the Internet users and enterprises on a large scale, which results in extensive cybercrime operations in the underground market⁷.  Generally, cyber attacks are categorized as first: targeted cyber attacks⁸ in which attackers target specific organizations or set of users, second: broad-based attacks in which attackers trigger exploitation on a mass level to compromise systems, and third: hybrid attacks in which the attack patterns are altered accordingly as per the convenience.

Attack vectors such as phishing attacks are used in conjunction with social engineering tactics and drive-by download attacks⁹ to infect users' systems so that networks of compromised systems can be created that are termed as botnets⁶.

Of course, system vulnerabilities are exploited in known software to compromise the systems successfully.  In most of these attacks, botnets are formed by compromising the end user systems to launch attacks in the wild.  However, recent times have shown that attackers are shifting their tactics and exploiting network devices and using those compromised devices to build controlled networks.  Network devices such as routers, switches, cameras, DVRs, etc. are considered to be under the hood of IoT.  When these network devices are compromised with malicious code to launch unauthorized operations on the Internet, these are termed as IoT botnets.

IoT botnets are deployed heavily to perform nefarious activities by circumventing the integrity of the IoT device to launch sophisticated targeted or broad-based attacks.  IoT botnets have enhanced the cybercrime operations to a great extent, thereby making it easier for the attackers to carry out unauthorized activities on the Internet.  This article presents the empirical analysis of the six botnet families to draw the comparative analysis of the widely known IoT botnets.  The study not only provides deep insights into the working behavior of the IoT botnets, but also highlights the preventive measures to be taken to defend against IoT botnets.

Related Works

Kolias et. al¹ analyzed the Mirai botnet and its functionalities to understand the internals of the botnet.  Habibi et. al² proposed a whitelist-based security solution named Heimdall to detect intrusions in IoT environments.  The solution can be deployed on the IoT routers (or gateways) that build profiles of IoT devices configured in the network and whitelists are generated accordingly with different detection parameters.

Tod et. al² detailed a model to explain the spreading and internal workings of an IoT bot.  IoT Botnet with Attack Information (IoT-BAI) was proposed that utilized the variation of the Susceptible-Exposed-Infected-Recovered-Susceptible (SEIRS) epidemic model.  The primary analysis of this study was to reduce the IoT infection by analyzing user behavior and mapping the IoT population through analysis of new hosts running IoT devices.  Jerkins⁴ reviewed the source code of Mirai IoT bot and used the similar attack vector to detect vulnerable IoT devices on the Internet and catalog them accordingly to educate the operators and service providers on how to secure these devices and prevent abuse.  This study was focused primarily on teaching the importance of device security to the users.

This article focuses on a comparative study of techniques and tactics opted by different IoT botnets.  This study provides a holistic approach to understanding the internal workings of the different bots and comparing the effectiveness of various IoT botnets.

Contribution of this Work

The main research contributions of this work can be summarized as follows:

• We conducted an analytical study of more than five IoT botnet families to better understand the various techniques deployed to abuse and exploit the IoT devices.  This includes analysis of protocols, network communication, anti-detection strategies, bricking devices, data exfiltration, and others.  The mapping of characteristic analysis provides a broad picture on the state of IoT botnets.
• Our empirical study demonstrates how the IoT botnets have been configured and deployed in the last few years and how these have been used to launch attacks against users by abusing IoT devices running insecurely on the Internet.
• Finally, we highlight strategies that can be deployed for detecting and preventing IoT communications.

IoT Botnets: Attack Model

In this section, we describe the generalized attack model followed by attackers to build networks of IoT bots.

Figure 1 highlights the working model of the IoT botnet.

Figure 1: Overview of IoT Botnets Attack Model

The model is explained below:

• Step 1 - Discovering IoT Devices:  The first step in the attack model is to find available IoT network devices on the Internet.  The attacker triggers mass scanning attempts to obtain the list of the exposed network devices on the Internet.  This includes looking for specific TCP/ UDP ports that are mapped to specific services.  For example: TCP 23 for Telnet, TCP port 22 for SSH, etc.  Once the list is obtained, the attacker initiates the next process, which involves the launching of a brute-force or password cracking attack to gain access to the device.  Attackers can use a dictionary list or generate passwords iteratively to verify against the network devices.  If a match is found and access is obtained, the next step is followed.
• Step 2 - Compromising IoT Devices:  The attacker installs a bot on the compromised IoT device in order to control the firmware.  Since the bot is installed on the underlying system used by network devices, it has the capability to manipulate the firmware and use the IoT devices as launch pads to launch additional sets of attacks.  Apart from weaponizing the network device, the bot has the built-in capability to further launch scans from the network devices to find more network devices on the Internet and compromise them accordingly.  This tactic results in the formulation of large IoT botnets.
• Step 3 - Abusing IoT Devices:  Since the attacker now controls the firmware of the compromised IoT devices, different types of attacks can be planted.  These devices are used to launch DDoS attack to target service providers or enterprises.  For example: targeting a DNS service provider using DDoS causes significant financial losses as online systems cannot function properly.  The attacker can opt for a variety of attacks depending on the requirement and preference.

The attackers can extend and amend this model in different ways to abuse the IoT devices.

IoT Botnet Characteristics

• C&C Architecture:  The Command and Control (C&C) architecture states how exactly the botnet operates.  The most important aspect of the botnet is the communication between the installed bots on the compromised hosts and the centralized server managed by the botnet operator.  IoT botnets can be operated using a centralized, decentralized, or hybrid design.  The centralized architecture refers to a design in which IoT bots receive a command from a centralized server.  In decentralized architecture, the IoT bots receive commands from the peers, making it hard to detect the C&C server.  Hybrid architecture uses the design from both centralized and decentralized C&C architectures to include a safe fallback mechanism if one communication channel fails.
• Brute Force/Password Cracking:  The brute-force/password cracking attacks are performed in an automated way to gain access to additional IoT devices so that more systems can be included in the network of IoT bots.  Generally, a number of IoT devices are configured with default or weak passwords, and compromising those devices using these attacks is not an arduous task.  The majority of IoT bots opt for this technique.
• Distributed Denial-of-Service (DDoS):  The IoT botnets are built-in to support DDoS functionality to launch denial-of-services attacks at the targeted devices.  The DDoS capability allows the IoT botnets to launch heavy traffic flooding attacks against other IoT devices in the network.  The DDoS attacks can abuse the feature of different communication protocols.  A number of protocol-specific supported DDoS techniques include, but are not limited to: HTTP floods, GRE IP and GRE ETH floods, as well as SYN and ACK floods, Simple Text Oriented Message Protocol (STOMP) floods, DNS floods, and UDP flood attacks.
• Device Bricking/Permanent Denial-of-Service (PDoS):  There is an inherent functionality of the IoT bots to render the device completely useless by corrupting the firmware and making the device unrepairable, except by replacing the hardware components.  This technique results in persistent Denial-of-Service (DoS) for a longer duration.
• Persistence:  Advanced malware has the capability to stay persistent even after the system reboot happens.  Generally, the persistence characteristic of malware reflects its robustness because it has the capability to maintain control on the compromised system.  Non-persistent malware loses control after the system boot-up, as the system becomes disinfected.  However, to overcome this, non-persistent malware stores the record of the compromised system in the Command and Control (C&C) panel.  When the system is rebooted and becomes active, the infection is triggered again.  Overall, it depends on the design of the bot to maintain control of the infected system.
• Offensive Tactic - Kill Bot Feature:  A number of bots deploy a kill feature, which primarily verifies whether other bots or malware are present in the infected device.  Generally, the bot looks for the presence of another bot in the system by checking some artifacts that reveal if the device is infected with other malicious code.  Additionally, the bot can also deploy proactive code to determine if the infected device is queried by another threat (or bot).  If yes, the bot kills the service or restricts the incoming connection by blocking the TCP/UDP ports.  This strategy helps the attackers to utilize the infected or compromised device for their own purposes and avoid sharing the system resources with other adversaries, in other words, allowing them to completely control the device without sharing.  For example: Mirai has the capability to kill the incoming connections on the device owned by it.
• Defensive Tactic - Restricted Scanning:  This technique is implemented by the bots to direct the scanning to non-reserved or critical IPs.  This technique is a defensive measure opted by bot authors to avoid blacklisting or detection by scanning widely known or reserved IP ranges.  For example: the bot authors do not want to scan IP ranges reserved for government, Internet Assigned Numbers Authority (IANA), private addresses, and known business organizations, etc.  It means IoT devices that are deployed in the provided IP ranges will not be scanned by the IoT bots.  This helps prevent detection and makes the bot run stealthier for longer periods of time.
• IP Spoofing:  This is an attack method that is deployed by malicious binaries to spoof the source IP address while performing nefarious and unauthorized operations on the Internet.  IP spoofing is combined with DDoS and other attack methods to ensure that the targets won't reveal the actual identity of the device (source).  This attack technique is implemented by manipulating the IP address in the packet header and altering the checksum values, including other parameters or flags in the packet headers.  As a result of this attack, the targets obtain the IP address of some random machine rather the actual one, thereby creating a detour so that the real identity of the sender is not revealed.
• Virtual Machine Evasion - Sandbox Bypass:  This mechanism is implemented by IoT bot authors to make sure sandboxes fail to detect the execution of binaries in the system.  Researchers conduct testing on the IoT binaries by running them in the emulated or virtual environment to detect and observe the behavior of IoT bots, covering network traffic, system interaction, lateral movements, and others.  To circumvent this process, bot authors embed additional code that detects the virtual environment and restricts the execution.  This provides an additional layer of security to IoT bots so that it dismantles the process of bot execution in the test environment.

Experiment Procedures and Methodology

We performed multiple tests to conduct a comparative study of the IoT botnets.

A combination of different techniques used in this study are discussed below:

• Reverse engineering of the IoT binary to understand the internals of the bot and how it works.  This technique is opted for when the source code is not available and the IoT binary is disassembled into machine language using a disassembler.  This technique helps to understand the structure of the bot, how it operates, and the types of built-in functions.
• Dynamic analysis of the IoT bot which involves the following:
  
  • Debugging the IoT bot binary to determine how the bot reacts when executed in the system deployed in a controlled environment.
  • Network traffic analysis in which the bot is installed in the controlled environment (VM) to dissect the network protocols in use and see how the IoT bot transmits data to the C&C panel.
  This technique allows us to obtain insights into the network communication model of the IoT bots.
• Code review technique is also opted for the IoT bots for which source code is available to understand the design and architecture of the IoT bot.

Different techniques for analysis and review provide substantial details about the internal working details of the IoT bot.

Data Collection

Data was collected from multiple outlets as shown above:

1. IoT bot binaries were collected from the malware sharing portals such as detux.org, Virus Total, and others.
2. Automated code was written to scrap the data from the publicly available data sharing portals such as Pastebin and other web portals.  This resulted in retrieving information for advertisements about IoT bots.
3. Network traffic files called PCAPs were also generated after running the IoT bot in controlled environments to analyze the protocols.

Obtaining different sets of data from multiple outlets helps to correlate the information during the analysis and results in gathering intelligence.

Results and Discussion

In this section, we discuss our findings based on the experiments conducted on the six IoT botnet families.  Table 1 shows the results.

Table 1: Characteristic Analysis of IoT Botnets

On analyzing the infection strategy, it was found that the number of IoT devices were compromised using standard password cracking and brute forcing attacks.  It has been noticed that attackers obtained access to unsecured IoT devices through default or weak passwords and used the compromised devices to build IoT botnets.

This highlights the fact that IoT devices are configured with weak credentials, which allow the attackers to take control of these devices on the fly.  Devices running with Telnet service on TCP port 23 were targeted the most, followed by HTTP, SSH, and others.  Four out of six IoT botnets were formed by gaining access to the Telnet service as the primary mode of compromise.

Amnesia, Bricker, Mirai, and Aidra followed centralized C&C communication models, whereas Hajime opted for a decentralized model.  Internet Relay Chat (IRC) protocol was used for C&C communication by Aidra and Amnesia, whereas Mirai used Telnet, Hajime used Peer-to-Peer (P2P), Bricker used Tor, and Persirai used HTTP.

Persirai was deployed on the IoT devices after exploiting a vulnerability in the PnP implementation in the custom HTTP server¹².

Mirai also used remote command injection in the implementation of CPE Wide Area Network (WAN) Management Protocol (CWMP)¹¹ in the network devices.  Later research¹⁰ also highlighted that Hajime added additional spreading methods that are based on the exploitation of vulnerabilities in specific components.  Basically, Hajime added the exploitation methods used by Persirai and Mirai.

When the C&C architecture was analyzed, it came as no surprise that five out of six botnet families followed centralized communication models in which all of the IoT bots residing on the compromised devices connected back to primary servers for receiving updates.

The majority of IoT botnets are utilized for DDoS activities.

During the design analysis, it has been noticed that IoT bots have built-in capability to launch DDoS attacks.  The DDoS attacks become more aggressive when large number of bots that are a part of IoT botnets trigger this attack simultaneously.  In our samples, all of the botnet families such as Hajime, Persian, Amnesia, Bricker, Mirai and Sidra have this functionality built-in.

The study highlighted that "persistence" is not the characteristic of the IoT bots that are assessed during analysis.  The IoT bots such as Mirai, Hajime, and others do not have built-in mechanisms to stay persistent after the system is rebooted.  This means that once the device is rebooted, the infection process has to re-initiate to gain access to the IoT device.  On analyzing the device bricking functionality in which IoT bots make the firmware useless (using various techniques, such as rewriting critical portions of the firmware), only the Bricker IoT bot had this capability.

We also looked into the "Kill Bot Feature" and samples were analyzed to determine whether the IoT bot has a built-in capability to kill or remove other bots on the device.

It has been observed that, except for Aidra, all the other bots (Hajime, Mirai, Persirai, Amnesia and Bricker) had this feature.  However, it depends on the nature of the bot whether this feature is actually utilized on the compromised device or not.  The bots were also analyzed for the "Restrictive Scanning" feature in which bots are embedded with IP blacklists, IPs that are not scanned by the IoT bot for the purpose of triggering additional infections.  The IPs can include the entries of security companies, private address spaces, etc.  The idea is to prevent the detection of compromised devices running IoT bots.  Mirai was the only botnet family that supported this feature.

Further, we also analyzed the "IP spoofing" capability of the botnet families.

It was observed that only Mirai and Aidra opted for IP spoofing while conducting scanning on the Internet.  (This helps the IoT bot spoof the actual source IP address of the compromised device.)  At last, we also dissected the anti-VM techniques implemented in the IoT bots and it was found that only the Amnesia IoT botnet family is coded with this functionality to detect virtual machines so that behavior analysis can be prevented in an emulated environment.

Overall, analysis of the IoT botnet family highlights that the IoT botnets have been heavily used for Denial-of-Service (DoS) attacks.  The majority of these devices are compromised via unsecured interfaces that are running services such as Telnet/SSH/HTTP with weak or default credentials.  Automated brute-force or dictionary attacks are conducted against large IP address space on the Internet to find vulnerable IoT devices so that botnets can be performed for nefarious operations.

Countermeasures and Recommendations

• Authorization via Access Control:  It should be taken into consideration how the access control needs to be deployed on IoT devices.  Access controls covers the IP access restrictions which include whitelisting or blacklisting of source IPs that are connecting to the device.  If the device is intended for internal networks, the external interfaces should be restricted, which means the devices should not be configured to allow connections from remote users on the Internet.
• Firmware Updates:  The IoT devices are built using firmware design principles as embedded software.  The firmware provides the core functionality to operate the IoT devices.  This highlights the importance and the necessity of applying firmware updates on a continuous basis to circumvent the exploitation of vulnerabilities that have been released and to obtain enhanced functionality for secure and robust working of the IoT devices.
• Security Assessments:  The IoT devices should undergo regular security assessments which include: (1.) network penetration testing to determine which services are exposed such as Domain Name System (DNS), Plug-and-Play (PnP), Secure Shell (SSH), Telnet, etc. and whether these can be exploited or not; (2.) If the IoT devices are deployed with the web interface enabled, the web application security assessment should be conducted to analyze and enhance the security posture of the web interface; (3.) Cross interface testing is a must, which involves verifying whether the attack payloads can be sent across interfaces.  For example: check whether the Telnet interface allows web injections.  The dynamic testing helps to understand the security posture of configured IoT devices and how to enhance it.
• Authentication Controls:  It is a highly recommended practice that, whether the IoT devices are deployed internally or enabled with external interfaces, authentication must be in place, which means only authorized users that have authentication credentials can access the IoT device on the network.  Authentication credentials such as passwords should be strong and unpredictable.  Default passwords should be disabled.  Make sure no information is disclosed (such as default pages) without authentication.  One can use the built-in authentication controls shipped as a component of IoT firmware as a part of embedded security.
• Proactive Security Controls:  Developers or engineers should opt for the code reviews, reverse engineering, and fuzzing mechanisms to determine the robustness of the IoT firmware before the release.  Code reviews help to prevent the security issues earlier in the software development life cycle, and many security issues can be fixed earlier before the code is released.  In addition, security engineers can opt for reverse engineering and fuzzing mechanisms to unearth security flaws and get those fixed before the release.  This reverse engineering and fuzzing is performed on the binary rather than the code.  So opting for proactive security approaches helps to fix security flaws effectively.

Acknowledgment

We would like to thank all of the security researchers who have invested time in the IoT research. Such research is a community driven effort.

References

1. C. Kolias, G. Kambourakis, A. Stavrou and J. Voas, "DDoS in the IoT: Mirai and Other Botnets," in Computer, vol. 50, no. 7, pp. 80-84, 2017.
2. J. Habibi, D. Midi, A. Mudgerikar, E. Bertino, "Heimdall: Mitigating the Internet of Insecure Things," in IEEE Internet of Things Journal, vol. PP, no. 99, pp. 1-1.
3. E. Bertino and N. Islam, "Botnets and Internet of Things Security," in Computer, vol. 50, no. 2, pp. 76-79, 2017.
4. J. A. Jerkins, "Motivating a market or regulatory solution to IoT insecurity with the Mirai botnet code," 2017 IEEE 7^th Annual Computing and Communication Workshop and Conference (CCWC), Las Vegas, NV, 2017, pp. 1-5.
5. M. T. Gardner, C. Beard and D. Medhi, "Using SEIRS Epidemic Models for IoT Botnets Attacks," DRCN 2017 - Design of Reliable Communication Networks; 13^th International Conference, Munich, Germany, 2017, pp. 1-8.
6. A. K. Sood, S. Zeadally and R. Bansal, "Cybercrime at a Scale: A Practical Study of Deployments of HTTP-Based Botnet Command and Control Panels," in IEEE Communications Magazine, vol. 55, no. 7, pp. 22-28, 2017.
7. A. K. Sood, R. Bansal and R. J. Enbody, "Cybercrime: Dissecting the State of Underground Enterprise," in IEEE Internet Computing, vol. 17, no. 1, pp. 60-68, Jan.-Feb. 2013.
8. A. K. Sood and R. J. Enbody, "Targeted Cyberattacks: A Superset of Advanced Persistent Threats," in IEEE Security & Privacy, vol. 11, no. 1, pp. 54-61, Jan.-Feb. 2013.
9. A. K. Sood and S. Zeadally, "Drive-By Download Attacks: A Comparative Study," in IT Professional, vol. 18, no. 5, pp. 18-25, Sept.-Oct. 2016.
10. "Is Hajime Botnet Dead?" blog.netlab.360.com/hajime-status-report-en
11. "Eir D1000 Wireless Router - WAN Side Remote Command Injection (Metasploit)," www.exploit-db.com/exploits/40740
12. "Multiple vulnerabilities found in Wireless IP Camera (P2P) WIFICAM cameras and vulnerabilities in custom HTTP server," pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html