A botnet DDoS attack is a distributed denial-of-service attack launched from a network of malware-infected devices that a single operator controls remotely. Routers, DVRs, cameras, and cheap Android TV boxes get hijacked, grouped into a botnet, then pointed at one target in the same second. The result is traffic no origin server survives on its own. In December 2025, the Aisuru botnet pushed 31.4 Tbps for 35 seconds, the largest flood ever disclosed publicly. This guide walks through how these attacks are built, the types you will meet, how to detect them early, and how to stop them. Start with the part most teams get wrong: some of the devices doing the flooding may be yours.

Key Takeaways

  • A botnet DDoS attack uses thousands to millions of compromised devices, coordinated through Command and Control (C2) infrastructure, to flood a target at once.
  • The record now sits at 31.4 Tbps and 14.1 billion packets per second, set by the Aisuru-Kimwolf botnet in December 2025 and mitigated by Cloudflare in 35 seconds.
  • Cloudflare blocked 47.1 million DDoS attacks in 2025, up 121% year over year, and more than 70% of HTTP floods traced back to known botnets.
  • IoT botnets grow because consumer devices ship with default credentials, rarely get patched, and sit on high-bandwidth residential links.
  • Botnet detection depends on traffic baselines: sudden request spikes, repeated TLS fingerprints, odd ASN clustering, and outbound scanning from your own hardware.
  • Modern bursts last 35 seconds, so on-demand scrubbing and manual response arrive too late. Always-on, automated filtering at the edge is the only defense that keeps pace.
  • Prevention and mitigation are separate jobs: harden devices so they are never recruited, and absorb traffic upstream so recruited devices elsewhere cannot reach your origin.

Botnet DDoS Attack vs Regular DDoS: What Actually Changes

Every botnet DDoS attack is a DDoS attack, but not every DDoS attack uses a botnet. The distinction is ownership of the attacking machines. A plain DDoS can come from rented cloud instances, open reflectors, or a handful of scripts. A botnet DDoS runs on hardware the attacker stole, which changes the economics, the geography, and the shape of the traffic.

That matters more than it sounds. Rented servers come from a few known providers, so blocking them by ASN is quick work. A botnet spreads its firepower across residential ISPs in dozens of countries, which means the packets arrive from the same networks your paying customers use. You cannot null-route Comcast.

The other shift is cost. Renting 30 Tbps of legitimate cloud capacity would cost a fortune. Renting a slice of the Aisuru botnet costs less than a decent dinner. If you are still mapping the difference between a DoS and a DDoS attack, the botnet variant is the version where the second D stops being a technicality and starts being the whole problem.

  • Source diversity: millions of residential IPs instead of a handful of datacenter ranges.
  • Attribution: the device owner is a victim, not the attacker, so takedowns get legally messy.
  • Persistence: null-routing a C2 node does not clean the infected devices, which reconnect elsewhere.
  • Cost asymmetry: roughly $38 per hour for the attacker against six-figure recovery bills for the target.

Pro Tip
Before you buy anything, pull 12 months of peak traffic from your CDN or origin logs and multiply it by 50. If your provider cannot absorb that volume without a phone call, you have bought a report, not a defense.

So who is holding the remote control, and how did they get into a stranger’s router in the first place?

How a Botnet DDoS Attack Works, From Infection to Flood

A botnet DDoS attack works in four stages: malware infects vulnerable devices, those devices register with Command and Control infrastructure, the operator issues an attack order, and every bot fires at the target simultaneously. The whole cycle from order to peak traffic takes seconds.

  1. Scan and infect. Malware sweeps IPv4 space looking for open Telnet, SSH, and HTTP admin ports, then tries a list of default credentials. Mirai shipped with 62 username-password pairs. It was enough.
  2. Enroll. The infected device resolves a hardcoded domain and reports in to a C2 server. It now waits, consuming almost no resources, which is why owners never notice.
  3. Command. The operator, or a customer renting a slice of the botnet, submits a target and a vector. Aisuru alone issued more than 200,000 attack commands according to the March 2026 Department of Justice complaint.
  4. Flood. Every bot sends traffic at once. The 31.4 Tbps peak was reached almost instantly, held for 35 seconds, and stopped before most monitoring dashboards refreshed.

