Over the past few years, several major distributed denial-of-service (“DDoS”) attacks took place, including a major event affecting the domain name service provider Dyn, which caused outages and slowness for a number of popular sites, including Amazon, Netflix, Reddit, SoundCloud, Spotify, and Twitter. However, since several of these large, highly-publicized attacks occurred in 2016, there have been new developments that provide insight into some of the current trends and risks that companies face today relating to these DDoS Attacks. Most recently, several security firms have identified the evolution of the source code used in the Mirai botnet that significantly expand its power by allowing more devices to be commandeered. In this post we delve into this threat vector and how it may impact organizations.

At their most basic level, DDoS attacks work by sending a high volume of data from different locations to a particular server or set of servers. Because the servers can only handle a certain amount of data at a time, these attacks overwhelm the servers causing them to slow significantly or fail altogether. This prevents authorized users from being able to use or access the services being provided via the attacked servers. DDos attacks are particularly problematic for companies because they can result in direct revenue losses if customers are unable to transaction.

The 2016 Mirai Malware and Attacks

In 2016, several sizeable attacks were attributed to a malware variant named Mirai, which commandeered various internet-enabled digital video recorders (DVRs), cameras, and other IoT devices and was then utilized by attackers to launch multiple high-profile, high-impact DDoS attacks against various Internet properties and services.

This botnet was particularly effective based on the increasing prevalence of Internet of Things (IoT) devices. Researchers estimate that over 23 billion IoT devices are installed globally in 2018 (and that number is expected to rise to 75 billion by 2025). The attackers are able to exploit the relative security weaknesses in IoT devices by using malware to create networks of these computers, known as botnets, which report to a central control server that can be used as a staging ground for launching powerful DDoS attacks. Due to the enormous number of IoT devices that can be compromised simultaneously, the amount of traffic an attacker could generate by using a botnet “army” is far more substantial than the DDoS attacks of the past.

Mirai operated primarily as a “DDoS-for-hire” service in which attackers launch DDoS attacks against a target in exchange for payment, generally made in Bitcoin. These Mirai-based attacks were successful in creating extensive outages and the method for gaining control over the IoT devices was relatively straightforward—relying on using weak or default passwords on these IoT devices. The source code for Mirai was released publicly in 2016, which, as predicted, lead to more of these attacks occurring and a continuing evolution of the source code.

In 2017, researchers identified a new IoT botnet, named IoT Reaper or IoTroop, that built on portions of Mirai’s code. Instead of exploiting passwords of the devices it infects, the new botnet uses known security flaws in the code of those insecure devices to take control of them and then searches for other vulnerable devices to spread itself further. Vulnerable devices include various routers made by leading manufacturers, such as D-Link, Netgear, and Linksys, in addition to the types IoT devices used by Mirai.

The Next Generation of Marai Variants

Earlier this year, researchers identified attempts to further refine the Mirai source code, which was posted publicly in 2016. Researchers from Netscout’s Arbor Security Engineering and Response Team (ASERT) identified that botnet authors are using the Mirai source code as a framework, but then adding in new exploits and functionally, thus dramatically decreasing the development time for botnets. Furthermore, these botnets are then being used not only to launch DDoS attacks, but for other purposes as well, including attacks on cryptocurrency mining clients. Specifically, researchers have identified the following four Mirai variants: Satori Botnet, Masuta Botnet, Wicked Mirai, and JenX botnet, each of which is described in further detail below.

Satori Botnet

The Satori Botnet is a variant of Mirai that targets software associated with ARC processors, which are used in a variety of IoT devices. Once it finds a vulnerable IoT device, Satori performs a check to determine whether the device’s default settings have been changed, and, if not, uses these default credentials to gain control of the device. Once a device has been compromised, it searches for other devices on the network and attempts to repeat this process.

Most recently, researchers have identified that Satori-controlled devices were mass-scanning the Internet for cryptocurrency-mining devices that were exposed to the internet. Once under control, the attackers would push instructions to reconfigure the compromised device to join a mining pool and deposit earned cryptocurrency into the attacker’s wallet.


 Masuta comes in two variants, Masuta Botnet, which uses the same techniques as Mirai by attempting to overcome the security of the target IoT devices using a built-in list of common passwords and default credentials, and PureMasuta, which has been described as “an enhanced version” with a built-in exploit against certain vulnerable routers. Masuta is believed to be the work of the same group responsible for developing the Satori Botnet, however unlike Satori, Masuta attacks allow the actors to take direct control of compromised devices, making other malicious actions possible, including:

  • Trojan Activity — Using embedded code to launch a Trojan virus onto the target IoT devices, allowing the attacker to view device activity in real time as well as take over control of the machines at any given time.
  • Traffic Redirect Activity— Using compromised networking gateway equipment (such as routers and switches) the attackers reroute internet traffic through a server they control, enabling complex man-in-the-middle attacks.
  • Malware Delivery — Using the compromised device to deliver various types of viruses to other connected devices on the network.

