Network operators, CERTs, vendors, and other stakeholders should be aware of emerging Internet of Things (IoT) threats that are quickly evolving and adapting to current defences.
Threats such as the Mirai botnet have provided a glimpse into what attackers can accomplish with a sufficiently large IoT botnet — DynDNS and Deutsche Telekom suffered service outages that had a profound impact on customers and network operations.
Given the changing nature of these attacks, it’s difficult to develop a plan to mitigate and/or remediate them. This is why we at the Georgia Institute of Technology, Zero Point Dynamics, and University of North Carolina conducted a large-scale longitudinal study on Linux-based IoT malware to understand the malware’s lifecycle, which we published at the 2021 Usenix Security Symposium.
- IoT malware has evolved to use a suite of exploits that target many diverse Internet-facing devices and devices on private networks — some have up to 72 different exploits.
- IoT malware uses polymorphism to evade signature-based detection, including packing, environmental keying, scripting, and cross-architecture binaries.
- Most IoT malware appears to rely on hard-coded IPs rather than domains — only 7% of the malware samples use domain names.
- Device owners, device vendors, and network operators all have a role to play to mitigate the risk of IoT malware.
We used a MITRE ATT&CK-inspired framework and traditional malware (desktop and mobile) to study and compare the lifecycle of IoT malware for the following phases:
- Infection tactics: How does the malware target and infect a device?
- Payload properties: What are the malware’s payload characteristics?
- Persistence: How does the malware implant on the targeted device?
- Capabilities: What can IoT malware do on an infected device?
- Command-and-Control (C&C): How do malware operators command and control infected devices?
We used binary analysis and network measurements to study each phase in the malware’s lifecycle — please refer to our paper for more details on the methodology.
How does IoT malware target and infect devices?
Early IoT malware relied on default credentials or a specific vulnerability to compromise Internet-facing IoT devices.
More recently, IoT malware has evolved to use a suite of exploits that target many diverse Internet-facing devices and devices on private networks (NAT). In Figure 1, we depict the evolution of the exploit arsenal found in IoT malware.
Some samples can bundle up to 72 different exploits that target many categories of devices. Table 1 presents the most popular exploits found in IoT malware samples. Because IoT devices have no graphical user interface or peripheral devices, exploits do not require user interaction to trigger, and they can potentially make IoT malware more efficient at infecting devices.
| VENDOR | CVE | DEV. TYPE | VULN. TYPE | DEV. ARCH. | AV LABELS | ARM | MIPS | PPC | SPARC | SH4 | M68K |
| Huawei | CVE-2017-17215 | Router | CMD Inject | MIPS | gafgyt, ircbot, mirai, tsunami | 10,046 | 5,527 | 2,604 | 2,352 | 2,277 | 2,226 |
| ZTE | – – | Router | Default Cred | MIPS | dlink, exploitscan, gafgyt, mirai, tsunami | 3,190 | 2,038 | 912 | 728 | 735 | 724 |
| D-Link | CVE-2014-8361 | Router | CMD Inject | MIPS | gafgyt, mirai, tsunami | 2,378 | 1,436 | 656 | 534 | 530 | 534 |
| GPON | CVE-2018-10562 | Router | CMD Inject | Unknown | gafgyt, mirai, tsunami | 2,016 | 1,245 | 539 | 448 | 443 | 435 |
| Zyxel | CVE-2016-10372 | Modem | CMD Inject | MIPS | gafgyt, mirai, tsunami | 531 | 356 | 129 | 117 | 132 | 132 |
| Juniper | CVE-2015-7756 | Firewall | Backdoor | ARM | gafgyt, mirai | 413 | 256 | 115 | 95 | 77 | 82 |
| Multi-vendor | – – | DVR | CMD Inject | ARM | gafgyt, mirai, tsunami | 326 | 229 | 74 | 56 | 68 | 70 |
| D-Link | CVE-2013-7471 | Router | CMD Inject | MIPS | gafgyt, mirai, tsunami | 317 | 205 | 79 | 62 | 71 | 71 |
| Synology | CVE-2017-9554 | NAS | Info Leak | Various | gafgyt, intercepter, minerd, mirai, stealthworker, xmrig | 289 | 145 | 49 | 31 | 34 | 31 |
| Zyxel | CVE-2017-18368 | Router | CMD Inject | MIPS | gafgyt, mirai | 191 | 105 | 48 | 41 | 43 | 38 |
Table 1 — Top exploits found in IoT malware binaries based on static analysis.
What are IoT malware payload characteristics?
Our analysis suggests that IoT malware uses polymorphism to evade signature-based detection.
We estimated at least 15% of the samples use packing, and we unpacked 78% of the packed samples. However, we estimate at least 3.3% use a more advanced anti-analysis method to thwart unpacking.
Most payloads use the system shell for reconnaissance and persistence. For example, various binaries invoke shell commands like uname, whoami, lsof, crontab, and os-release to collect information about the device.
How does IoT malware persist on an infected device?
The original Mirai botnet did not persist on infected devices because the malware files were in volatile memory, and the malware would be wiped from memory when the device reboots. Most embedded devices mount their rootfs (file system) as read-only. This reduces wear on flash memory, eliminates system file corruption, avoids accidental overwrites, facilitates device update over-the-air, and eases factory reset.
IoT Malware must consider these file system constraints to persist on the device. Notably, we observed some samples attempting to remount the file system with read-write permissions on non-volatile memory regions to persist through reboots.
In several instances, IoT malware uses vendor-specific tools such as /bin/cfgmtd that target Ubiquiti devices to add an SSH backdoor.
What capabilities are present in IoT malware?
The initial version of the Mirai botnet focused on DDoS and scanning capabilities. We found an expanded set of capabilities including aggressive evasion by disabling firewall processes, access control modules, ISP remote administration, unblocking restricted domains, modifying timestamps on files, and deleting access, history, and service access logs.
We also found data theft attempts targeting Sybase files, device profiles, device configurations, and system files. IoT malware may brick infected devices by deleting system files, dbus devices, the Linux device table, zeroing out MMC memory, and removing configured devices on general-purpose IO pins.
Cryptocurrency mining and proxy services appear to be the most common ways that IoT malware monetizes infected devices. Infected devices may degrade or damage IoT services and facilitate criminal activities through tunneling illicit traffic.
How does a malware operator command-and-control their IoT botnet?
The first version of Mirai used a C&C infrastructure to control the botnet. However, we found that IoT malware can use peer-to-peer (P2P) and centralized infrastructure for C&C communication.
For example, some IoT malware families use the Kademlia overlay network or the Tor network for C&C call-back. Moreover, most IoT malware appears to rely on hard-coded IPs rather than domains. We found only 7% of the malware samples use the DNS, and for those that do, some hide their DNS A record resolution by using TXT records instead. This lack of DNS appears to be caused by malformed DNS requests generated by an initialization bug in Mirai’s leaked source code, which we identified during our study.
What can stakeholders do to limit their infection risk?
The deployment and operation of IoT devices involve many stakeholders.
End-users have physical access to the device but lack direct visibility in terms of diagnostics and telemetry.
Device vendors lack direct physical access. However, they have diagnostic and telemetry visibility in some cases. Additionally, when vendors outsource a device’s hardware or software, they introduce third-party stakeholders that may complicate the device’s lifecycle management.
Lastly, network operators, who carry traffic from end-users to the broader Internet, don’t have physical access, diagnostic telemetry, or remote access. This creates a burden on network operators because end-users may frequently contact their Internet service provider for support.
For infected devices, we recommend the following action items for each stakeholder:
Device owners have limited options for detecting and removing IoT malware infections. Device owners, whenever possible, should:
• Disable vulnerable Internet-facing services.
• Change default credentials.
• Segment the LAN network to mitigate some of the risks of an infected device.
An infected device can experience degradation in quality-of-service or unresponsiveness, and the device owner can initiate a reboot to remediate the symptoms, which should remove the malware infection residing on volatile memory.
Device vendors have end-to-end visibility into their devices through telemetry. Telemetry data can provide early detection of IoT malware infections. For example, vendors can:
• Use telemetry to detect system anomalies.
• Configure firmware to limit system shell interaction.
• Containerize processes to limit cross-process interaction.
• Allowlist only trusted processes/services to run.
• Remotely attest system services to guarantee a clean system state.
• Use client-server architecture to limit the exposed services on the network.
Network operators can play an important role in IoT malware infection clean-up by:
• Applying a walled garden policy for infected end-users.
• Blocking IP addresses for C&C and payload hosting servers.
• Dropping traffic for known IoT C&C or payload hosting servers.
Additionally, network operators should proactively:
• Identify the equipment on their network.
• Plan and manage the device’s end-of-lifecycle (EOL).
• Recommend devices that update automatically to end-users.
• Be informed about emerging threats through CERTs and threat feeds.
• Monitor and audit their networks by collecting and analyzing telemetry data.
• Create a contingency plan for infected devices and include other stakeholders for coordination.
We have created a dedicated resource to study Linux-based IoT malware, and we invite practitioners and researchers to use and improve our tools at BadThings.
Omar Alrawi is a PhD candidate at Georgia Tech. He specializes in the security assessment and threat analysis of IoT systems.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.