On Monday 16 September 2024 at 11:29 UTC, a login endpoint flood targeted a fashion retail customer in the UK. The attack peaked at 101.4 million requests per second and lasted 137 minutes. Traffic originated from 3875 autonomous systems in 108 countries, predominantly a rented booter service.
| Vector | login endpoint flood |
| Peak | 101.4 million requests per second |
| Duration | 137 min |
| Time to mitigation | 0.876 s |
| Attack traffic reaching origin | 0.085% |
| Legitimate traffic challenged | 0.11% |
Timeline
The attack was preceded by no stated motive. Request rates on the targeted routes exceeded their hourly baseline by a factor of 123 within 25 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
No customer-visible impact. The on-call engineer was notified and acknowledged the incident from the dashboard.
Recommendations
- Enable log streaming to your SIEM for faster correlation.
- Keep origin IPs out of public DNS history.
- Review allow-listed partner ranges quarterly.
This matches what we see in iGaming around big matches.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Any plans to support per-tenant limits keyed on a JWT claim?