On Friday 11 April 2025 at 17:20 UTC, a UDP reflection (NTP) targeted a tax authority portal customer in the Benelux. The attack peaked at 143.8 Gbps and lasted 140 minutes. Traffic originated from 985 autonomous systems in 31 countries, predominantly a rented booter service.
| Vector | UDP reflection (NTP) |
| Peak | 143.8 Gbps |
| Duration | 140 min |
| Time to mitigation | 0.189 s |
| Attack traffic reaching origin | 0.019% |
| Legitimate traffic challenged | 0.34% |
Timeline
The attack was preceded by a ransom note demanding payment in Monero. Edge packet filters identified the flood by source port and payload signature and dropped it at line rate across 30 points of presence.
What the customer saw
The customer’s status page stayed green throughout; they learned about the attack from our notification.
Recommendations
- Keep origin IPs out of public DNS history.
- Enable authenticated origin pulls.
- Review allow-listed partner ranges quarterly.
Is the risk score exposed in the logs so we can build our own dashboards on it?
How do you avoid challenging uptime monitors and partners?
This matches what we see in iGaming around big matches.
Nice to read a vendor blog that admits what went wrong.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Could you share the dataset behind the percentages?
Is the risk score exposed in the logs so we can build our own dashboards on it?
Interesting that most attacks are under ten minutes. Our experience is similar.