Incident report: the DDoS attack of 25 May 2026

On Monday 25 May, SiteHost received a ransom demand. This came from an actor using the name "BlackMatter" who had taken the time to sign up for an account with us. They demanded a nominal amount of Monero cryptocurrency, threatening a massive DDoS attack if we didn't pay. We had 15 minutes. We declined. Just before midday, the attack began.

What follows is the detailed account of what happened, what we did about it and what we’ve learned. Some details may be a bit vague where we have opted to protect sensitive information, for ourselves or our upstream providers.

Why didn't we pay the ransom demand?

We refused for three primary reasons:

1. Paying provides no guarantee the attack will stop, or that a new demand won't follow.
2. Capitulating to extortion helps fund further attacks against us and others.
3. The New Zealand government strongly discourages cyber-ransom payments.

We would make the same decision again.

What actually happened?

Typically a DDoS attack will originate from a large number (typically millions) of compromised devices targeting a single or perhaps a small number of targets. We have blogged previously about how we would work with you if you are targeted by a DDoS attack.

In this instance, the specific target was us, SiteHost. We saw a sudden surge in traffic to effectively every single network address on our network. Individually the volume of traffic was not insurmountable, but combined it overwhelmed a number of our, and our upstream providers’, safeguards.

Timeline (NZST)

Monday 25 May

• 11:52 — A DDoS attack was detected via monitoring alerts. Our network team opened an incident meeting within minutes and began working to identify which specific IPs were being targeted. Traffic volumes were substantial across our entire IP address space.
• 12:05 — Our network engineers struggled to identify any clear patterns in the traffic when compared to a traditional DDoS attack.
• 12:09 — First calls to upstream transit providers to coordinate mitigation.
• ~12:30 — We confirmed that the source of the traffic was widely distributed, across our entire network and coming in via a large number of remote IPs and networks. This ruled out simple edge blocking as a solution.
• ~13:00 — Mitigation applied to our network. We attempted to block traffic for unused IP space to reduce the attack surface. This was ineffective due to the sheer volume of traffic.
• ~13:15 — We began working with our upstream providers to adjust DDoS protection settings and engage scrubbing services. While our providers had DDoS scrubbing capability, the nature of the attack made it difficult for their systems to effectively distinguish attack traffic from legitimate traffic.
• ~13:30 — To get additional upstream support we engaged our secondary provider to assist. They immediately sprung into action creating their own incident response meeting with over 25 engineers, which we joined.
• 13:50 — We dropped peering sessions that were contributing to large volumes of international + unfiltered traffic being routed to our network via local Internet Exchanges (IXPs). Services routed within New Zealand stabilised.
• ~14:15 — We called the National Cyber Security Centre (NCSC) for coordination and assistance. They committed to following up via email and a return call, though immediate solutions were limited.
• ~14:30 — We further refined our traffic filtering, blocking non-essential UDP traffic. Some services began stabilising, however our upstream networks were still under load and experiencing high packet loss across their networks.
• ~15:00 — We rerouted all Sydney transit traffic through Auckland and isolated our network to our secondary provider to utilise enhanced scrubbing capabilities.
• ~15:30 — Degraded performance persisted across some parts of our network in both Australia and New Zealand. DDoS scrubbing services are still struggling with the attack.
• ~16:00 — We continued with our upstream provider to find ways to improve stability to both our network and theirs. It was agreed to bring online additional scrubbing capacity from a provider further upstream.
• ~16:30 — Additional DDoS scrubbing capacity is brought online further upstream. This is a complex change which requires an on the fly network reconfiguration to achieve. Traffic volumes to our network are greatly reduced for the first time in 4 hours.
• ~17:00 — Further tuning of DDoS mitigations takes place, and our team is now primarily focused on feedback from our customers and implementing custom mitigations where possible.
• ~17:30 — We identified that the additional scrubbing is causing significant disruption for certain sites. This depended on originating ISP and what Cloudflare node the traffic was routed through. Engineers suspect our control plane in one region has been overwhelmed due to the sheer volume of traffic. Direct server access remains functional, suggesting the issue was in the path between Cloudflare and our infrastructure. We are unable to see this path, making troubleshooting very difficult.
• 17:56 — An unplanned network outage hits our AKL02 region. While troubleshooting the above issues, our network engineers attempt to clear the control plane on a fully drained switch which resulted in a switch reload. This should not normally cause a problem, but in this instance it boots without a valid config, creating a loop in the network. This results in a total outage in AKL02.
• 18:05 — After identifying this was a hardware issue an engineer is dispatched to AKL02 with a replacement network device.
• ~18:30 — AKL02 services restored. The faulty switch is removed from the rack, and a new switch is being installed. We continue monitoring AKL02.
• 19:03 — AKL02 experienced a second outage. The control plane instability was persistent, and while trying to repair the network the active switch failed.
• 19:20 — Engineers stabilise the AKL02 switch and service is restored.
• ~20:00 — We identify a workaround for sites impacted by the specific Cloudflare network path issue above, but it requires manual configuration changes on a per customer basis. Our team starts working with individual customers who have contacted us and for whom the workaround is viable. Some ISPs such as Spark routed traffic remain largely unaffected, likely confirming the issue involves specific paths between ISPs, Cloudflare nodes, and our network.
• ~21:00 — Mitigations and improvements continue to be made across our own and upstream networks. Our team continues trying to identify ways we can improve the current DDoS scrubbing which, while keeping our network protected from the attack, comes at the cost of a high false positive rate.
• ~22:00 — The faulty AKL02 distribution has been replaced. Redundancy is fully restored. We continue to work with upstream providers and Cloudflare to obtain better visibility of the issues customers are seeing.