The Command and Control (C2) layer

Command and Control is the botnet’s nervous system, and it is the part defenders can actually hit. Early botnets used IRC channels. Modern ones use HTTPS, DNS tunneling, peer-to-peer gossip, and residential proxy networks that make C2 traffic look like someone streaming video.

Lumen’s Black Lotus Labs null-routed close to 1,000 Aisuru and Kimwolf C2 servers, and the botnets kept working. Kimwolf still averaged over 150,000 daily victims in early March 2026. Decapitating C2 slows a botnet down. It does not kill it. The infected devices simply keep hunting for a new controller, and they have nothing else to do.

Why IoT botnets grow faster than anyone patches

IoT botnets scale because the supply of vulnerable hardware is effectively infinite. Kimwolf conscripted more than 2 million Android devices, mostly off-brand smart TVs and set-top boxes that no vendor will ever update. Add DVRs, webcams and Wi-Fi routers, and the four linked botnets crossed 3 million devices by March 2026.

Each Android TV box contributes maybe a fraction of a gigabit. That sounds harmless until you multiply it by two million. Your home router is not a threat. Two million home routers on fiber connections are a national infrastructure problem, and every unmanaged device you own expands somebody’s attack surface, including your own.

Knowing the machinery is one thing. Recognizing which flavor is hitting your edge at 3 a.m. is another.

Botnet DDoS Attack Types You Will Actually Face

Botnet DDoS attack types fall into four groups: volumetric floods that saturate bandwidth, protocol attacks that exhaust connection state, application-layer floods that mimic real users, and multi-vector campaigns that run all three at once.

Botnet DDoS Attack Types

Type Measured in Typical vectors What breaks first Where you stop it
Volumetric Tbps / pps UDP, DNS, NTP floods Uplink and ISP Distributed edge
Protocol pps / connections SYN, ACK, fragmented packets Firewall state L4 filtering
Application (L7) rps HTTP floods, login abuse App and database WAF, rate limits
Multi-vector L3/L4/L7 Mixed attack vectors Response process Automated mitigation

The numbers behind these categories moved fast. Layer 3 and 4 attacks made up 71% of Cloudflare’s Q3 2025 traffic, and attacks above 100 million packets per second grew 600% year over year. Meanwhile, Layer 7 attacks rose 74% year over year in Q2 2025, because as network defenses improve, attackers climb the stack.

Carpet bombing deserves a mention on its own. Rather than hammering one IP, Aisuru’s 31.4 Tbps run sprayed roughly 15,000 destination ports per second across a whole prefix. Each IP stayed under the detection threshold. The combined traffic still melted the pipe. It is the DDoS equivalent of shoplifting one item from a thousand stores instead of robbing a bank.

A volumetric DDoS attack is the loudest of the four, and it is also the one on-premise hardware can never win, because the fight is already lost at your uplink before a single packet reaches your rack.

Organizations relying on on-premise mitigation appliances or on-demand scrubbing centers may benefit from re-evaluating their defense strategy. Cloudflare, Q4 2025 DDoS Threat Report

These are not hypotheticals. Two botnets in particular rewrote the rules, ten years apart.

Mirai to Aisuru: What a Decade of IoT Botnets Taught Defenders

Mirai and Aisuru bracket the modern history of botnet DDoS. Mirai proved in 2016 that cheap cameras could take down half the internet’s DNS. Aisuru proved in 2025 that nobody learned the lesson, and that the ceiling had moved by an order of magnitude.

Mirai, 2016: the proof of concept nobody wanted