Wicked Mirai

The Wicked iteration of Mirai contains a package that includes at least three exploits. This variant scans multiple ports on network devices, and uses open ports to download copies of various payloads (the nature of the payload will depend on which ports are available). Unlike Mirai, however, which used brute force to gain access to vulnerable IoT devices, the Wicked version relies on a variety of port-related vulnerability exploits, some new and some very old, to gain access to a device.

Once on a system, Wicked Mirai contacts a command and control server from which it downloads a payload (in some cases payloads from other Mirai variants like Sora, Owari, and Omni) that can vary based on the attackers’ objective and the nature of the affected device. Wicked looks for specific vulnerabilities on a platform that the botnet can exploit. This change allows the botnet controllers to have a faster compromise time, which allows the botnet to come online faster. In addition, the Wicked variant is also able to maintain a presence on IoT devices it infects beyond the occasional reboots, increasing its power and persistence to launch substantial DDoS attacks.

 JenX Botnet

 The JenX variant is a unique variant that leverages the Grand Theft Auto videogame community to infect IoT devices. Unlike the Satori and Masuta variants, JenX has a centralized infrastructure and uses a central server to perform the scanning of new hosts. The other variants perform distributed scanning and exploiting (e.g., each compromised device searches for new victims), facilitating rapid growth of the botnet, but that comes at the price of flexibility and sophistication. The centralized structure of JenX provides the attackers with greater flexibility to add and improve the functionality of the malware over time. This variant was advertising DDoS attacks as a service with a guaranteed bandwidth of 290 to 300 Gbps for the attack, which the attackers explained would employ “God’s wrath . . . against the IP that you provide us.

Next Steps

 With the increasing threat of these attacks, coupled with the number of different ways that they can be leveraged, organizations should take steps to prepare for, respond to, and mitigate some of the potential fall-out associated with a DDoS or other botnet attack. Outlined below are some of the steps that organizations can consider to mitigate their exposures before, during, and after such an attack.

Before an Attack 

  • Incident Response Planning. As with any potential security incident, effective planning can help reduce or eliminate some of the potential business harms and legal consequences before an attack occurs. Companies should incorporate emergency situations like DDoS or ransomware attacks, which have the propensity to affect critical business operations, in their Incident Response Plans (IRP). E-commerce companies and others that rely heavily on website traffic may wish to identify “mission critical” resources and devise alternative solutions that can be used in the event of website failure following a DDoS attack.
  • Negotiating/Reviewing Contractual Liability. Losses of service could affect an organization’s contractual obligations; for example, unavailability of resources may impact uptime and reliability guarantees contained in service-level agreements or other similar contract provisions. Contracting parties should be certain to consider and address these issues during the contract negotiation process to ensure that the risks associated with these incidents are properly allocated between or among the parties involved. For example, organizations may wish to address the potential repercussions from a DDoS in various contractual provisions:
    • Revising force majeure provisions or other exceptions to contractual service guarantees to exclude downtime attributable to these type of incidents from uptime or reliability calculations;
    • Creating disclaimer or limitation of liability language in agreements that expressly limits or eliminates potential liability associated with the inability to perform transactions during a system or website outage;
    • Carefully drafting security incident notification clauses to avoid contractual liability where notice might be required under a contract, but would not be required under any other law or regulation; and
    • Allocating risk and liability for potential outages in terms governing limitations on liability and indemnity.
  • DDoS Mitigation. Organizations should consider retaining third parties to provide DDoS mitigation services designed to combat these attacks by absorbing or deflecting DDoS traffic. Companies already using these services may wish to review the level of services provided to ensure that they have an adequate amount of protection in light of the increasing data volume seen in recent IoT-based attacks. Historical levels of protection may be insufficient in light of the increasing numbers of IoT devices that are becoming more easily exploitable.
  • Documenting Security and Preventative Measures. In anticipation of potential litigation and regulatory enforcement, we recommend that organizations document the various security measures that are being implemented, including those designed to prevent and mitigate the effects of cyber attacks. Documenting security practices and decisions as they are being designed can help bolster arguments that a companies’ actions were reasonable under the circumstances. Although, in the context of litigation or a regulatory investigation, these actions will be viewed in hindsight by a court, jury, or regulator, contemporaneous information about these can significantly bolster defenses against claims of negligence or breach of contract by litigants or non-compliance by regulators and may also help defend against litigation.

