Nearly ten years after its source code was leaked, Mirai’s methodology is still working largely unchanged. The original botnet scanned the Internet for devices running default credentials and unpatched services, then weaponized them at scale. Its descendants do the same thing against the same device categories: consumer routers, DVRs, and IP cameras. What has changed is the size of the target population, not the sophistication of the attack.
Executive Summary
- Aisuru’s command-and-control (C2) infrastructure was substantially disrupted. Only 9% of reported C2 IPs remained active after the March 2026 takedown, but reported infrastructure more than doubled against its pre-takedown baseline within four months.
- Kimwolf was assessed as no longer active following the same operation, yet Nokia’s Deepfield team reports it fragmented into more than 20 competing botnets while daily active DDoS endpoints rose from roughly 1 million to 8–9 million.
- Internet-exposed Android Debug Bridge services (Kimwolf’s primary target) dropped immediately after the takedown and have since returned to roughly the level observed a year earlier. Over 90% sit on ADB’s default ports.
- Over 500,000 hosts still report running Boa, an HTTP server discontinued in 2005. Roughly 19,900 also present a Realtek certificate, consistent with Microsoft’s finding that Boa reaches finished products through chip-level SDKs.
- Consumers generally cannot remediate these components themselves. Consumer IoT firmware ships as a signed, monolithic image, so a vulnerability in an SDK component can only be fixed in a vendor release — and for end-of-life products, that release never comes.
Mirai’s Origins
The mid-2010s were the height of Minecraft’s multiplayer server economy: giant gaming servers where players could play custom minigames together that generated substantial revenue. One common issue within these servers was lag, which peaked during prime game times. Players would often make this worse by intentionally targeting game servers to increase lag for opposing teams to better their chances of winning. In response, two individuals, Paras Jha and Josiah White, co-founded ProTraf Solutions, a Minecraft server “DDoS mitigation” company that advertised itself as a defender against this type of malicious traffic.
However, the business model was inverted from the start. Rather than defending servers from lag, ProTraf intentionally generated DDoS attacks it then offered to stop, and rented attack time to others. To better their business, ProTraf brought in a third collaborator, Dalton Norman, to help build and run the botnet behind the scheme. Wired later described the dynamic as a “mafia-protection racket.” The botnet built to generate these DDoS campaigns, written in 2016, was Mirai. Mirai spreads by scanning for Internet-facing IoT devices and brute-forcing default credentials. Once its source code was published online, it became a template that countless other attackers copied and adapted, making it one of the most widely forked botnet families the Internet has seen.
Timeline
| July 2016 | Mirai originally developed in-house at ProTraf Solutions. Attacked rival Minecraft hosting servers to upsell victims on mitigation services. |
| September 2016 | Mirai owners DDoSed Krebs on Security after Brian Krebs began reporting on the booter/DDoS-for-hire scene. The attack (~620 Gbps at the time) knocked Krebs’ site offline entirely, grabbing the attention of defenders across the world. |
| October 1, 2016 | Mirai source code was publicly released on Hackforums by a user named “Anna-Senpai” (later confirmed to be one of the creators). |
| October 2016 | An unidentified actor used the leaked Mirai code to hit Dyn, a major DNS provider with an estimated ~1 Tbps of traffic: one of the largest DDoS attacks recorded at the time. The takedown of DNS resolution resulted in major platforms such as Amazon, Twitter, Netflix, Reddit, PayPal, GitHub, and Spotify going down, which caused Mirai to be headlines across global news. |
| November 2016 | Mirai worm was used to attack Deutsche Telekom, taking over 900,000 Deutsche Telekom customers offline in Germany. |
| December 2016 to January 2017 | FBI investigation traced the original malware back to Jha, White, and Norman. All three eventually pled guilty (2017/2018) to CFAA violations. The creators of Mirai agreed to cooperate with FBI/researchers on IoT security and botnet takedowns in exchange for a reduction in sentencing. |
| Ongoing / Present Day | Because the source was leaked, Mirai spawned dozens of variants (Satori, Okiru, Masuta, Reaper, etc.) run by unrelated threat actors. Per Cloudflare’s Q1 2025 DDoS threat report, Mirai-based traffic ranked as the 3rd most common network-layer DDoS attack type that quarter, behind SYN floods and DNS floods.  (Source: Cloudflare) IoT default-credential exposure hasn’t gone away. It is a persistent, low-effort attack surface widely exploited today. |
The Current State of IoT Device Regulation In the U.S.
Nearly 10 years have passed since the original Mirai botnet’s source code was released to the public on Hackforums in late September 2016, resulting in an unprecedented rise in copycat DDoS attacks. In August 2017, a few months before Mirai’s creators were identified and charged, U.S. Senators introduced The Internet of Things Cybersecurity Improvement Act of 2017, a bill aimed at setting minimum cybersecurity standards for government-purchased IoT devices. Though that bill ultimately stalled and never passed, it helped lay the groundwork for the Internet of Things Cybersecurity Improvement Act of 2020, which was signed into law and established new cybersecurity standards for government-purchased IoT devices. Additionally, the FCC has more recently introduced an IoT cybersecurity labeling program under Title 47 of the U.S. Code of Federal Regulations, though participation and compliance remain optional for manufacturers.
Where the Vulnerabilities Originate
Although regulatory frameworks for IoT devices exist, and U.S. states’ legislative acts have introduced specific requirements, coverage remains inconsistent and leaves manufacturers considerable discretion over security implementation. This regulatory gap rests on an implicit assumption that both manufacturers and users will independently prioritize security. Thus, IoT manufacturers and users are largely responsible for their own IoT device security.
Mirai primarily targets IoT devices with exploitable default credentials and services. Although it originally exploited home routers, DVRs, and other low-level devices, its methodology — scanning the Internet for devices running outdated or unmanaged software — introduced a blueprint that other botnets have since followed. Because Mirai’s source code was leaked publicly, several botnets emerged using that same codebase with slight alterations to targets and entry points, becoming known as “heirs” of Mirai. Other malware families, such as BotenaGo, are not built from Mirai’s source code but follow the same underlying methodology and have been linked operationally to Mirai infrastructure, underscoring how durable this attack pattern has become. What makes this attack surface so persistent, however, is not just botnet code reuse, but where the underlying vulnerabilities originate in the first place: the manufacturing process itself.
Within IoT device production, it’s common to use chips and parts with pre-made SDK systems. An SDK (software development kit) is a bundle of drivers, libraries, and configuration tools that a chip or hardware manufacturer provides so downstream companies can build products on top of that hardware without writing everything from scratch. When factory products ship, they often retain this base SDK as a foundation for configuration, which companies then overlay with their own software and brand. Though unintentional, companies can accidentally stack their software on top of these systems without applying updates or patches to the underlying layer. This is precisely where the regulatory gap described earlier becomes concrete. The assumption that manufacturers will prioritize security features only holds if someone within that supply chain actually takes ownership of the SDK layer, and frequently no one clearly does. The result is a supply chain weakness that can reintroduce known vulnerabilities across an entire product line. Companies that fail to audit and update these base systems inherit that risk regardless of how secure their own code may be.
Boa, an open-source HTTP web server discontinued in 2005, is a clear case study of this exact failure. Mirai and its heirs are not limited to any single vulnerable component; rather, they exploit whatever outdated or misconfigured software happens to be exposed on a device, and Boa’s persistence shows how deep that exposure can run. As of July 2026, over 500,000 hosts still run a Boa webserver, a figure that on its own underscores how deeply embedded this discontinued software has become in production hardware despite being retired. Narrowing that search to hosts where Boa co-occurs with a Realtek-issued certificate returns over 19,900 hosts, which is consistent with Microsoft’s 2022 finding that Boa is often introduced through chip-level SDKs, such as those from Realtek. These hardware components are commonly used in routers, access points, and repeaters. Even so, Boa’s presence is not limited to these devices. Over 82,000 hosts expose a WiFi-connected camera running a Boa web server, indicating that this discontinued software’s reach extends well beyond network equipment into other IoT device categories entirely.
Because the vulnerability is introduced at the chip and SDK level rather than the finished product, downstream device manufacturers may not be aware their products run Boa (or other vulnerable SDKs) and firmware updates may fail to address it, under the assumption that the underlying layer has already been secured. Despite repeated exploitation, many device manufacturers and operators still fail to patch or replace outdated software and hardware, leaving thousands of devices exposed with end-of-life software.
Past the production line, it falls on consumers to ensure underlying components are being secured via firmware. Under such circumstances, consumers are often left vulnerable and dependent on a system’s update cycle. If a company neglects its firmware maintenance, consumers are forced to become unwilling participants for hosting insecure software and can only rectify the situation by purchasing a new system.
Although a gradual transition away from Boa has been observed within the last few years, the service still retains a significant footprint on the Internet, leaving many devices vulnerable to botnet exploits and Mirai heirs.
Historical snapshot of Boa Host count in Censys’ Database.
The Variants That Never Die
Mirai publicized a methodology on how insecure, exposed IoT devices can be weaponized at scale, with Mirai heirs like Aisuru pushing that approach to new extremes. First identified in 2024, Aisuru is a Mirai-derived botnet that compromises routers, DVRs, and other IoT devices by continuously researching and exploiting new firmware vulnerabilities. Kimwolf, a botnet first showing signs of activity in October 2025 and profiled by KrebsOnSecurity, is an Android-focused variant of Aisuru that spreads through compromised residential proxy networks to reach and exploit exposed Android Debug Bridge (ADB) services on internal devices. Record-breaking attacks from both botnets drew global attention in late 2025. Despite making world headlines, the underlying infrastructure powering these botnets still exists today.
The frustrating reality is that the parties best positioned to reduce this infrastructure are rarely the ones under pressure to do it or have limited mitigation tactics. Defenders can identify exposed devices, but they cannot patch the SDK components inherited from hardware. Manufacturers have limited incentive to revisit SDK components once a chip is adaptable across product lines, and consumers have limited ability to self-configure devices. However, one exception is the government, which holds the legal authority and resources to act on national infrastructure security in ways individual manufacturers or consumers cannot.
On March 19th, 2026, the U.S. Justice Department issued a press release announcing the takedown of C2 infrastructures for Kimwolf, Aisuru, and other botnets. Additionally, on May 21st, 2026, the FBI announced the arrest of a Canadian man charged with administering the Kimwolf DDoS botnet.
Government takedowns clearly disrupt botnet structure, but disruption and elimination are not the same thing. When observing the after effects of this government takedown, researchers observed an immediate drop in active infrastructure. Yet, neither botnet’s underlying capacity actually disappeared.
Aisuru’s Rapid Recovery and Growth
When analyzing the persistence of known Aisuru C2 servers reported on ThreatFox, a public threat-intelligence database, 9% of reported C2 IPs persisted past the FBI’s March 2026 takedown. Although the takedown produced an immediate reduction in active Aisuru C2 servers, within four months the total infrastructure of known Aisuru servers had more than doubled relative to its pre-takedown size.
Note that ThreatFox is a public, community-submitted dataset, so this figure should be read directionally rather than as a precise count. Public feeds are susceptible to false positives and detection bias, and growth in reported infrastructure isn’t identical to growth in actual infrastructure.
Still, this pattern is consistent with independent reporting on Aisuru’s growth. So long as the botnet has access to a pool of unpatched devices to recruit, it will continue to be a public threat. If the exploitable vulnerabilities that built a botnet in the first place are never addressed at the source, its infrastructure may regenerate, and potentially exceed, its original size once enforcement pressure lifts.
Kimwolf’s Persistent Infrastructure
Kimwolf’s outcome looks different on the surface, but tells a similar story underneath. Nokia’s Deepfield team, which participated directly in the March 2026 takedown, reported that the record-breaking attacks that defined Kimwolf at its peak have slowed. Even so, the threat did not die, but rather metastasized. Kimwolf fragmented into more than 20 competing botnets, and the number of DDoS active daily endpoints climbed from roughly 1 million to 8–9 million over the same period. The takedown also altered the botnet’s geography rather than its size, with Brazil replacing a significant portion of the disrupted U.S. traffic according to Nokia. Summarizing their overall findings, Nokia reports that the size of residential proxy networks has remained largely unchanged. They found that the disrupted proxy command-and-control servers migrated to other infrastructure and were back to pre-takedown levels within weeks.
This story is reflected in Censys Internet scan data tracking exposed Android Debug Bridge (ADB) services over the past year. Kimwolf specifically targets devices exposing ADB on its default ports, 5555 or 5037, which makes those ports a useful lens for measuring the botnet’s available attack surface. Most ADB systems were never designed to be exposed in the open Internet, and devices that retain manufacturer-default credentials after being exposed become immediate targets for Kimwolf’s scanners.
Over 90% of ADB services observed by Censys were running on these default ports. It’s worth noting that reachability alone does not confirm whether authentication is disabled on each device.
Tracking the size of this exposed population over the past year shows a gradual increase, followed by a steep decline of over 500 hosts immediately after the March 2026 takedown. In recent months, however, the total number of exposed devices has returned to nearly the same level it was at a year before the takedown.
The Cyber Education Problem
It’s worth pausing on how unsophisticated most Mirai heir attacks actually are. Although some botnets take more advanced approaches, most of Mirai and its heirs rely on simple credential spraying and dictionary attacks — probing random IP ranges and brute-forcing entry with default or commonly reused credentials. In theory, this approach should have limited returns. In practice, it continues to work at scale, largely because of the security habits of the people operating these devices, not the sophistication of the malware itself.
Among cybersecurity practitioners, leaving a router on its default credentials reads as an obvious mistake. But most of the general public isn’t trained on what a router does or how to configure one, and manufacturers often market these devices as “plug and play,” reinforcing the assumption that a working connection means a secure one. Genuine security hygiene requires changing default credentials and configurations at setup, but many users never do, either because they don’t know how, or because a functioning Internet connection feels like confirmation that nothing needs to change. Additionally, maintenance adds to the problem. It is not unusual for users to be frequently behind on updates, leaving routers running unpatched or end-of-life software. Even when routers are compromised, users often have no way of noticing unless it affects their Internet connection.
The result is a large, persistently exploitable population of devices. GPON routers are a clear illustration of how visible that population can be. The acronym GPON stands for Gigabit Passive Optical Network which is “fiber access technology for delivering gigabit Internet services to residential and business subscribers” as described by Calix. GPON routers are not inherently less secure than other router types, though they have been targeted by Mirai and related botnets due to known vulnerabilities in their firmware. What makes them a useful case study is visibility: because GPON login interfaces use a distinctive name and interface, they’re easy to identify at scale. Over 120,000 GPON hardware vendor web services are currently visible on the open web.
What’s concerning is that Censys observed 117,000 of these exposing GPON Home Gateway login pages, many bearing default HTML titles (“GPON Home Gateway”) that are associated with a model commonly deployed in residential networks. These login portals exist so new users can configure a router upon first connecting and are not meant to remain reachable from the public Internet after setup.
Such a high volume suggests that a large share of users are leaving their routers on factory-default settings or failing to restrict access to the login page after setup. When a router is left on default credentials and publicly reachable, anyone, including automated botnet scanners, can locate its login page and authenticate using nothing more than the manufacturer’s default username and password. This figure suggests that non-enterprise environments make up the population most exposed to these login-page misconfigurations.
Router misconfiguration is only part of the picture; internal network exposure is another. Many IoT devices ship with UPnP (Universal Plug and Play) enabled by default, a protocol that lets devices on the same local network automatically discover each other and open router ports without manual configuration. UPnP was designed to operate within a trusted local network, not across the open internet. When an internet-exposed device also has UPnP enabled, that design assumption breaks: if the device is compromised, an attacker can use its automatically opened ports to pivot into the rest of the internal network. For this reason, UPnP should generally be disabled on any low-level smart device with internet exposure; left enabled, it functions as a bridge that lets a single compromised device expose an entire home network.
Despite this, over 17,000 internet-facing IoT devices have UPnP enabled across the Internet.
Defenders have tools to mitigate individual misconfigurations, but the scale of these exposures points to something larger than a technical gap. Botnets built on credential spraying and default configurations succeed in large part because of a persistent education gap between what “secure setup” requires and what the average consumer is able to do. Until that gap narrows, through manufacturer defaults, consumer education, or both, the growing computing power of everyday routers and IoT devices will keep expanding what these botnets have to work with.
Conclusion
Despite being over a decade old, Mirai persists today not because of technical sophistication, but because of the structural neglect it originally exploited. Mirai’s persistence is not primarily a story about malware. What sustains it is a steady supply of vulnerable devices, replenished from three directions. The first is manufacturers who ship simplified SDK components with no security caveats attached. The second is producers who fail to audit for these security flaws across the assembly line. The third is unknowing consumers who fail to update firmware, monitor security configurations, and maintain end-of-life systems, prioritizing functionality over security.
The 2026 takedowns tested what happens when pressure lands on these botnet infrastructure systems. Although the botnets were disrupted, their infrastructure was able to rapidly regenerate.
Until these foundational weak points are remediated, it’s likely that Mirai and its heirs will remain a security threat for years to come.
