Under Attack? Call (844) END.DDoS

Mirai IoT Botnet Description and DDoS Attack Mitigation

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.


Collateral Impact 

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.


Mitigating Factors

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.


Recommended Actions

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.











TrickBot Banker Insights

ASERT team

A new banking trojan, TrickBot, has seemingly risen from the ashes left behind by the November 2015 takedown of Dyreza/Dyre infrastructure and the arrests of threat actors identified by Russian authorities. Dyreza was used to target customers of over 1000 U.S. and U.K. banks and other companies during the peak of operations. Researchers at Threat Geek […]

Annual Security Survey – Call for Participation

ASERT team

It’s that time again! Arbor Networks is opening its 12th annual Worldwide Infrastructure Security Report survey. Findings from this survey are compiled and analyzed to provide insights on a comprehensive range of issues from threat detection and incident response to staffing, budgets and partner relationships.  A copy of the report will be sent to all participants. We […]

On DNS and DDoS

ASERT team

The global DNS infrastructure provides the critical function of mapping seeming random sets of numbers in IP addresses (like to a name that an Internet consumer may recognize (like www.myfavoritestore.com).   To scale to a global level, the DNS system was designed as a multi-level reference network that would allow any user on the Internet […]

The Great DGA of Sphinx

Dennis Schwarz

This post takes a quick look at Sphinx’s domain generation algorithm (DGA). Sphinx, another Zeus-based banking trojan variant, has been around circa August 2015. The DGA domains are used as a backup mechanism for when the primary hardcoded command and control (C2) servers go down. It is currently unknown to us as to what version […]

Panda Banker’s Future DGA

Dennis Schwarz

Since we last visited the Panda Bankers at the malware zoo, two new versions have emerged: 2.2.6 and 2.2.7. While sifting through the encrypted strings of the latest version, two interesting ones stood out: dgaconfigs DGA, download “%S”. Tracing the first one through the code does indeed lead to a DGA or a domain generation […]

Who Let the Pandas Out? Zeus, Zeus, Zeus, Zeus

Dennis Schwarz

A few months ago Proofpoint released a blog post about a new banking trojan called Panda Banker. They credit Fox-IT with the discovery and both companies indicate that it is another variant based on the Zeus banking trojan source code. Under the hood Panda Banker certainly feels Zeus-like, but it has plenty to distinguish itself […]

The Mad Max DGA

Jeff Edwards

This post describes a domain generation algorithm (DGA) used by the “Mad Max” malware family. Mad Max is a targeted trojan, and we plan to post a follow-up article that documents our findings regarding the features of the Mad Max malware itself. But for now we will focus on the reversing of its DGA, since […]

The Lizard Brain of LizardStresser

Matthew Bing

LizardStresser is a botnet originally written by the infamous Lizard Squad DDoS group. The source code was released publicly in early 2015, an act that encouraged aspiring DDoS actors to build their own botnets. Arbor Networks’ ASERT group has been tracking LizardStresser activity and observed two disturbing trends: The number of unique LizardStresser command-and-control (C2) […]