On September 20th, the well-known website KrebsonSecurity faced a targeted distributed denial-of-service (DDoS) attack. This attack had been performed using a huge botnet of IoT devices (more than 300.000 participants) – the majority were cameras. This botnet has been called “Mirai”. On October 21st, another massive DDoS attack against the Domain Name System (DNS) company Dyn caused several hours of disruption for U.S. users. Popular websites such as Twitter, Netflix, Paypal and Spotify were affected and inaccessible. Although the attack did not target the sites themselves, it took down part of a key service on which web browsing relies – the Domain Name System. According to Dyn, the attack involved tens of millions of malicious devices. They confirmed that a part of the traffic came from devices infected by the “Mirai” IoT botnet.

The Internet of Things is now part of our new lifestyle and represents a new way to interact with our environment. Today, most of these devices are connected to the Internet without proper security configuration. Because of this lack of security, these devices represent a major threat. This growing threat can also have major consequences in an industrial environment and Sentryo is highlighting this with its analysis of the Mirai botnet based on its source code and some malware samples.

Mirai’s track record

1. September 20th, KrebsOnSecurity attack:

On September 20th at 8 PM, the website https://krebsonsecurity.com, hosted by the company Akamai, faced a Distributed Denial-Of-Service (DDoS) attack. According to Akamai, the attack was among the biggest assaults the Internet has ever witnessed. Indeed, in this case, we are talking about more than 620 Gbps of network traffic targeting the website.

KrebsonSecurity DDoS Attack
                                                      Source : www.krebsonsecurity.com

Martin McKeay, Akamai’s senior security advocate, said the largest attack the company had seen previously clocked in earlier this year at 363 Gbps. But he said there was a major difference between last night’s DDoS and the previous record holder: The 363 Gbps attack is thought to have been generated by a botnet of compromised systems using well-known techniques allowing them to “amplify” a relatively small attack into a much larger one.

Actually, the traffic was composed mainly of Generic Routing Encapsulation (GRE) data packets. The usage of GRE data packets is quite unusual. To perform this attack the attacker had to control every infected device to generate GRE data-packets directly. Indeed, GRE data-packets can’t be spoofed or faked in the same way it can with DNS traffic. Below, infected devices used to perform this attack are displayed on a world map:

World map infected devices

Source: www.incapsula.com

The infection of this botnet was performed using a malware called Mirai. The source code of this malware was released on the 30th of September.

2. A couple of days later, the OVH attack:

A couple of days later hosting company OVH declared, on their own, it had also been facing the same type of attack traffic with a superior bandwidth equivalent to 1.1 Tbps. So far, nobody has confirmed their claim.

3. October 21st, the Dyn attack:

The October 21st, the company Dyn also faced a huge DDoS attack against their own DNS servers. Dyn published an article describing the attack on their website. It explains: “Starting at approximately 7:00 am ET, Dyn began experiencing a DDoS attack. While it’s not uncommon for Dyn’s Network Operations Center (NOC) team to mitigate DDoS attacks, it quickly became clear that this attack was different (more on that later). Approximately two hours later, the NOC team was able to mitigate the attack and restore service to customers. Unfortunately, during that time, internet users directed to Dyn servers on the East Coast of the US were unable to reach some of our customers’ sites, including some of the marquee brands of the internet.“ (Editor’s note: Netflix, NY Times, Paypal, Twitter) 

[…] “We can confirm, with the help of analysis from Flashpoint and Akamai, that one source of the traffic for the attacks were devices infected by the Mirai botnet. We observed 10s of millions of discrete IP addresses associated with the Mirai botnet that were part of the attack.”

Mirai code analysis

Using the source code and malware samples, Sentryo has been able to realize this analysis and explain how this botnet works.

Mirai

Different steps of the malware activity will be described :

  • The reconnaissance phase of the infection process
  • The reporting of the potential victims
  • The actual malicious payload insertion
  • The attack capabilities of the botnet

