The March 2026 Takedown
In March 2026, the U.S. Department of Justice announced the seizure of command-and-control infrastructure behind one of the largest IoT botnets ever documented. The operation, coordinated with law enforcement agencies in multiple countries, disrupted a network that had enrolled over 3 million compromised devices — primarily IP cameras, DVRs, home routers, and smart home controllers — into a DDoS-for-hire platform capable of generating sustained attacks exceeding 2 Tbps.
The takedown was a significant law enforcement achievement. The C2 servers were seized. The operators were identified and indicted. The botnet's infrastructure was dismantled. For a brief period, the attack capacity available on underground DDoS-for-hire markets dropped measurably.
But here is the part that does not make the press release: those 3 million devices are still plugged in, still running the same vulnerable firmware, and still exposed to the internet with the same default credentials or unpatched vulnerabilities that got them compromised in the first place. Seizing the C2 infrastructure removes the operator's control, but it does not patch the devices. It does not change the default passwords. It does not update the firmware. Within weeks of the takedown, security researchers began observing scanning activity targeting the same device types from new infrastructure, operated by different groups looking to rebuild what was lost.
This cycle — takedown, brief disruption, rapid rebuilding — has repeated with every major botnet operation since Mirai in 2016. The devices do not get fixed. They get re-recruited.
Why Devices Get Re-Compromised
Understanding why the same devices end up in botnet after botnet requires understanding the IoT device lifecycle, which bears little resemblance to the lifecycle of a managed server or workstation.
No Automatic Updates
The vast majority of IoT devices deployed before 2024 have no automatic update mechanism. The manufacturer may release a firmware update that patches the vulnerability, but the device has no way to discover or install the update without manual intervention. The update process typically requires a user to download a firmware binary from the manufacturer's website, log into the device's web interface, navigate to the firmware update page, and upload the file. Realistically, this never happens for consumer devices and rarely happens for commercial installations.
Even devices that do support automatic updates often ship with the feature disabled by default. The user must opt in during initial setup — a step that most consumers skip entirely. The result is that a vulnerability disclosed in 2023 remains exploitable on millions of devices in 2026, three years after a patch was available.
Default Credentials
The original Mirai botnet compromised devices by trying a list of 62 default username/password combinations via Telnet. In 2026, this technique still works. Despite industry awareness campaigns, regulatory pressure, and even legislation in some jurisdictions requiring unique default passwords, the installed base of devices with factory-default credentials (admin/admin, root/root, admin/password) numbers in the hundreds of millions.
Devices installed before credential requirements took effect will remain in the field for years. A security camera mounted on a building exterior has a typical operational lifespan of 7 to 10 years. A home router might run for 5 to 8 years before replacement. These devices will carry their default credentials until they are physically decommissioned.
Manufacturer Abandonment
Many IoT devices are manufactured by companies that no longer exist, have been acquired, or have simply stopped supporting older product lines. When the manufacturer disappears, so does any prospect of firmware updates. The device is permanently frozen at whatever firmware version it last received, with whatever vulnerabilities that firmware contains. There is no entity responsible for patching it and no supply chain for delivering an update even if a patch existed.
The fundamental IoT botnet problem is not a shortage of law enforcement action or a lack of security patches. It is that the devices cannot or will not receive the patches that exist. Every takedown is temporary because the vulnerable population is permanent.
The Mirai Legacy: Aisuru and Beyond
Mirai's source code was published on HackForums in September 2016. In the eight years since, it has spawned hundreds of variants, forks, and evolved successors. The codebase has been refactored, extended, and specialized by operators around the world. Two of the most significant active successors in 2026 are the Aisuru family (also tracked as Airashi by some researchers) and the Kimwolf variants.
The Aisuru botnet, which first gained prominence in late 2024 when it was linked to record-breaking attacks exceeding 5 Tbps, represents a substantial evolution from the original Mirai codebase. It incorporates encrypted C2 communications that resist the kind of traffic analysis that helped identify Mirai C2 servers. It uses a modular architecture that allows operators to deploy new exploit modules for freshly disclosed vulnerabilities within hours of a CVE being published. And it implements anti-analysis features that detect sandbox environments and honeypots, reducing the intelligence that researchers can gather.
Kimwolf variants focus on a different niche: persistence. While Mirai (and many of its early successors) could be removed by simply rebooting the device, Kimwolf variants write themselves to non-volatile storage on devices that support it. They modify the device's startup scripts to re-establish the bot process after a reboot. On some device types, they patch the firmware update mechanism to reject legitimate updates that would remove the malware. A device infected by a persistent variant cannot be cleaned by power cycling — it requires a full firmware reflash, a process beyond the capability of most device owners.
The Most Vulnerable Device Categories
Not all IoT devices are equally susceptible to botnet recruitment. The most commonly compromised categories share several characteristics: they are network-connected, they run a Linux-based operating system, they have enough CPU and bandwidth to generate meaningful attack traffic, and they are typically deployed with minimal security configuration.
- IP cameras and DVRs: These remain the single largest category of botnet-enrolled devices. They run embedded Linux, have dedicated network connectivity, and are often deployed with default credentials on internet-facing interfaces. Many use the same handful of chipsets (HiSilicon, Novatek, Ambarella) with shared firmware vulnerabilities that affect millions of devices across dozens of brand names.
- Home and SOHO routers: Consumer routers are attractive targets because they have high bandwidth connections and are always on. Vulnerabilities in web management interfaces, UPnP implementations, and TR-069 remote management protocols provide multiple attack surfaces. Routers also offer the attacker a strategic advantage: compromising the router gives access to the entire local network behind it.
- Smart home hubs and controllers: Devices like smart home bridges, NAS appliances, and media servers run full Linux distributions with significant processing power. They are often deployed on residential broadband connections with 100 Mbps or higher upload speeds, making each compromised device a potent attack node.
- Industrial and commercial IoT: Building automation controllers, industrial sensors, digital signage players, and point-of-sale terminals increasingly appear in botnet populations. These devices are often deployed on dedicated network connections with no monitoring, making compromise difficult to detect.
The Scale Problem
Industry estimates place the total number of connected IoT devices worldwide at over 20 billion as of 2026. Of these, security researchers estimate that somewhere between 500 million and 1 billion have exploitable vulnerabilities that could enable botnet enrollment. The 3 million devices seized in the March takedown represent less than 1% of the estimated vulnerable population.
Even aggressive assumptions about the growth of secure-by-default devices do not change the math in the near term. If every IoT device manufactured starting today shipped with unique credentials, automatic updates, and hardened firmware, the installed base of vulnerable devices would still take a decade to cycle out through natural replacement. The devices deployed between 2015 and 2023 — the peak years of "ship it with default credentials and no update mechanism" — will remain a permanent botnet recruitment pool for years to come.
The capacity these devices represent is staggering. If even 5% of the estimated vulnerable population (25 million devices) were enrolled in a coordinated botnet, each contributing just 10 Mbps of attack traffic, the aggregate attack capacity would be 250 Tbps. That is more than enough to overwhelm any single target, any single scrubbing provider, and most transit networks. The 5.6 Tbps record-breaking attacks attributed to Aisuru used only a fraction of the available vulnerable device population.
What Network Operators Can Do
While individual device owners bear some responsibility for securing their devices, network operators — ISPs, hosting providers, and enterprise network teams — have both the capability and the incentive to reduce botnet activity on their networks.
BCP38 and Egress Filtering
BCP38 (RFC 2827) specifies that network operators should filter outbound traffic to ensure that packets leaving their network carry source addresses that belong to that network. This prevents compromised devices on the network from sending spoofed packets, which eliminates their usefulness as amplification attack sources. Despite being published in 2000, BCP38 adoption remains incomplete. Every network that implements egress filtering removes its subscribers from the pool of potential amplification reflectors.
Detecting Bot Traffic on Your Network
Compromised IoT devices on your network exhibit detectable behaviors. They scan for new victims (high volumes of outbound connection attempts on ports 23, 2323, 80, 8080, and 37215). They communicate with C2 infrastructure (periodic DNS lookups or connections to hard-coded IP addresses on unusual ports). And when activated for an attack, they generate large volumes of outbound UDP traffic to targets they have no legitimate reason to contact.
Network operators can deploy flow-based monitoring to detect these behaviors on their subscriber base. Anomalous outbound scanning from a residential IP, sustained outbound UDP floods from a device that normally generates minimal upstream traffic, or connections to known C2 infrastructure all indicate a compromised device that should be quarantined and the subscriber notified.
Subscriber Notification and Quarantine
When a compromised device is identified, the network operator can notify the subscriber and, in severe cases, quarantine the device's network access until the issue is resolved. Some ISPs implement automated quarantine systems that redirect HTTP traffic from compromised devices to a remediation portal with instructions for securing the device. This approach has been shown to significantly reduce the time that compromised devices remain active in botnets.
Detecting Botnet Traffic Hitting Your Infrastructure
Whether you are an ISP, a hosting provider, or an enterprise, IoT botnet traffic is a fact of life on the modern internet. Your infrastructure will be targeted. The question is whether you detect and mitigate the attacks before they cause meaningful service degradation.
IoT botnet DDoS traffic has several characteristics that aid detection. The traffic is predominantly UDP, using amplification vectors (DNS, NTP, CLDAP, memcached) or direct floods (UDP payloads with randomized content). The source addresses are widely distributed geographically, spanning residential ISPs across many countries. Packet sizes tend to be uniform within a single attack wave, reflecting the specific amplification vector or bot payload in use. And the traffic arrives suddenly, with a ramp-up period of seconds rather than the gradual increase characteristic of legitimate traffic growth.
Flowtriq's per-node detection is particularly effective against IoT botnet floods because the agent captures every packet on the host's interface and classifies it by protocol, source port, and packet size. When a botnet flood arrives, the agent detects the sudden shift in traffic composition — a spike in UDP from port 53, an increase in inbound packets from thousands of previously unseen source IPs, or a jump in packets of a specific size — and classifies the attack vector within seconds. There is no sampling loss, no polling delay, and no reliance on a central flow collector that might be overwhelmed during a large-scale event.
For network operators monitoring their own subscribers for botnet enrollment, Flowtriq's agent can be deployed on network infrastructure to baseline normal outbound traffic patterns and detect the anomalous scanning and flooding behavior that indicates a compromised device. The same dynamic baseline technology that detects inbound attacks on your servers can detect outbound attack traffic from your subscribers.
Detect botnet traffic at the host level. Flowtriq's agent classifies IoT botnet floods by protocol and vector within seconds of arrival, with no sampling loss and no polling delay. Start your free trial and see every attack as it hits your infrastructure.