// HACKER NEWS — CYBERSECURITY
Three Days in August: What a DDoS Attack Exposed in Our Network
On the evening of 11 August 2026, one of our customers became the target of one of the largest attacks we have ever seen directed at our infrastructure. Because we provide that customer’s connection to the internet, the impact hit us directly as well, and a few hours later the attacker turned against our own services too. We already published a technical postmortem as a PDF on this incident. In this post, we want to walk through what actually happened over those three days in more depth, why handling an attack of this size took as long as it did, and what we have changed in our infrastructure since.
To put the scale into perspective: we estimate a peak volume of 500 to 600 Gbit/s hitting our network and the affected customer across all our links combined. Two of our upstream providers confirmed 260 Gbit/s of that directly. That is several times more than our own uplinks can carry in the first place, no matter how well the defences inside our own network are set up.
Over the course of the incident, different services were affected at different times: every application on Deploio, our own website, Cockpit and our ticketing system. The word “different times” matters here. This was not a single, continuous 42 hour outage, it was a series of waves, with normal operation in between. From Tuesday evening at around 19:15 to Thursday around 12:51, these waves kept recurring, each time with shifting targets and intensity.
One thing was never in question throughout: the safety of your data. There was no unauthorised access and no compromised systems. This was an overload attack, not an intrusion.
Independent telemetry from Nokia’s Deepfield threat research team backs up our own read of events. Their sensors are registered as bots on the same botnet command-and-control (C2) servers the attackers used, so they can log the actual attack commands as they go out, not just the traffic that later lands on a target. That data shows two botnet families involved, CECbot and Katana, and confirms the sequence we saw ourselves: the attack first targeted our customer directly, and only broadened to Nine’s own infrastructure roughly three hours later, exactly what you would expect if we were hit because we provide that customer’s internet connection, not because we were the actual target.
It also surfaced a detail worth calling out on its own: our customer announces its address block through two different providers, us and one other, so anyone trying to filter or attribute this attack by looking at our network alone would only ever see half the picture. Nokia’s data does not attribute the attack to a specific actor, and neither do we.
The attackers used a technique called UDP amplification. In simple terms: you send small requests to open services on the internet, but instead of using your own address as the sender, you spoof the victim’s address. The response, which is many times larger than the original request, then lands not with the attacker but directly with the target. A relatively small amount of the attacker’s own bandwidth turns into a massive attack volume, spread across tens of thousands of sources worldwide. If you want the mechanics in detail, CISA covers the method thoroughly under “UDP-Based Amplification Attacks”.
The point that matters for everything that follows: once your own internet uplink is full, filtering inside your own network no longer helps. The packets you would want to filter out have already clogged the line by the time they reach your filter, along with all the legitimate traffic trying to use the same line. From that point on, mitigation has to happen further out, at the providers that carry the traffic to you in the first place.
The tool for that is blackholing. We ask our upstream providers to stop delivering all traffic destined for a specific address to us entirely and drop it instead. That reliably protects the whole network and every customer who has nothing to do with the attack. The cost: the affected a