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.
An attack that outsized our own capacity
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.
Confirmed by outside telemetry
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.
How an attack like this actually works
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 address becomes deliberately unreachable during that time, for everyone, including genuine visitors. That was, in many cases during this incident, the actual reason an application was down. Not because something was broken, but because we sacrificed that one address to keep everything else stable.
Making things harder, the attacker did not back off. When we moved our own website to a new IP address, that new address was under attack again within minutes. And it was not just about raw volume: the sheer number of requests was enough on its own to overload individual services, regardless of bandwidth. That called for a different tool than blackholing, one that can tell legitimate traffic apart from malicious traffic instead of blocking both indiscriminately.
The way back to availability
This is where the measure that ultimately ended the incident came in. Once it was clear that blackholing alone would not hold against an attacker also targeting us by sheer request volume, we started moving our exposed applications behind bunny.net, a European CDN with built in DDoS protection, one day into the incident, and had the migration complete by the next day. Our customer evaluated and rolled out additional protection measures on their end at the same time. Since then, attack traffic terminates at the protection provider, while legitimate requests still reach us.
One thing that concretely helped us during those three days: because we operate our own network, we could make routing changes directly while the attack was still ongoing, and coordinate the additional protection measures without waiting on changes to some underlying, third-party network infrastructure. That is part of why an attack of this magnitude did not turn into a multi-day total outage.
Three gaps we found
We found three concrete gaps during this incident, and we would rather be upfront about them than gloss over them.
First, our automated attack detection was scoped only to our own addresses. Networks that we announce on the internet on a customer’s behalf, but that belong to the customer, were not part of that automation. The very first wave hit exactly such a network, which is why it took around 90 minutes of manual mitigation to contain it. We closed that gap the same night.
Second, we had never systematically verified whether our blackhole signal actually takes effect on every single path our traffic travels. That signal only applies for peers with whom blackholing was already configured in advance, or for traffic reaching us through an internet exchange’s route servers. At the internet exchanges we connect to, we have no such agreement with any of our direct peers, so blackholing there only covers traffic sent through the route servers, not traffic exchanged directly. On top of that, we did not yet have a way to withhold a specific network from just one specific provider, so we had to build that capability while the attack was still ongoing, under full load. It worked, but building a tool in the middle of an emergency is always slower and riskier than already having it ready.
Third, and this was the most uncomfortable consequence for many customers: our own website runs on the same Deploio platform as your applications. When the attack targeted our website, unrelated applications on the same platform were automatically affected too. And because Cockpit and our ticketing system were later attacked directly as well, some customers temporarily lost their application, the ability to manage it, and part of their way of reaching us, all at the same time, exactly when they needed us most.
What is different now
All three gaps are either closed or actively being worked on. Every customer network we announce is now automatically part of our attack detection, that is a fixed part of our standard process. Our exposed applications remain permanently behind bunny.net’s CDN with DDoS protection, and migrating further services is now a prepared procedure rather than something we would have to improvise under pressure. We monitor the effectiveness of our mitigations across every link now, and we work more closely with our upstream providers to do so.
And because we deliberately keep running our own services on the Deploio platform, the same one we offer our customers, rather than moving them elsewhere, we are working instead on making it more resilient. We are evolving the architecture so individual applications depend less on shared addresses. Cockpit and the ticketing system are additionally hardened, so you can reach us even during an attack. And the scenario from this incident is now a fixed part of our regular exercises, not just theory on paper.
What you can do yourself
This incident leads to one concrete recommendation for anyone running their own domains on Deploio.
Use a CNAME or ALIAS record instead of an A record. An A record ties your domain to one specific IP address on our platform. That fixed binding was exactly the problem during the attack: wherever we could change the address on short notice, availability could be restored, wherever we could not, only the blunt measure remained. On top of that, other applications are often reachable via the same shared address, which is exactly the risk described above. That is primarily an architectural issue on our end, and we are working on it. Until then, a CNAME or ALIAS is the single most effective step you can take yourself.
And wherever possible, put a CDN with its own DDoS protection in front of your application. That is precisely what restored our availability. For most setups the effort is manageable and the running cost is low.
If you are not sure which option fits your application, reach out to support@nine.ch. We are happy to work through it with you.
For the full technical sequence of events, including the exact timeline, see the official postmortem as a PDF.
In closing
We cannot fully prevent an attack of this magnitude, that is simply outside our control. What we can influence is how quickly we react and how few uninvolved customers get caught in the crossfire, and that is exactly what we have continued working on since this incident. We apologise for the inconvenience during those three days, and thank you for your patience.