The reconnaissance phase of the infection process

The infection spreads itself from infected IoT devices which regularly scan IP addresses on the Internet to find other connected targets. In the malware source code, a C program called scanner.c contains a function to generate random IP addresses (the addresses are tested against an IP blacklist before being used). For example, if the rand_next() function returns an IP address corresponding to the DoD, the randomize function is called again. As you can see in the picture below, the blacklist is surprisingly short and contains the following organizations: the DoD, General Electric, HP, and the US Postal Service.

Blacklist

Once an infected device has chosen a new random IP address (not in the blacklist), it tries to access the remote device using a list of hardcoded credentials. Indeed, the same scanner.c program contains a list of credentials that can be used to access devices protected with default factory credentials. Below, the list of hardcoded credentials used by the malware is displayed:

Harcoded credentials

To test these credentials, the malware actually tries to find any online services available on the target that would prompt for user and passwords. To do this, it checks if the string “ogin”, “assword” or “enter” are displayed on the prompt. If this is the case, it tries to login using the default IoT credentials listed above.

IoT credentials

IoT credentials list

 

The website KrebsOnSecurity published a list of IoT devices which were targeted along with the associated vendors:

Username/Password Manufacturer
admin/123456 ACTi IP Camera
root/anko ANKO Products DVR
root/pass Axis IP Camera, et. al
root/vizxv Dahua Camera
root/888888 Dahua DVR
root/666666 Dahua DVR
root/7ujMko0vizxv Dahua IP Camera
root/7ujMko0admin Dahua IP Camera
666666/666666 Dahua IP Camera
root/dreambox Dreambox TV receiver
root/zlxx EV ZLX Two-way Speaker?
root/juantech Guangzhou Juan Optical
root/xc3511 H.264 – Chinese DVR
root/hi3518 HiSilicon IP Camera
root/klv123 HiSilicon IP Camera
root/klv1234 HiSilicon IP Camera
root/jvbzd HiSilicon IP Camera
root/admin IPX-DDK Network Camera
root/system IQinVision Cameras, et. al
admin/meinsm Mobotix Network Camera
root/54321 Packet8 VOIP Phone, et. al
root/00000000 Panasonic Printer
root/realtek RealTek Routers
admin/1111111 Samsung IP Camera
root/xmhdipc Shenzhen Anran Security Camera
admin/smcadmin SMC Routers
root/ikwb Toshiba Network Camera
ubnt/ubnt Ubiquiti AirOS Router
supervisor/supervisor VideoIQ
root/<none> Vivotek IP Camera
admin/1111 Xerox printers, et. al
root/Zte521 ZTE Router

We can directly conclude that the targets were not only cameras but also printers, some routers, phones…

The reporting of the potential victims

Once the access to the new remote IoT device has been granted, the original infected device sends back all the information related to this new potential target to a report server. This report server has been configured during the botnet compilation with TABLE_SCAN_CB_DOMAIN and PORT parameters.

Server report botnet

The actual malicious payload insertion

At this point the attacker can connect to the report server and decide to infect the new remote device. If it takes this step, the remote target architecture is detected and the appropriate malicious charge is sent to this IoT device which will become a bot member of the whole botnet. Indeed, in function of the target architecture (x86, mips, mpsl, arm, arm5n, arm7, ppc, spc, m68k or sh4), a dedicated malicious busybox image is uploaded on the targeted device.

Target architecture

Compile Bot

 

The attack capabilities of the botnet

Now, the remote IoT device is infected and is a botnet member. It can connect back to a C&C server. Inside each bot code, a C&C server has been configured during the malware compilation with the TABLE_CNC_DOMAIN and PORT parameters:

CNC domain

The C&C also contains a database called mirai with three tables:

  • History → user_id, command, max_bots…
  • Users → username, password, duration_limit, cooldown, max_bots…
  • Whitelist → prefix and netmask
  • Infected devices are controlled using these parameters.

