Authors: Roland Dobbins & Steinthor Bjarnason
Since its inception in August of 2016, the Mirai ‘Internet-of-Things’ (IoT) botnet, comprised largely of internet-enabled digital video recorders (DVRs), surveillance cameras, and other Internet-enabled embedded devices, has been utilized by attackers to launch multiple high-profile, high-impact DDoS attacks against various Internet properties and services. Mirai serves as the basis of an ongoing DDoS-for-hire ‘booter’/‘stresser’ service which allows attackers to launch DDoS attacks against the target(s) of their choice in exchange for monetary compensation, generally in the form of Bitcoin payments. While the original Mirai botnet is still in active use as of this writing, multiple threat actors have been observed customizing and improving the attack capabilities of the original botnet code, and additional Mirai-based DDoS botnets have been observed in the wild.
The original Mirai botnet (henceforth referred to as ‘the Mirai botnet’, or ‘Mirai’, unless otherwise indicated) currently consists of a floating population of approximately 500,000 compromised IoT devices worldwide; relatively high concentrations of Mirai nodes have been observed in China, Hong Kong, Macau, Vietnam, Taiwan, South Korea, Thailand, Indonesia, Brazil, and Spain. Additional Mirai concentrations have been also been observed in multiple countries located in North America, Europe, and Oceania.
Mirai is capable of launching mutiple types of DDoS attacks, including SYN-flooding, UDP flooding, Valve Source Engine (VSE) query-flooding, GRE-flooding, ACK-flooding (including a variant intended to defeat intelligent DDoS mitigation systems, or IDMSes), pseudo-random DNS label-prepending attacks (also known as DNS ‘Water Torture’ attacks), HTTP GET attacks, HTTP POST attacks, and HTTP HEAD attacks. While none of the DDoS attack capabilities of Mirai observed to date are new or unique, it is a flexible DDoS attack generation system and can launch high-volume, non-trivial DDoS attacks when wielded by a capable attacker. Mirai features segmented command-and-control, which allows the botnet to launch simultaneous DDoS attacks against multiple, unrelated targets.
Vulnerable IoT devices are subsumed into the Mirai botnet by continuous, automated scanning for and exploitation of well-known, hardcoded administrative credentials present in the relevant IoT devices. These vulnerable embedded systems are typically listening for inbound telnet access on TCP/23 and TCP/2323; additionally, a remote-control backdoor is also present in Mirai, accessible via TCP/103. Given the prevalence of continuous scanning for vulnerable nodes across the entire IPv4 internet address space, mean time to compromise of a vulnerable IoT device is 10 minutes or less, which means that compromised devices which are switched off or simply rebooted will almost certainly be re-compromised in short order, unless proactive steps are taken to shield TCP/23, TCP/2323, and TCP/103 access to the devices.
Once an IoT device has been subsumed into the Mirai botnet, it immediately begins scanning for other vulnerable devices to compromise. This scanning takes place against destination ports TCP/23 and TCP/2323.
As noted above, multiple threat actor groups are actively working to expand and improve the DDoS attack capabilities of Mirai-variant botnets. Some alterations in the DDoS attack capabilities of at least one Mirai-derived botnet have been observed in the wild.
The potential collateral impact of DDoS attacks launched by the Mirai botnet can be highly significant, depending upon the target selection and efficacy of a given attack.
Outbound/crossbound DDoS attacks launched by Mirai bots can cause significant network performance issues or outages for broadband access network operators.
Threat actors may significantly increase the rate of scanning for vulnerable systems, which could lead to an inadvertent DDoS attack on scanned/scanning systems and networks.
The DDoS attack capabilities of Mirai which have been observed to date are well-known and can be successfully mitigated by implementing industry-standard Best Current Practices (BCPs) and by utilizing intelligent DDoS mitigation systems (IDMSes) such as Arbor SP/TMS and APS to defend the targets of these attacks.
It is possible (and recommended) for network operators to actively scan for both vulnerable and compromised IoT devices on their networks and the networks of their customers, and then take steps to isolate those devices, notify their legitimate owners of the problem, and urge them to take corrective action.
It is possible (and recommended) for network operators to identify likely compromised IoT devices by detecting and classifying outbound/crossbound TCP/23 and/or TCP/2323 activity originating from these devices, and then take steps to isolate those devices, notify their legitimate owners of the problem, and urge them to take corrective action.
In order to inhibit scanning for vulnerable IoT devices, it is possible for broadband access network operators to implement access-control lists (ACLs) at a situationally-appropriate point in the network topology to prohibit high-port TCP traffic destined for TCP/23, TCP/2323, and TCP/103 on their customer access networks. Such policies would typically be implemented as ingress ACLs on the coreward interfaces of broadband customer aggregation gateways. Operators should gauge the benefits of enforcing a network access policy of this nature vs. potential negative effects, if any, and should thoroughly test any proposed anti-scanning ACLs prior to deployment.
All relevant network infrastructure, host/application/service, and DNS Best Current Practices (BCPs) should be implemented by network operators with public-facing network infrastructure and/or internet properties.
Network operators should export flow telemetry (e.g., NetFlow, IPFIX, s/Flow, cflowd/jflow, Netstream, et. al.) from their peering/transit/customer aggregation edges and Internet data center (IDC) distribution edges to anomaly-detection/traffic visibility systems Arbor SP, which provide the ability to detect, classify, and traceback DDoS attack traffic.
Network operators should make use of DDoS mitigation mechanisms such as source-based remotely-triggered blackholes (S/RTBH), flowspec, and/or intelligent DDoS mitigation systems (IDMSes) such as Arbor TMS and APS in order to mitigate DDoS traffic sourced from Mirai-based botnets.