Mirai scanned for IoT devices using factory-default logins and built an army out of DVRs and IP cameras. It hit Krebs on Security at 620 Gbps, then took Dyn’s DNS offline in October 2016, which dragged Twitter, Reddit, Netflix and Spotify down with it. The source code leaked weeks later, and that leak is the reason we are still here. Aisuru is Mirai’s descendant, built on the same bones.

Aisuru: industrial scale

Aisuru appeared around August 2024 and became the apex botnet of 2025. The escalation timeline is the part worth reading twice: 3.8 Tbps in October 2024, 5.6 Tbps that quarter, 7.3 Tbps in mid 2025, 15.72 Tbps against Microsoft Azure in October 2025 from over 500,000 source IPs, then 31.4 Tbps in December 2025. That is more than 700% growth in roughly 14 months, and each record stood for weeks rather than years.

The collateral damage is the underrated detail. Brian Krebs reported that US ISPs saw widespread congestion from Aisuru traffic even when they were not the target. When a botnet is large enough, being nobody’s target stops being a defense.

In March 2026, the US Justice Department, working with Canadian and German authorities, seized C2 infrastructure for Aisuru, KimWolf, JackSkid and Mossad. Krebs traced one operator to a 23-year-old in Ottawa and named a 15-year-old in Germany as the other prime suspect. Three million devices, and the charging documents name a 23-year-old and a teenager.

You might be thinking that takedowns solve this. They do not. Within weeks of the seizures, Kimwolf and JackSkid were still averaging six figures of daily victims, because the infected devices were never cleaned. History says the next botnet inherits the same hardware.

Which raises the practical question: how would you even know it was your turn?

Botnet Detection: How to Tell You Are Under Attack

Botnet detection starts with a traffic baseline. Without one, every spike looks like either a marketing win or an outage, and you waste the first ten minutes arguing about which. With one, an attack announces itself as traffic that is too uniform, too sudden, and too indifferent to your funnel.

Botnet Detection

Real traffic is messy. It arrives from varied browsers, browses several pages, and follows a daily rhythm. Botnet traffic is the opposite: it is clean, repetitive, and arrives everywhere at once. That uniformity is the tell.

  • Request rate jumps 20x in under 60 seconds with no campaign, launch, or press hit behind it.
  • Traffic concentrates on one endpoint, often a login page, search route, or an uncached API.
  • Source IPs cluster on ASNs you have never sold to, or on residential ranges in countries with no customers.
  • TLS and JA3 fingerprints repeat across thousands of distinct IPs, which real browser diversity never produces.
  • Server metrics diverge: CPU and connection counts spike while conversions and session depth flatline.
  • Your uplink saturates before your application even reports load, which points to Layer 3 or 4 rather than Layer 7.

One media client we reviewed spent 40 minutes celebrating a 900% traffic surge before anyone checked the bounce rate. It was 99.8%. The whole surge was a single URL, requested by 14,000 IPs across 31 countries, all with identical user agents. Congratulations were premature.

Speed of detection sets your ceiling on everything else. If a burst lasts 35 seconds and your alert threshold is a five-minute rolling average, your dashboard will tell you about a war that already ended. Detection has to be automated and inline, which is where the standard DDoS mitigation techniques stop being theory and start being architecture.

There is a second, more awkward question hiding here. What if the traffic is leaving your network rather than arriving?

Is Your Network Part of a Botnet? Signs You Are the Attacker

Yes, your own devices can be conscripted, and most organizations find out from an abuse complaint rather than a dashboard. Hundreds of thousands of the three million devices seized in the March 2026 operation sat in the United States, inside homes and offices whose owners had no idea.

