Mukashi: Zyxel NAS-Focused Mirai Variant

• Mukashi is a Mirai-derived botnet variant characterized by exploiting Zyxel NAS devices via a pre-authentication OS command injection vulnerability (CVE-2020-9054) alongside traditional Telnet brute-force methods.
• It maintains Mirai’s architectural continuity with compromised bots, integrated scanning/loader functions, and centralized command-and-control communication while specializing on the Zyxel ecosystem.
• Its design highlights a shift in IoT botnet strategies from weak credential exploitation to targeted remote code execution, emphasizing the need for robust firmware updates and network segmentation.

Mukashi is a Mirai-derived Internet of Things botnet variant first observed in March 2020. It preserves Mirai’s core architectural pattern—bots on compromised devices, loader/scanner logic embedded in the bots, and a central command-and-control server with hard-coded address/ports and a custom command set—but replaces Mirai’s original “weak Telnet credential only” emphasis with a pre-authentication OS command-injection exploit against Zyxel NAS devices. Within the Mirai lineage discussed alongside Satori, Moobot, and Sonic, Mukashi is defined by its concentration on the Zyxel NAS ecosystem and by its combination of targeted remote code execution with traditional Telnet brute forcing (Famera et al., 3 Aug 2025).

1. Mirai lineage and defining characteristics

Mukashi emerged after the 2016 leak of Mirai’s source code, an event the paper identifies as having “allowed the botnet to grow and evolve into the many variants seen today” (Famera et al., 3 Aug 2025). It was “detected … and dubbed the Mirai variant ‘Mukashi’ on March 12th, 2020” after researchers observed exploitation of a Zyxel NAS vulnerability, CVE-2020-9054. Chronologically, it appears after Satori’s original 2017 wave and before Sonic, and it is presented as one of the first Mirai variants clearly tied to the Zyxel NAS ecosystem.

At the architectural level, Mukashi remains recognizably Mirai-like. Compromised devices act as bots; scanning and loader behavior are integrated into those bots; and a central C2 server coordinates propagation and attack activity through fixed ports and explicit command verbs. This continuity matters because Mukashi is not a wholesale redesign of Mirai’s operational model. Rather, it exemplifies a transition in Mirai-derived malware from broad weak-credential harvesting toward the weaponization of specific remotely exploitable vulnerabilities.

Relative to Satori, Moobot, and Sonic, Mukashi is narrower in exploit breadth but more specialized in target selection. Satori concentrated on Realtek, Huawei, and later Iteris devices; Moobot assembled a larger multi-exploit portfolio across routers, cameras, PBX systems, and Docker-exposed services; Sonic chained vulnerabilities across multiple vendor ecosystems. Mukashi, by contrast, is centered on Zyxel NAS and adjacent Telnet-exposed IoT classes, especially DVRs and security cameras. This specialization is central to understanding both its operational efficiency and its risk profile.

2. Target ecosystem and exposed population

Mukashi is defined largely by its focus on Zyxel NAS devices. The paper states that “ZyXel is a Taiwanese manufacturer that has 100 million devices worldwide,” and further states that Mukashi “made more than a hundred million Zyxel NAS devices vulnerable through its new exploits” (Famera et al., 3 Aug 2025). The emphasis is on the scale of the exposed surface rather than on a measured botnet census.

The primary technical target is Zyxel NAS firmware affected by CVE-2020-9054, documented in the paper as including version 5.21. In addition to this HTTP-exploitable population, Mukashi also brute-forces Telnet on “Zyxel NAS products, as well as digital video recorders (DVRs), security cameras, and other similar devices.” The result is a hybrid target set: a high-value storage-appliance niche reached through a critical web vulnerability, plus a broader residual IoT population reached through credential attacks.

A common misconception is that the paper’s “100 million” figure implies a measured infection count. It does not. The paper explicitly contrasts Mukashi with Satori and Mirai, for which concrete infection figures are given, and notes that geographic distribution and exact infection counts are not quantified for Mukashi. The defensible interpretation is that Mukashi exposed an unusually large Internet-reachable population, not that it infected all or most of that population.

This device focus is significant because NAS appliances occupy a different operational role from many earlier Mirai targets. They are storage-oriented systems that may possess persistent connectivity, administrative web interfaces, and, plausibly, higher upstream bandwidth than minimal embedded devices. The paper does not quantify Mukashi-specific DDoS throughput from this target class, but it clearly frames the NAS ecosystem as a strategically important expansion of Mirai-derived botnet territory.

