Skip to content

The history of DDoS: from the 1996 Panix attack to terabit floods

· 22 min read
Copyright: MIT
history ddos networking
The letters DDoS as a large monospace wordmark with an orange flood arrow, over a faint timeline from 1996 to 2025

In September 1996, a few hundred packets per second took New York’s oldest commercial ISP offline. Thirty years later, an attack that Cloudflare clocked at 31.4 terabits per second came and went in 35 seconds. Those two numbers bracket the entire history of distributed denial of service, and the distance between them is not just bandwidth. It is a story of who owns the firepower, how the firepower is sourced, and which layer of the stack the attacker decides to exhaust. The packets-per-second math changed by twelve orders of magnitude. The underlying logic did not change at all.

Denial of service has always been about asymmetry. The attacker spends a little, the victim spends a lot, and the gap between those two costs is the whole game. A forged SYN packet is twenty bytes; the half-open connection it creates ties up state the server has to hold. A 60-byte DNS query returns a 3,000-byte answer aimed at someone else. A single HTTP/2 frame opens a stream and another cancels it before the server finishes the work it already started. This post walks the timeline. It starts with Panix and the SYN flood, moves through the 1999 handler-agent tools that put the second D in DDoS, the year-2000 attacks that made a teenager a household name, the amplification era that turned the internet’s own infrastructure into a weapon, the Mirai botnet that drafted home cameras into terabit assaults, the HTTP/2 Rapid Reset attack that broke records with 20,000 machines, and the hyper-volumetric era of 2024 and 2025. Along the way it cross-links the mechanism pieces where the wiring deserves its own page.

Before the flood: denial of service without the distribution

The earliest denial-of-service attacks were not distributed at all. One machine, one target, one bug. The Morris worm of 1988 was a denial of service by accident, crashing thousands of VAX and Sun machines because its anti-reinfection check spawned too many copies of itself. Through the early 1990s the pattern was a single host exploiting a single flaw: a malformed packet that crashed a TCP/IP stack, a teardrop fragment that a reassembly routine could not handle, a ping of death that overran a buffer. These were point attacks. Patch the bug and the attack stopped working.

There was also a class of single-host floods that did not depend on a bug, the most famous being the smurf attack. Smurf sent ICMP echo requests to a network’s broadcast address with the victim’s source address spoofed, so every host on that network answered the victim at once. It was an amplification attack before the word was common, and the fix was structural rather than per-host: routers stopped forwarding directed broadcasts by default, and the reflector population dried up. That pattern, an attack closed not by patching endpoints but by changing a default in the infrastructure, recurs over and over in this history.

The SYN flood was different, and that difference is why it still works in 2026. It does not exploit a bug. It exploits the design of TCP itself. When a client opens a connection it sends a segment with the SYN flag set. The server replies with SYN-ACK and, critically, allocates a small block of state to remember the half-finished connection while it waits for the client’s final ACK. That block sits in a fixed-size queue. The connection is in the SYN-RECEIVED state, half-open, and RFC 4987 (the IETF’s 2007 survey of the attack) describes exactly this window: the server has committed resources but has not heard back. Forge the source address so the SYN-ACK flies off to a machine that never asked for it, the final ACK never comes, and the half-open slot stays occupied until it times out. Send these faster than they time out and the queue fills. New legitimate connections get dropped not because the link is full or the CPU is pegged, but because a counter measured in low dozens has hit its ceiling.

That is the attack that hit Panix.

1996: Panix and the first SYN flood

On 6 September 1996, Panix (Public Access Networks Corporation), the third-oldest ISP in the world, came under a SYN flood that brought down its mail, news, name, and login servers. Contemporary reporting put the rate at 150 to 210 SYN packets per second with forged source addresses. By the volumetric standards of today that is nothing. It was enough. Panix’s services were degraded for days while engineers, with help from hardware vendors including Cisco, worked out how to filter the traffic, and the incident dragged in a globe-spanning group of specialists before the domains were stable again.

