New Risks Revealed by Mirai Botnet

November 1, 2016 03:00 PM

The Mirai botnet struck the security industry in three massive attacks that shook traditional DDoS protection paradigms.

Download a Copy Now


The Mirai botnet struck the security industry in three massive DDoS attacks that shook traditional DDoS protection paradigms, proving that the Internet of Things (IoT) DDoS botnet threat is real and the grounds for building powerful and sophisticated cyber-attack tools.

In addition to generating traffic volumes above 1TBps, Mirai Botnet features a selection of ten predefined attack vectors, some of which have proven effective in taking down the infrastructure of service providers and cloud scrubbers by attacking their protections. Among the ten vectors, there are highly sophisticated attack vectors such as GRE floods, TCP STOMP and Water Torture attacks. Mirai DDoS attacks also highlight the challenges organizations face when it comes to visibility into the legitimacy of GRE traffic or recursive DNS queries.

Radware’s research team has analyzed Mirai Botnet code to understand how it operates – infecting devices, creating the botnet, generating attack traffic and evading security controls – as well as identifying the risks and security measures to successfully mitigate these attacks. Analyzing the characteristics of its vectors and payloads, we could create a dedicated protection.

Why Is an IoT DDoS Botnet So Attractive?

Iot DDoS botnet devices are attractive targets for hackers for several reasons:

  • First, they usually fall short when it gets to endpoint protection implementation.

  • Second, there is no regulation or standards for a secure use of IoT DDoS botnet devices as exists for PCs and servers for example. Such regulation shall ensure secured configurations and practices such as changing default passwords, access control restrictions (for instance, disable remote access to administrative ports).

  • Third, they operate 24*7 and can be used at any moment.

Common malware usually takes advantage of zero-day and known exploits to gain control over their target machines. This is usually complex and time consuming. Mirai Botnet authors wisely choose to skip the wearing zero-day research and instead attack one of the most insecure areas in the cyber landscape – IoT devices.

It specifically targets devices such as closed-circuit television cameras, routers and DVR’s, taking them over to create a botnet which is later used to launch sophisticated multi-vector DDoS assaults. The source code of the malware was written in C and the code for the command and control server (C&C) was written in Go. Mirai Botnet scans for potential targets - specifically devices with default manufacturer credentials. These are hard coded into the device hardware by the manufacturer. Mirai Botnet remotely connects to the attacked targets using Telnet and SSH access points which are often left open by default. With a basic dictionary attack, Mirai Botnet gains control over its targets using the default credentials.

Figure 1: A portion of the dictionary content used by the malware

New Dangers Lurking In Mirai Source Code

Mirai botnet hosts common attacks such as SYN and ACK floods, as well as introduces new DDoS vectors like GRE IP and Ethernet floods. It also features intelligent evasion mechanisms to bypass known security controls and DDoS mitigation methods before reaching its target.

Figure 2: Menu of Mirai’s attack vectors

GRE Flood Attack

Generic routing encapsulation (GRE) is a tunneling type protocol developed by Cisco. GRE mainly encapsulates data packets and routes them through the tunnel to a destination network that de-encapsulates the payload packets. Sending many GRE packets with large amount of encapsulated data may lead to resource consumption once the victim will try to de-encapsulate them until exhaustion. This screen shows the bot sends GRE packets with encapsulated UDP packet containing 512 bytes of random data.

Figure 3: Bot sends GRE packets with encapsulated UDP packet containing 512 bytes of ransom data


Figure 4: A function creating a GRE packet and including it within a GRE flood attack

HTTP (Layer 7) flood attack

HTTP flood consists of seemingly legitimate session-based sets of HTTP GET or POST requests sent to a target web server. These requests are specifically designed to consume a significant amount of the server’s resources, and therefore can result in a denial-of-service.

HTTP makes it difficult for network security devices to distinguish between legitimate HTTP traffic and malicious HTTP traffic, and could cause a high number of false-positive detections. Rate-based detection engines are also not successful at detecting HTTP flood attacks, as the traffic volume of HTTP floods may be under detection thresholds. Because of this, it is necessary to use several parameters detection including rate-based and rate-invariant.

Mirai’s HTTP L7 attack’s strings are encrypted within the source code. Using the encryption key we were able to decrypt it and continue to review the code.

Figure 5: Encryption of Mirai’s scripts


Figure 6: HTTP flood function


Figure 7: Mirai’s HTTP flood program creates huge 80MB POST requests

The malware is able to recognize DDoS protection solutions and adjust the attack accordingly.

Figure 8: Mirai Botnet trying to bypass DDoS Protection

This IoT DDoS botnet uses common headers and standard user agent to emulate legitimate traffic. This type of DDoS attack could be mitigated using an automatically adapting, network behavioral solution that differentiates legitimate user traffic from botnet traffic.

Figure 9: Http headers used by Mirai


The classic ACK flood attack with a twist. As simple botnets will be easily blocked by most network security solutions as they send large volumes of ACK packets, this IoT DDoS botnet starts with the ACK flood only after gaining a legitimate sequence number by completing the TCP connection process. By receiving a sequence number, this IoT DDoS botnet raises the odds of bypassing network security solutions.

DNS Water Torture Attack

The attacker sends a pre-crafted DNS query to the service provider’s DNS server. The malicious DNS query contains random string concatenated previous to the victim’s domain (For example The DNS server will attempt to get an answer from the authoritative nameserver repeatedly with no success. Sending different false strings with the victims’ domain name will eventually increase the DNS server’s CPU utilization until it is no longer available.

How To Prepare

  • Hybrid DDoS Protection - (on-premise + cloud) – for real-time DDoS attack prevention that also addresses high volume attacks and protects from pipe saturation.

  • Behavioral-Based Detection - to quickly and accurately identify and block anomalies while allowing legitimate traffic through.

  • Real-Time Signature Creation - to promptly protect from unknown threats and 0-day attacks.

  • Protect your GRE Tunnels - or have your providers do so by monitoring and probing the traffic that passes through them.

  • A cyber-security emergency response plan - that includes a dedicated emergency team of experts.

Under Attack and in Need of Expert Emergency Assistance? Radware Can Help.

Radware offers a DDoS service to help respond to security emergencies, neutralize the risk and better safeguard operations before irreparable damages occur. If you’re under a DDoS attack or malware outbreak and in need of emergency anti DDoS protection, Contact us with the code "Red Button".


Click here to download a copy of the ERT Threat Alert.

Download Now

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program

Get Social

Connect with experts and join the conversation about Radware technologies.

Security Research Center