Tuesday 26 May

• ~01:00 — With a mitigation available for customers behind Cloudflare we believe we have resolved the highest priority issues. Our engineers are exhausted and their ability to troubleshoot further solutions is severely impaired. We make the call to stand down our New Zealand team, with our overseas teams taking over supporting our customers for the next few hours.
• ~06:30 — Our New Zealand team gathers again and starts investigating options for outstanding issues.
• ~08:30 — A meeting with our upstream network providers is scheduled for 09:30 to discuss remaining issues.
• ~09:30 — Attack volumes significantly subside allowing us to apply further tuning to the DDoS scrubbing on our network and with our upstream providers. Services from all locations and network paths gradually return to normal.
• ~11:00 — Services remain stable. We continued close monitoring and kept the status page incident open as a precaution.

The incident will rightly raise a few questions, and we have done our best to answer some below.

Don’t you have protection for this?
We do. This is the first time we have experienced a sustained and targeted attack like this. The attack was spread across our entire network and this event tested our upstream providers' capabilities as well.

What are you going to improve or do differently in the future?
Unlike a specific hardware issue, or unsuccessful failover, there are less obvious points of failure and easily identifiable improvements to make. There is also the additional factor, which of course is the group responsible for the attack. They opened an account with us, and are likely reading this report. For this reason it is difficult for us to be fully transparent about the changes we will make.

However, we want to make sure our customers understand that we know there is room for improvement, and we will be taking multiple steps to improve our resilience to attacks like these. We can’t promise it won’t happen again, no infrastructure provider can, but we can promise we will learn and improve.

Why did scrubbing make things worse for some traffic (Cloudflare path)?
DDoS protection by its nature is imperfect. The scrubbing systems are trying to rapidly differentiate between legitimate and illegitimate traffic and struggled with the scale of this attack. As many of these systems are upstream from us we have very limited control or opportunity to fine tune the filtering to suit our customer base.

While these protections kept us partially online, there are a number of areas we have identified where we think improvements can be made, and give us more agency in these situations.

Why was my site impacted when others seemed fine?
The scrubbing systems affected some IP addresses based on a set of criteria that is not transparent to us and we do not have the ability to investigate every single scenario. Simply put: DDoS scrubbing is an imperfect service and while there is room for improvement here, it did very well considering the nature and volume of the attack.

Was my server, data, account, or customer data at risk at any point?
No customer data or internal systems were at risk during this attack.

Why did your AKL02 switches fail? Isn't that on you, not the attacker?
Yes, this is on us. We were attempting to move quickly to rule out issues and made a decision to perform emergency maintenance which went wrong.

What stops this happening again next week, by the same or a copycat actor?
As much as we would like to say otherwise, nothing stops another attack of this nature, and globally they are getting more frequent and more aggressive. We can only learn from this and prepare for the next one.

Are any fixes actually deployed, or still "planned"?
Both. Our priority at the start of the week has been to keep our customers online, and now our focus has shifted towards implementing a number of short term improvements which we have done and planning a number of larger improvements as part of what we learned on Monday.

Should I put my site behind Cloudflare (or move off it) given what happened?
Cloudflare and other WAFs serve a purpose, and in many situations are helpful. However in an attack such as this they can make troubleshooting harder and sometimes near impossible. As with most things this is a tradeoff that only you can decide.

Is there anything I should change my end — DNS, VPN config, failover region?
If you’re unsure you can always get in touch to discuss, and there are always options to make your sites and infrastructure more resilient. But in general, no, we don’t think action is required at your end as a direct result of this incident.

Who do I contact next time, and how will you communicate updates?
We encourage customers to always check our status page first (sitehost-status.net) and, if possible, to subscribe for updates. This is our single, official channel for communicating during incidents like this.

Final thoughts

DDoS attacks of this nature are, unfortunately, a reality of operating internet infrastructure. This was the most significant attack we've experienced in 22 years of business, and the cascading effects, particularly the network control plane saturation and the interaction between scrubbing services and legitimate traffic (particularly Cloudflare), made it far more complex than a straightforward volumetric event against a single target.

We are genuinely grateful for the patience and support our customers showed throughout the incident. Several of you sent messages of encouragement (and doughnuts) while our team worked through the night. It meant a lot.

Lastly, I would like to say a huge thank you to the entire SiteHost team who went above and beyond during this incident. It was a true collective effort across the entire business, putting our customers first and upholding our already high support standards under what can only be described as challenging circumstances. To our partners, your support during this time truly embodied what it means to see kiwi businesses backing each other. Thank you.

If you have any questions about this incident, please don't hesitate to reach out to us at support@sitehost.nz.

Glossary

UDP (User Datagram Protocol)
A connectionless network protocol. Unlike TCP (Transmission Control Protocol), UDP does not establish a session before sending data, which makes it fast but can also be easier for attackers to abuse.

Upstream Provider
The network provider that connects our network to the wider internet. Our traffic to and from customers passes through their infrastructure, so they sit between us and most external networks.