In 149 seconds, a 99 KB Mirai-derived binary contacted 238,756 remote hosts. It carried exploit requests for Huawei, ThinkPHP, and Zyxel targets, and it ran from /tmp on a MIPS system. The device hosting it had stopped behaving like an appliance and started working as attack infrastructure.
That shift is difficult to prevent at the endpoint. Many cameras, televisions, building controllers, and proprietary gateways cannot run conventional endpoint agents. Their logs are limited, and their security depends on vendor support, available firmware, maintenance windows, and eventual replacement.
The network boundary does not have to share those limitations. Zero Trust Connectivity gives each device only the connections required for its role. A compromise may still execute code, but the device cannot scan arbitrary hosts, retrieve payloads, reach command infrastructure, join a DDoS attack, or probe neighboring systems unless those connections are allowed.
A 99 KB binary scanned 238,756 hosts
A March 2026 Recorded Future Sandbox analysis of jade.mpsl.elf identified the sample as EchoBot and Mirai. It was a 99 KB, statically linked MIPS little-endian ELF. During a 149-second network detonation, it contacted 238,756 remote hosts – roughly 1,600 per second across the observation window.
The destinations included TCP ports 23, 2323, 80, 8080, and 37215. Mirai used ports 23 and 2323 to recruit devices over Telnet. Ports 80 and 8080 expose the web interfaces and CGI handlers targeted by later Mirai-derived scanners. TCP 37215 is associated with the Huawei HG532 command-injection path tracked as CVE-2017-17215.
Static inspection showed that the binary was doing more than checking whether those ports were open. It contained a POST /ctrlt/DeviceUpgrade_1 request with a SOAP body that used NewStatusURL to execute BusyBox wget and retrieve a MIPS payload from 176.65.139.25. It also contained a ThinkPHP invokefunction request that called shell_exec, plus a POST /cgi-bin/ViewLog.asp request followed by a command that downloaded and ran zyxel.sh. The last request matches the Zyxel P660HN-T1A ViewLog.asp command-injection path, CVE-2017-18368.
The sandbox recorded execution from /tmp, access to /dev/watchdog and /dev/misc/watchdog, reads from /proc/net/tcp, and inspection of running processes through /proc/<pid>/exe and /proc/<pid>/fd. The process renamed itself 35a121ib2mnbeo1beeb. Those observations establish socket and process discovery, watchdog access, and a process-name change consistent with camouflage.
Mirai turned recruitment into reusable machinery
The original Mirai operation generated public IPv4 targets and probed TCP ports 23 and 2323. A hardcoded credential table supplied Telnet login attempts. Successful credentials went to separate loader infrastructure, which connected to the victim and selected a payload for its processor architecture.
When the actor known as Anna-senpai released the Mirai source code and deployment notes in 2016, the package included the bot, scanner, loader, command server, database schema, and cross-compilation workflow. A later USENIX study of the original Mirai botnet measured a peak of roughly 600,000 infected devices.
The released code made the recruitment model reusable. Each compromised device added scanning and attack capacity, while operators could replace or extend the methods used to find the next victim.
By 2017 and 2018, Mirai-derived operations were adding public remote-code-execution and command-injection flaws to the credential scanner. Satori and related variants used vulnerabilities including Huawei HG532 CVE-2017-17215 and Realtek SDK CVE-2014-8361, recruiting exposed devices through unauthenticated code execution rather than a successful login.
EchoBot showed how far that exploit catalog could grow. In 2019, Unit 42 documented 18 exploit paths in one build and later documented 71 unique paths. Its targets extended beyond home routers to cameras, NAS appliances, wireless presentation systems, enterprise management products, building controls, and industrial-edge systems.
RondoDox rotates 174 exploit paths
In March 2026, Bitsight documented 174 vulnerabilities used by the RondoDox operation between May 25, 2025, and February 16, 2026. Researchers mapped 148 to CVEs, found 15 with a public proof of concept but no assigned CVE, and identified 11 for which they could not find a public proof of concept.
The full catalog was not active at once. Bitsight saw no more than 49 vulnerabilities used on a single day, while 84 appeared for only one day. The busiest day produced about 15,000 exploitation attempts. The pattern suggests that operators add an exploit, measure its results, retain productive paths, and retire weak ones.
Trend Micro reached a related finding across its broader 2025 botnet dataset. Its analysis recorded 97 unique vulnerabilities, including 90 RondoDox exploits. Across that dataset, the average time from NVD disclosure to weaponization was 72 hours, and 80 percent of observed targets were IoT devices. Those two figures describe the broader dataset, not RondoDox alone.
RondoDox also separates exploitation from the final bot. Bitsight identified distinct exploitation and payload-hosting infrastructure. A successful vulnerability launched a shell implant that suppressed output, removed competing malware, found a writable directory, and downloaded the binary built for the victim’s processor.
One RondoDox staging script supported 18 architectures: x86_64, i686, i586, i486, armv4l, armv5l, armv6l, armv7l, powerpc, powerpc-440fp, mips, mipsel, arc700, sh4, sparc, m68k, armeb, and armbhf. Once installed, the main bot used a text-based protocol over raw TCP and supported DDoS activity. Later samples added XMRig-based cryptomining.
The delivery chain is short:
[Exploit infrastructure]
|
v
[Internet-facing target]
|
v
[Payload hosting]
|
v
[Architecture-specific RondoDox binary]
|
v
[C2, DDoS, and mining]
The scanner can run on a compromised device, as it did in the jade.mpsl.elf detonation, or remain on attacker-controlled infrastructure, as Bitsight observed with RondoDox. Both models require connections that a normal IoT device rarely needs: arbitrary scanning, shell-script retrieval, payload downloads, command and control, and traffic to attack targets.
One pipeline reaches new flaws and retired hardware
The target pool includes consumer IoT, enterprise edge systems, security platforms, and devices still online after vendor support ends.
In April 2026, FortiGuard Labs documented Nexcorium, a Mirai variant delivered through CVE-2024-3721 in TBK DVR products. The campaign used multi-architecture delivery, retained an embedded Huawei CVE-2017-17215 exploit, included Telnet brute-force behavior, and established persistence through /etc/inittab, rc.local, systemd, and cron. A current DVR flaw and a 2017 router flaw remained useful in the same operation.
Akamai observed active exploitation of CVE-2025-29635 against D-Link DIR-823X routers in March 2026. The vendor had retired the affected devices in September 2025. The campaign turned the public command-injection path into a download chain that tried wget, curl, TFTP, and ftpget before launching the Mirai payload.
The same recruitment method reaches systems outside the usual IoT category. Akamai found two Mirai campaigns exploiting CVE-2025-24016 in Wazuh weeks after disclosure. The flaw affected Wazuh manager versions 4.4.0 through 4.9.0 and was fixed in 4.9.1. A successful exploit fetched a shell script that downloaded Mirai builds for multiple architectures.
In each case, remote execution hands control to a commodity staging chain. Once the target runs a shell command, the loader can proceed whether the vulnerable product is a DVR, router, security-management server, wireless display, NAS device, or industrial gateway.
Compromised devices attack outward and inward
DDoS remains the most visible use of IoT botnets. Cloudflare’s Q4 2025 DDoS report tied the Aisuru-Kimwolf ecosystem to a record 31.4 Tbps attack and HTTP DDoS bursts exceeding 200 million requests per second. Cloudflare attributed much of the infected population to Android-based televisions.
RondoDox added cryptomining. Other IoT botnets provide proxy and relay capacity, allowing operators to originate traffic from residential or business networks whose addresses may carry a stronger reputation than conventional hosting infrastructure.
The same compromised device can also provide access to systems behind the perimeter. It may share local routes with recorders, printers, file servers, management interfaces, industrial controllers, or other embedded systems that are not exposed to the public internet.
In August 2026, Bitsight captured Aisuru operators using a proxy command to scan local networks for Android Debug Bridge services. Researchers redirected the traffic to a honeypot and observed a chain that downloaded an APK over netcat, installed it, started its service, and launched a proxy bot. On July 7, they captured the same local scanning and payload-drop method from Kimwolf. In both cases, an infected device supplied the local network access needed to reach another device.
Claroty found comparable capability in IOCONTROL. Its port-scan command accepts a starting IP, ending IP, and destination port, and the malware can execute arbitrary operating-system commands. Claroty assessed those functions as sufficient for lateral movement from a compromised Linux-based IoT or OT system.
| Direction | What the attacker gains | What the organization inherits |
|---|---|---|
| Outbound | Scanning capacity, DDoS bandwidth, mining compute, proxy traffic, C2 reach | Abuse traffic, bandwidth consumption, service instability, reputation damage |
| Inbound | A foothold behind the perimeter with access to local routes and services | Exposure of internal management planes, peer devices, and trusted network relationships |
A shared IoT VLAN reduces broadcast scope, but broad peer access can still place cameras, printers, access controllers, NVRs, smart displays, and HVAC gateways in the same trust zone. Their business roles differ. Their allowed network relationships should differ too.
Where endpoint and perimeter controls stop
A managed Linux server may run EDR. A sealed camera, television, building controller, or proprietary gateway often cannot. CPU and memory limits, package formats, operating systems, vendor support, and warranty restrictions determine whether endpoint software can be installed. Some devices expose an SSH shell and useful logs; others provide little more than a web page and a firmware file.
Perimeter controls face a separate problem. A stateful firewall enforces the policy it receives. If an IoT segment has permissive outbound access or broad east-west reach, the compromised device can make harmful connections that are allowed exactly as configured.
DNS filtering covers traffic that begins with a DNS query. The jade.mpsl.elf detonation instead connected directly to hundreds of thousands of IP addresses. There was no hostname to classify before the first packet reached each scan target.
The remaining control point is the connection itself: which destinations, peers, ports, and services should this specific device be able to reach?
Give each device a small network world
NIST SP 800-207 removes implicit trust based on network location or asset ownership. A device inside the LAN still needs policy approval for the resource and relationship it requests.
For IoT, that policy can follow the device’s function. A camera needs an assigned recorder or video-management system, DNS, time synchronization, an approved update service, and controlled administration. A printer needs print services, DNS, NTP, management, and perhaps a vendor update endpoint. A building controller needs its management platform and the field systems required for its work.
| Device role | Typical approved relationships | Connections that can remain closed |
|---|---|---|
| IP camera | Assigned NVR/VMS, DNS, NTP, approved management, approved updates | Random public IPs, Telnet destinations, peer cameras, user subnets, unrelated cloud services |
| Network printer | Print server, DNS, NTP, approved management and updates | Broad internet egress, unrelated SMB services, arbitrary peer access |
| Building controller | BMS, required field devices, time service, approved support path | User workstations, public scan targets, unrelated controllers and servers |
| Smart display or TV | Required streaming services, DNS, NTP, vendor updates | Local ADB scanning, proxy destinations, management networks |
| OT or IIoT gateway | Historian, engineering station, required controllers and sensors | General user networks, arbitrary internet destinations, unrelated production cells |
The resulting policy excludes every unneeded stage of the botnet chain. Random scan targets have no approved relationship. Telnet recruitment is outside the device’s role. Payload hosts are not vendor update services. A new C2 address is absent from the service map. DDoS victims and neighboring Android TVs are unrelated peers.
These limits remain in place while a device is fully patched, waiting for a vendor fix, or past end of life. The endpoint’s condition may change, but its permitted relationships remain tied to its function.
Direct-IP scanning meets default deny
Mirai-style scanners generate destination addresses directly, so their first packets can bypass DNS. A default-deny connection policy treats direct-IP access as an exception. Devices that genuinely require fixed-IP services receive narrow rules for those destinations; other direct-IP paths remain closed.
ADAMnetworks’ Don’t Talk To Strangers applies that model by treating DNS as a root of trust. IP connections are denied by default unless the destination was first verified through DNS and permitted by policy, or explicitly allowed through an Enabler. The rule applies to the first connection attempt, including the direct-IP scans observed in the 2026 sample.
For a camera attempting 238,756 direct-IP connections, the policy question is concrete: which of those destinations has an approved relationship with this camera?
The same test applies inside the network. The camera can reach its assigned NVR without gaining access to peer cameras, printers, televisions, workstations, or management interfaces. Each permitted connection follows the device’s role instead of its physical location on a trusted segment.
Containment lasts beyond vendor support
Unique credentials, restricted management access, supported firmware, secure boot, signed updates, asset inventory, and timely replacement reduce the chance of endpoint compromise. Connection policy limits what happens after compromise, including during patch testing, maintenance windows, and the years after a vendor stops publishing firmware.
An unpatchable camera may still run hostile code. If its policy permits only the NVR, DNS, NTP, management system, and approved update service, that code cannot use the same network paths for random scanning, payload retrieval, command and control, DDoS, proxying, or peer discovery. The device remains confined to the connections required for its job.