{
	"id": "ef3d63ee-ed66-46d7-ba00-50d39977b2be",
	"created_at": "2026-04-06T00:13:38.714365Z",
	"updated_at": "2026-04-10T13:12:19.559123Z",
	"deleted_at": null,
	"sha1_hash": "4c5949203e9e5d98a31759701d5203f419502ae4",
	"title": "Two New IoT Vulnerabilities Identified with Mirai Payloads",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 199993,
	"plain_text": "Two New IoT Vulnerabilities Identified with Mirai Payloads\r\nBy Ken Hsu, Yue Guan, Vaibhav Singhal, Qi Deng\r\nPublished: 2020-10-14 · Archived: 2026-04-05 19:41:24 UTC\r\nExecutive Summary\r\nPalo Alto Networks is proactively trying to safeguard its customers from attacks however possible. By leveraging\r\nits Next-Generation Firewall as sensors on the perimeter to detect malicious payloads and attack patterns, Unit 42\r\nresearchers are able to hunt down the menaces out there on the network, be they known or not.\r\nUnit 42 researchers have taken a closer look at four Mirai variants from two recently discovered campaigns\r\nleveraging command injection vulnerability exploits that reveal a familiar IoT attack pattern.\r\nWhile this generic approach allows researchers to observe the entire killchain and even acquire the malware\r\nbinary from the attack, this post-exploitation heuristic does have its caveat: the traffic fingerprinting. Similar\r\nservices yield similar traffic patterns because of similar, if not identical, code bases and underlying\r\nimplementation. Since a service can exist in multiple devices with different configurations and there are multiple\r\nbrands for a specific device, it’s become exponentially hard, if not impossible, to identify the susceptible device(s)\r\nin real time.\r\nThis blog includes a brief analysis of the two IoT exploits observed in the wild and the four Mirai variants\r\ndelivered during the attack. Palo Alto Networks Next-Generation Firewall customers are protected against these\r\nattacks.\r\nExploit Payloads Include Mirai Variants\r\nA total of four Mirai variants were recently discovered. Two new vulnerabilities were leveraged as attack vectors\r\nto deliver Mirai. Upon successful exploitation, the wget utility is invoked to download a shell script from the\r\nmalware infrastructure. The shell script then downloads several Mirai binaries compiled for different architectures\r\nand executes these downloaded binaries one by one.\r\nThe first exploit, shown in Figure 1, targets a command injection vulnerability in a web service with an NTP\r\nserver setting feature. The service fails to sanitize the value of the HTTP parameter NTP_SERVER, which in turn\r\nleads to arbitrary command execution.\r\nhttps://unit42.paloaltonetworks.com/iot-vulnerabilities-mirai-payloads/\r\nPage 1 of 5\n\nFigure 1. Command injection exploit over the wire\r\nFollowing the leads acquired from the attack traffic, we have narrowed our scope to some IoT devices that are\r\nknown to synchronize time through HTTP and found several vulnerable NTP-server-handling routines in firmware\r\nin some IoT devices, which is concerning since some vendors no longer support the products running said\r\nfirmware. Figure 2 shows one such vulnerable function found in a library module. While the firmware that we\r\nhave analyzed have such insecure functions, they are fortunately impervious to this specific attack because the\r\ntargeted uniform resource identifier (URI) is not present in these firmware. The identification of the affected\r\nproduct is still in progress as we proceed to analyze other IoT devices that are likely to do time synchronization\r\nthrough HTTP.\r\nFigure 2. Vulnerable code snippet in one of the firmware\r\nThe initial attack incident of the first exploit was observed on July 23, 2020, at 05:55:06 a.m. UTC. The attack\r\n(shown in Figure 1) lasted for a few weeks, with the last incident reported on Sept. 23, 2020, at 15:21:23 p.m.\r\nUTC. There were 42 unique alerts at the time of this writing.\r\nThe second exploit caught in the wild provides less context than the first exploit; the URL and the HTTP request\r\nheaders do not yield any useful insights. Evidently, there is a lack of parameter sanitization in the HTTP parameter\r\npid that results in a command injection vulnerability, as shown in Figure 3. We speculate that the targeted service\r\nis some type of remote process management tool because of similar parameter patterns in the attack traffic, and\r\nthat it’s possibly experimental and thus low in usage.\r\nFigure 3. Command injection exploit over the wire.\r\nA total of 48 unique attack incidents occurred in just 12 seconds. The attack started on Aug. 16, 2020, at 09:04:39\r\na.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.\r\nhttps://unit42.paloaltonetworks.com/iot-vulnerabilities-mirai-payloads/\r\nPage 2 of 5\n\nWe grouped the Mirai variants by numbers: one, two, three and four. The SHA256 for each of the Mirai variants\r\nare available in the Indicators of Compromise section below. Table 1 shows the delivery method as well as the\r\nembedded decryption key for each variant.\r\nDelivery Method Mirai Variant Decryption Key\r\nExploit one Variant One 0xdeadbeef\r\nExploit one Variant Two 0xdedefbba\r\nExploit two Variant Three 0xdedefbaf\r\nExploit two Variant Four 0xdeadbeef\r\nTable 1. Delivery methods and the decryption key.\r\nWhile these variants do not share the exact same origin and configuration, they all possess the necessary\r\nfunctionality to launch DDoS attacks. Variant four also possesses an infection capability that is not present in the\r\nother three variants, making it a more dangerous threat. Table 2 below summarizes the exploits that this particular\r\nMirai variant uses for infecting other vulnerable hosts. Just like its predecessors, this variant inherits exploits that\r\nwere also used in the previous variants.\r\nTable 2. Variant four’s infection capability.\r\nConclusion\r\nSecurity for IoT devices is still concerning. One major challenge for IoT security is that IoT devices that are no\r\nlonger supported are still being deployed and used. Flaws in their firmware unfortunately do not just go away with\r\nan end-of-life and end-of-support announcement. The good news is that Palo Alto Networks offers the following\r\nproducts and services to protect its customers from this kind of attacks, whether the threat is known or not:\r\nNext-Generation Firewalls with Threat Prevention licenses can block the exploits and C2 traffic with best\r\npractice configuration.\r\nFor tracking and protection purposes, the relevant coverage threat IDs are 59194 and 59083. Please update\r\nto the latest threat detection release.\r\nWildFire can stop the malware with behavioral heuristics.\r\nAutoFocus customers can track this activity with the Mirai tag.\r\nThe IoT Security subscription for the Next-Generation Firewall helps discover and identify IoT devices on\r\nan organization’s network.\r\nIndicators of Compromise\r\nMirai Variant One\r\n1b45cf0e6663aa736a2296ff753d8261032b80effcf6b0c4da2f836c2df48f2b\r\nhttps://unit42.paloaltonetworks.com/iot-vulnerabilities-mirai-payloads/\r\nPage 3 of 5\n\n96f3b93b2b4560bbcfc0dbcbcc490d6914eb674d2f745197761ec73121b2f0d9\r\nbae705d860eb190edb7512bc4c9e240b79009ba15464134c0b09e01a4d9c7853\r\n05a5d6929031deed51f2c7ee8936d1e5b82db9126f746ed5e0be28a758675844\r\n7a1a49c077c0600cec0985456c8134196c7e6a09811576896eedd20c03fca9b9\r\nMirai Variant Two\r\n3eadc091b2eafd3c6d6195f20a6755084fa35b72dba9255dbdd0421a5f89380d\r\n13a0c95b6c23a9da188533fa7bf9e438bf74096a97df8d187cecaf579f72478d\r\n94d2caf1b122583a9c3a17b24a0ed6efbc34491c79de231072989eaf938c3985\r\n99408a1a1c40a4db4cfde0f17a6791f16ca102c26ecda8f44501d03541d4b2b2\r\nMirai Variant Three\r\n34fe9ec63e0861a40dd44468fd79d8fa97df0de2b3a70a42de3c26ebfdfea14c\r\n12a1a6f1368c60452e9b0732199521b3c786356bb2cb98289abe8b0c9772940e\r\nc7b846783d8704fa22ba06208066ef4cbde8cb48e07c24fea4cdefc9ba117b3c\r\nMirai Variant Four\r\n6f2f274639439174687b6368b795a999896f20fea9b8c203e4e3af9eeba4d53a\r\nMalware Hosting Site\r\n80[.]82[.]78[.]85\r\n185[.]61[.]137[.]165\r\n78[.]142[.]18[.]20\r\n185[.]172[.]110[.]199\r\nMirai C2\r\ndotheneedfull[.]xyz\r\nxyz[.]hxarasxg[.]xyz\r\nlol[.]thezone[.]vip\r\nhttps://unit42.paloaltonetworks.com/iot-vulnerabilities-mirai-payloads/\r\nPage 4 of 5\n\nSource: https://unit42.paloaltonetworks.com/iot-vulnerabilities-mirai-payloads/\r\nhttps://unit42.paloaltonetworks.com/iot-vulnerabilities-mirai-payloads/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/iot-vulnerabilities-mirai-payloads/"
	],
	"report_names": [
		"iot-vulnerabilities-mirai-payloads"
	],
	"threat_actors": [],
	"ts_created_at": 1775434418,
	"ts_updated_at": 1775826739,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4c5949203e9e5d98a31759701d5203f419502ae4.pdf",
		"text": "https://archive.orkl.eu/4c5949203e9e5d98a31759701d5203f419502ae4.txt",
		"img": "https://archive.orkl.eu/4c5949203e9e5d98a31759701d5203f419502ae4.jpg"
	}
}