The giveaways are outbound, not inbound. An IP camera that suddenly talks to 400 foreign hosts is not doing its job. Neither is a printer resolving a domain generated by an algorithm.

  • Unexplained outbound scanning on ports 23, 2323, 22, 80, and 7547 from IoT or OT hardware.
  • Devices resolving high-entropy domains, or holding long-lived encrypted sessions to unknown endpoints.
  • Upstream bandwidth consistently above downstream on segments that should only receive.
  • Abuse reports, blocklist entries, or ISP notices naming your egress IPs.
  • Devices that reboot themselves, run hot, or lose config after a firmware reset, which suggests a fight over control.

The fix is segmentation before it is anything else. IoT and OT devices belong on their own VLAN with egress filtering that permits only what the device provably needs. A camera does not need to reach the open internet. Most network security solutions can enforce that in an afternoon, and it is the single highest-return change on this list.

Pushing inspection and policy out to the perimeter is what modern edge security is for, because inspecting a compromised device’s traffic after it has already crossed your core is inspection at the wrong end of the problem.

Pro Tip
Block outbound Telnet at the firewall today and log every attempt for a week. Anything that tries to speak Telnet in 2026 is either a forgotten piece of hardware or already infected. Both need your attention, and the log tells you which devices to investigate first.

Cleaning your own house is prevention. Surviving somebody else’s botnet is a different discipline entirely.

Botnet Mitigation: Stopping a Live Attack in Seconds, Not Minutes

Botnet mitigation works by absorbing and filtering traffic upstream, across a distributed network, before it ever reaches your origin. An effective DDoS attack protection strategy relies on always-on edge filtering, automated detection, and distributed traffic scrubbing because anything that requires a human to notice, decide, and act is already too slow for a 35-second burst.

Layered Botnet Mitigation

The first layer is geography. An Anycast network advertises the same IP from every point of presence, so a flood from Brazil lands in Brazil instead of traveling to your rack in Mumbai. The botnet’s distribution, its greatest strength, becomes the mechanism that divides it.

The second layer is transport filtering. SYN floods, ACK floods, and UDP carpet bombing are packet problems, not application problems, and they need to be dropped before a connection is ever established. Purpose-built transport-layer filtering, such as an L4 Shield, forwards only clean TCP and UDP traffic to your infrastructure.

The third layer is throttling. Well-tuned rate limiting caps how many requests any single source can send in a window, which blunts the long tail of small, persistent floods that never make a threat report. Since 94.4% of web DDoS attacks stay under 100,000 requests per second, this layer handles most of what you will actually see.

  • Detect inline, at the edge, with automated thresholds rather than dashboards a human watches.
  • Divert nothing. Always-on beats on-demand, because BGP diversion costs minutes you do not have.
  • Drop spoofed, malformed, and amplification-shaped packets at Layer 3 and 4 first, so Layer 7 inspection is not wasted on garbage.
  • Challenge or score what is left: JA3 fingerprints, header order, and behavioral signals separate bots from browsers.
  • Keep the origin invisible. If attackers can resolve your origin IP, every layer above becomes optional for them.

Yes, on-premise appliances still have a role, but not this one. A scrubbing box behind a 10 Gbps uplink cannot filter a 4 Tbps average burst, because the uplink dies first and the box never sees a packet. Conventional wisdom says defense in depth means hardware at the perimeter. For volumetric botnet traffic, depth means distance, and the only useful perimeter is one hop from the attacker, not one hop from you.

None of that helps if you buy the wrong contract, which is where most of these projects quietly fail.

Botnet Prevention and Choosing DDoS Protection That Survives 30 Tbps

Botnet prevention and DDoS protection answer two separate questions. Prevention stops your devices from joining a botnet. Protection stops somebody else’s botnet from reaching your users. You need both, and the second one is a purchasing decision as much as a technical one.

Prevention: the boring checklist that works

  • Change default credentials on every device with an IP address, including the ones procurement forgot about.
  • Disable Telnet, UPnP, and remote admin interfaces unless a documented process needs them.
  • Patch firmware on a schedule, and retire hardware whose vendor has stopped shipping updates. Unsupported means recruitable.
  • Segment IoT and OT onto isolated VLANs with strict egress rules.
  • Inventory ruthlessly. You cannot patch the smart TV in the boardroom that nobody logged.

