On Wednesday 30 August 2023 at 20:33 UTC, a cache-busting query flood targeted a gaming community customer in Central Europe. The attack peaked at 212.3 million requests per second and lasted 125 minutes. Traffic originated from 3090 autonomous systems in 97 countries, predominantly a rented booter service.
| Vector | cache-busting query flood |
| Peak | 212.3 million requests per second |
| Duration | 125 min |
| Time to mitigation | 0.010 s |
| Attack traffic reaching origin | 0.063% |
| Legitimate traffic challenged | 0.36% |
Timeline
The attack was preceded by a competitor’s product launch. Request rates on the targeted routes exceeded their hourly baseline by a factor of 474 within 31 seconds. The risk score of participating clients crossed the challenge threshold automatically and proof-of-work difficulty rose with origin load.
What the customer saw
The customer’s status page stayed green throughout; they learned about the attack from our notification.
Recommendations
- Enable log streaming to your SIEM for faster correlation.
- Review allow-listed partner ranges quarterly.
- Enable authenticated origin pulls.
The point about origin IPs leaking through certificate transparency logs is underrated.
Could you share the dataset behind the percentages?
Verified good bots and allow-listed partners bypass challenges entirely.
Interesting that most attacks are under ten minutes. Our experience is similar.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
The point about origin IPs leaking through certificate transparency logs is underrated.
How do you avoid challenging uptime monitors and partners?
Could you share the dataset behind the percentages?
Nice to read a vendor blog that admits what went wrong.