Two New IoT Vulnerabilities Identified with Mirai Payloads

By , , and

Category: Unit 42

Tags: , ,

This conceptual image illustrates the idea of cybercrime.

This post is also available in: 日本語 (Japanese)

Executive Summary

Palo Alto Networks is proactively trying to safeguard its customers from attacks however possible. By leveraging its Next-Generation Firewall as sensors on the perimeter to detect malicious payloads and attack patterns, Unit 42 researchers are able to hunt down the menaces out there on the network, be they known or not.

Unit 42 researchers have taken a closer look at four Mirai variants from two recently discovered campaigns leveraging command injection vulnerability exploits that reveal a familiar IoT attack pattern.

While this generic approach allows researchers to observe the entire killchain and even acquire the malware binary from the attack, this post-exploitation heuristic does have its caveat: the traffic fingerprinting. Similar services yield similar traffic patterns because of similar, if not identical, code bases and underlying implementation. Since a service can exist in multiple devices with different configurations and there are multiple brands for a specific device, it’s become exponentially hard, if not impossible, to identify the susceptible device(s) in real time.

This blog includes a brief analysis of the two IoT exploits observed in the wild and the four Mirai variants delivered during the attack. Palo Alto Networks Next-Generation Firewall customers are protected against these attacks.

Exploit Payloads Include Mirai Variants

A total of four Mirai variants were recently discovered. Two new vulnerabilities were leveraged as attack vectors to deliver Mirai. Upon successful exploitation, the wget utility is invoked to download a shell script from the malware infrastructure. The shell script then downloads several Mirai binaries compiled for different architectures and executes these downloaded binaries one by one.

The first exploit, shown in Figure 1, targets a command injection vulnerability in a web service with an NTP server setting feature. The service fails to sanitize the value of the HTTP parameter NTP_SERVER, which in turn leads to arbitrary command execution.

The first exploit targeting IoT vulnerabilities in unknown devices targets a command injection vulnerability in a web service with an NTP server setting feature.
Figure 1. Command injection exploit over the wire

Following the leads acquired from the attack traffic, we have narrowed our scope to some IoT devices that are known to synchronize time through HTTP and found several vulnerable NTP-server-handling routines in firmware in some IoT devices, which is concerning since some vendors no longer support the products running said firmware. Figure 2 shows one such vulnerable function found in a library module. While the firmware that we have analyzed have such insecure functions, they are fortunately impervious to this specific attack because the targeted uniform resource identifier (URI) is not present in these firmware. The identification of the affected product is still in progress as we proceed to analyze other IoT devices that are likely to do time synchronization through HTTP.

This shows an example of one of the IoT vulnerabilities, a vulnerable function found in a library module.
Figure 2. Vulnerable code snippet in one of the firmware

The initial attack incident of the first exploit was observed on July 23, 2020, at 05:55:06 a.m. UTC. The attack (shown in Figure 1) lasted for a few weeks, with the last incident reported on Sept. 23, 2020, at 15:21:23 p.m. UTC. There were 42 unique alerts at the time of this writing.

The second exploit caught in the wild provides less context than the first exploit; the URL and the HTTP request headers do not yield any useful insights. Evidently, there is a lack of parameter sanitization in the HTTP parameter pid that results in a command injection vulnerability, as shown in Figure 3. We speculate that the targeted service is some type of remote process management tool because of similar parameter patterns in the attack traffic, and that it’s possibly experimental and thus low in usage.

A lack of parameter sanitization in the HTTP parameter pid results in a command injection vulnerability, as shown here.
Figure 3. Command injection exploit over the wire.

A total of 48 unique attack incidents occurred in just 12 seconds. The attack started on Aug. 16, 2020, at 09:04:39 a.m. UTC, and it ended on Aug. 16, 2020, at 09:04:51 a.m. UTC, indicating that this exploit is quick and short-lived.

We grouped the Mirai variants by numbers: one, two, three and four. The SHA256 for each of the Mirai variants are available in the Indicators of Compromise section below. Table 1 shows the delivery method as well as the embedded decryption key for each variant.

Delivery Method Mirai Variant Decryption Key
Exploit one Variant One 0xdeadbeef
Exploit one Variant Two 0xdedefbba
Exploit two Variant Three 0xdedefbaf
Exploit two Variant Four 0xdeadbeef

Table 1. Delivery methods and the decryption key.

While these variants do not share the exact same origin and configuration, they all possess the necessary functionality to launch DDoS attacks. Variant four also possesses an infection capability that is not present in the other three variants, making it a more dangerous threat. Table 2 below summarizes the exploits that this particular Mirai variant uses for infecting other vulnerable hosts. Just like its predecessors, this variant inherits exploits that were also used in the previous variants.

Android debug bridge shell CVE-2019-14931 Fastweb Fastgate RCE
ASUS RT-AC66U RCE HomeMatic Zentrale CCU2 RCE EnGenius RCE
CVE-2013-2251 CVE-2015-1187 Netlink GPON Router RCE
ThinkPHP RCE D-Link Router RCE CVE-2020-5722
Vacron NVR RCE CVE-2019-16920 CVE-2019-10655
Netgear RCE CVE-2020-8515 Unknown Exploit Two
CVE-2017-18377 Edimax EW-7438RPn RCE CVE-2020-1956
CVE-2018-17173 CVE-2019-19356 3Com OfficeConnect RCE
CVE-2018–13023 NUUO NVRmini RCE CVE-2019-7276
CVE-2018-19276 Multiple IoT RCE CVE-2011-3587
CVE-2016-6277 Sar2HTML RCE CVE-2018-7841
CVE-2019-16057 CCTV-DVR RCE

Table 2. Variant four’s infection capability.


Security for IoT devices is still concerning. One major challenge for IoT security is that IoT devices that are no longer supported are still being deployed and used. Flaws in their firmware unfortunately do not just go away with an end-of-life and end-of-support announcement. The good news is that Palo Alto Networks offers the following products and services to protect its customers from this kind of attacks, whether the threat is known or not:

  • Next-Generation Firewalls with Threat Prevention licenses can block the exploits and C2 traffic with best practice configuration.
  • For tracking and protection purposes, the relevant coverage threat IDs are 59194 and 59083. Please update to the latest threat detection release.
  • WildFire can stop the malware with behavioral heuristics.
  • AutoFocus customers can track this activity with the Mirai tag.
  • The IoT Security subscription for the Next-Generation Firewall helps discover and identify IoT devices on an organization’s network.

Indicators of Compromise

Mirai Variant One






Mirai Variant Two





Mirai Variant Three




Mirai Variant Four


Malware Hosting Site





Mirai C2