The attack can be chosen by the attacker by using the following options:

image09-options-attack

As seen above, and given the details from KrebsOnSecurity, this massive DDoS attack probably started with the ATK_VEC_GREIP parameter (index 6).

In the GRE-IP attack, crafted UDP/IP packets are encapsulated within GRE packets. For each encapsulated packet, IP addresses and UDP ports can be randomized. This way, Mirai is able to spoof IP addresses and defeat basic Denial of Service protection.*

pasted_image_at_2016_10_26_03_29_pm

pasted_image_at_2016_10_26_03_30_pm

Therefore, we can say that the number of infected IoT devices estimated by victims is quite hard to verify and should be used only as an assumption.

 

Mirai overview

In order to illustrate the code analysis, you can find below a scheme, extracted from the Level3’s blog, explaining the botnet architecture. We can see infected devices (B) performing DDoS attacks on victims (D) while being controlled by the C&C server (C). At the same time, bots (B) are also scanning to  find new potential bot members (V) and report them to the report server (R).

Scheme botnet architecture

Source : blog.level3.com

Who is behind this malware?

Inside the source code, we can read Russian text as displayed below but so far nothing is clear about the group behind the attack nor its motivation.

Russian text

 

Some Russian translation:

  • Mпользователь -> member
  • Пароль → password
  • Проверив → checking
  • Произошла неизвестная ошибка → An unkown error occurred
  • Нажмите любую клавишу для выхода. → Press any key to exit
  • я люблю куриные наггетсы → I love chicken nuggets (It seems a troll or a joke from the developer)
  • So far, we cannot conclude on the provenance but we can guess there is a Russian speaker behind this malware or at least someone who is trying to fingerprint Russia.

Is it a risk for industrial networks?

Currently this malware is not an infection risk for the industrial network due to the hardcoded credentials list of IoT consumers devices.

Nevertheless, adapting the malware source code to add default credentials of industrial controllers (ABB, Emerson, Rockwell, Schneider, Siemens…) could easily be done due to the generic aspect of the malware. The resulting threat of this modification could have a huge terrible impact.

With the advent of the Industrial Internet of Things (IIoT), IoT devices are also coming to industrial networks. We have to be prepared and focus on improving OT security.

The key point to remember is that OT devices can be used as a major threat vector. Securing them properly is not an option. In any case, detecting the connection of an infected device to a C&C or report server can be done with appropriate solutions and should be a priority. Such a task can be done intuitively with advanced Network Security Monitoring solutions like ICS CyberVision.

Indicator of Compromise (IoC)

The KrebsOnSecurity attack was performed mainly from the DNS santasbigcandycane.cx. Today this domain name is not used anymore but we left it because infected IoT devices can continue trying to reach it. Below, a list of indicators of compromise:

network.santasbigcandycane.cx  80.87.205.11  C2 server
network.santasbigcandycane.cx 185.93.185.12 C2 server
network.santasbigcandycane.cx 185.93.185.11 C2 server
network.santasbigcandycane.cx 80.87.205.10 C2 server
network.santasbigcandycane.cx 185.70.105.161 C2 server
network.santasbigcandycane.cx 185.130.225.95  C2 server
network.santasbigcandycane.cx 185.130.225.94 C2 server
network.santasbigcandycane.cx 185.130.225.65 C2 server
network.santasbigcandycane.cx 185.130.225.83 C2 server
network.santasbigcandycane.cx 185.130.225.66 C2 server
network.santasbigcandycane.cx 185.70.105.164 C2 server
network.santasbigcandycane.cx 185.130.225.90 C2 server
network.santasbigcandycane.cx 46.249.38.153 C2 server
network.santasbigcandycane.cx 46.249.38.149 C2 server
network.santasbigcandycane.cx 46.249.38.152 C2 server
network.santasbigcandycane.cx 46.249.38.148 C2 server
network.santasbigcandycane.cx 46.249.38.154 C2 server
network.santasbigcandycane.cx 46.249.38.151 C2 server
network.santasbigcandycane.cx 46.249.38.150 C2 server
network.santasbigcandycane.cx 46.249.38.146 C2 server
network.santasbigcandycane.cx 46.249.38.145 C2 server
network.santasbigcandycane.cx 46.249.38.159 C2 server
report.santasbigcandycane.cx 65.98.91.181 report server
report.santasbigcandycane.cx 72.8.183.202 report server
report.santasbigcandycane.cx 93.158.200.115 report server
cnc.disabled.racing 93.158.200.115 C2 server
cnc.disabled.racing 92.222.66.137 C2 server
cnc.disabled.racing 188.209.52.101 C2 server
cnc.disabled.racing 93.158.200.66 C2 server
cnc.disabled.racing 173.212.192.219 C2 server
cnc.disabled.racing 191.96.249.29 C2 server
cnc.disabled.racing 151.80.27.90 C2 server
gay.disabled.racing 151.80.27.90 C2 server
gay.disabled.racing 51.255.172.22 C2 server
gay.disabled.racing 77.247.178.191 C2 server
report.disabled.racing 93.158.200.115 report server
report.disabled.racing 93.158.200.68 report server
report.disabled.racing 166.62.80.172 report server
report.disabled.racing 173.212.192.219 report server
report.disabled.racing 77.247.178.191 report server
report.disabled.racing 93.158.200.126 report server
report.disabled.racing 93.158.200.105 report server
lol.disabled.racing 151.80.27.90 C2 server
lol.disabled.racing 93.158.200.66 C2 server
lol.disabled.racing 93.158.200.103 C2 server
lol.disabled.racing 92.222.66.137 C2 server
lol.disabled.racing 51.255.172.22 C2 server
dongs.disabled.racing 93.158.200.126 malware distribution               
penis.disabled.racing 77.247.178.191 C2 server
b0ts.xf0.pw 185.47.62.199 C2 server
b0ts.xf0.pw 149.56.232.146 C2 server
b0ts.xf0.pw 158.69.142.34 C2 server
b0ts.xf0.pw 185.153.197.103 C2 server
b0ts.xf0.pw 176.126.245.213 C2 server
b0ts.xf0.pw 137.74.49.205 C2 server
report.xf0.pw 91.185.190.172 report server
report.xf0.pw 149.56.151.180 report server
report.xf0.pw 149.56.232.146 report server
report.xf0.pw 185.115.125.99 report server
report.xf0.pw 93.104.209.11 report server
report.xf0.pw 23.89.159.176 report server
report.xf0.pw 137.74.49.208 report server
report.xf0.pw 104.223.37.150 report server
swinginwithme.ru 154.16.199.48 C2 server
swinginwithme.ru 77.247.178.47 C2 server
swinginwithme.ru 151.80.99.91 C2 server
swinginwithme.ru 151.80.99.90 C2 server
swinginwithme.ru 154.16.199.78 C2 server
swinginwithme.ru 185.100.87.238 C2 server
swinginwithme.ru 185.62.190.38 C2 server
imscaredaf.xyz 154.16.199.48 C2, same IP as swinginwithme.ru
imscaredaf.xyz 154.16.199.78 C2, same IP as swinginwithme.ru
imscaredaf.xyz 154.16.199.144 malware distribution
kankerc.queryhost.xyz 192.69.89.173 C2 server
kankerc.queryhost.xyz 154.16.199.34 C2 server
report.queryhost.xyz 192.69.89.173 report server
report.queryhost.xyz 45.32.186.11 report server
report.queryhost.xyz 154.16.199.34 report server
meme.icmp.online 77.247.178.191 C2 server
report.icmp.online 93.158.200.124 report server
dongs.icmp.online 93.158.200.126 report server
                             Source : blog.level3.com

 

*Thanks to @esdaniel for his useful comment!