Protection: what to compare before you sign

Capability Why it decides the outcome Question to ask the vendor
Always-on vs on-demand 35-second bursts end before diversion What is your measured time to mitigation?
Network capacity Hyper-volumetric attacks reach Tbps scale What is your total capacity and PoP headroom?
Anycast footprint Distribution splits attack traffic How many PoPs do you operate near users?
L3, L4 and L7 coverage Multi-vector attacks change layers One policy engine or multiple vendors?
Automation Manual response is too slow What triggers mitigation automatically?
Collateral tolerance Carpet bombing bypasses IP limits Do you detect by prefix or IP?

A serious edge platform folds an advanced web application firewall into the same policy path that handles volumetric filtering, so Layer 7 scoring inherits the same intelligence that dropped the packet floods. Splitting those across vendors sounds like healthy redundancy and behaves like a gap.

Capacity planning is the other half. Intelligent load balancing across pools and zones means no single origin absorbs a surge, and health checks pull a struggling node before it takes the cluster with it. That is not DDoS defense on its own. It is what keeps the residual traffic that gets through from finishing the job.

One fintech platform we worked through this with had solid Layer 7 rules and a 10 Gbps scrubbing appliance. Their first real botnet event never reached Layer 7. The uplink saturated in under 20 seconds, the appliance went dark with the rest of the rack, and the WAF rules they had spent six months tuning inspected exactly zero malicious requests. The lesson was cheap only because the attack was short.

The Bottom Line on Botnet DDoS Defense

The defining fact about modern botnet DDoS attacks is speed, not size. A 31.4 Tbps headline is easy to fixate on, but the attack that takes you offline will probably be a two-minute burst from a rented slice of somebody’s IoT army, aimed at the one endpoint you never cached. Size is a capacity problem, and capacity can be bought. Speed is an architecture problem, and you have to settle architecture before the traffic shows up.

Treat prevention and protection as two budgets. Harden and segment your own devices so they never become somebody’s ammunition, and put automated, always-on filtering upstream so the ammunition aimed at you never lands. Then measure the thing that matters: not whether you can survive the record attack, but how many seconds pass between the first malicious packet and the last one you drop.

Start with a traffic baseline and an honest device inventory. Everything else on this page is easier once you know what normal looks like and what you actually own.

Frequently Asked Questions About Botnet DDoS Defense

How many devices does a botnet DDoS attack need?

There is no minimum. A few thousand devices can exhaust an unprotected origin server, while the Aisuru-Kimwolf botnet operated between 1 and 4 million devices and reached 31.4 Tbps. Device count matters less than aggregate bandwidth and packet rate. A thousand fiber-connected devices outgun a hundred thousand on slow links.

Can a firewall stop a botnet DDoS attack?

A firewall alone cannot stop a volumetric botnet attack. Traffic saturates your uplink before it reaches the firewall, and stateful firewalls are themselves vulnerable to SYN floods that exhaust their connection tables. Firewalls handle policy enforcement well. Absorbing terabits of hostile traffic requires distributed, upstream mitigation.

How do I know if my device is part of a botnet?

Watch outbound behavior. Signs include unexplained upstream bandwidth, connections to unfamiliar foreign hosts, scanning activity on Telnet and SSH ports, devices running hot or rebooting on their own, and abuse notices from your ISP. On IoT hardware, a factory reset plus a firmware update removes most Mirai-class malware, though reinfection takes minutes if the default password goes back on.

Is botnet detection possible before an attack starts?

Partially. You cannot see another organization’s infected devices, but you can see reconnaissance against your own infrastructure, low-volume probing that maps your endpoints, and threat intelligence feeds listing known C2 nodes and botnet source ranges. On your own network, egress monitoring catches recruitment before your devices are ever used in an attack.