Two things made Panix the watershed rather than just another outage. First, the attack code was published. A few days earlier the hacker magazine Phrack had printed working SYN flood source, which turned a clever technique into a commodity that anyone could compile and point at anyone else. Sprint, EarthLink, and E-Trade saw follow-on attacks. Second, CERT responded at the protocol-advisory level rather than the patch-this-host level. CERT advisory CA-1996-21 described the attack and the available mitigations, and the longer-term answer arrived within weeks: SYN cookies, worked out by Daniel J. Bernstein and Eric Schenk, let a server validate the final ACK without holding per-connection state at all, by encoding the necessary information into the sequence number it sends in the SYN-ACK. The mechanism, its costs, and the modern variants get their own treatment in the SYN flood history piece.

Three decades of denial of service 1996 Panix SYN flood — ~200 pps 1999 Trinoo / TFN / Stacheldraht 2000 Mafiaboy — Yahoo, eBay, CNN down 2013 Spamhaus — ~300 Gbps (DNS amp) 2016 Mirai — Krebs 623 Gbps, OVH ~1 Tbps 2018 GitHub memcached — 1.35 Tbps 2023 HTTP/2 Rapid Reset 2025 — 31.4 Tbps record 1996 2025 *The scale axis here is illustrative, not linear; the point is the climb from a few hundred packets per second to tens of terabits in thirty years.*

1999: the tools that added the second D

A SYN flood from one machine has a ceiling: one uplink, one set of forged addresses, one process to kill or one route to filter. The leap to distributed denial of service was organizational rather than technical. Instead of one attacking host you coordinate hundreds, each contributing its own modest flood, and the victim faces an aggregate that no single-source filter can absorb. The software that made this practical appeared in 1999.

Trinoo (also spelled Trin00) showed up around June or July 1999 and is generally credited as the first widely analyzed DDoS tool. It used a two-tier handler-agent model: the attacker controls a small number of master/handler machines, each handler commands many agent (daemon) machines, and the agents do the actual flooding on command. Tribe Flood Network (TFN) followed, adding ICMP, SYN, and UDP flood options plus a smurf-style amplification mode, and Stacheldraht (German for barbed wire) arrived in late summer 1999 combining TFN’s attack repertoire with encrypted handler-to-agent communication so the control channel was harder to sniff. CERT publicized the tool family in mid-November 1999, and David Dittrich’s detailed teardowns of trinoo, TFN, and Stacheldraht (written at the University of Washington in late 1999) became the reference analyses that defenders read for years.

The handler-agent architecture is the direct ancestor of every botnet command-and-control design that followed. The names change (IRC channels, then HTTP polling, then peer-to-peer, then domain-generation algorithms), but the shape is the same: a small number of controllers issuing commands to a large fleet of compromised machines. The botnet history piece follows that lineage forward.

February 2000: Mafiaboy and the week the commercial web blinked

The tools were in the wild for a few months before someone aimed them at the most valuable targets on the internet. In February 2000, a 15-year-old from Quebec calling himself Mafiaboy, later identified as Michael Calce, ran a week-long campaign that knocked over the biggest names of the dot-com web. Yahoo, then the most-trafficked site on the internet, went down on 7 February for about an hour. Over the following days the attacks hit eBay, Amazon, CNN, Dell, and E-Trade. Calce did not write his own tool; he took an existing denial-of-service program and pointed roughly 200 compromised university-network machines, which had fat pipes and lax security, at one target at a time.

The damage estimates were enormous and probably soft, with figures between 1.2 and 1.7 billion US dollars thrown around at the time. The real impact was political. The notion that the largest commercial sites on the internet could be rendered unreachable by a teenager with borrowed code reached the White House and produced a cybersecurity summit. Calce was arrested that spring, and in September 2001 the Montreal Youth Court sentenced him to eight months of open custody, a year of probation, and a token fine. The attack did not exploit anything subtle. It was raw aggregate volume from a few hundred well-connected machines, and it worked because nobody on the defending side had built infrastructure to absorb a distributed flood. That infrastructure, the scrubbing centers and anycast networks, was a direct response to this era.

Mafiaboy also exposed how little attribution capability existed in 2000. Calce was caught largely because he bragged about the attacks in IRC channels and a journalist tipped off investigators, not because the forged-source traffic led anywhere on its own. Source-address spoofing was, and to a degree still is, the structural reason denial of service is hard to trace: the packets carry whatever return address the attacker chooses. The IETF’s answer was BCP 38, the 2000 best-practice document that asked networks to filter outbound packets whose source addresses could not legitimately originate from them, which would kill spoofing at the edge if every network did it. Most still do not, which is why reflection attacks remained viable for the two decades that followed.