3. Exploitation of CVE-2020-9054

Mukashi’s defining exploit is CVE-2020-9054, characterized in the paper as a critical OS command injection and pre-authentication remote code execution vulnerability in Zyxel NAS weblogin.cgi, with CVSS 9.8 (Famera et al., 3 Aug 2025). The vulnerable CGI component handles web login, and the paper states that the username parameter “fails to properly sanitize the username parameter during authentication, allowing attackers to use special characters like ' and ; to close strings and concat commands.”

The vulnerability is notable for several reasons. First, it is pre-authentication: “pre-authentication command injection vulnerability that allows the remote execution of arbitrary code within the vulnerable device by unauthenticated attackers.” Second, the exploitation path is operationally simple: “By sending a certain HTTP POST or GET request to weblogin.cgi, remote unauthenticated attackers can execute arbitrary code on the NAS device.” Third, although the Zyxel web server itself does not run as root, the device includes a setuid utility that can be invoked after compromise to escalate commands to root.

In classification terms, the paper associates Mukashi primarily with OS command injection, improper input validation, and an insufficient privilege boundary. The first two categories derive from direct reuse of unsanitized HTTP input in command execution; the third derives from the post-exploitation leverage afforded by the setuid helper. This combination explains why a single vulnerability could support both initial access and high-privilege execution.

Compared with the exploit portfolios of Satori, Moobot, and Sonic, Mukashi’s strategy is narrower but highly concentrated. It does not rely on a large menu of independent RCE paths. Instead, it operationalizes one “very high-impact Zyxel NAS bug” against a large deployed base. A plausible implication is that operational simplicity, when paired with a large homogeneous target ecosystem, can substitute for exploit diversity in botnet propagation design.

4. Infection workflow and host-side behavior

Mukashi inherits Mirai’s basic propagation model but augments it with the Zyxel NAS exploit path. The paper states that, “Similar to Mirai, Mukashi randomly scans TCP port 23 of IoT hosts and performs brute force attacks using default and previously recorded credentials” (Famera et al., 3 Aug 2025). This scanning behavior is directed at Zyxel NAS devices, DVRs, security cameras, and related systems.

Its infection workflow has two principal paths. The first is direct exploitation of CVE-2020-9054 over HTTP: a crafted POST or GET request to weblogin.cgi injects shell commands through the malicious username parameter. The paper states that these commands typically fetch and execute the Mukashi binary or execute a shell one-liner that downloads and runs the bot. The second path is conventional Telnet brute force. For devices reachable on TCP 23, Mukashi attempts login using “default and previously recorded credentials,” consistent with Mirai-style credential attacks.

Once access is obtained, Mukashi reports compromise information to the C2-side collection channel. The paper specifies: “Once successfully connected, it sends the machine's information to the C&C server 45.84.196.75 on TCP port 34834 in the form <host ip address>:23 <username>:<password>.” This aligns Mukashi with the classic Mirai pattern in which bots identify reachable or compromised devices and forward credential data for subsequent deployment activity.

Mukashi also enforces single-instance execution and registers for command dispatch. “To evade detection, Mukashi binds to TCP port 23448 to ensure only one instance runs on the infected system.” In addition, “Once initialized, Mukashi notifies the C&C server 45.84.196.75 listening on TCP port 4864 that it is ready for a command from the C&C.” The paper further notes commands such as killallbots and killer, indicating explicit mechanisms for conflict avoidance and removal of competing malware or services.

The host-side operational footprint can therefore be summarized as follows:

Element	Value	Function
Local lock port	23448/tcp	Single-instance binding on bot
Remote report channel	34834/tcp	Credential and compromise reporting
Remote command channel	4864/tcp	Main C2 command channel

This workflow shows that Mukashi is not merely an exploit dropper. It is a full Mirai-lineage bot that integrates scanning, exploitation, reporting, command registration, and competitive exclusion into a coherent operational loop.

5. Command-and-control semantics and attack repertoire

Mukashi follows Mirai’s centralized botnet architecture with a distinct command set and “custom encryption and decryption” for commands, credentials, and attacks (Famera et al., 3 Aug 2025). The paper does not publish the cryptographic algorithm, but it is explicit that command traffic is not sent in plain decoded form. At the logical level, the botnet comprises bots on compromised devices, a C2 server at 45.84.196.75, and a loader conceptually consistent with Mirai’s separation between credential acquisition and binary deployment.