During an Attack

  • Establishing and Preserving Attorney-Client Privilege. A key consideration in the investigation of and response to any cyber incident is establishing and preserving attorney-client privilege or work-product doctrine protections. Important steps in preserving privilege include: (i) retaining or involving legal counsel early in the process, (ii) focusing the investigation on providing legal advice to the organization, including providing legal advice in anticipation of litigation and regulatory inquiries, and (iii) retaining forensic or security experts through legal counsel.
  • Balancing Remediation and Investigation Objectives. Unfortunately, remediating an attack and restoring operations may adversely impact evidence needed to investigate an incident. We recommend that organizations confer with forensic experts and legal counsel as soon as possible following the start of an attack to gauge how containment and remediation could affect important evidence.
  • Involving Law Enforcement. Organizations often reflexively want to contact law enforcement in response to a data incident. Although this may be beneficial, there are some considerations that organizations should weigh before doing so. The frequency and severity of these attacks has led to more attention from various law enforcement agencies and significantly more success in identifying and prosecuting attackers. Federal law enforcement agencies often have intelligence on various groups responsible for these attacks and, as a result, may be able to provide important information in responding to, containing, and remediating these attacks. However, law enforcement agencies may not always be able to share much information, particularly where the information relates to an ongoing investigation.

Additionally, alerting law enforcement can result in having the agency become significantly more involved in, or even controlling, the investigation of the incident. Law enforcement involvement could impact privilege issues and, more generally, may not be ideal in all circumstances. We suggest that organizations consult with legal counsel to evaluate the potential advantages and disadvantages of notifying law enforcement based on their specific circumstances.

  • DDoS Mitigation. Companies should be aware that many DDoS mitigation vendors offer emergency DDoS hotlines or protection services that can be deployed for new customers, even where a company has not proactively secured such services. Engaging a DDoS mitigation service provider after an attack has started can help to reduce the length and severity of an attack, allowing a company to get its affected servers and websites back up and running more quickly.

After an Attack

  • External Communications. When and how an organization communicates about a DDoS or other cyber attack may impact its exposure and liability following an incident. These communications may include: (i) general communications about the incident with media, investors, customers, or regulators; and (ii) formal notifications ranging from those necessitated by legal or regulatory requirements to formal contractual notices necessary to exercise force majeure or emergency circumstances. Organizations should be especially cautions about all internal and external communications and we suggest that organizations consult with legal counsel, and in some cases external public relations resources, to more fully evaluate the potential effects such communications may have on the investigation and the organization more generally.
  • Further Investigation. Following an organization’s remediation and restoration efforts, it is often necessary to conduct a further investigation into the circumstances surrounding the attack and to determine whether and to what extent any legal obligations have been triggered. Depending on the organization’s capabilities and resources, it may be possible to leverage any incident detection measures the organization has to identify indicators of compromise and confirm that the malicious activities were limited to the known aspects of the particular attack. In some circumstances, retaining independent forensic investigators may be necessary to conduct a thorough investigation into whether any unauthorized access or acquisition to customer information or confidential business information occurred prior to or during the attack.
  • Preparing for Potential Litigation or Claims. As mentioned previously, DDoS attacks could result in litigation or regulatory scrutiny for a variety of reasons. Examples of potential actions stemming from such an attack include:
    • An action brought by financial services customers alleging consequential damages and lost profits based on an inability to access financial accounts or buy and sell stock during an attack;
    • Claims against service providers for failing to provide contractually-guaranteed service levels;
    • Claims based on allegations of the theft of customer information, trade secrets, intellectual property, or other confidential or protected information; and
    • Claims alleging negligence or fraud based on a company’s failure to adequately protect against a DDoS attack or appropriately limit liability in its agreements with customers.

Anticipating and preparing for this type of potential exposure can better position the organization for defending against these claims. Relatedly, organizations are required to preserve potentially relevant information and documents once they reasonably anticipate litigation. To that end, organizations should consult with legal counsel to determine when it is appropriate to put litigation holds in place to ensure that they avoid potential spoliation issues and sanctions. Organizations in this position must also consider whether and how an assertion of privilege protections under the work-product doctrine may affect its preservation obligations. If a company asserts that materials have been prepared by and with legal counsel “in anticipation of litigation” and are therefore protected, it should consider whether this assertion also triggers an obligation to preserve evidence at that time.


Posted by Cooley