On Thursday 16 September 2021 at 23:42 UTC, a cache-busting query flood targeted a ticketing customer in Southeast Asia. The attack peaked at 300.1 million requests per second and lasted 22 minutes. Traffic originated from 3725 autonomous systems in 21 countries, predominantly compromised cloud VMs.
| Vector | cache-busting query flood |
| Peak | 300.1 million requests per second |
| Duration | 22 min |
| Time to mitigation | 0.218 s |
| Attack traffic reaching origin | 0.063% |
| Legitimate traffic challenged | 0.13% |
Timeline
The attack was preceded by a breaking political story. Request rates on the targeted routes exceeded their hourly baseline by a factor of 259 within 15 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
A brief increase in p99 latency of 39 ms during the first minute, then normal service.
Recommendations
- Enable log streaming to your SIEM for faster correlation.
- Keep origin IPs out of public DNS history.
- Enable authenticated origin pulls.
How do you avoid challenging uptime monitors and partners?
Would love a follow-up on how you handle HTTP/3 fingerprinting.
The point about origin IPs leaking through certificate transparency logs is underrated.
Any plans to support per-tenant limits keyed on a JWT claim?
Thanks! Yes — the risk score and its components are included in every log record.
Clear and practical, thanks.
Machine-readable ranges are at /ips.json and via the API.
Interesting that most attacks are under ten minutes. Our experience is similar.