The decoded command names listed in the paper are shown below:

Command	Description
.http	HTTP flood
.tcp	Normal TCP scan
.tcpbypass	TCP scan that can bypass firewall rules
.udp	UDP flood with more options
.udpbypass	UDP scan that can bypass firewall rules
.udphex	N/A
.udpplain	UDP flood (fewer options, higher PPS)
.udprand	UDP flood with randomized port & payload
killallbots	Kill all bots under control of C2
killer	Kill specific service
[PING](https://www.emergentmind.com/topics/prefix-injection-guard-ping)	Ping flood
scanner	Scanner process/module control

This command set makes clear that Mukashi is primarily a DDoS botnet with Mirai-compatible semantics. Its attack modes span HTTP floods, TCP-oriented actions, multiple UDP flood variants, and ICMP echo flooding through PING. The inclusion of scanner indicates that propagation behavior remains actively controllable from the botnet’s control plane, while killallbots and killer show that ecosystem competition is treated as a first-class operational concern.

The paper does not provide attack-bandwidth measurements specific to Mukashi. It instead characterizes the botnet by capability and command repertoire. Accordingly, the strongest supported conclusion is not about measured throughput, but about functional parity with the Mirai-style DDoS model: Mukashi combines targeted exploitation with a conventional flood-oriented arsenal and a centrally coordinated control loop.

6. Comparative position and defensive implications

In the paper’s comparative framing, Mukashi differs from Satori, Moobot, and Sonic primarily in exploit breadth, target ecosystem, and sophistication profile (Famera et al., 3 Aug 2025). Satori used Realtek, Huawei, and Iteris vulnerabilities; Moobot assembled multiple command-injection and SQL-injection paths across Hikvision, Tenda, DrayTek, Grandstream, and WIFICAM systems; Sonic targeted SonicWall, D-Link, Yealink, ARM Trusted Firmware, Micro Focus, Netis, and Netgear, among others. Mukashi’s main exploit is CVE-2020-9054, supplemented by Telnet brute forcing. The paper’s characterization is that Mukashi is “narrow but deep”: limited in exploit diversity, but potent against a large Zyxel-centered installed base.

In sophistication terms, Mukashi sits between plain Mirai and more elaborate descendants. The paper attributes to it custom C2 encryption/decryption, single-instance enforcement via 23448/tcp, and commands for removing competing bots or services. By contrast, Moobot is described as using stronger obfuscation features such as prctl()-based process disguise and a changed PRNG seed string, while Sonic uses shell scripts, Go-based tooling, firewall manipulation, and periodic re-execution attempts. Mukashi is therefore more advanced than vanilla Mirai in exploitation strategy and bot management, but less multi-ecosystem than Moobot or Sonic.

The defensive guidance associated with Mukashi follows directly from its two infection paths. Against its Zyxel-specific exploit, the primary measure is to patch Zyxel NAS firmware so that weblogin.cgi no longer exposes CVE-2020-9054. The paper also recommends disabling unnecessary HTTP/S management interfaces from the public Internet and avoiding direct WAN exposure of weblogin.cgi or administrative panels. Against the Mirai-style Telnet path, the recommendations are to disable Telnet where possible, use SSH with key-based authentication, and replace default usernames and passwords with long, unique credentials. The paper emphasizes that “One of the easiest … ways to defend against these botnets is by changing the default username and password on IoT devices.”

Network-level detection and containment are equally central. The paper recommends monitoring for unusual Telnet activity on 23/tcp, filtering outbound connections from IoT segments to 34834 and 4864, watching for local binding of 23448, segmenting IoT networks from critical infrastructure, and deploying IDS/IPS signatures for both Mirai/Mukashi Telnet scanning patterns and Zyxel weblogin.cgi command-injection attempts. At a broader engineering level, the paper identifies recurring root causes—input validation failures, insufficient credential protections, and poorly designed setuid helpers—and recommends automatic firmware updates, proper constraint validation of user input, modular software architectures, and PKI for safe, trusted updates.

Taken together, these points place Mukashi at an important juncture in Mirai’s evolution. It retains the proven Mirai template of distributed scanning, centralized control, and flood-based attacks, but it shows how a single pre-authentication RCE in a widely deployed NAS ecosystem can be converted into a large global attack surface. That combination of architectural continuity and exploit modernization is the principal reason Mukashi remains analytically significant.