In November 2025, Cloudflare automatically detected and absorbed a DDoS attack that peaked at 31.4 terabits per second. It lasted 35 seconds. When Cloudflare published the technical detail behind it in early February, the number that stood out wasn’t the peak bandwidth — it was what the botnet was actually made of.
What happened
The attack, attributed to a botnet tracked as AISURU (also referenced as Kimwolf), briefly became the largest publicly recorded DDoS attack in history, more than 700% larger than the biggest attacks reported just a year earlier. It wasn’t a one-off: the same botnet was linked to a follow-on campaign starting December 19, 2025 — internally nicknamed “The Night Before Christmas” — that sustained average rates around 4 Tbps and 54 million requests per second for an extended run, with peaks reaching 24 Tbps and 205 million requests per second.
How it worked
What makes AISURU/Kimwolf notable isn’t novel exploitation technique — it’s composition and scale. The botnet is built from more than 2 million compromised devices, the large majority of them cheap, off-brand Android TV boxes: the kind of streaming hardware that ships once, gets plugged into a home network, and then receives no further security attention for years. That combination — always-online, rarely patched, effectively unmonitored by anyone — is close to ideal botnet material.
The attacks themselves blended hyper-volumetric HTTP floods with network-layer assaults, aimed squarely at exhausting bandwidth and saturating the routers, switches, and firewalls sitting in front of a target rather than attacking application logic. And the botnet didn’t route its attack traffic directly — it tunneled through residential proxy networks, most notably one called IPIDEA, which let attack traffic blend in with what looks like ordinary residential internet traffic rather than obviously-hostile hosting-provider IP ranges. Google’s response included legal action against the proxy infrastructure itself, working with Cloudflare to disrupt IPIDEA’s domain resolution — going after the laundering layer, not just the botnet.
Why it matters beyond one attack
A few things about this attack describe where volumetric DDoS is heading, not just where it’s been:
- The baseline has moved. Attack sizes that would have been headline news two years ago — a few hundred Gbps, even 1 Tbps — are now routine background noise. The plausible ceiling for a single attack has grown roughly 8x in about a year.
- The device pool is expanding into categories with weaker security norms. Traditional botnet targets (routers, DVRs, webcams) already have poor patch hygiene. Consumer streaming devices are an even larger, faster-growing category with the same problem and far less security industry attention.
- Laundering infrastructure is now part of the attack surface. Residential proxy networks meant for ordinary traffic-blending use cases (ad verification, web scraping, geo-testing) are being repurposed as attack-traffic camouflage. Disrupting the botnet alone doesn’t address that layer.
What it means for defenders
Most organizations can’t influence how well-secured a stranger’s Android TV box is. What you can control is how your own architecture responds when volumetric attacks of this scale are the realistic threat model, not the edge case:
- Confirm your DDoS mitigation capacity is sized against multi-terabit, not multi-gigabit, assumptions — and confirm that with your provider directly rather than assuming last year’s sizing still holds.
- If your mitigation or detection logic leans on IP reputation or residential-vs-hosting heuristics, understand that proxy-laundered attack traffic is specifically designed to defeat that signal — you need behavioral and volumetric detection layers that don’t depend on source IP classification alone.
- Push for and support device-level accountability where you have any leverage — procurement standards, vendor security requirements — since the device populations feeding these botnets are consumer hardware with essentially no post-sale security lifecycle.
The attack lasted 35 seconds. The trend line behind it is the part worth tracking.
Further reading: The Hacker News, BleepingComputer, and FastNetMon’s technical breakdown.