Hosting provider Nine details three-day 600 Gbit/s DDoS and the network gaps it revealed

A distributed denial-of-service attack peaking at an estimated 500 to 600 Gbit/s put hosting provider Nine through three days of rolling disruptions last August. The postmortem the company has published, recently surfaced on Hacker News, doubles as a checklist of the assumptions that fail when an attack is larger than your own connectivity. According to Nine, the attack began on the evening of 11 August 2026 against one of its customers; because Nine supplies that customer's internet connection, the impact hit Nine directly, and roughly three hours later the attacker turned on Nine's own services as well.

Waves rather than one outage

Nine stresses that the incident was not one continuous outage but a series of waves between roughly 19:15 on Tuesday and 12:51 on Thursday, with shifting targets and intensity. Applications on its Deploio platform, Nine's website, its Cockpit control panel and its ticketing system were affected at different times. The company is equally clear that this was an overload attack, not an intrusion: no unauthorised access occurred and no systems were compromised. Two upstream providers confirmed 260 Gbit/s of the traffic directly, and the combined peak across all links was several times more than Nine's own uplinks can carry.

Telemetry confirms the sequence

Independent telemetry from Nokia's Deepfield threat research team, whose sensors register as bots on the command-and-control servers the attackers used and log attack commands as they are issued, backs Nine's account. It points to two botnet families, CECbot and Katana, and confirms the customer was hit first, with Nine targeted about three hours later — the pattern expected if Nine was attacked for supplying the victim's connectivity rather than being the intended target. Neither Nokia nor Nine attributes the attack to a specific actor. The telemetry also revealed a visibility trap: the customer announces its address block through two providers, so analysis based on Nine's network alone sees only half the traffic.

Saturation defeats internal filtering

The attack relied on UDP amplification: small requests with a spoofed sender address are sent to open services on the internet, and the much larger responses land on the victim. Once an uplink is saturated, filtering inside your own network no longer helps, because the packets you would drop have already clogged the line alongside legitimate traffic. Mitigation has to happen further out, at the providers carrying traffic to you.

Nine's main upstream tool was blackholing: asking providers to drop all traffic bound for a specific address. That protects the rest of the network, but the sacrificed address becomes unreachable for everyone — often, according to Nine, the real reason an application was down rather than any broken component.

The attacker also adapted. When Nine moved its website to a new IP address, it came under attack within minutes, and the sheer number of requests overloaded individual services regardless of bandwidth — a problem blackholing cannot solve because it blocks legitimate and malicious traffic alike. The fix that ended the incident was moving exposed applications behind bunny.net, a European CDN with built-in DDoS protection, starting one day in and completing the next, while the customer rolled out additional protections of its own. Attack traffic now terminates at the CDN while legitimate requests still reach Nine. Nine also credits owning its network, which let it make routing changes live rather than waiting on third-party infrastructure.

Three gaps the incident exposed

First, automated attack detection covered only Nine's own addresses, not customer-owned networks announced on the customer's behalf. The first wave hit exactly such a network and required around 90 minutes of manual mitigation; the gap was closed that same night.

Second, Nine had never systematically verified whether its blackhole signal takes effect on every path its traffic travels. The signal applies only where blackholing was pre-configured with a peer, or for traffic arriving through internet exchange route servers — direct peerings at Nine's exchanges were not covered. Nine also lacked a way to withhold a specific network from a single provider, and had to build that capability mid-attack, under load.

Third, and most uncomfortable for customers: Nine's own website runs on the same Deploio platform as customer applications, so attacking the website took unrelated applications down with it. With Cockpit and the ticketing system also targeted, some customers simultaneously lost their application, the means to manage it, and a channel to reach support.

What has changed

Nine says all three gaps are closed or actively being addressed. Every customer network it announces is now automatically part of attack detection, and its exposed applications remain permanently behind bunny.net's protection.

Why it matters

The account is a practical template for infrastructure operators. Amplification attacks can dwarf a provider's uplink capacity, making upstream mitigation non-optional and blackhole coverage something to verify path by path in advance rather than assume. Detection scope must include customer-announced prefixes, not just your own. And running your website, control panel and support systems on the same platform as customer workloads concentrates failure at the exact moment customers need information most. Finally, an attacker who retargets within minutes forces a move from blunt volume-based defences to protection that can distinguish legitimate traffic — worth arranging before an incident, not during one.