The amplification era: turning the internet’s own servers into a cannon

Botnets gave attackers many sources. Amplification gave them leverage on top of that. The idea is simple and nasty. Find a UDP service that answers a small request with a large response, spoof the source address of your requests to be the victim, and let the service blast its oversized replies at a target that never asked for them. The attacker spends the bandwidth of the small query; the victim absorbs the bandwidth of the large answer; the ratio between them is the amplification factor.

DNS was the first big one. An open recursive resolver, of which there were tens of millions on the public internet, would answer a 60-byte query for a large zone with a response several kilobytes long. The Open Resolver Project counted 21.7 million open resolvers around 2013, an enormous reflector population that anyone could borrow.

Reflection and amplification Attacker spoofs victim IP Open resolver Open resolver Open resolver tiny queries Victim buried large replies *The attacker's queries carry the victim's source address; the reflectors answer the victim, and the response/request size ratio is the amplification.*

In March 2013 this technique hit the anti-spam organization Spamhaus in what Cloudflare titled the DDoS that almost broke the internet. The dispute was mundane: Spamhaus had blocklisted the Dutch hosting outfit CyberBunker, and a campaign linked to CyberBunker’s orbit retaliated. The attack started around 10 Gbps on 18 March, climbed to roughly 90 Gbps on 19 March, hit 120 Gbps against Cloudflare’s network by 22 March, and a major Tier 1 carrier reported seeing more than 300 Gbps of related traffic, the largest publicly reported figure at the time. The attackers sent DNS queries for a large zone (ripe.net was named in contemporaneous accounts) to open resolvers with Spamhaus’s Cloudflare-served addresses spoofed as the source, yielding roughly a hundredfold amplification. When the attackers shifted to targeting Internet Exchange Points around 23 March, the congestion was measurable at LINX in London, AMS-IX in Amsterdam, and DE-CIX in Frankfurt, which is why the breaking-the-internet headline was not pure hyperbole. The DNS amplification mechanism, reflector hygiene, and BCP 38 source-address validation get a dedicated page in the DNS amplification piece.

DNS was just the first reflector, and the years after Spamhaus turned reflector-hunting into a routine. NTP came next: the monlist command on an unpatched time server returned a list of the last several hundred hosts that had queried it, turning a small request into a large reply, and a wave of NTP amplification attacks in late 2013 and early 2014 reached comparable volumes before operators patched and firewalled the service. SSDP, the discovery protocol on consumer routers and smart devices, became a reflector when those devices answered M-SEARCH probes from the public internet. CLDAP, a connectionless variant of LDAP, joined the list with a high ratio of its own. Each new reflector followed the same arc: discovery, a burst of record-setting attacks, then a coordinated cleanup as operators closed the service or rate-limited the port, shrinking the usable population. The amplification factors varied from a handful for some services to thousands for others, and the most extreme was memcached.

2018: GitHub, memcached, and the 1.35 Tbps single-vector record

Memcached is an in-memory key-value cache. It was never meant to face the public internet, but tens of thousands of instances did, with UDP enabled on port 11211 and no authentication. Store a large value, then ask for it with a spoofed source address, and the response dwarfs the request. Cloudflare’s analysis put the amplification factor at up to 51,000, the highest of any reflector observed: a kilobyte of request could return tens of megabytes of reply.

On 28 February 2018, GitHub took the full force of it. GitHub’s own incident report records the peak at 1.35 Tbps carried by 126.9 million packets per second, traffic that came from over a thousand autonomous systems and tens of thousands of endpoints. GitHub.com was fully down from 17:21 to 17:26 UTC and intermittently unreachable until 17:30. The mitigation was to move all traffic to a scrubbing provider: GitHub withdrew its BGP announcements over its transit providers and announced its prefix exclusively over its links to Akamai Prolexic, whose scrubbing centers had the capacity to absorb and filter the flood. Recovery came inside about nine minutes from detection. A secondary spike of around 400 Gbps came in after 18:00. The fix at internet scale was equally direct: operators rate-limited or filtered UDP/11211, and the reflector population shrank fast. Amplification’s weakness is that the reflectors are known infrastructure, and once the world notices, the world closes the door. The memcached episode and its arithmetic get their own page in the memcached amplification piece.

