On Monday 27 November 2023 at 21:21 UTC, a search endpoint flood targeted a online casino customer in Southeast Asia. The attack peaked at 408.4 million requests per second and lasted 129 minutes. Traffic originated from 1278 autonomous systems in 91 countries, predominantly mobile carrier ranges.
| Vector | search endpoint flood |
| Peak | 408.4 million requests per second |
| Duration | 129 min |
| Time to mitigation | 0.538 s |
| Attack traffic reaching origin | 0.037% |
| Legitimate traffic challenged | 0.48% |
Timeline
The attack was preceded by no stated motive. Request rates on the targeted routes exceeded their hourly baseline by a factor of 62 within 19 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
- Add a dedicated rate limit for the targeted route.
- Lower challenge thresholds on authentication endpoints during high-risk events.
- Enable log streaming to your SIEM for faster correlation.
Our auditors asked for exactly this kind of incident evidence under DORA.
Any plans to support per-tenant limits keyed on a JWT claim?
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Machine-readable ranges are at /ips.json and via the API.
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
This matches what we see in iGaming around big matches.
Nice to read a vendor blog that admits what went wrong.