How the Grinch Stole IoT

Level 3 Threat Research Labs has previously reported on a family of malware that exploits Internet of Things (IoT) devices to create distributed denial of service (DDoS) botnets. With a rapidly increasing market for these devices and little attention being paid to security, the threat from these botnets is growing.  Level 3 Threat Research Labs has been continuously tracking these botnets as they wreak havoc on victims across the internet.

In mid-September, we discovered a new botnet connected to the malware known as “Mirai,” which has been responsible for attacks such as the record-breaking DDoS attack on KrebsOnSecurity.com.  Recently the source code of Mirai was released, which has inspired a significant number of new bad actors, all working to exploit similar pools of vulnerable devices. In this post we explore the behavior, structure, and trends of Mirai botnets, focusing on their interaction with our network backbone.

C2s

Using various machine learning techniques to analyze DDoS attacks sourced from known susceptible devices, Level 3 Threat Research Labs was able to identify a number of C2s associated with this botnet. Additionally, the IP addresses identified pointed to domains containing “santasbigcandycane.cx” (.cx is a top-level domain of Christmas Island) and were prefixed by “network” and “report” to denote their role in the botnet.  As a challenge to the security community, an IP from one of the network C2s was also once resolved to “catch.me.if.you.can” as opposed to the usual “network.santasbigcandycane.cx”.  By querying DNS records, these C2 IPs were easily enumerated.  A list of C2 IP addresses and domains can be found in the table at the bottom of this post.

At any one time, only a handful of network C2 IP addresses were active.  Approximately every two days, a new network C2 IP became active (see figure below).  This switching behavior is roughly 3-times more rapid than we observed in the gafgyt botnet.  It is likely done in an effort to evade detection.  In the plot below, we show the outbound traffic from network C2s, with each color representing a different network C2 IP.  The bars show the number of unique hosts sending traffic to the C2 each hour varied greatly (these hosts are assumed to be bots). The Mirai report C2 at “report.santasbigcandycane.cx” had much less communication with bots than the network C2s.

Figure 1 – Mirai “network” C2 outbound traffic binned by hour. Colors represent different C2s.

One interesting interaction we discovered was that the Mirai network C2s were attacked several times by a gafgyt/BASHLITE botnet.  In particular, there were gigabit-per-second level simultaneous attacks on two separate Mirai network C2s that stretched just over 24 hours, mostly during September 18.  Additionally, there were several shorter attacks on additional C2s in subsequent days, as can be seen by the spikes in bandwidth in the plot below.

Figure 2 – Mirai “network” C2 inbound traffic binned by hour. The spikes in the plot are attacks against the Mirai C2s. Several C2s were attacked by gafgyt/BASHLITE bots, including a significant 24-hour attack on September 18.

Structure of the Botnet

Figure 3 – Structure of a Mirai botnet

By analyzing the communication patterns of the Mirai C2 IP addresses, we were able to identify and enumerate Mirai’s infrastructure. This analysis was later confirmed accurate when the Mirai source code was released. It is interesting to note the initial Mirai infrastructure was much more complex than the various gafgyt variants we analyzed in our previous work. The diagram above outlines the basic functionality of Mirai and its components.

Bots (B) communicating with the Mirai C2 (C) were found scanning across TCP port 23 and port 2323 as well as performing DDoS attacks against various victims (D). Bots sent one-way traffic towards a report server (R) (report.santasbigcandycane.cx), which were the IP addresses and credentials of the vulnerable hosts. This was hypothesized due to the fact that several other IP addresses (L, loaders) would communicate with IP addresses that were previously scanned and later identified as bots. This communication contained bi-directional traffic on port 23, sometimes with large packet sizes, signifying interaction with the telnet service. We observed these same victims accessing a different IP address (M) on port 80 with large packet sizes. This IP address hosted the Mirai binary itself and the large packet sizes were due to the victim downloading the malware. After downloading the binary and finishing interaction with the loader, the victim IP would begin bot activity. Throughout our investigation we identified a long-lived IP connection from a TOR exit node to the report server (R), which we believe may have been the botnet author controlling the botnet.  With the botnet established, it was being sold to various users (U) who used an API hosted on the C2 server (C) to order DDoS attacks.

Bots

As with the gafgyt malware family, Mirai targets IoT devices.  The majority of these bots are DVRs (>80percent) with the rest being routers and other miscellaneous devices, such as IP cameras and Linux servers.  The devices are often operated with the default passwords, which are simple for bot herders to guess.  From the source code it has been found that Mirai’s scanning protocol utilizes a list of generic and device-specific credentials to gain access to susceptible devices.

We have been able to identify bots via communications with the C2. Once new bots are identified, their common communications lead to new C2s, which then lead to more bots.  Prior to the Mirai source code release, we identified approximately 213,000 bots using this method.  Since the code release, multiple new Mirai botnets have accumulated an additional 280,000 bots, bringing the count of Mirai bots to 493,000.  The true number of actual bots may be higher based on an incomplete view of the infrastructure.

While the types of devices infected by Mirai and gafgyt are similar, the geographic distribution of devices we observed are quite different.  The highest fraction of devices used are located in the United States (29 percent), followed by devices in Brazil (23 percent) and Colombia (8 percent).  Of the hosts we are confident have been assimilated by the Mirai botnet, 24 percent of them overlap with bots known to be used in gafgyt attacks.  Such a high overlap indicates that multiple malware families are targeting the same pool of vulnerable IoT devices.