2016: Mirai and the day the things fought back

Amplification borrowed other people’s servers. Mirai built its own army out of the cheapest hardware on earth. In 2016 a botnet assembled from IP cameras, DVRs, and home routers, devices with embedded Linux and default passwords nobody ever changed, produced the largest attacks the internet had seen and did it from devices their owners did not know were participating.

Mirai’s propagation was almost insultingly simple. It scanned the internet for open Telnet, and when it found a login prompt it tried a fixed list of well-known default credential pairs (Cloudflare’s retrospective puts the dictionary at 64 combinations). Cheap consumer gear shipped with admin/admin, root/root, and a handful of vendor-specific defaults baked in, and millions of those devices sat on residential connections with the management port exposed. A hit meant another bot. The numbers got large fast.

Mirai infection loop Scan Telnet :23 / :2323 Try 64 default credentials Infect device Report to C2, await command new bot scans for more *Mirai's whole edge was reach, not sophistication; a 64-entry credential list against millions of unpatched devices.*

The attacks came in a cluster in late 2016. On 20 September, Brian Krebs’s security blog was hit with what his telemetry put at 623 Gbps, large enough that Akamai, which had been hosting his site pro bono, decided it could no longer absorb the cost and dropped protection. Days later the French host OVH reported attacks exceeding 1 Tbps, the largest on public record then, from a botnet of roughly 145,000 compromised cameras and routers. Then on 21 October, a Mirai variant turned on Dyn, a managed DNS provider, and because so much of the web resolved through Dyn, the collateral damage took down Twitter, Spotify, Reddit, GitHub, Netflix, and others for users across the eastern United States. Researchers later concluded the Dyn attack was probably not aimed at the internet at large but at gaming infrastructure, with the rest of the web as collateral.

On 30 September 2016, between the OVH and Dyn attacks, someone using the handle Anna-senpai posted Mirai’s source code on a hacking forum. That release is the reason Mirai never really ended. Dozens of variants spawned from the leaked code, each tweaking the credential list, the exploit set, or the attack vectors, and Mirai-derived families still account for a meaningful slice of botnet traffic today. The original co-authors, Paras Jha and Josiah White, pleaded guilty in US federal court in December 2017. Mirai’s mechanics, its variants, and the IoT-security failure that fed it get a full treatment in the Mirai piece.

2023: HTTP/2 Rapid Reset and the return of asymmetry

The volumetric records kept climbing, but in 2023 a different kind of attack reminded everyone that the cleverest denial of service is not the biggest. On 10 October 2023, Google, AWS, and Cloudflare jointly disclosed CVE-2023-44487, the HTTP/2 Rapid Reset attack, which had been exploited in the wild since late August. It set request-rate records with a botnet of about 20,000 machines, a rounding error compared to Mirai’s hundreds of thousands.

The trick lives in HTTP/2’s stream multiplexing. A single HTTP/2 connection carries many concurrent requests, each on its own stream, and the server caps how many can be open at once via the SETTINGS_MAX_CONCURRENT_STREAMS parameter. The protocol also lets a client cancel a stream at any time by sending a RST_STREAM frame. Here is the asymmetry. When a client opens a stream and immediately sends RST_STREAM, the stream is torn down on the wire instantly, which frees the client to open another in its place right away, but the server has often already started the expensive work the request kicked off: routing, backend calls, allocation. The client pays the cost of two small frames. The server pays the cost of a full request it will never get to finish answering. Multiply by tens of thousands of open-and-cancel cycles per connection per second and a tiny botnet generates a request rate that buries the backend.

HTTP/2 Rapid Reset (CVE-2023-44487) Attacker Server HEADERS (open stream N) RST_STREAM (cancel N) work already started here slot frees instantly — open stream N+2, repeat *The cancel frees the concurrency slot on the wire while the server keeps paying for work it already began. The cost is lopsided in the attacker's favor.*

