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.
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:
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)
Mirai code analysis
Using the source code and malware samples, Sentryo has been able to realize this analysis and explain how this botnet works.
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.
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:
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.
The website KrebsOnSecurity published a list of IoT devices which were targeted along with the associated vendors:
|admin/123456||ACTi IP Camera|
|root/anko||ANKO Products DVR|
|root/pass||Axis IP Camera, et. al|
|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|
|admin/1111111||Samsung IP Camera|
|root/xmhdipc||Shenzhen Anran Security Camera|
|root/ikwb||Toshiba Network Camera|
|ubnt/ubnt||Ubiquiti AirOS Router|
|root/<none>||Vivotek IP Camera|
|admin/1111||Xerox printers, et. al|
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.
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.
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:
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:
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.*
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.
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).
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.
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:
|imscaredaf.xyz||188.8.131.52||C2, same IP as swinginwithme.ru|
|imscaredaf.xyz||184.108.40.206||C2, same IP as swinginwithme.ru|
Source : blog.level3.com
*Thanks to @esdaniel for his useful comment!