Figure 4 – Global Distribution of Mirai bots

DDoS Victims

Typically, we have observed Mirai attacks on game servers and residential IP addresses. However, Mirai has also been blamed for the record attack on KrebsOnSecurity during September 20-22.  We can confirm that Mirai bots attacked Brian Krebs’ website.  Of the attackers we observed, approximately half were known Mirai bots at the time.

The magnitude of attacks observed can be quite significant.  We have observed several attacks using more than 100 Gbps.  Large armies of bots participated in attacks, with several using over 100,000 bots against the same victim. We have seen Mirai botnets employ a variety of different attacks, the majority of which are L7 HTTP attacks and UDP and TCP floods, while a smaller fraction utilized GRE. Additionally, we have seen a number of attacks against authoritative DNS infrastructure, sometimes as a part of attacks using multiple of these methods.

Figure 5 – Observed number of attacks attributed to Mirai

Proliferation

With the public release of the Mirai source code around October 1, it is expected additional actors will continue to utilize the malware to initiate DDoS attacks.  Shortly after the release, on October 2, we began observing bots connect to another C2 domain.  The domain associated with the IP, “cnc.disabled.racing”, appears analogous to the “network.santasbigcandycane.cx” C2 type.  Additionally, the “report” naming convention is duplicated in the “report.disabled.racing” domain.  As of this article, cnc.disabled.racing only talks to about 25 percent of the known susceptible IoT devices that network.santasbigcandycane.cx did. Interestingly, a single IP (93.158.200.115) related to report.disabled.racing and cnc.disabled.racing on October 3, was also associated with report.santasbigcandycane.cx on October 4.  We cannot confirm if the original author has moved to this new domain infrastructure or rather this newer Mirai variant is utilizing the same rented server infrastructure.

Table 1 – Mirai C2s and Report C2s

We also identified a new C2 domain, xf0.pw, associated with similar Mirai activity and hosting a new Mirai binary on its own IP. Traffic shows this variant was most likely using the same IP for initial scanning, scan result reporting, and malware distribution for some time. An IP address associated with xf0.pw had previously been identified as a gafgyt C2 back in late August using our C2 detection algorithm. On October 5, we identified another C2 variant using queryhost.xyz who seems to be also hosting its infrastructure on the same host.

A new Mirai variant hosted on the IP address associated with the domain names imscaredaf.xyz and swinginwithme.ru was found on October 3, but had slightly different network behavior when compared to the original Mirai variant. As it turns out, around the same time this same IP was hosting a “get.sh” shell script submitted to VirusTotal. This shell script uses wget to download various binaries based on architecture and when run, downloads a new Mirai variant. Gafgyt used a very similar type of script via their scanners.

Looking Forward

With the recent and frequent introduction of new Mirai variants, we expect continued DDoS activity from Mirai botnets.  The structure of these botnets is evolving as different owners adapt the malware. In some cases, we see the new variants running all of their infrastructure on one or two hosts, as opposed to the original Mirai variant which had many different hosts and frequently changed IPs to avoid detection or attack. We also see different malware distribution mechanisms, as in the case of swinginwithme.ru.  Level 3 Threat Research Labs will continue to identify and track developments in these botnets. We will also work with hosting providers and domain registrars to block traffic to these C2s.

There are further actions that can be taken to prevent attacks from IoT botnets. Manufacturers play a vital role in mitigating threats from malware like Mirai.  By disabling unused services, such as telnet, and requiring users to set passwords after installation, devices become much less vulnerable.  Consumers can improve their security as well by changing default passwords and following security best practices.  As IoT devices become more widespread, implementing these basic security measures will become more important.

Appendix A: C2 list as of 10/14/2016

Appendix B: Hashes

Mirai Samples
Filename	Hash	C2
mirai.arm	35156594d941216f7fe6ced5c1893921	network.santasbigcandycane.cx
mirai.arm	b0803b91933fe61b1abc91b001699058	network.santasbigcandycane.cx
mirai.arm7	d2273df4dcff8cca812104cf17a23bca	network.santasbigcandycane.cx
mirai.m68k	75f752e4785f359511a781a1aa67bbed	network.santasbigcandycane.cx
mirai.mips	c16ea02487ddcdfbae313f45de23d064	network.santasbigcandycane.cx
mirai.mpsl	0ddfad615dbd51b088d4f535a045efd3	network.santasbigcandycane.cx
mirai.mpsl	6a1774e85f866f37be32c3b6cf30c972	network.santasbigcandycane.cx
mirai.ppc	edeb470ad89d81dfcf72e5c9d7a9eb6c	network.santasbigcandycane.cx
mirai.sh4	1cb8051b5a220b12a913048a23490f02	network.santasbigcandycane.cx
mirai.spc	753742e76ad5589fd8bab94a16755

This content is provided for informational purposes only and may require additional research and substantiation by the end user. In addition, the information is provided “as is” without any warranty or condition of any kind, either express or implied. Use of this information is at the end user’s own risk. Lumen does not warrant that the information will meet the end user’s requirements or that the implementation or usage of this information will result in the desired outcome of the end user. All third-party company and product or service names referenced in this article are for identification purposes only and do not imply endorsement or affiliation with Lumen. This document represents Lumen products and offerings as of the date of issue.