Cloudflare’s attack peaked just above 201 million requests per second, nearly three times its previous record of around 71 million. Google measured a peak of 398 million requests per second. Because the flaw is in how servers handle a legal protocol feature rather than in any one product, every HTTP/2 implementation was affected, and the fix was server-side: cap or count reset streams, and drop connections that abuse the open-and-reset pattern. Rapid Reset belongs to the broader family of application-layer attacks, where the goal is to exhaust backend work rather than link bandwidth, covered in the Layer 7 DDoS piece and dissected frame by frame in the Rapid Reset piece.

2024 and 2025: the hyper-volumetric era

Then the volumetric records went vertical again. The supply of firepower changed: not home routers this time but compromised cloud instances, virtual private servers, and a new generation of infected consumer devices including Android-based TV boxes with stronger uplinks than the cameras of the Mirai era. Cloudflare began describing attacks above 1 Tbps, 1 billion packets per second, or 1 million requests per second as hyper-volumetric, and the count of those attacks climbed quarter over quarter through 2024 and 2025.

The headline numbers from Cloudflare’s 2025 Q4 threat report are stark. Total DDoS attacks mitigated more than doubled to 47.1 million for the year, a 236% jump from 2023. Network-layer attacks roughly tripled year over year. Hyper-volumetric attack sizes grew over 700% compared to the large attacks of late 2024. The single largest attack on record reached 31.4 Tbps and lasted 35 seconds, attributed to a botnet Cloudflare named in connection with the Aisuru family running on infected Android TV devices. Earlier in the year the public records had already stepped through 3.8 Tbps, then 7.3 Tbps, then 11.5 Tbps, each one briefly the largest ever disclosed before the next eclipsed it.

Public peak records, terabits per second 2018 1.35 2024 3.8 2025 H1 7.3 2025 Q3 11.5 2025 Q4 31.4 *Heights are scaled to the peak figures; the 31.4 Tbps record dwarfs the 1.35 Tbps that was the headline only seven years earlier.*

Two details about the 31.4 Tbps record are worth holding onto. It lasted 35 seconds, and it was absorbed automatically. The duration matters because hyper-volumetric attacks are increasingly short and sharp, designed to overwhelm before a human can respond, which is why automated mitigation at the edge has become the only viable defense. The absorption matters because it shows where the defensive center of gravity moved. No single origin server, and almost no single data center, can stand in front of tens of terabits. The mitigation lives in anycast networks that spread the load across hundreds of points of presence so that an attack aimed at one address is divided across the planet’s worth of capacity. How that works is the subject of the CDN volumetric absorption piece and, more broadly, the history of Cloudflare, the company whose Spamhaus and Rapid Reset write-ups supply much of the primary record for this era.

What stayed the same

Read the timeline end to end and the technology looks unrecognizable from one decade to the next. Panix faced a single host forging SYN packets at a couple hundred per second. The 2025 record was tens of thousands of compromised Android TV boxes pushing 31.4 terabits. In between, the firepower moved from one machine to handler-agent fleets, from fleets to amplification through the internet’s own open infrastructure, from open resolvers to drafted IoT cameras, and from cameras to compromised cloud instances. Each shift was a change in where the cheap power came from, and each one made the previous defensive assumption obsolete.

But the logic never moved. Every attack on this list is the same trade dressed in different clothes: spend a little on the attacking side, force the defending side to spend a lot, and aim the imbalance at whichever resource is scarcest. For Panix it was a fixed-size connection queue. For the amplifiers it was the victim’s downlink, paid for with the attacker’s far smaller uplink. For Rapid Reset it was backend request-handling capacity, exhausted by frames that cost almost nothing to send. The defenses that work are the ones that attack the asymmetry directly: SYN cookies that refuse to hold state, source-address validation that makes spoofing harder, reflector hygiene that closes the open services, and anycast that turns one victim address into a planet-sized sponge. The attacks that keep working are the ones where the imbalance has not yet been closed.

The thirty-year arc says something uncomfortable about the next number. Records used to fall every few years. In 2025 they fell every few months, and the largest one was over before a pager could finish buzzing. The bandwidth ceiling is no longer set by what attackers can muster. It is set by what defenders can absorb without noticing, and for now that line is still moving up fast enough to keep pace. The day it stops is the day the asymmetry wins.

Sources & further reading

Further reading